Tech Arch

ADCO
Technology Architecture
411510471.doc/ADCO Technology Architecture

Printed 10/03/2019 10/03/2019 Page 1
Table of Contents
TABLE OF CONTENTS...........................................................................................................................
PREFACE TO THE TECHNOLOGY ARCHITECTURE...................................................................

DESCRIPTION................................................................................................................................................
LIMITATIONS.................................................................................................................................................
APPROACH....................................................................................................................................................
EVOLUTION OF THE TECHNOLOGY ARCHITECTURE......................................................................................
SECTION 1 - VISION AND SCOPE.......................................................................................................
BUSINESS PROBLEM......................................................................................................................................
The need for a Technology Architecture..................................................................................................
USER PROFILE...............................................................................................................................................
Who is affected by the Technology Architecture?...................................................................................
VISION AND SCOPE.......................................................................................................................................
SECTION 2 - FEATURES AND BENEFITS..........................................................................................
FEATURES......................................................................................................................................................
Simplicity.................................................................................................................................................
Classify Components...............................................................................................................................
Integration...............................................................................................................................................
Absorb Change........................................................................................................................................
Provides a platform for distributed applications....................................................................................
Integrated Systems...................................................................................................................................
BENEFITS......................................................................................................................................................
Location Transparency............................................................................................................................
Single System Image................................................................................................................................
Reuse existing IT infrastructure..............................................................................................................
Flexibility to adapt to changing IT and Business strategies (management of change)........................
Management of Risk................................................................................................................................
SECTION 3 - A SOFTWARE TECHNOLOGY INFRASTRUCTURE MODEL..............................
THE NEED FOR A MODEL...............................................................................................................................
DESCRIPTION OF THE MODEL........................................................................................................................
DOMAINS......................................................................................................................................................
The Application Domain..........................................................................................................................
The Support Domain................................................................................................................................
The Control Domain................................................................................................................................
The Infrastructure Management Domain................................................................................................
CONTENT OF THE DOMAINS.........................................................................................................................
RULES OF THE MODEL..................................................................................................................................
General Rules..........................................................................................................................................
Domain Rules...........................................................................................................................................
Application Domain Rules.......................................................................................................................
Support Services Domain Rules..............................................................................................................
Control Domain Rules.............................................................................................................................
Infrastructure Domain Rules...................................................................................................................
SECTION 4 - FACTORS FOR SUCCESSFUL IMPLEMENTATION................................................
ORGANISATIONAL SUCCESS FACTORS...........................................................................................................
TECHNICAL SUCCESS FACTORS.....................................................................................................................
Global naming conventions.....................................................................................................................
Minimum Set of Functionality.................................................................................................................
RULES FOR IMPLEMENTATION OF THE CLIENT-SERVER MODEL...................................................................
DISTRIBUTION...............................................................................................................................................
Distribution defined.................................................................................................................................
Processors/Processing........................................................................................................................................
Data....................................................................................................................................................................
Control...............................................................................................................................................................
Distribution Rules....................................................................................................................................

Printed 10/03/2019 10/03/2019 Page 2
Processors/Processing........................................................................................................................................
Data....................................................................................................................................................................
Control...............................................................................................................................................................
INTEGRATION................................................................................................................................................
Integration defined..................................................................................................................................
Application Integration.......................................................................................................................................
Systems Integration............................................................................................................................................
Integration Criteria.................................................................................................................................
Completeness (Functional Equivalence)............................................................................................................
Compatibility......................................................................................................................................................
Portability...........................................................................................................................................................
Integration Rules.....................................................................................................................................
Portability...........................................................................................................................................................
User Interface.....................................................................................................................................................
Common Data Formats.......................................................................................................................................
Programming Interface.......................................................................................................................................
INTERFACE MANAGEMENT............................................................................................................................
Choices for Interface standards..............................................................................................................
Methods of managing an interface..........................................................................................................
Conclusion...............................................................................................................................................
SUMMARY.....................................................................................................................................................
SECTION 5 - USE OF THE TECHNOLOGY ARCHITECTURE......................................................
STEP 1 - ANALYSE REQUIREMENTS...............................................................................................................
Purpose....................................................................................................................................................
Deliverables.............................................................................................................................................
Inputs........................................................................................................................................................
Process.....................................................................................................................................................
STEP 2 - ANALYSE DOMAIN INTER-DEPENDENCIES.....................................................................................
Purpose....................................................................................................................................................
Deliverables.............................................................................................................................................
Inputs........................................................................................................................................................
Process.....................................................................................................................................................
STEP 3 - SPECIFY FUNCTIONALITY REQUIRED..............................................................................................
Purpose....................................................................................................................................................
Deliverables.............................................................................................................................................
Inputs........................................................................................................................................................
Process.....................................................................................................................................................
STEP 4 - IDENTIFY REUSABLE INFORMATION TECHNOLOGY........................................................................
Purpose....................................................................................................................................................
Deliverables.............................................................................................................................................
Inputs........................................................................................................................................................
Process.....................................................................................................................................................
STEP 5 - BUY OR BUILD SOLUTION..............................................................................................................
Purpose....................................................................................................................................................
Deliverables.............................................................................................................................................
Inputs........................................................................................................................................................
Process.....................................................................................................................................................
SECTION 6 - NEXT STEPS.....................................................................................................................
APPENDIX A.............................................................................................................................................
ENTERPRISE PROFILE.........................................................................................................................
ENTERPRISE BUSINESS PROFILE....................................................................................................................
ENTERPRISE TECHNOLOGY PROFILE.............................................................................................................
APPENDIX C.............................................................................................................................................
SOFTWARE COMPONENTS WITHIN DOMAINS............................................................................

CONTROL DOMAIN COMPONENTS................................................................................................................
Resource Management Services..............................................................................................................
Specific Rules....................................................................................................................................................

Printed 10/03/2019 10/03/2019 Page 3
-..........................................................................................................................................................................
Functionality......................................................................................................................................................
Inter-dependencies.............................................................................................................................................
Security Services......................................................................................................................................
Specific Rules....................................................................................................................................................
Functionality......................................................................................................................................................
Inter-Dependencies.............................................................................................................................................
Directory Services....................................................................................................................................
Specific Rules....................................................................................................................................................
Functionality......................................................................................................................................................
Replication (Change Propagation) Services...........................................................................................
Specific Rules....................................................................................................................................................
Functionality......................................................................................................................................................
SUPPORT DOMAIN COMPONENTS..................................................................................................................
Image Services.........................................................................................................................................
Workflow Management Services..............................................................................................................
Workgroup Services.................................................................................................................................
File and Print Services............................................................................................................................
Database Gateway Services....................................................................................................................
Mail Gateway Services............................................................................................................................
SNA Gateway Services.............................................................................................................................
LAN Protocol...........................................................................................................................................
WAN Protocol...........................................................................................................................................
Data Distribution Services......................................................................................................................
Specific Rules....................................................................................................................................................
Functionality......................................................................................................................................................
Data Interchange Services.......................................................................................................................
Specific Rules....................................................................................................................................................
Functionality......................................................................................................................................................
Data Content Services.............................................................................................................................
Specific Rules....................................................................................................................................................
Functionality......................................................................................................................................................
Object Storage Services...........................................................................................................................
Specific Rules....................................................................................................................................................
Functionality......................................................................................................................................................
Messaging Services..................................................................................................................................
Specific Rules....................................................................................................................................................
Functionality......................................................................................................................................................
Inter-Process Communications Services.................................................................................................
Specific Rules....................................................................................................................................................
Functionality......................................................................................................................................................
Display (Presentation) Services...............................................................................................................
Specific Rules....................................................................................................................................................
Functionality......................................................................................................................................................
System Services........................................................................................................................................
Specific Rules....................................................................................................................................................
Functionality......................................................................................................................................................
APPLICATION DOMAIN COMPONENTS...........................................................................................................
Database API...........................................................................................................................................
Operating System Services API...............................................................................................................
Messaging API.........................................................................................................................................
Software Component Interface................................................................................................................
Communications API...............................................................................................................................
Object Storage API..................................................................................................................................
INFRASTRUCTURE MANAGEMENT DOMAIN COMPONENTS...........................................................................
Network Management Interface..............................................................................................................

Printed 10/03/2019 10/03/2019 Page 4
Inventory Management Interface............................................................................................................
Software Distribution Management Interface.........................................................................................
Configuration Management Interface.....................................................................................................
NETWORK EVENT SERVICES.........................................................................................................................
Specific Rules....................................................................................................................................................
Functionality......................................................................................................................................................
Inventory Management Services.............................................................................................................
Specific Rules....................................................................................................................................................
Functionality......................................................................................................................................................
APPENDIX C.............................................................................................................................................
APPENDIX C1....................................................................................................................................
The relationship of the Technology Architecture to Microsoft’s Technology Architectures...................
Mapping of Technology Infrastructure Components to Microsoft technology....................................................
Distribution........................................................................................................................................................
Integration Criteria.............................................................................................................................................
Single System Image..........................................................................................................................................
Technical Success Factors..................................................................................................................................
Summary............................................................................................................................................................
APPENDIX C2....................................................................................................................................
The relationship of the Technology Architecture to IBM’s Technology Architecture.............................
APPENDIX C3....................................................................................................................................
The relationship of the Technology Architecture to Sun Microsystems’ Technology Architecture.........
APPENDIX C4....................................................................................................................................
The relationship of the Technology Architecture to Hewlett Packard’s Technology Architecture.........
APPENDIX C5....................................................................................................................................
The relationship of the Technology Architecture to Digital Equipment Corporation’s Technology
Architecture..............................................................................................................................................
APPENDIX C6....................................................................................................................................
The relationship of the Technology Architecture to Novell’s Technology Architecture..........................
APPENDIX D.............................................................................................................................................
MODELS....................................................................................................................................................
THE CLIENT-SERVER MODEL...........................................................................................................

Client -Server Technology Misconceptions........................................................................................................
A MODEL OF A SUB-OPTIMISED TECHNOLOGY INFRASTRUCTURE....................................
A MODEL OF A UNIFIED TECHNOLOGY INFRASTRUCTURE...................................................
A MODEL OF TECHNOLOGY OWNERSHIP....................................................................................
APPENDIX E.............................................................................................................................................
SAMPLE SERVICE DEFINITION TEMPLATE..................................................................................
APPENDIX F..............................................................................................................................................
SAMPLE TEMPLATE FOR HARDWARE, SOFTWARE & API STANDARDS..............................

NETWORK COMMUNICATIONS PROTOCOL FOR LANS...................................................................
HARDWARE SPECIFICATIONS.........................................................................................................
Workstation Types....................................................................................................................................
Workstation Technical Specifications by Type........................................................................................
Notes..................................................................................................................................................................
General...............................................................................................................................................................
Type A................................................................................................................................................................
Types B and C....................................................................................................................................................
SERVER TYPES..............................................................................................................................................
NOTEBOOKS..................................................................................................................................................

Printed 10/03/2019 10/03/2019 Page 5
Network connection of Notebooks...........................................................................................................
PRINTERS......................................................................................................................................................
SOFTWARE SPECIFICATIONS..........................................................................................................
Desktop Operating Systems.....................................................................................................................
Server Operating System.........................................................................................................................
Software Services.....................................................................................................................................
Notes..................................................................................................................................................................
(1) MS-Mail Gateway........................................................................................................................................
Office Automation Applications..............................................................................................................
PC Application Development Languages & Tools..................................................................................
Tools.........................................................................................................................................................
Application Programming Interface (API) Standards.............................................................................
Windows Operating System API Standards.............................................................................................
WOSA APPLICATION PROGRAMMING INTERFACES (API'S) STANDARDS......................................................
CD-ROM'S...................................................................................................................................................
STANDARD WORKSTATION CONFIGURATIONS BY TYPE...........................................................
Usage by Workstation type......................................................................................................................
Software Components by Workstation Type.............................................................................................
Notes..................................................................................................................................................................
General...............................................................................................................................................................
SERVER CONFIGURATIONS AND LOCATIONS..............................................................................
Standard Server Configurations..............................................................................................................
Notes..................................................................................................................................................................
(1) Microsoft Exchange Server..........................................................................................................................
(2) Database Gateways.......................................................................................................................................
Server Deployment Scheme.....................................................................................................................
Notes..................................................................................................................................................................
(1) District Offices.............................................................................................................................................
(2) Printing.........................................................................................................................................................
TECHNICAL ISSUES TO BE RESOLVED..........................................................................................
APPENDIX G.............................................................................................................................................
IT/IS PRINCIPLES FOR STANDARDISATION AND MANAGEMENT OF NON-

CONFORMING SOLUTIONS................................................................................................................
PC/LAN TECHNOLOGY MANAGEMENT PRINCIPLES................................................................

THE LAN WORKSTATION PLATFORM WILL BE STANDARD AND MAY NOT BE COMPROMISED........................
Business Impacts......................................................................................................................................
THE SERVER PLATFORM WILL BE STANDARD, CENTRALLY MANAGED AND DISTRIBUTED WITHIN THE
NETWORK......................................................................................................................................................
Description...............................................................................................................................................
LAN-BASED SOFTWARE SERVICES WILL BE STANDARD, CENTRALLY MANAGED, AND DISTRIBUTED
WITHIN THE NETWORK..................................................................................................................................
Description...............................................................................................................................................
REMOTE MANAGEMENT OF SERVERS AND WORKSTATIONS..........................................................................
Description...............................................................................................................................................
REMOTE SOFTWARE INSTALLATION, CONFIGURATION AND DISTRIBUTION (CID)........................................
Description...............................................................................................................................................
VENDOR SOLUTIONS WILL CONFORM TO OUR LAN INFRASTRUCTURE STANDARDS.....................................
Description...............................................................................................................................................
Workstations.......................................................................................................................................................
Servers and Services..........................................................................................................................................
FLEXIBILITY/CONSTRAINTS..........................................................................................................................
Description...............................................................................................................................................
ILLUSTRATIONS.............................................................................................................................................

Printed 10/03/2019 10/03/2019 Page 6
Preface to the Technology Architecture
Description
This Technology Architecture is one of four architectural components that comprise the Enterprise
Architecture. This Technology Architecture is a logical view of the physical Technology
Infrastructure in that it describes a Technology Infrastructure independent of any vendor’s products,
or open, proprietary or private standards. Where specific names and/or standards are used, they are
used solely to illustrate a concept.
A Technology Infrastructure is the physical set of all software and hardware components and a
Technology Architecture is a description of those software and hardware components with rules for
their acquisition, standards and guidelines. A design specifies how the components are arranged, and
specifies which one of many available models (e.g. modular, peer-to-peer, component-based, star, bus,
ring, client-server, distributed, heterogeneous, homogeneous, and so on) will be used to define their
arrangement. Put another way, a Technology Architecture defines the what, a Design defines the how,
and a Technology Infrastructure represents the implementation of the architecture and design.
We use the term “Technology Infrastructure” to define one dimension of an “IT Infrastructure”, which
includes Human Resources, Organisational Structure, Technology, Finance, and so on.
Limitations
This is a software Technology Architecture. No statements or assumptions are made about hardware
or network architectures. A hardware architecture must consider technology trends in CPU’s, BIOS
plug and play, RAM, symmetric multi-processors, storage media (magnetic, optical), disk
management (raid, mirroring), Bus technology, display technology, and so on to arrive at a blueprint
for hardware acquisition. There is a great deal of confusion caused by the term “network
architecture”. The term is commonly used to mean network design. To illustrate this point, contrast
the content of IBM’s SNA Concepts and Facilities documentation with an SNA network design. The
former defines logical concepts (e.g. Logical Unit, Physical Unit), whereas the latter defines the type
and arrangement of physical devices (e.g. network front-end processors, cluster controllers).
Approach
The approach taken is to develop and discuss the concepts and rules necessary for a Technology
Architecture to be able to define a Technology Infrastructure that supports applications built to the
client-server model, operating in a heterogeneous computing environment. Depending on the target
computing environment and the degree of heterogeneity required, some of the concepts and rules
might seem idealistic; however, we maintain that these concepts and rules are necessary for the
creation of a truly distributed, heterogeneous computing environment. In practice, the degree to
which a distributed heterogeneous Technology Infrastructure can be created is influenced by software
vendors and the choices made by the enterprise. This Technology Architecture is a blueprint against
which software technology can be evaluated for its adherence to the standards and criteria chosen by
the enterprise.
The Technology Architecture is described in six sections and a number of appendices. The first
section describes the Business Problem to be solved by the Technology Architecture; the User Profiles
of the users of the Technology Infrastructure, and the Vision and Scope. The second section describes
the Features and Benefits of the Technology Architecture. The third section describes a model of a
Technology Infrastructure which serves as a tool for managing the content of a Technology
Infrastructure. The fourth section, Criteria, describes the criteria for achieving an integrated
heterogeneous computing environment. The fifth section describes how to use the model of a
Technology Infrastructure to cater for changing functionality, reuse and technology acquisition. The
sixth section discusses the next steps that ADCO can take to migrate to a distributed, heterogeneous
computing environment.
The most volatile aspects of a Technology Architecture are contained in the appendices. Appendix A
provides a template for Enterprise Business and Technology Profiles.
Appendix B names the services required in a Technology Infrastructure. Appendix C is divided into
parts (C1, C2,...., Cn). Each part describes a mapping of a particular vendor’s technology architecture
to the Technology Architecture model described in section three. Appendix D contains a number of

Printed 10/03/2019 10/03/2019 Page 7
illustrations or models to aid in understanding and dealing with issues that arise during any
discussion of a Technology Infrastructure for client-server applications. More than one model is
needed for communication of the Technology Infrastructure because the Technology Infrastructure can
be viewed from many perspectives and by different types of user. These models can be used as tools to
manage facilitate discussion of the Technology Infrastructure for technology acquisition, evolution of
the Technology Infrastructure, and technology ownership. Appendix E contains a sample template for
specifying the required services of a software component. Appendix F contains
Evolution of the Technology Architecture

It is envisaged that Appendix C will be expanded in future architecture activities as business plans are
linked to the Technology Infrastructure by this Technology Architecture.
It is envisaged that the second and third sections of the Technology Architecture may change when
component-based software becomes commercially viable for enterprise-wide use.
Appendix C will change as vendor’s introduce new technology architectures; as the industry defines
new technology architectures; and as the enterprise adopts new technology. A high-level mapping of
Microsoft’s Technology Architectures to the model of section three is provided. It is recommended
that these appendices are completed in more detail before implementation of a Technology
Infrastructure in support of applications based on the client-server model. It is envisaged that new
sections (Appendix C2,...,Cn) will be added in future architecture activities to map a variety of
vendor’s technologies (e.g. IBM, Sun Microsystems, Hewlett Packard, DEC, Novell) to this
Technology Architecture.

Printed 10/03/2019 10/03/2019 Page 8
Section 1 - Vision and Scope
Business Problem
The diversity of available hardware and software, the changing needs of business, and decentralised
and autonomous decision-making processes for technology acquisition can combine to sub-optimise
the enterprise technology infrastructure.
Business Application Human Strategic

Technology
Processes Portfolios Resources Management
TECHNOLOGY TECHNOLOGY
TECHNOLOGY
TECHNOLOGY
TECHNOLOGY
TECHNOLOGY
TECHNOLOGY
Figure 1: A sub-optimised technology infrastructure
Each organisational unit perceives a benefit, whilst the benefits to the enterprise are lessened. The
measures of benefit to the enterprise might be capital expenditure for perceived benefit; the ability to
obtain information about the enterprise from existing systems; the ability to deploy systems which
cross organisational boundaries (“enterprise applications”, typically cross-functional applications).
The problem for IT Management is to manage the degree of diversity, type and rate of change of an
enterprise technology infrastructure to meet the business objectives of the enterprise, without
constraining the business.
The need for a Technology Architecture

A Technology Infrastructure without governance results in a decrease in effectiveness of information
technology because there is no process or tool to assess, evaluate and manage the impacts of the
different drivers on the technology infrastructure.

Printed 10/03/2019 10/03/2019 Page 9
By governance we mean the management (planning, organising, leading and controlling) of the
technology infrastructure. Typically the management of an Enterprise Technology Infrastructure is
focused on efficiency (e.g. optimisation, tuning). Governance provides direction for the evolution of
the technology infrastructure to achieve integration and consistency and results in a unified
Technology Infrastructure.
The Technology Architecture is the link between business IS plans and the development of the

Technology
TECHNOLOGY
INFRASTRUCTURE
Technology Infrastructure. A Technology Architecture provides IT Management with a tool to

exercise governance on behalf of the enterprise.

Printed 10/03/2019 10/03/2019 Page 10
Technology
SOFTWARE TECHNOLOGY
ARCHITECTURE
SOFTWARE TECHNOLOGY
INFRASTRUCTURE
Figure 2: Software technology architecture as a link
User Profile
Almost every employee in a enterprise is a user of information technology. The stakeholders in
information technology are executive management, business units and the information technology
division. These stakeholders are represented by executive management, line management and
influential end users.
Who is affected by the Technology Architecture?

There are different levels of users of the Technology Infrastructure, and the Technology Architecture
affects them in different ways. The levels of users are:
· End-Users (Level-4 Users)
An End-User is not normally an IT professional. These users use the Technology
Infrastructure as a tool to accomplish their work. End-Users may be clerks, supervisors,
managers, executives or business professionals.
· End-User (Product) Support (Level-3 Users)
An End-User Supporter may or may not be an IT professional (End-Users often play the
informal role of End-User Supporter when they are recognised as “power users”). In a
formal role of End-User Supporter, these users spend some or all of their time supporting the
use and exploitation of the Technology Infrastructure (usually in the form of package and tool
support) and are located in an End-User Support Centre or at a “Help Desk”.
· Systems Developer (Solutions Developers and Component Builders)(Level-2 Users)
Systems Developers includes Solutions Developers and Component Builders. They are IT
professionals who specialise in software development, and this class includes systems designers,
database designers, systems architects, contract programmers, external consultants, and so on.

Printed 10/03/2019 10/03/2019 Page 11
They are usually responsible for the development of business solutions or reusable business
components for a broad range of users throughout the enterprise.
· Technical Specialist (Level-1 users)
Technical Specialists are trained to install, configure, support and operate:
· Software services (e.g. TP Monitors, Database Management Systems)
· Software products (e.g. an Operating System, a General Ledger package)
· Hardware (e.g. a mainframe, desktop PC, Server, disk drives, tape drives, CD-ROM drives)
· Networks (e.g. Cabling, Network Processors, Protocols, Statmux’s, Modems, Routers,
Bridges).
· Infrastructure Management tools (e.g. Storage Management, Network Management).
Technical Specialist differ from End-User Product Supporters in that they specialise in systems
software support.
Their views of technology are different; they are:
View
User
Technology Infrastructure
End User
· The view presented through a
dumb terminal or desktop PC
or workstation
· Business Packages
· End-User Tools
· End-User (Product) Support · Business packages
· End-user tools (e.g. Personal
productivity applications)
· Desktop PC or Workstation
Application Architecture
· Systems Developer · Application Models
· APIs
· Operating System Services
· User Interface Services
· File & Database Services
· Messaging Services
· Component (Object)
Interfaces
· Communications Services
· Multimedia Services
· Operating Systems
· Databases
· Messaging Systems
· Other Applications
· Network
· Image, Text, Voice, Graphics,
Sound files
Technical Specialist
· Operating Systems
· TP Monitors
· Database Management Systems
· E-Mail/EDI Systems
· Protocols

Printed 10/03/2019 10/03/2019 Page 12
· File Systems
· PCs
· Workstations
· Servers
· Mainframes
· Infrastructure Management Tools
· Devices (Scanners, Routers,
Modems, etc.)
For all of these users, the more anomalies there are in the Technology Infrastructure, the more
difficult it becomes to function efficiently and effectively. From the point of view of stakeholders and
IT management, the more anomalies there are in the Technology Infrastructure, the more difficult it is
to justify expenditure on information technology. Thus the Technology Infrastructure affects all users.
If the vision and scope of the Technology Architecture are realised, then all users will be affected
(positively) by the Technology Architecture because its effect will be seen and felt in the Technology
Infrastructure. Thus, the Technology Architecture affects all users of the Technology Infrastructure.
The Systems Developer’s concern is to create a consistent view of the Technology Infrastructure for
End-Users and End-User Supporters of business solutions. The Technical Specialist’s concern is to
create a consistent view of the Technology Infrastructure for all types of users, for example, a single
logon for End-Users, a standard network protocol and operating system for End-user Supporters, and
standard APIs for Systems Developers, and (last but not least) common infrastructure management
tools for Technical Specialists.
End-Users also have a direct influence on the Technology Infrastructure by their choice of packaged
business solutions. End-Users can and do contribute to anomalies by choosing solutions that do not
integrate well into the existing Technology Infrastructure. IT staff too have a direct influence on the
Technology Infrastructure by their choice of tools and systems software.
Thus, the impact of their technology buying decisions on the Technology Infrastructure should be of
prime concern to all Users for the sake of the enterprise.
Vision and Scope

The Technology Architecture provides direction for the evolution of the Technology Infrastructure. It
is the link between enterprise business plans and the development of the Technology Infrastructure.
The Technology Architecture is owned by all parties involved in the use and provision of information
technology (the stakeholders). The custodian of the Technology Infrastructure is the IT division of the
Enterprise.
The Technology Architecture ensures integration and consistency in the Technology Infrastructure.
The development, communication and implementation of the Technology Architecture enables the
development of the Technology Infrastructure to be synchronised with business needs and
opportunities. It is the means by which the Enterprise will make the transition from a reactive to a
proactive mode of management in the evolution of information systems. By implementing the
Technology Architecture (as an IT management tool) the Enterprise will create systems that are
integral parts of the Technology Infrastructure rather than anomalies.
The effectiveness of the resultant Technology Infrastructure can be measured in terms of time and
money (e.g. for an expenditure of x dollars on information technology, the time to perform process y is
reduced by z hours/days/weeks; for an expenditure of x dollars on information technology, process y
is enabled). This measure can be applied to customer service, variable costs of production, and so on.
A Technology Architecture does not dictate buying decisions; it is a tool for management of the
content of a Technology Infrastructure.

Printed 10/03/2019 10/03/2019 Page 13
Section 2 - Features and Benefits
Features
The Technology Architecture, which describes the Technology Infrastructure, must enable the
enterprise computing environment to be partitioned into clearly defined manageable components.
These components must be able to co-operate with each other and it must be possible to change or
enhance software components without impacting other software components. To meet these
objectives, the Technology Architecture should have the following features:
Simplicity
The Technology Architecture must be easy to understand and easy to communicate.
Classify Components
The Technology Architecture must focus on what components needs to be provided, rather than how
those components are implemented. It must provide a scheme for identification and de-coupling of
software components to enable technology requirements to be managed without being overly
concerned with complex inter-dependencies between software components..
Integration
The Technology Architecture must facilitate the integration of individual software components by
addressing Co-operation (Interoperability), Regulation, Compatibility and Portability. These terms are
defined in the following sections.
Absorb Change
The Technology Architecture must provide for technology independence so that software components
of the Technology Infrastructure can be changed or extended without impacting other software
components.
Provides a platform for distributed applications

The Technology Infrastructure provides a platform for implementing applications designed to the
client-server model. Applications built in-house, or purchased, which conform to the Application
Architecture and Application Model are inherently able to be distributed. However, to enable
applications to be distributed the systems software in the Technology Infrastructure must provide the
functionality required to support distribution, and the Technology Architecture must describe that
functionality.
Integrated Systems
The Technology Infrastructure provides a platform for integrated applications and integrated systems
software. Integrated systems are required to be able to distribute applications in a heterogeneous
computing environment.
Benefits
Here are some of the benefits we can expect if we implement a Technology Infrastructure guided by a
Technology Architecture:
Location Transparency
Location transparency gives the user a view of data and function without knowledge of physical
location in the computing environment. The computing environment becomes a gigantic disk drive.

Printed 10/03/2019 10/03/2019 Page 14
Single System Image
A Single System Image gives the user a consistent view of, and easy way of using, the components of
the computing environment appropriate to the user’s level of use (User Levels 2,3 and 4). A Single
System Image also reduces the learning curve when new components are added.
Users need to able to identify their data, the type of manipulation, and the form of presentation
required. At present users are faced with a variety of ways of identifying these things, depending on
the processing environment in which they reside, the types of manipulation and forms of presentation
available, limited by that environment. Each environment requires the user to work according to its
own rules.
Reuse existing IT infrastructure

Reuse of application software components will reduce duplication of work for developers and users.
Much time and effort is expended developing computer applications of both a general and a specific
nature. A large part of this effort duplicates work already done in another application, but not useable
by this one because different computing environments and/or applications aren’t integrated.
Similarly there is significant capital expenditure on packaged business solutions often resulting in
duplicate functionality, and data.
Reuse of systems software components will reduce the complexity of the environment and keep the
breadth of skills at a workable breadth.
Much time and effort is expended in acquiring skills to operate and support the Technology
Infrastructure. A large part of this effort duplicates skills already acquired in a specific technology
(e.g. Databases, Network Operating Systems) and is concerned with learning the differences between
similar technologies. Trying to master many systems software products which essentially perform the
same task dissipates the skills of the enterprise, instead of strengthening it. Alternatively, a
multiplicity of similar software products can lead to over-staffing because of the number of products
fulfilling the same function.
Flexibility to adapt to changing IT and Business strategies (management of

change)
An architecture, when implemented, will provide the flexibility to adapt the Technology Infrastructure
to new technology. This is achieved by using the Technical Architecture’s conceptual view of the
physical Technology Infrastructure as a tool to manage change. The change in IT and business
strategies is first applied to the Technology Architecture (to understand the effect on the Technology
Infrastructure) and then to the Technology Infrastructure.
Management of Risk
An IT infrastructure provides appropriate levels of control, and a Technology Architecture provides
consistency and integration. Both can be used to manage risks.

Printed 10/03/2019 10/03/2019 Page 15
Section 3 - A Software Technology Infrastructure Model
The need for a model

This section describes a vendor-independent software model of a distributed computing environment -
the Software Technology Infrastructure Model. The Software Technology Architecture is the link
between the business drivers and the physical Technology Infrastructure. The Software Technology
Architecture is this document - its text and the models and illustrations contained in it.
The Software Technology Infrastructure is described by the Software Technology Architecture. We use
a model to classify the components of the Software Technology Infrastructure. Why use a model? We
need to be able to describe the Software Technology Infrastructure without any constraints and this is
especially true of a heterogeneous computing environment. What are we describing? The software
components that will meet the requirements determined from the business drivers.
What does the model of a Software Technology Infrastructure look like?:

Technology
Software Technology Infrastrastructure Model
APPLICATIONS
INFRASTRUCTURE
CONTROL
MANAGEMENT
SUPPORT
SOFTWARE TECHNOLOGY
INFRASTRUCTURE
Figure 3: The Software Technology Infrastructure Model
This model is the pattern chosen to represent a physical Technology Infrastructure. When the base
technology of a Technology Infrastructure changes to component-based software, this model should
still hold because it is based on a client-server model of software (see Appendix).
This model is more than an illustration. It is the conceptual model of the Technology Infrastructure.
It gives a form and structure to the Technology Infrastructure. It is key because it offers an

Printed 10/03/2019 10/03/2019 Page 16
architectural framework for naming, describing and selecting software components of the Technology
Infrastructure
It must model all software components of the Technology Infrastructure if it is to function as the link
between business plans and the Technology Infrastructure.
What does the Software Technology Infrastructure comprise? Software Components. This is an
architecture, so it does not specify the physical arrangement of the software components - that is
design.

Technology
Software Technology Infrastructure Model
APPLICATIONS
INFRASTRUCTURE
CONTROL
MANAGEMENT
SUPPORT
SERVICES
Software Technology Infrastructure
LAN
RPC Protocol
SQLAPI Network
API
Management
Protocol
WAN
APPC Protocol
Operating Inventory
API
System Services Management
API API
Software
Messaging
Distribution
API
Server
User
Interface
API Network Inventory
Management Management Other
Server Server Gateway
Servers
Desktop Database SNA

Server Operating
Operating Gateway Gateway Other
System
System Server Server Server
Types
Object
Image FIle & Messaging Database
Storage
Server Print Server Server Server
Server
Figure 4: Software components in the technology infrastructure

Printed 10/03/2019 10/03/2019 Page 17
The double-headed arrows («) are intended to illustrate that the drivers, the software technology
architecture (this document) and the software technology infrastructure affect, and are affected by,
each other. There is a feedback loop in operation which makes this Technology Architecture a
dynamic part of the Enterprise Architecture.
There is a risk in using these models. One way to overcome these objections is to validate the model
against the physical computing environment (proof of concept) and to start using the model as
described in a later section. This validation will be vital for buy-in to the Technology Architecture
approach to managing the Technology Infrastructure.
Now we describe the Software Technology Infrastructure model.
Description of the model
Software Technology Infrastructure Model
APPLICATIONS
INFRASTRUCTURE
CONTROL
MANAGEMENT
SERVICES
SERVICES
SUPPORT
SERVICES
Domains
The Technology Infrastructure Model defines four domains of software services that are present in an
enterprise software technology infrastructure, they are Control, Application, Support and
Infrastructure Management. The purpose of each domain is described next.
The Application Domain

The Application domain provides an environment in which applications will be executed.
The Support Domain

The Support domain provides system services required to run any process within a processor. This
domain provides the services required by the Application, Control and Infrastructure Management
domains. The purpose of this domain is to shield the other domains from differences in the
underlying physical computing environment (hardware, database, operating system, and so on).
The Control Domain

The Control domain provides the overall run-time control of a processing environment according to
parameters set by the Infrastructure Management domain. This domain co-ordinates and regulates
the computing environment so that it becomes a cohesive, integrated whole. This domain ensures
reliability, availability and security of the computing environment.
The Infrastructure Management Domain

The Infrastructure Management domain provides the means of setting parameters for the Control
domain and monitoring the run-time environment. It could be argued that this functionality is part of
the Control domain.
Content of the Domains

The domains contain operating systems, servers and interfaces. Each of these software components
provides one or more services. A service is defined as a specific area of functionality within a software

Printed 10/03/2019 10/03/2019 Page 18
component. Examples of services are Security, Inter-Process Communication, Data Management,
Replication. Each service is provided by one and only one software component.
Each component required in the technology infrastructure should be defined before being
implemented. In practice, the vendor of the software provide details of all of the services provided by
a component. However, when new functionality is being considered it is advisable to enumerate the
services required of a software component so that software products can be evaluated. A sample
template for a component and its services is given in the appendix.
Rules of the Model
General Rules
Any software component used must not implement functionality that spans domains. The reason for
this rule is that, if this rule is not satisfied, it implies that the software performs more than one
fundamental function. In practice, until systems software is implemented in component form this rule
is unlikely to be satisfied (even though the internal design of a systems software product may separate
functionality into some internal domain structure or layers). In practice the best we can do is to
ensure that we don’t implement two software products to provide the same services.
Domain Rules
· The logical unit of addressability within a domain is a service.
· Services are implemented by software components called servers. A software server can provide
one or more services.
· A service definition (interface) consists of a service name and a template for the data, consisting
of the “in” and “out” parameters. This definition must remain consistent across the whole
environment.
· The protocols defined for Inter-Process Communication must be used when requesting a service.
Application Domain Rules

· Applications must make use of the of the logical interfaces provided by the Technology
Infrastructure. Only by using these interfaces can integration, control and portability of the
application be ensured.
· The data services layer of an application must be used to isolate users and business services from
the format and location of the data.
· The user services layer of an application must be used to integrate applications (“user” means any
user of an application - human being or another software component).
Support Services Domain Rules

· All services provided by the servers in this domain are logical and not environment dependent.
· Any hardware control within the system must be managed within this domain.
· Logical connection and co-operation between clients and servers must be provided by services in
this domain.
Control Domain Rules

· All resources used within the computing environment must be known to this domain. A resource
is defined as any entity in the computing environment that can be named.
· Software in this domain uses services in the Support Services domain to perform its functions,
and must not contain any physical or environmental dependencies.

Printed 10/03/2019 10/03/2019 Page 19
Infrastructure Domain Rules
· Any change in the definition, regulation or configuration of resources must be performed by
services contained in this domain.
· Software in this domain uses services in the Support Services domain to perform its functions,
and must not contain any physical or environmental dependencies.
When defining and implementing a software component it is not only the specific rules or
interdependencies of that software component that need to be considered. Consider also the rules
defined for:
· The Domain in which it is a member
· Components in general
· The Client-Server Model
· Distribution
· Integration

Printed 10/03/2019 10/03/2019 Page 20
Section 4 - Factors for successful implementation
This section specifies the factors - Technical, Rules, Criteria - for successful implementation of the
technology infrastructure. The rules are necessary to achieve an integrated, distribute homogeneous
computing environment. The criteria are a measure of how integrated and distributed the resultant
technology infrastructure will be. The degree to which these criteria are a matter of choice by the
enterprise and are influenced, to a certain extent, by vendors. However, the choice of vendor rests
with the enterprise.
Organisational Success Factors

This is not intended to be an exhaustive discussion of organisational success factors. It is intended to
highlight the critical organisational success factors for implementing a distributed computing
environment.
· Skills
End-Users, End-User Supporters, Systems Developers and Technical Specialists. All need
training in the new environment.
· Organisation
Distribution of the computing environment will necessitate restructure ore redefinition of
responsibilities.
· Culture of change
Direction-setting and defining new roles and structures can do a lot to ease people’s fear of
change.
· Infrastructure Management
A distributed computing environment is a microcosm of a centralised computing environment at
each location. This can result in duplication and/or diversification of infrastructure management
functions. In some cases it can result in there being no infrastructure management function being
performed through ignorance. Because the components of a distributed computing environment
are so accessible, unlike the mainframe, attention to infrastructure management is crucial for
successful operation. A mindset of “operation” rather than “support” aids in viewing the new
environment as an operational environment, as opposed to the ad-hoc management of PCs and
LANs. Service Level Agreements are a possible tool to reinforce this viewpoint.
· Negotiation
Ownership of technology is tangible - my PC, my Server, my development tools. The central IT
function and the business units must establish a balance between central control and business unit
autonomy. The balance will be different for different aspects of the environment. Criteria for
establishing balance are: When business unit autonomy negatively affects the enterprise; and
when central control negatively affects a business unit. Negotiating policy is one method for
establishing a balance. The central IT department can also cause the environment to be sub-
optimised by viewing itself as “special” or “beyond the rules”.
Technical Success Factors
Global naming conventions

Names are a means of identifying or addressing resources. A resource is defined as anything that can
be named, e.g. Printers, Users, Functions, Components, Files, Databases, Servers, Network Nodes,
Entities, Attributes, Tables, Indexes, and so on.
Naming conventions must cater for the distinction between logical and physical resources. A
relationship between logical and physical names must be maintained (name resolution). In a
distributed environment, a relationship between a resource and its physical location must be
maintained.

Printed 10/03/2019 10/03/2019 Page 21
Minimum Set of Functionality
In order for the Technology Infrastructure described by the Technology Architecture to function it is
required that all components can be identified using Global Naming Conventions, that their physical
location within the computing environment can be found using their global name and that they are
able to co-operate with other components.
Rules for implementation of the Client-Server Model

· The interfaces between clients and servers must be managed (see Interface Management in this
section).
· A simple logical interface, independent of any physical implementation or limitation, must be
provided. Drivers, Class Libraries, DLL’s and Subroutines or modules are all examples of
the way in which interfaces are provided to hide or encapsulate a physical implementation.
“Encapsulation” and “Information-Hiding” are commonly used terms to describe these
techniques.
· Must be able to process sequentially or in parallel.
· Must be able to de-couple software components such that location of components is transparent.
· Physical links between client and server components must be dynamic at run-time.
· The interface(s) to each service are defined by the service provider (according to the needs of the
clients).
Distribution
Distribution defined
One of the characteristics of the Technology Infrastructure is that it is distributed. To aid
understanding of a distributed computing environment it is important to provide a working definition
of distribution.
There are three aspects to distribution which together determine the degree to which a system is
distributed. They are Processors/Processing, Data and Control.
Processors/Processing
Distributed processing improves system resilience (eliminate single point of failure; relieve
performance degradation; availability), enables load balancing and provides a “best fit” by using the
processing environment best suited to a process. Distributed processing is a characteristic of
applications designed to the client-server model.
Levels of distribution are:
· Single Processor (different address space on same CPU)
· Multi-Processor (different CPU on same computer)
· Multiple Computers (different computer)
Application and system software distribution is enabled by a Remote Procedure Call facility.
Data
Data distribution is used to improve system resilience (eliminate single point of failure) and to
improve performance by locating data close to where it originates or is used (locality of reference).
· Single master Copy of Data and Directory (Location of Data)
A single copy of data is kept in a universally available location. No duplicate copies
exist.

Printed 10/03/2019 10/03/2019 Page 22
· Distributed Data and Single Master Directory
Copies of data are replicated or partitioned (replication and partitioning are not mutually
exclusive) throughout the enterprise but only one master directory for locating the data
exists. All access to distributed data must go through the master directory.
· Complete Distribution
Both data and the directory are distributed.
Data distribution scenarios are discussed in the Data Architecture.
Control
Distribution of control is used to provide a degree of autonomy in the computing environment and to
improve system resilience. However control is distributed, the system must appear as a single uniform
system (single system image), hiding the physical distribution and heterogeneity of the computing
environment.
· Centralised
A single fixed point of control in the computing environment.
· Master/Slave
Many control points under the direct control of a master control point. All updates and
maintenance are performed at the master control point.
· Autonomous (Non-Co-operative)
Autonomous systems each perform their own control using their own mechanisms and
are totally de-coupled.
· Autonomous (Co-operative)
Autonomous systems each maintain their own control and are completely coupled by means
of a co-operative protocol.
Distribution Rules
All logical designs within the Technology Infrastructure will cater for full distribution:
Processors/Processing
Multiple computers.
Data
Fully distributed data, replicated and/or partitioned.
Control
Multiple, fully autonomous, co-operating points of control.
Integration
Integration defined
In a distributed computing environment, heterogeneous or homogeneous, integration is necessary to
“undo” distribution. To aid understanding and guide the design and selection of software systems it is
important to provide a working definition of integration. There are two levels of integration. They
are Application Integration and Systems Integration. Systems Integration, or inter-operability, is a
prerequisite for Application Integration in a heterogeneous computing environment.

Printed 10/03/2019 10/03/2019 Page 23
Application Integration
Applications designed and built, or purchased, which conform to the Application Architecture and
Application Model are inherently able to be integrated. In an applications context, integration avoids
re-keying data and/or duplicating data.
Levels of Integration are:
· Functional Integration
· Component
Two applications communicate through their published component interfaces.
· Application Programming Interface (API)
Two applications communicate with each other through their published APIs.
· User Interface
Two applications communicate with each other by programatically reading screens
(“screen-scraping”) or invoke each other’s functions by programatically writing to
screens (“key-faking”).
· Manual
Users enter data from one application into another application. This action results
in duplicate data.
· Data Integration
· Component
Two applications request data of each other through their published component
interfaces.
· Application Programming Interface (API)
Two applications request data of each other through their published APIs.
· Data Sharing
An application gains access to the data of another application through a common
data access interface which enables access to another application’s databases or files.
· Data Exchange
An application gains access to the data of another application by having the other
application export its data in a data format that can be read and written by both
applications (a common data format).
· Manual
Users enter data from one application into another application. This action results
in duplicate data.
Systems Integration
Systems integration is a prerequisite for distributed applications in a heterogeneous computing
environment. Systems software which conforms to the protocol and interface standards of the
Technology Architecture is inherently able to be integrated and thus, enables applications to be
integrated in a distributed computing environment. These protocol and interface standards are the
features that enable Application Integration. That is, they are the mechanisms which enable
applications to communicate across the boundaries of differing systems software. In a systems
context, integration is the ability of different systems software to communicate. The term
“Interoperability” better describes the sense of Systems Integration.
Levels of Integration are:
· Network Integration

Printed 10/03/2019 10/03/2019 Page 24
Network integration is achieved by adoption of a single network protocol or by providing
gateways that perform protocol conversion. Two levels of protocol are of interest - the
transport protocol and the session protocol. The session protocol is of interest to
applications (the Applications Layer in the ISO model). There are many variations of
which session protocols can carried over which transport protocol. In a fully distributed
environment a routeable protocol is necessary. Where non-routeable protocols are used
(e.g. Netbios), then tunnelling (encapsulating a non-routeable protocol in a routeable
protocol) is a technique that can be used to overcome the limitation of a non-routeable
protocol.
· Network Operating System
Interoperability is achieved by the ability of the Network Operating System to support
the standard protocols and interfaces defined by the Technology Architecture. These are
the standard protocols and interfaces that will be implemented in the network.
· Database
Interoperability is achieved by the ability of the Database Management Systems to
support the standard protocols and interfaces defined by the Technology Architecture. In
the database context, these are a standard session protocol (to communicate with the
Database Server) and a standard SQL dialect.
· Messaging
Interoperability is achieved by the ability of the Messaging System to support the
standard protocols and interfaces defined by the Technology Architecture. In the
messaging context, these are a standard session protocol (to communicate with a
Messaging Server) and a standard set of messaging functions.
· Directory Services
Interoperability is achieved by the ability of the Directory Services to support the standard
protocols and interfaces defined by the Technology Architecture. In the Directory Services
context, these are a standard session protocol (to communicate with the Directory Server) and
a standard set of directory functions.
Integration Criteria
One of the design objectives of the Technical Infrastructure is to achieve full integration of the
individual components into a cohesive whole. To achieve this objective, the Technology Architecture
defines the major criteria which facilitate integration. These are completeness (functional
equivalence), compatibility of interfaces, and portability. The level of conformance to each of these
criteria determines to what degree integration will be achieved in the Technology Infrastructure.
Completeness (Functional Equivalence)

Determines how many of the services defined within the sub-domain are provided by the implemented
software and whether the functionality in each is similar. This must be viewed distinctly from the
interface defined within a service definition. Three levels of functional completeness are defined:
· Fully Complete (Fully Equivalent)
A software component fully implements all services defined within a domain. In this case
the service definitions and the server functionality provided are equivalent.
· Incomplete (Partially Equivalent)
A software component partially implements the services defined within a domain (missing
functionality)
· Non-existent (No Equivalence)
There is no equivalence and thus none of the functionality defined within the sub-domain is
provided by the software component under consideration.

Printed 10/03/2019 10/03/2019 Page 25
Compatibility
Specifications must be defined for the user interface, programming interface and common data
formats. Compatibility can be defined as a level of conformance to a specification. Levels of
conformance are:
· Compatible (Level 1)
Full compatibility is achieved when an interface, or data format, conforms to a given
specification.
· Adapted Compatibility (Level 2)
Adapted compatibility is achieved when an interface, or data format, does not conform to a
given specification but can be transformed in such a way that it conforms. This could be
described as simulated compatibility. The effect achieved is that of conformance, although
there might be overheads in doing this.
· Accommodated Incompatibility (Level 3)
Accommodated Incompatibility occurs when an interface, or data format, does not conform
to a given specification but is accommodated in the Technology Infrastructure for whatever
reason. The component(s) that do not conform are classified as being islands of non-
conformance.
· Incompatible (Level 4)
Incompatibility occurs when a non-conforming interface, or data format, cannot be
accommodated in the Technology Infrastructure.
Having chosen a specification, elements that are evaluated for compatibility are:
· User Interface
The interface between the user and the computer
· Programming Interface (Component Interface or API)
The interface between servers and clients used by systems developers.
· Data Formats
The formats in which data of different types are stored. One common format for each type of data
e.g. text, graphics, image, voice.
Portability
Portability is defined as the ability to move software components between processing environments
and hardware architectures. Another sense of portability is the ability of different processing
environments to execute the same software component, rather than any inherent quality embodied in a
programming language and compilers. However, portability is usually viewed from a programming
language perspective. Levels of Portability are:
· Load and Go (Level 1)
A software component is fully portable if it can be moved from one processing environment
to another and executed without any change to source code.
· Interpretive (Level 2)
Interpretive portability is achieved when program source is transferred from one processing
environment to another and is either recompiled or run using an interpreter or emulator. No
change is made to source code.
· Transcribe (Level 3)
Transcription portability is achieved when the differences required to port to a different
processing environment are simple and do not impact the design of the software. Changes
that have to be made can be achieved through standard conversion techniques. So-called
“porting labs” do this using tools like code mirrors.

Printed 10/03/2019 10/03/2019 Page 26
· Redesign (Level 4)
No portability can be achieved and redesign is necessary. The code cannot be re-used and has to
be rewritten, or is replaced by packaged software.
Level 3 and 4 portability are caused either by incompatibilities in the language compilers or
interpreters used in different processing environments, or by the inconsistency of interfaces across
processing environments. If a consistent programming interface for all processing environments is
defined and used then many portability problems can be solved.
Integration Rules
Portability
Interpretive portability must be attained. For packages “Load and Go” portability must be attained.
User Interface
Full Compatibility must be attained
Common Data Formats

Data formats used by programs should conform to level 1 compatibility (full compatibility, the data
interface and data format conforms to defined specifications)
Programming Interface
Software products that provide services must conform to the defined service definitions.
Compatibility must be at level 1 (full) or level 2(adapted)
Interface Management
Interface incompatibilities are identified as one of the biggest inhibitors to achieving full integration.
The Technology Architecture defines a standard protocol and a standard programming interface i.e.
the interface which systems developers (level 2 users) will use. This is the Technology Architecture
view which was discussed in the section one.
The reality is that many products are, and will be, used which support many different interfaces. It is
idealistic (unrealistic) to believe that interface standards, per se, will solve the problems of interfaces
between software components (built or purchased). It is also naive to believe that vendors have the
customer’s interests at heart when designing their own standards. Industry standards will help solve
the problem, but the final responsibility rests with ADCO to ensure that the chosen software interfaces
are compatible.
If integration is a high priority, then it is imperative that ADCO takes a pro-active role in choosing
and managing interfaces through a formal Technology Acquisition Process (“TAP”). In that case, it
becomes the responsibility of the Technical Specialists (Level-1 Users) to adapt products and to
provide management tools so that all software used conforms to the interfaces defined by the
Technology Architecture. The minimum acceptable level is adapted compatibility.
Choices for Interface standards

· Industry Standard (de jure)
An interface, or group of interfaces, defined by an international body representing the
computer software industry.
· De-facto standard
An interface that becomes a standard by virtue of its wide-spread use.
· Proprietary standard.
An interface defined by a vendor or manufacturer. This is distinguished from a de-facto
standard by the scope of its use in the computer software industry.

Printed 10/03/2019 10/03/2019 Page 27
· Private standard
An interface defined by ADCO implemented in the Technology Infrastructure.
Methods of managing an interface

· Stubs
Stubs are a method whereby software components are inserted between the client and server
so that compatibility with the interface standard defined by the Technology Architecture is
achieved.
· Pre-processor
A pre-processor is a means whereby source code is written to an interface specification
defined by the Technology Architecture and is pre-processed before compiling.
· Isolation
Isolation is a means whereby a non-standard interface is encapsulated (wrapped) in a
standard interface. Another technique is to package a non-conforming interface within a
subroutine so that it is isolated from other software components. Containment is another
word which describes this technique.
· Computer-Aided Software Engineering (CASE)
CASE is a technology where a set of automated tools assist in program specification and
generation. Interfaces to services in the Technology Infrastructure are entered into a repository
and the CASE tool manages the complexity of the interfaces.
Conclusion
Cost and time are factors that have to be considered in choosing and managing the interfaces. These
must be weighed up against the benefits of compatibility and portability which are critical in
achieving integration, consistency and, ultimately, a Single System Image
All of the above criteria are of the form:
· “What has to conform”
Interfaces and data formats
· “How must it conform?”
Interface and data format standards
· “How do you manage conformance?”
Techniques for achieving conformance.
By adhering to these criteria the features and benefits of the Technology Infrastructure can be
achieved.
Summary
All of these rules and criteria combine to form the framework for the definition and implementation of
software components. If the rules can be adhered to, then the probability of achieving integration and
distribution is increased. The software components that can be defined for a heterogeneous
computing environment are many and varied and change as the business needs and technology
change. Because of this volatility the software component descriptions are contained in the appendix.

Printed 10/03/2019 10/03/2019 Page 28
Section 5 - Use of the Technology Architecture
To achieve the benefits, described in section two it is necessary for the Technology Architecture to be
capable of being implemented. This section describes a process for implementing the Technology
Architecture.
The Technology Architecture is for use by IT Management, Systems Developers and Technical
BUSINESS DRIVERS APPLICATION

INFRA-
CONTROL
STRUCTURE
SUPPORT
FURTHER FUNCTIONALITY IDENTIFIED
ANALYSE FUNCTIONALITY
ANALYSE DOMAIN INTERDEPENDENCIES
SPECIFY FUNCTIONALITY REQUIRED
BUY OR BUILD SOLUTION NO REUSEABLE IT?

YES
FUNCTIONALITY SATISFIED
Figure 5: A process for using the technology architecture
Specialists and describes the rules for integrating functionality into ADCO’s Technology
Infrastructure. (Computing Environment).

Printed 10/03/2019 10/03/2019 Page 29
There are five steps in using the Technology Architecture:
Step 1 - Analyse business drivers to determine what functionality/features is/are required.
Step 2 - Analyse Domain Inter-dependencies to understand the knock-on effects of new functionality.
Step 3 - Specify Functionality Required.
Step 4 - Examine current Technology Infrastructure for opportunities for re-use.
Step 5 - Buy or Build a solution to meet requirements.
Step 1 - Analyse requirements.
Purpose
Gather high-level business requirements or features required of the Technology Infrastructure.
Deliverables
· List of business requirements expressed in terms of the technology architecture model.
Inputs
· Business IS/IT Plans
· Client-Server Model
· Technology Infrastructure Model
Process
1. Understand the Client-Server Model.
2. Understand the Technology Infrastructure Model.
3. Classify requirements in terms of the Technology Infrastructure Domain, Server, Service
hierarchy.

Printed 10/03/2019 10/03/2019 Page 30
Step 2 - Analyse Domain Inter-dependencies
Purpose
Discover additional functionality required (if any) by analysing the knock-on effect of introducing new
functionality. New functionality in one domain may need new functionality in another domain or
software component.
Deliverables
· List of logical functionality required
· List of inter-dependencies between software components.
Inputs
· List of requirements expressed in terms of the Technology Infrastructure model domains and
software components.
· List of Technology Infrastructure software components.
· Current Functionality
· Technology Architecture Rules and Integration Criteria
Process
1. Match functionality required to functionality in the Technology Infrastructure model’s software
components.
2. Select each domain needed and document the functionality required.
3. Analyse the inter-dependencies between the domains to gain an understanding of the logical
functionality required.
4. Categorise missing functionality required into two types:
· Application-specific
· Potentially reusable (generic). This functionality might be an extension to current domains,
or require an entirely new domain.
1. Architect reusable functionality into domains thereby enhancing the overall functionality now
provided by the Technology Architecture. To do this incorporate the new functionality required
into domains by using the rules of the technology architecture model. Then analyse the inter-
dependencies between the domains once more to gain a full understanding of the logical
functionality required. At this stage we now have a full linear list of the initial business
requirements.
Step 3 - Specify Functionality Required
Purpose
To produce evaluation criteria for the functionality required to satisfy the requirements.
Deliverables
· List of services required
· List of interfaces required
Inputs
· List of logical functionality required

Printed 10/03/2019 10/03/2019 Page 31
· List of inter-dependencies between domains
· List of Technology Architecture Software Components
· Services provided
· Services Required
Process
The list of logical functionality required and the list of inter-dependencies between domains, obtained
from the previous step, are now taken and further refined. At the end of this step we now have
sufficient detail to evaluate software products for functional equivalence.
Step 4 - Identify Reusable Information Technology
Purpose
To establish what can be re-used of the existing Technology Infrastructure
Deliverables
· List of requirements satisfied by existing Technology Infrastructure
· List of projects to investigate unsatisfied requirements
Inputs
· List of services required
· List of interfaces required
· List of conforming Technology Infrastructure
· Tactical plans for technology acquisition
Process
Match the output of the previous step to the existing Technology Infrastructure. Reuse should be
made of the Technology Infrastructure that is already conforming (i.e. fully compatible or adapted
compatibility). Reuse could also be made of components of the Technology Infrastructure that can be
adapted, but, obviously, needs to be adapted before it can be used.
By reusing the Technology Infrastructure that is “accommodated incompatible”, non-conforming
infrastructure is further entrenched, and this is to be avoided.
Step 5 - Buy or Build Solution
Purpose
Fully satisfy the requirements.
Deliverables
· List of requirements satisfied by the enhanced Technology Infrastructure.
· List of unsatisfied requirements (shopping list)
Inputs
· List of projects to investigate unsatisfied requirements

Printed 10/03/2019 10/03/2019 Page 32
Process
The Technology Acquisition Procedure (“TAP”) should be used with the focus on Buy or Build. Buy
or Build is an enterprise policy decision.

Printed 10/03/2019 10/03/2019 Page 33
Section 6 - Next Steps
ADCO has a highly heterogeneous computing environment (Refer to IT/S Planning Exercise CASE
Tool documentation), using six different operating systems (excluding the mainframe) and a wide
variety of applications. Even with the best of intentions, the likelihood of achieving a workable
integrated environment at the level described in this technology architecture is low. Because the
environment is so diverse, the lowest common denominator of integration will prevail - file transfers.
To achieve a higher level of integration, we recommend the following steps, with supporting
arguments:
1. Make Technology Decisions
· Technical Business Units
· Operations
Process Control Systems. Leave as is. If a decision is made later to change the
technology platform we imagine that it will be either to an even more specialised
environment (such as Programmable Logic Controllers - PLC’s) or to a more standard
platform. If the latter choice is made, then we recommend that the chosen platform is
the same as the platform for Technical.
· Technical
The number of vendors world-wide for the applications used in this business unit can be
counted on one hand. ADCO’s technology platform in this business unit is dictated by
less than five vendors world-wide. Given that there is already an initiative to
standardise on the Finder/GeoShare environment for ADNOC and sister operating
companies (OPCO’s) then ADCO must follow by standardising on the UNIX/Oracle
platform dictated by Finder. If, in the future, the vendor decides to provide this solution
on an alternative platform, then ADCO should do its utmost to ensure that the platform
used by Business Support and Administration is on the vendor’s list. In that way, ADCO
can manage convergence to a homogeneous computing environment, and achieve greater
integration.
· Business Support and Administration
Standardise on one set of technology. Our understanding is that the degree of integration
required between the technical business units and these “commercial” business units is low
(i.e. the requirements for integration of data and function is low). Further, our understanding
is that the degree of integration within these “commercial” business units is high (e.g. Supply
& Maintenance, HR and Finance). Hence, the recommendation that ADCO standardise this
environment to achieve a higher level of integration. This argument is further supported by
the fact that there are a substantial number of vendors providing packaged solutions to
support the “commercial” business functions; so ADCO will not be constrained in its choice
of packaged solutions by making a decision to standardise on one vendor’s technology.
When we say “one set of technology” we mean, at a minimum, the operating system(s),
database management system, office automation tools (word processor, spreadsheet, business
presentation graphics, data access and reporting tools, calendar/personal scheduler), e-mail,
development tools, data administration tools and database management tools. We
recommend that the “systems software” (operating system, database management system,
database management tools, infrastructure management tools and e-mail) are from the same
vendor. The reason for this is that integration will be more easily achieved. The choice of
office automation tools and development tools affects the whole business community and that
choice will probably be made by the business community.
2. Define Standards for Technology Acquisition
A prerequisite to this step is to make a decision about the technology for each business unit.
Once that decision has been made the standards need to be documented and managed:
A sample of a set of standards for PC/Server hardware and software can be found in the
appendix. ADCO needs to develop a set of standards for the enterprise and then for each
business unit. Thinking of this in an object-oriented way - the enterprise standards are the
“superclass” of all standards (the common standards); the business unit standards are sub-

Printed 10/03/2019 10/03/2019 Page 34
classes of the enterprise standard (the variations), and the need for each variation is handled
by the technology architecture process (section five) and a technology acquisition process.
3. Implement a Technology Acquisition Process
A technology acquisition process (‘TAP”) is essential to mange the technology infrastructure. In
section five we gave a five-step process for using the technology architecture and this forms part
of a TAP. A successful TAP should have the following characteristics:
· It is known to the enterprise and understood.
If nobody knows about and if nobody understands it, then the TAP will fail. We suggest that
workshops are held to communicate it, develop it and get buy-in.
· There is a contact person for initiating the acquisition of technology
· It is non-judgmental and objective.
It does not exist to judge users. It exists to manage the technology infrastructure to meet the
shared goals and objectives of the enterprise.
· It must be easy to use and quick to arrive at decisions
No bureaucracy
· It must represent the total user community
It is not an “IT thing”. It is an “enterprise thing”. It is a process for ensuring that the
enterprise goals and objectives for IT are met. The goals and objectives must be shared. By
“shared” we mean that the whole IT-using community share the same goals and objectives.
The technology architecture exists to enhance business activities with information technology
in a managed way. The purpose of the technology architecture is to act as a blueprint against
which technology acquisition decisions can be evaluated.
Of course business must never be constrained by technology and so ADCO must develop a
way of managing non-conforming solutions. The appendix states and explains a number of
principles for standardising a PC/LAN technology infrastructure and managing non-
conforming solutions.
Whenever a non-conforming business solution is chosen, there is an additional cost. These
costs should be borne by the business community. The cost are: skills training, support,
headcount, and extraordinary processes required to operate and manage a non-conforming
environment. All of these costs are over and above the costs of providing the skills, support,
headcount, and processes to operate and support a standard environment, and these must be
brought to the attention of, and resolved by, IT and business management prior to a decision
being made to acquire a non-conforming business solution.
The business community’s understanding of the impact of technology decisions on the IT
Infrastructure (HR, Technology, and son) is key to managing the technology infrastructure.
3. Establish the IT Infrastructure for a distributed, heterogeneous computing environment
The IT Infrastructure for a distributed computing environment is quite different from that of
a centralised computing environment. It is not only the hardware and software that get
distributed. Roles and responsibilities do too. These are hard things for the IT community to
adjust to. A “we know best” attitude will not work in a distributed computing environment
because it is easy for the users to walk away. to b
Hold plenty of workshops to share the progress and knowledge. Encourage the business
community to do the same. The recent presentation by Finance on Client-Server technology
was a great example of the business community showing their interest. It is not important
whether or not the business community understands the precise meanings of “client-server”,
“distributed”, or “architecture”. It is important that the enterprise understands the key
management issues and processes that need to be in place to make the transition. We
strongly recommend that IT does not try to assert a superior attitude in this process of
transition. It is very easy for the business community to walk away in a distributed
computing environment and do their own thing, often very successfully. IT needs to be
aware of the impact on its own roles in this process. The establishment of the IT
Infrastructure is an important step to resolve identity crises caused by such a transition.

Printed 10/03/2019 10/03/2019 Page 35
4. Initiate projects to migrate from the current environment to the target computing environment.
The IT Migration project is the master project for the transition. We recommend a number of
focused sub-projects. A starting point could be one project for each dimension of the IT
Infrastructure, namely:
· Human Resources
Covering skills, roles and responsibilities, job descriptions,
· IT Organisation
This will help IT staff understand their new “place” in the organisation.
· Technology and Standards
· Operations and Processes
The discipline of a centralised mainframe environment is a valuable asset to carry forward
into a distributed computing environment. However, there is not a “one-to-one” fit. Current
operation and processes need to be overhauled to fit. The biggest difference is that they need
to be negotiated with the business community because the presence of the computing
environment is tangible.
· Management
· Finance
“Cost of ownership” is a question that is raised by the business community when they
want to know whether or not they are getting their money’s worth. Financial models
showing the cost per PC, and per LAN (including consumables) are a useful tool for
financial management. Cost Accountants, aided by technical specialists, are very good
at building these models.
· Asset Management
Asset management is more complex in a distributed computing environment. Enlisting
the aid of computer auditors to drive this process can ease the pain for IT management.
· Disaster Recovery and Business Continuity
These topics need a different approach from that of a centralised mainframe
environment.
· Planning
Many microcosms of a centralised mainframe computing environment are created in a
distributed computing environment. This means that the number of concurrent projects
can rise dramatically. More focus on planning is required.
3. Establish an IT Architecure Function
Although this falls under IT Infrastructure we have chosen to document it as a separate step
because we think it is important.
The technology, data and application architectures are not passive, nor are they complete. The
role of IT Architect for technology, data and application architectures will be key in the migration
project. Already package evaluation is in progress. The primary role of the IT Architect will be
to apply the architectures to technology decisions and rollout so that the vision ADCO has set for
itself can be realised. A secondary role of the the IT Architect will be to develop the architectures
(technology, data and application) so that they become more effective guides to the establishment
of a distributed, heterogeneous computing environment. Only when the technology infrastructure
is stable and mature can the architecture function revert to a periodic activity.
Without an IT Architecture function in place for migration the result will be a sub-optimised
technology infrastructure. This is inevitable if there is no function to look after the interests of
the enterprise. This function is the driver of the negotiation process to achieve a balance between
central control and local autonomy.
6. Continue Architecture Activities

Printed 10/03/2019 10/03/2019 Page 36
· Review, and assimilate these architecture documents. Question them and debate them. If
they are not working for you, change them.
· Technology Architecture Activities
· Choose the degree of distribution and level of integration that are going to work for
ADCO.
The technology architecture defines different levels of integration and distribution and
the criteria for achieving them. . Often enterprises make grandiose statements about
vision and goals and then give up because they are unrealistic. Conversely the “shoot for
the stars and hit the ceiling” approach often gets an enterprise further than it thought
was possible (this approach depends heavily on a few key people with the vision, drive
and ambition to make things happen).
· Validate the technology architecture
· Map business requirements to the technology architecture (use the process in section 5).
· Define Technology Standards
· Update the techbnology architecture to reflect current standards (Appendix C1, C2, ....,
Cn).
· Application Architecture Activities
· If you have an application under development for the PC/LAN environment, try out the
application architecture on your application. Add a real one as an example. If you
need it Microsoft gives two courses based on this Application Architecture and the
srvices-based Application Model, they are called MSF/SDD (Microsoft Solutions
Framework/Software Development Discipline) and DCS (Developing Client-Server
Solutions).
· Examine the packages under evaluation and use the Application Architecture to evaluate
a package’s architecture.
· Identify developer’s business requirements
· Map developer’s business requirements to the technology architecture (use the process of
section 5 in the technology architecture).
· Data Architecture Activities
This Architecture is the most difficult to define because it has the widest Vision and Scope.
Currently it contains a Preface, Vision and Scope, Features and Benefits, A Framework for
developing it further, and Policies on Data Management, Distribution and Database
Management.
· Validate the Framework contained in it.
See if it covers all of the aspects of a data architecture
· Enhance the framework until it can serve as a model for data architecture
Remember not to get physical. A Data Architecture describes what not how.
· Act on the activities that the Framework illustrates must be done:
See “Evolution of the Data Architecture” in the current Data Architecture document.
· Define Standards, Procedures & Guidelines for Data Administration, Users (for access to
data) and Database Management.
· Define File Storage Management and organisation for managed data (unstructured) that
is not in databases.
· Transform the File Storage Management and organisation to Object Storage
Management and organisation for managed data (unstructured) that is not in databases.
Right now you need to take care of “documents” (File and Attributes about the
document) that contain linked objects using Microsoft OLE (If you move the container
or the contained object the link gets broken).

Printed 10/03/2019 10/03/2019 Page 37
Printed 10/03/2019 10/03/2019 Page 38
APPENDIX A
ENTERPRISE PROFILE
Enterprise Business Profile

Type of Business (SICC)
Number of Employees
Locations
Organisation
IT Organisation
IT Budget
Enterprise Technology Profile

Number of Mainframes
Number LANs (Physical Rings (TKR); Subnets (Ethernet)
Number of dumb terminals
Number of PCs/Workstations
Number of Servers
Number of applications
Number of databases
Total Disk storage - Mainframe, LAN
Structured - Database, ISAM
Unstructured - Files
Software Products
Operating System(s)
Network Protocols (LAN, WAN)
Teleprocessing Monitor(s)
DBMS’
Workgroup
Workflow
Development Tools
Personal Productivity Tools
Infrastructure Management Tools
Vertical Application Packages
Hardware Types
Mainframe
Minicomputer
Server
Desktop PC/Workstation

Printed 10/03/2019 10/03/2019 Page 39
Network Hardware
Cabling/FDDI
Modems
Statmux’s
FEP’s
Cluster Controllers
Routers
Bridges
Lines - Leased, Dial-Up
Satellite Links
Links to external environment
Mail Gateways
EDI
Other
Approved List of Vendors
Approved List of Products

Printed 10/03/2019 10/03/2019 Page 40
APPENDIX C
Software Components within Domains

The software components - operating systems, services and interfaces - within each domain are
specified in this appendix. The specifications are by no means exhaustive. They merely represent, at
a very high level, the major types of functionality that are present in a distributed, heterogeneous
computing environment. The level of detail required will vary for each enterprise.
Control Domain Components

Server Operating System
Desktop Operating System
Resource Management Services

Management of information about resources
Management of currency of resources
Specific Rules
Functionality
· Registration of new resources to assign a global unique identifier (GUID)
· De-registration and destruction of resources
· Addition of meta-data to any registered resource type.
· Amendment of meta-data (excluding GUID)
· Deletion of meta-data.
· Retrieval of meta-data.
· Copying of meta-data to other locations.
· Copying of physical resources.
Inter-dependencies
· Location Services
A global location service is required to determine the location of meta-data.
· Replication Services
A replication service is required to facilitate maintenance of currency of resources. Services
Security Services
Management of relationships between Users, Services and Data.
Specific Rules
Invocation of security services must be transparent to an application
Security checking will take place at the point of access.
A User resource is the focal point of security.

Printed 10/03/2019 10/03/2019 Page 41
Functionality
Maintenance
· Create relationship between resources
· Create a rule
· Remove relationships between resources
· Move relationships of resources
· Copy relationships of resources
Operational
· User verification/authentication/impersonation
· Checking of relationships between resources, in particular between a user and any other resource.
· Encryption/Decryption
Inter-Dependencies
Resource Management Services
Directory Services
The maintenance and provision of Location and Currency information about resources.
Specific Rules
Responsible for location information about all resources at its own and all sub-network nodes.
Knows the network address of its immediate parent.
All requests for services are subject to authentication by the Security Services.
Functionality
· Maintain location data about resources.
· Provide location information about resources.
· Maintain currency data about resources.
· Provide currency information about resources.
· Load local servers when required.
Inter-Dependencies
Replication (Change Propagation) Services

Management of currency of resources.
Specific Rules
Requests for services are subject to authentication by the Security Services.
Functionality
· Synchronise the currency of all resources in the Technology Infrastructure.
· Synchronise the currency of all resources at a specified network node and its child nodes.
Inter-Dependencies

Printed 10/03/2019 10/03/2019 Page 42
Support Domain Components
Image Services
Workflow Management Services
Workgroup Services
File and Print Services
Database Gateway Services
Mail Gateway Services
SNA Gateway Services
LAN Protocol
WAN Protocol
Data Distribution Services

Responsible for selecting, inserting, updating and deleting the underlying data resources of a logical
data view.
Specific Rules
All functionality provided is location transparent.
Functionality
· Select data with location transparency.
· Insert data with location transparency.
· Update data with location transparency.
· Delete data with location transparency.
· Transform data from one format to another using the data interchange services.
Inter-Dependencies
· Data Interchange Services
Data format conversion.
· Resource Management Services
Provide meta-data storage.
Data Interchange Services

Convert data into a requested format using common data formats and transformation models.
Specific Rules
None

Printed 10/03/2019 10/03/2019 Page 43
Functionality
Data Interchange management converts data into the requested format by using common data formats
and transformation models. A common data format is a format in which data is exchanged between
different data formats. Without a common data format, data interchange management must have an
expanding array of multiple conversion formats. With a common data format, each additional data
format requires only one transformation - to and from the common data format.
Transformation models are used to convert data to and from the common data format. A
transformation model provides a description of data in its original format and a mechanism for
converting for converting it to and from a common data format.
Inter-Dependencies
Provide meta-data.
· Data Content Services
Provide facilities to define logical data views.
Data Content Services

Provide logical data views
Specific Rules
All functionality is location transparent.
Functionality
· Define a view
· Modify a view definition.
· Delete a view definition.
· Execute Views with Select, Insert, Update and Delete functionality.
Inter-Dependencies
· Data Interchange Services
Object Storage Services

Responsible for storage, retrieval of objects. Objects are defined as any data which cannot be sub-
divided into a pre-defined structure (as in an entity stored in a relational database). Typical object
types are Scanned Image, FAX, Text Document, Graphics, Spreadsheet, Program Executable, Font.
Specific Rules
All functionality provided is location transparent.
Functionality
· Locate, Retrieve, Add, Delete, Move, Copy Object
· Select, Update object meta-data (properties)
· Search content (Text and OCR)
· Search based on meta-data values (properties)

Printed 10/03/2019 10/03/2019 Page 44
· Index an Object on Object meta-data (properties)
Inter-Dependencies
Meta-data storage and retrieval
Maintain and return physical location of object.
Messaging Services
Responsible for storage and retrieval of messages (Text and Facsimile) and a storage structure for
personal and shared messages.
Specific Rules
All functionality will be location transparent.
Functionality
· Compose a message
· Send Message
· Receive Message
· Delete Message
· Move Message
· Forward Message
· Reply to Message
· Attach object to message (e.g. a FAX, document, spreadsheet, etc.)
· Create Folder (Local and Remote; Private or Shared)
· Delete Folder
· Promote Folder
· Demote Folder
· Export Folder
· Import Folder
· Search Folders
· Maintain personal address book of message recipients
· Maintain global address book of message recipients
· Convert messages between disparate messaging systems
· Provide API for messaging-enabled applications with all of the above functionality
Inter-Dependencies
Meta-data storage and retrieval
Maintain and return physical location of object.

Printed 10/03/2019 10/03/2019 Page 45
· Data Content Services
Storage and retrieval of messages
Inter-Process Communications Services

Management of connectivity and interaction between Client and Server components of applications in
a heterogeneous computing environment
Specific Rules
· Guarantees transparency for inter- and intra-processor communication.
· Guarantees the delivery of data.
· Guarantees secure communications.
· Invokes all servers.
Functionality
Provides a fast lightweight protocol aimed at providing a transaction-oriented transport mechanism
between clients and servers. The protocol makes a fast reliable message transfer mode of transport
available. The protocol does not impose constraints on the size of messages and therefore should
provide for assembly and disassembly of messages when required. The protocol is implemented
directly over the transport protocol and can use different transport protocols. The only requirement
from the transport protocol is that it must be possible to transmit an arbitrary packet, possibly of a
limited size.
The messaging model chosen for the Technology Infrastructure model is inherently an asynchronous
model. This provides for parallel processing between two co-operating environments, and enhances
the parallelism inherent in a multi-processing environment.
Inter-Dependencies
Convert logical server names to physical server addresses.
Display (Presentation) Services

Management of data to/from the user interface
Management and maintenance of the user’s perspective of the computing environment.
Specific Rules
An instance of a display manager controls the visual interface. No other software component will
communicate directly to the visual interface.
Functionality
· Tailoring of user views of the computing environment.
· Tailoring of presentation formats (e.g. forms, dialogues)
· Interfacing to device drivers
· Transformation of input device specifics to application messages.
· Display data to the user interface
· Accept data from the user interface

Printed 10/03/2019 10/03/2019 Page 46
Inter-Dependencies
System Services
Provides interfaces to the physical computing environment and resources.
Specific Rules
Services provided are not environment-specific.
Functionality
· File/Storage Services
· File and Directory
· Services
· Queuing Services
· Virtual Device Services (e.g. Screen and Printer)
· Network Services
· Memory Management
· Task/Process related Services
· System Control
· Time
· Monitors
· Semaphores
· Signals
· Schedulers
Inter-Dependencies
· Security Services
· Inter-Process Communication Services

Printed 10/03/2019 10/03/2019 Page 47
Application Domain Components
Database API
Operating System Services API
Messaging API
Software Component Interface
Communications API
Object Storage API

Printed 10/03/2019 10/03/2019 Page 48
Infrastructure Management Domain Components
Network Management Interface
Inventory Management Interface
Software Distribution Management Interface
Configuration Management Interface
Network Event Services

Management of Network Events.
Specific Rules
· Must be able to monitor network events
Functionality
· Definition of Network Events
· Maintenance of Network Events
· Logging of Network Events
· Triggering of Actions.
Inter-Dependencies
Inventory Management Services

Responsible for gathering and storing data about hardware and software inventory
Specific Rules
-
Functionality
· Collect inventory data
· Store inventory data
· Query Inventory data
Inter-Dependencies
Directory Services
Data Content Services
Replication Services

Printed 10/03/2019 10/03/2019 Page 49
APPENDIX C
APPENDIX C1
The relationship of the Technology Architecture to Microsoft’s Technology

Architectures
Mapping of Technology Infrastructure Components to Microsoft technology

DOMAIN/SERVICES MICROSOFT SOFTWARE COMPONENTS
CONTROL DOMAIN
Server Operating System Microsoft Windows NT Server
Desktop Operating System Microsoft Windows 3.x
Microsoft Windows for Workgroups 3.x
Microsoft Windows 95
Microsoft Windows NT Workstation
Resource Management Services Microsoft Windows NT Server
Security Services Microsoft Windows NT Server
Directory Services Microsoft Windows NT Server
Microsoft Windows NT DHCP/WINS Services
Future - Cairo
Replication (Change Propagation) Services Microsoft Windows NT Server (Security)
Microsoft SQL Server (Data)
Microsoft Systems Management Server (Software
Distribution; Software/Hardware Inventory)
Location Services Microsoft Windows NT Server
SUPPORT DOMAIN
Image Services Is an application. Microsoft does not develop
vertical market applications, only the technology
to enable them.
Microsoft’s Windows Operating Systems, and
Microsoft Back Office and Microsoft’s inter-
process communications services provide a
platform for development of solutions.
Document Management Services Is an application.
Microsoft’s Windows Operating Systems, and
Microsoft Back Office and Microsoft’s inter-
process communications services provide a
platform for development of document
management solutions.
Workflow Management Services Low-End.
Low-end workflow management systems are
forms-based. Electronic forms are routed around
an enterprise and/or to 3rd parties. Microsoft E-
Forms, Microsoft MS-Mail, and Microsoft
Exchange Server (H2/95) provide a platform

Printed 10/03/2019 10/03/2019 Page 50
developing low-end workflow solutions.
High-End
High-end workflow management systems are
applications that drive applications with work-
tracking, business process definition. Microsoft’s
Windows Operating Systems, and Microsoft Back
Office and Microsoft’s inter-process
communications services provide a platform for
development of high-end workflow management
solutions.
Workgroup Computing Microsoft MS- Mail
Microsoft Schedule+
Microsoft Office
Microsoft Operating Systems
Microsoft Network (Peer-to-Peer and/or Server)
File & Print Services Microsoft Windows Operating Systems
Virtual Device Driver architecture for printer
support
Database Gateway Services Microsoft Open Data Services. A gateway
development kit for developing database
gateways.
Alternatively, for IBM DB2, Microsoft SNA
Server (Version 2.11) provides ODBC/DRDA
drivers for access to DB2 without the need for an
expensive database gateway.
Mail Gateway Services Microsoft MS-Mail Gateway
Microsoft Exchange Server (H2/95)
SNA Gateway Services Microsoft SNA Server
LAN Protocol Microsoft provides support for NetBeui, IPX/SPX
and TCP/IP
WAN Protocol Microsoft supports TCP/IP and, through SNA
Server, DLC.
Data Distribution Services Microsoft SQL Server
Data Interchange Services Microsoft SQL Server /Open Data Services for
access to foreign databases, flat files
Microsoft SNA Server for data conversion to/from
host.
Microsoft Access & FoxPro for
import/export/access to major database and file
systems.
Microsoft Word for import/export from/to all
major Word Processor file formats.
Microsoft Excel for import/export from/to to all
major Spreadsheet file formats.
Data Content Services Microsoft Access
Microsoft SQL Server
Microsoft FoxPro

Printed 10/03/2019 10/03/2019 Page 51
Object Storage Services Microsoft OLE
Cairo (future)
Messaging Services Microsoft Mail
Microsoft Mail Gateway
Microsoft Exchange Client (with Windows 95)
Microsoft Exchange Server(H2/95)
Inter-Process Communication Services Microsoft Windows Operating Systems
Microsoft SNA Server
Display (Presentation) Services Microsoft Windows Operating Systems
System Services
Microsoft Windows Operating Systems
APPLICATION DOMAIN
Database API Native Microsoft SQL Server: DBLIB
Native Microsoft Access: SQL
Object Interface to Microsoft SQL Server,
Microsoft Access and Microsoft FoxPro Data
Objects: OLE-COM
Access to other database/file types: ODBC
Operating System Services API For Microsoft’s 16-bit Operating Systems
(Windows/Windows for Workgroups): Win16,
Win32s and/or Microsoft Foundation Classes
(MFC, for C++)
For Microsoft’s 32-bit Operating Systems
(Windows 95, Windows NT Workstation,
Windows NT Server): Win32 and/or Microsoft
Foundation Classes (MFC, for C++)
Messaging API Messaging API (MAPI)
Software Component Interface Microsoft OLE-COM, either native or
encapsulated in MFC. Supported in Microsoft
Visual Basic and Visual Basic for Applications
(VBA, Microsoft’s macro programming
language)
Communications API For Program-to-Program communications:
Remote Procedure Call (RPC)
For basic network communications programming:
WinSockets
For communications across SNA networks: DLC,
HLLAPI, LU6.2, APPC, CPI-C
For communications between software
components: RPC
Object Storage API OLE-COM container storage
Either native OLE or encapsulated in MFC.
INFRASTRUCTURE MANAGEMENT
DOMAIN
Network Management Interface Microsoft Windows NT SNMP Service

Printed 10/03/2019 10/03/2019 Page 52
Inventory Management Interface Microsoft Systems Management Server, Microsoft
Windows 95: Desktop Management Interface
(DMI)
Software Distribution Management Interface Microsoft Systems Management Server:
Proprietary - dependent on vendors establishing a
standard for software installation.
Configuration Management Interface Microsoft Systems Management Server:
Proprietary.
Network Event Services Microsoft Windows NT SNMP Service
Microsoft Windows NT Event Log for any events
logged by an NT Service
Inventory Management Services Microsoft Systems Management Server, Desktop
Management Interface (DMI)
Distribution
Microsoft supports Processor, Data and Control distribution. Microsoft Windows NT Server executes
on single or multi-processors. Microsoft Windows NT Server’s Domain architecture enables an
enterprise to create NT Servers as autonomous co-operating points of control. Alternatively, the
Microsoft Network enables workgroups to set up peer-to-peer networks with each node operating
autonomously. Microsoft SQL Server supports full data distribution, replication and partitioning.
Integration Criteria
Microsoft’s Windows Open Services Architecture (WOSA), OLE and Win32 enable the creation of
fully integrated applications and systems. ODBC provides an open (published API) standard for
database access. MAPI provides an open standard for e-mail and messaging. OLE provides an open
standard for the development of co-operating software components. RPC provides a DCE-compliant
interface for inter-process communication in a distributed heterogeneous computing environment.
Microsoft’s support for TCP/IP enables integration across heterogeneous systems. Win32 provides an
open standard for the development of GUI applications. The Win32 interface is emulated in IBM’s
OS/2 and in various UNIX environments (using Windows Application Binary Interface WABI, or
emulators developed using Microsoft’s WISE software development kit).
Microsoft’s product line provides a complete technology infrastructure for building a distributed
computing environment. Microsoft’s Back Office products are designed to inter-operate with the all
major server operating systems and clients. In this sense Microsoft’s technology satisfies the
completeness criterion.
Adapted Compatibility in a heterogeneous computing environment can be achieved through the use of
emulators, although that solution should be considered only in the short-term.
“Load and Go” portability is achieved automatically for any software written for Windows NT Server
or Windows NT Workstation. Windows NT executes on a variety of single- and multi-processor
hardware including Intel, MIPS, DEC Alpha, and PowerPC. Through the emulation of the Win32
interface “Interpretive” portability can be achieved. Through the use of code-mirroring techniques,
“Transcribe” portability can be achieved.
The User Interface, Application Programming Interface and Data Formats are open (Published) and
thus Microsoft’s technology meets the integration criteria.
Single System Image

Microsoft’s Windows NT Server and Desktop Operating Systems inter-operate with all major server
operating systems and clients. For the user this provides a single system image.

Printed 10/03/2019 10/03/2019 Page 53
Technical Success Factors
Microsoft’s Universal Naming Convention (UNC) provides for unique identifiers of resources within
domains. Cross-domain references are qualified, making identifiers unique in the Microsoft
environment.
Microsoft technology provides the minimum set of functionality, described above.
Summary
A Microsoft technology platform provides maximum flexibility for working in a heterogeneous
distributed computing environment. In a homogeneous distributed computing environment, based on
Microsoft technology, an enterprise has the ability to centralise or distribute processors and
processing, data and control throughout the enterprise.

Printed 10/03/2019 10/03/2019 Page 54
APPENDIX C2
The relationship of the Technology Architecture to IBM’s Technology

Architecture
APPENDIX C3
The relationship of the Technology Architecture to Sun Microsystems’

APPENDIX C4
The relationship of the Technology Architecture to Hewlett Packard’s Technology

Architecture
APPENDIX C5
The relationship of the Technology Architecture to Digital Equipment

Corporation’s Technology Architecture
APPENDIX C6
The relationship of the Technology Architecture to Novell’s Technology

Architecture

Printed 10/03/2019 10/03/2019 Page 55
APPENDIX D
MODELS
These models are used to develop, communicate and understand the Technology Infrastructure.
Different models will be required for different audiences and/or to communicate different concepts.
The models are not a design, nor are they models for implementation.
The Client-Server Model

The Client-Server model has been chosen to describe the relationship between inter-dependent
components (processes) within the Technology Infrastructure. It has been chosen because it is used
widely within the computer industry and is easy to understand.
Process A Process B
Requests Services Process C

CLIENT SERVER
Provides Services
Requests Services
CLIENT SERVER
Provides Services
Figure 6: The Client-Server Model
In the Client-Server Model, a service is defined as a logical unit of work and a process is defined as
any executing program. Clients are requestors of services and Servers are providers of services.
Processes can be Client and/or Servers. Services are requested or provided by sending messages
between processes.
Whenever a client needs work done that it cannot do itself, it will send a request (message) to a server.
The server will perform the work for the client and send back a reply (message). If a server needs
work done (services), the server, in turn, becomes a requestor of a service i.e. a client.
Server does not mean hardware, it means an executing software process that services clients.
Client -Server Technology Misconceptions

Foremost among the misconceptions of client-server technology is the narrow association of client-
server computing with a two-tier platform architecture in which the desktop is the client and a LAN
database is the server. This confuses the physical implementation with the logical concept of client-
server systems. It is important not to associate the specific platform topology with the definition of
client-server computing.
Just as platform topology is not central to the definition of Client-Server computing, neither are the
specific communication protocols between client and server. There are many activation models for
client-server (e.g. blocking, asynchronous). To date, a request-response protocol has been most widely
used. However, as the technology evolves, mail-enabled applications, for example, offer a compelling
alternative protocol when interactive confirmation and response are not required.
In a broader sense, client-server computing characterises the business goals associated with building
applications using a flexible application architecture and a user-centric approach. A user-centric
approach identifies the user as the driver of the application.
Characteristics of Client-Server Computing:
· Distributed processing.
· Distributed data.

Printed 10/03/2019 10/03/2019 Page 56
· A services model in which user (or consumer) needs drive the solution.
· A heterogeneous, multi-vendor hardware and software environment.
Using the “right” technology may mean:
· Using the fastest and cheapest (per unit) technology. This creates a correlation between
client-server architectures and microprocessor-based systems, where businesses are
looking for good price and performance in their computing systems.
· Placing the functionality close to the users to enable self-managed teams. This forms an
interesting relationship between business process re-engineering and client-server as an
enabling technology.
· Adopting new tools that improve the current business processes without throwing away the
existing investments in both hardware and software.
Benefits for implementation:
· Clients can focus on what has to be done (services) and not how it is done.
· The interface to services is logical and not physical.
· For any particular service request only two parties are required to interface with one another,
namely the client and the server. Conformance to requirement thereof is simplified.
· Sequential or parallel processing can be implemented.

Printed 10/03/2019 10/03/2019 Page 57
A model of a sub-optimised Technology Infrastructure
This model is intended to illustrate a Technology Infrastructure without governance. The Technology
Infrastructure is driven directly with little or no control over the shape and form of the resultant
Technology Infrastructure. The message is that without governance the Technology Infrastructure
will be a sub-optimisation of the enterprise Technology Infrastructure. Each organisational unit
benefits but the enterprise suffers in terms of overall business capability (e.g. implementation of
business processes crossing organisational boundaries) and cost of ownership of information
technology.
The intended audience is executive management and the business community. This model could be

Technology
TECHNOLOGY TECHNOLOGY
TECHNOLOGY
TECHNOLOGY
TECHNOLOGY
TECHNOLOGY
TECHNOLOGY
Figure 7: A sub-optimised Technology Infrastructure
backed up with examples of duplication of function and data, problems of integration, and costs in the
current Technology Infrastructure.

Printed 10/03/2019 10/03/2019 Page 58
A model of a unified Technology Infrastructure
This model is intended to illustrate a Technology Infrastructure with governance. The Technology
Infrastructure is driven with control exercised over the shape and form of the resultant Technology
Infrastructure. The message is that with governance the resultant Technology Infrastructure will be a
unified Enterprise Technology Infrastructure. Each organisational unit benefits and the enterprise
benefits in terms of overall business capability (e.g. implementation of business processes crossing
organisational boundaries) and cost of ownership of information technology.
The intended audience is executive management and the business community. This model could be

Technology
TECHNOLOGY
INFRASTRUCTURE
Figure 8: A Unified Technology Infrastructure
backed up with examples of cross-functional business capability, shared function and data, integration
capabilities, and costs in the desired Technology Infrastructure.

Printed 10/03/2019 10/03/2019 Page 59
A model of technology ownership
This model is intended to illustrate the different components in a Technology Infrastructure from the
perspective of ownership. In a distributed computing environment ownership of hardware and
software often becomes an issue. Ownership means the definition of components, as well as
ownership assumed through capital expenditure and location. Without clear ownership a tug-of-war
over “who owns and defines what” ensues. The message is that all of these need to be negotiated.
Some will be easy and some will be difficult. Problematic areas are where users sacrifice standards
for price and where IT itself undermines the standards by exercising personal preferences, often
disguised as “special cases”. Everybody is a user, they just use different applications and tools.
The intended audience is executive management (for financial perspective) and all users.
Decision Infrastructure Software

Technical Commercial Development
Support Management Version
Applications Applications Tools
Tools Tools Control Tools
Office Office Office Office Office

Automation Automation Automation Automation Automation
Applications Applications Applications Applications Applications
Network Infrastructure
Network
Cabling & LAN to WAN
Adapter
Hubs Bridge/Router
Modems Cards
LAN
Protocol
Desktop
MultiPlexers
Front-End LAN-to-LAN Hardware
Processors Bridge
TeleComms
Lines
WAN Server
Bridge/Router
Protocol Satellite Cluster Hardware
Links Controllers
Gatewys
Software Technology Infrastructure
Desktop Other
Server Operating
Operating DBMS Server
System
System Types
Image FIle & Messaging

Server Print Server Server
Figure 9: Technology Ownership - “Who owns and defines what”?

Printed 10/03/2019 10/03/2019 Page 60
APPENDIX E
SAMPLE SERVICE DEFINITION TEMPLATE

· Subject Area
The focus of the software component.
· Component Constraints
Specific constraints for this component covering design and implementation considerations.
· Functionality
A high-level description of the functions provided by this component.
· Data
The majority of functions will need data. A definition of this component’s data model
defining entity types and attributes.
In a component-based technology infrastructure using object-oriented techniques function
and data would be combined and this template would combine Function and Data to become
“Component” and “Interfaces”.
· Services
Each component may consist of one or more services. A service definition template is:
· Service Name
· Parameters
Name, Data Type, In/Out
· Interdependencies
· The functionality required of other components to provide this component’s functionality.
· Services required of other components
Lists all services required by this component.
· Products
Lists the software products contained in the Technology Infrastructure which implement the
services defined in this component.

Printed 10/03/2019 10/03/2019 Page 61
APPENDIX F
SAMPLE TEMPLATE FOR HARDWARE, SOFTWARE & API

STANDARDS
NETWORK COMMUNICATIONS PROTOCOL FOR LANs

The standard transport protocol for network communications within and between LANs will be
TCP/IP.

Printed 10/03/2019 10/03/2019 Page 62
HARDWARE SPECIFICATIONS
Workstation Types
Desktop hardware has been classified into types. Each type defines a technical specification and
usage category. This classification by type serves three purposes.
Firstly, it facilitates a simpler hardware acquisition process for the user. By specifying the workstation
type, the user is relieved of the burden of having to supply technical specifications when ordering.
Secondly, it facilitates a simpler way of deciding what type of workstation to order. By stating the
intended usage, the user is assured that the workstation type will be capable of meeting the user's
requirements. This can eliminate the frustrating situations where users purchase low-cost PC's with
high-end usage expectations.
Thirdly, it enables to maximise the usage of its PC technology. By classifying workstations and taking
a corporate view of the deployment of workstations, organisation can maximise its investment in
workstation by redeploying workstations according to user's requirements.
Workstation Technical Specifications by Type

SPECIFICATION TYPE A TYPE B TYPE C
(See Note 1) (See Note 2) (See Note 2)
Hardware 386DX, 486SX · 486DX 66MHz · 486DX 75/100
Minimum 8Mb RAM MHz
· PCI/ISA Bus
270 Mb Hard Drive · PCI/EISA Bus
· 16Mb RAM
· 24-32Mb RAM
· 256Kb Internal
Cache · 256Kb Internal
Cache
· 270Mb Hard Drive
· 500Mb Hard Drive
· Floppy Drive
· Floppy Drive
· 14 "Super VGA
Energy-Saving · 14" Super VGA
Monitor Energy-Saving Monitor
· 101-Keyboard · Keyboard
· Mouse · Mouse
Network Interface Card 16 bit Ethernet RJ45, 16 bit Ethernet RJ45, 16 bit Ethernet RJ45,
10 Mbps 10 Mbps 10 Mbps
Operating System Windows for Windows for Windows 95 or
Workgroups Workgroups, Windows Windows NT
95 or Windows NT Workstation
Workstation
Network Protocol TCP/IP TCP/IP TCP/IP

Printed 10/03/2019 10/03/2019 Page 63
Notes
General
All workstations are capable of being connected to a network. By default, all workstation types are
connected to a network.
Type A
Since type A classifies an installed base of hardware and operating systems, demanding that users
upgrade to meet the specification is unrealistic.
Recommendations
(1) On redeployment of 386DX and 486SX workstations, upgrade them to meet the Type A technical
specification.
Specifically, upgrade to:
· 8Mb RAM
· 270 Mb Hard Drive
· Windows for Workgroups
· TCP/IP protocol
· 16 bit Ethernet RJ45,

(2) Implement a hardware upgrade acquisition process.
The purpose of this process will be to manage convergence of the installed base of workstations to the
classification scheme set by the LAN strategy. The desired result is that ad-hoc upgrades by
individual owners of workstations are eliminated. On examining a request for upgrade, it may be that
the request is better satisfied by replacement of the workstation by a different type.
Types B and C
Types B and C include a network interface card, whereas currently a user must order a network
interface card as a separate item.
Types C is distinguished from type B by the ability to upgrade the processor.
Types B is the minimum specifications for new workstations. By default, new workstations will be
Type B. Acquisition of Type C workstations will require a motivation based on application
requirements. Type C is appropriate when it is anticipated that there will be need for frequent
upgrades to provide more computing power.
Depending on application requirements, this base technical specification may be enhanced with more
memory, larger monitors, specialised peripherals (e.g. Scanners), and specialised cards (e.g. Image
compression/decompression cards, Sound/Video cards).

Printed 10/03/2019 10/03/2019 Page 64
Server Types
*** TO BE DECIDED ***
A factor to consider in deciding on the technical specification of servers is the scope of the decision to
standardise on Microsoft software. If the scope is limited to desktops, then servers which are not
supported by the Microsoft Windows NT hardware abstraction layer are an option, with the potential
downside of introducing yet another operating system. If the scope of the Microsoft decision extends
to servers, then only servers for which Microsoft Windows NT provides a hardware abstraction layer
can be considered.
Notebooks
In the majority, the current usage of notebooks is for stand-alone computing with intermittent dial-up
for terminal emulation. As mobile computing (with intermittent or frequent connection to the
enterprise network) becomes common, the strategy for desktop hardware will need to be revised.
To adopt notebook technology now, as an alternative desktop standard, would be prohibitively
expensive on a large scale. A notebook with the specification of a type B or C workstation will cost an
extra R 5000 to R10 000 per desktop over the current negotiated desktop prices because notebook
technology is evolving using more expensive leading-edge technology.
The type B and C specifications are necessary to enable Company to deploy business-critical systems
which will typically require one or more concurrent communications links, a multitasking operating
system and a graphical user interface.
Purchasing of notebook technology now, based purely on low price, means that we will be lowering
the specification of devices that may well become the next generation of desktops in Company. That
takes us right back to where we were before the Company LAN strategy. We may be constrained in
our deployment of business-critical systems in the future by the [lower] power of our notebook desktop
hardware.
That is not to say that we should ban the purchase of notebooks. We can't. But bear in mind that,
currently, the lower the price, the lower the specification, and that may limit us in the future.
Network connection of Notebooks

The majority of our workstations will be desktop workstations (i.e. ."fixed") with a standard network
interface card. If we were to allow "free-standing" notebooks in our infrastructure, then we will have
to set a standard for PCMCIA token-ring network interface cards. These cards are more expensive
than the standard network interface cards used in desktop workstations. A way to meet the
requirement to connect notebooks to our LANs in the office is to use docking stations for notebooks.
This enables us to use the same standard network interface card as we will be using for desktop
workstations, since the network interface card will be installed in the docking station, not the
notebook. An added benefit for network management will be that we manage one standard for
network interface cards and their software drivers.
Recommendation
Where notebooks are used as LAN-connected workstations, use a docking station as the means to
connect to the LAN.

Printed 10/03/2019 10/03/2019 Page 65
Printers
Recommendation
As a standard, printers will be LAN-attached. This will allow for management of printers as a device
on the network, instead of being a peripheral attached to a workstation or server.
Corporate applications on LANs use the intrinsic print facilities of LANs
Mainframe printing
...

Printed 10/03/2019 10/03/2019 Page 66
SOFTWARE SPECIFICATIONS
· Desktop Operating Systems

 Windows for Workgroups
 Windows 95
 Windows NT
· Server Operating System

 Windows NT Server
· Software Services
The table shows the software services implemented by each software server product.
SERVICE IMPLEMENTED BY
Software Installation, Configuration & Microsoft Systems Management Server
Distribution
X.400 Gateway, E-Mail MS-Mail Gateway (1)
SNA Services Microsoft SNA Server
Database Microsoft SQL Server
Database Gateway *** TO BE DECIDED ***
File Storage Microsoft Windows NT Server
Software Storage Microsoft Windows NT Server
Printing Microsoft Windows NT Server
Notes
(1) MS-Mail Gateway

MS-Mail Gateway software will be replaced by Microsoft Exchange Server, after successful
evaluation. This will replace DOS file-server mail gateways by Microsoft Windows NT client-server
mail gateways.

Printed 10/03/2019 10/03/2019 Page 67
· Office Automation Applications
 Microsoft Office [Professional]
· PC Application Development Languages & Tools

This is a sensitive are to set standards for!
We acknowledge that PC developers have invested much time, effort and skill in developing
systems in various application development languages and tools. There are many existing PC
systems undergoing maintenance and enhancement in languages which will differ from this
standard, and that is accepted. Whenever a standard is chosen, it will cause existing systems to
be non-standard, that is our legacy. Remember that setting a standard and converging to it takes
time.
What do we mean by "PC Application Development Languages & Tools"? For systems to be
deployed on the Company LAN Infrastructure, which are not developed using a CASE Tool, then
the standard PC Application development languages/tools will be:
 Visual Basic Professional
 Visual Basic for Applications
 Visual C++ Professional
 MS Project
Note that any corporate standard may be formally challenged through a corporate technology
acquisition process, but the outcome must be that the enterprise converges to one set of
development tools for development of systems to be deployed on its LAN Infrastructure.
Tools
Whilst modern application development environments include debuggers, compilers, editors, etc.,
there is a need to define a standard software version control system for the PC environment.

Printed 10/03/2019 10/03/2019 Page 68
· Application Programming Interface (API) Standards
By conforming to Microsoft's software architecture, we have the opportunity to set standards and
guidelines for Company's LAN infrastructure, share skills, share application software, minimise
the dislocations caused by diverse LAN infrastructures, and exploit the LAN infrastructure to the
full. To do otherwise would perpetuate our current divergent approach to PC application
development for LAN's.
From a software developer's viewpoint, Microsoft's software architecture is implemented in two
sets of Application Programming Interfaces (API's).
· Windows Operating System API Standards

The choice of API is determined by the target Windows operating system.
 Win16 for Microsoft Windows 16-bit Operating Systems
 Win32s for Microsoft Windows 16-bit and 32-bit Operating Systems
 Win32 for Microsoft Windows 32-bit Operating Systems
WOSA Application Programming Interfaces (API's) Standards

 Messaging Services: MAPI
 Database Services: ODBC
 SNA Communications Services: WinAPPC
 Non-SNA Communications Services:
WinRPC (high-level interface) or
WinSockets (low-level interface)
 Software Component Interface OLE
WOSA API's shield the application developer from different vendor's back-end services - like
database, messaging. These APIs are supplied in the WOSA Software Development Kit (SDK).
Depending on your level of programming you may or may not be exposed to these API's. For
example, a 4GL Windows programmer using, say, Visual Basic will not normally use these APIs
directly. A 'C' programmer will use these APIs directly. A C++ programmer will use a Class
Library in which these APIs have been encapsulated.
While Microsoft provides many of the back-end services provided in our environment (SQL
Server, SNA Server) there will be cases where we use other vendor's products or maybe swap out
a Microsoft back-end service for another vendor's equivalent service. We want our application
developers, and 3rd-party application software vendors to program to one interface for databases,
messaging, and co-operative processing, remote procedure calls etc. To achieve this we set
WOSA API's as the standard for programming and WOSA-compliant back-end services as the
standard for services. This gives us maximum flexibility in the choice of back-end services.
WOSA is an emerging standard. API's are continually being enhanced (e.g. ODBC Version 2,
MAPI Extended Services, OLE Version 2.01) and new ones are being introduced (e.g. Telephony
API (TAPI), WOSA Extensions for Financial Services, Software Licencing API). Some WOSA
API's are also supplied by third-party vendors; usually because that vendor claims a higher
performance implementation of an API (e.g. ODBC). If you require more detailed information on
the architecture and workings of WOSA, OLE or the Windows APIs, consult the relevant
Programmer's Reference manual and/or the Microsoft Information Network (“MSIN”) DevNet
and TechNet CD-ROMs which contain a number of technical articles and strategy documents on
these topics.
CD-ROM's
q Development Library

Printed 10/03/2019 10/03/2019 Page 69
Also known as DevNet, this CD-ROM contains code samples and technical papers for
developers.
q Development Platform
Also known as DevNet Level II, this CD-ROM contains:
q Operating Systems
q SDK's
q TechNet
This CD-ROM is for technical support staff and contains bug lists and technical papers on
Operating Systems and Server Software.

Printed 10/03/2019 10/03/2019 Page 70
STANDARD WORKSTATION CONFIGURATIONS BY TYPE
Usage by Workstation type

The following table specifies the intended usage for each type of workstation.
TYPE A0 TYPE A TYPE B TYPE C
USAGE Terminal Emulation Local LAN-based · Corporate · Corporate
Applications Applications Applications
· Local LAN- · Professional

based Applications Development
Environment
· Professional
Development
Environment
Software Components by Workstation Type

The following table specifies the software components of each workstation type to support the
intended usage.
SOFTWARE TYPE A0 TYPE A TYPE B TYPE C
COMPONENTS
Operating System DOS Windows OR Windows for Windows/NT
Workgroups OR
Window for
Workgroups Windows/NT (1)
Network Protocol TCP/IP (for DOS) TCP/IP TCP/IP TCP/IP
Office Automation N/A MS-Office MS-Office MS-Office
Suite
3270/5250 Terminal DOS-based Terminal Windows-based Windows-based Windows-based Termi
Emulation (2) Emulation Terminal Emulation Terminal Emulation Emulation
Co-operative N/A N/A WinAPPC WinAPPC
Processing with
S/390, AS/400
Database N/A N/A ODBC ODBC
Messaging N/A N/A MAPI MAPI
Non-SNA N/A N/A WinRPC WinRPC
Communications
(high-level) (high-level)
WinSockets WinSockets
(low-level) (low-level)
Object Linking & N/A N/A OLE OLE
Embedding
Configuration, N/A Systems Systems Systems Management
Installation & Management Agent Management Agent
Distribution

Printed 10/03/2019 10/03/2019 Page 71
Notes
General
An "N/A" entry in the table means that the workstation type is not intended to provide this feature.
(1) Type B : Windows for Workgroups or Windows/NT
Depending on application requirements.
(2) 3270/5250 Terminal Emulation Client Software
Requests for volume prices have been sent out.

Printed 10/03/2019 10/03/2019 Page 72
SERVER CONFIGURATIONS AND LOCATIONS
Server types have not yet been specified (see section: Hardware/Server Types). However, we can
summarise the services that will be available on servers. A matrix for deployment of services is
suggested. The following table summarises the services provided on the server and client workstation
by each server product. Microsoft Windows NT Server is the base operating system for all servers.
Standard Server Configurations

SERVER SERVICES PROVIDED
SERVER CLIENT
Microsoft Windows NT Server LAN Administration Network Logon/Access Rights
Domain Management TCP/IP
RAID
Print spooling
System Management Agent
Microsoft SNA Server APPC using IBM SNA LU 6.2 protocol WinAPPC API
3270/5250 Protocol Conversion API for Terminal Emulation
products
Microsoft Windows SQL Server Relational DBMS Engine DBLIB API
Open Data Services to non-SQL Server ODBC API
Data Sources
Stored Procedures/Triggers
Replication Services
Data Distribution Services
Systems management Agent
Microsoft Exchange Server (1) Information Exchange Microsoft MS-Mail or
Forms Repository; Information Microsoft Exchange Client
Repository (Windows 95)
Microsoft Systems Management Server H/W & S/W Asset Management System Management Agent
Remote Hardware Configuration
Remote Software Configuration,
Installation & Distribution
Database Gateway (2) N/A N/A
Notes
(1) Microsoft Exchange Server

Recommendation
IT Planning Board to schedule evaluation when product is released.
(2) Database Gateways

The corporate ideal is that one Database Gateway product is used throughout the enterprise.

Printed 10/03/2019 10/03/2019 Page 73
Recommendation
IT Planning/Architecture Boards to resolve.

Printed 10/03/2019 10/03/2019 Page 74
Server Deployment Scheme
The following matrix suggests a deployment scheme for services to locations in the network. A ü
indicates that the service may be deployed to the indicated location, depending on the required level of
service. A û indicates that the service would not be deployed at the indicated location.
LOCATIONS
HEAD OFFICE REGIONAL URBAN DISTRICT DISTRICT
OFFICE OFFICE OFFICE (1) OFFICE (1)
SMALL TINY
SERVICES ±20 workstations (±5 workstations) 1 Workstation

Software Installation,
Configuration &
Distribution Service ü ü û û û
X.400 Gateway ü ü û û û
E-Mail Gateway
SNA Services ü û û û û
Database ü ü ü û û
Database Gateway ü û û û û
File Storage ü ü ü û û
Software Storage ü ü ü û û
Printing (2) ü ü ü ü ü
Notes
(1) District Offices

Will be connected to the corporate network by a "small" router (e.g. a router on a card).
(2) Printing
Where a LAN exists, Printers are attached to the LAN (i.e. not to the server machine).
Front-Office Operations at Branches
Require PC-attached printers. See also Hardware Specifications/Printers
Small District Office.
A printer attached to a workstation may be shared by workstations using Windows for Workgroups.
One workstation will use Microsoft Windows NT Server or Workstation to provide printing services
Tiny District Office
A printer is attached to the workstation.
The workstation will use Microsoft Windows NT Server or Workstation to provide printing services
Options for Confidential/Sensitive printing:

Printed 10/03/2019 10/03/2019 Page 75
Option Description
1 Located next to user's workstation (Printers to be LAN-attached where possible)
2 Secure Area for printer
Separate printer id to route confidential printing
Authorised users only have access to printer id & secure area
3 Software security
Authorised users release confidential printing to general printer
Authorised User watches over confidential printing

Printed 10/03/2019 10/03/2019 Page 76
TECHNICAL ISSUES TO BE RESOLVED
1 Technical Specification of Server Hardware Type(s)
2 Identification of replacement technology for NOVELL-based Services
3 Support of multiple transport protocols until migration to TCP/IP is completed
4 TCP/IP Naming Schemes
5 Microsoft Windows NT Server Domain Management
6 Microsoft Windows NT Server/Systems Management Server Domain Management. Revisit
if Microsoft Exchange Server is to be implemented.
7 Storage Management Strategy : Backup/HSM
8 Business Continuity Strategy
9 Software Configuration, Installation & Distribution
9.1 Management of VXD's and DLL's on Workstations
9.2 Management of Printer Drivers & Fonts on Workstations
10 Management of PC Development Environment
10.1 Access to Development Platform (DevNet Level II) beta release software
10.2 DLL's used in development vs DLL's installed on workstations (e.g. ODBC, MAPI,
OLE)
11 Role of Microsoft Systems Management Server to be clarified
11.1 Remote Management of Workstations and Servers
11.2 Includes:
11.2.1 Software Configuration, Installation & Distribution
11.2.2 Problem Diagnosis
11.2.3 Software Licencing Management (which implies asset management)
11.2.4 Workstation and Server Hardware Configuration Management
11.3 Excludes:
11.3.1 Physical network management (managed hubs)
11.3.2 Network connection management
11.3.3 Network address management
12 Routable Protocols for LAN-attached Printers
13 Proving of the Server/Services deployment strategy.

Printed 10/03/2019 10/03/2019 Page 77
14 Assessing Vendor's conformance to the Company LAN Standards
14.1 Vendor-supplied WOSA API's versus Company installed WOSA API's
14.1.1 ODBC
14.1.2 MAPI
14.1.3 OLE
14.1.4 WinAPPC
14.1.5 WinRPC
14.1.6 WinSockets
14.1.7 etc.
14.2 Vendor's use of OLE for reusable components
14.2.1 Reuse of OLE components of vendor's software - contractual considerations
14.2.2 Conformance of vendor's application user interfaces to Windows
Application Design Guidelines

Printed 10/03/2019 10/03/2019 Page 78
APPENDIX G
IT/IS Principles for Standardisation and Management of non-

conforming solutions
An ideal LAN infrastructure provides the business with the flexibility to choose technology solutions
(hardware, software and communications) which meet business needs, whilst maintaining the integrity
of the infrastructure.
With unlimited flexibility we place ourselves in danger of losing control of LANs because there is no
governance. With rigid standards as a means of governance, we place ourselves in danger of
becoming inflexible and unresponsive to business needs. There are cost benefits in defining standards
- volume discounts on hardware, software & training; ease of communication; and focused skills - are
examples.
The goal is to constantly seek a balance between flexibility and standards. Guidelines for adherence to
standards can aid the business community in making decisions on technology acquisition, and also aid
the IT community in maintaining the integrity of the infrastructure.
How do we create this balance between standards and flexibility the first time around? In this design,
we have chosen to set design principles as the means to achieve a balance. We arrived at the design
principles by: using our collective experience of managing LANs, developing LAN-based client-server
applications, and LAN technology selection; gaining insight through the systemic modelling process;
and surveying the current PC/LAN environment.
Looking at the whole LAN user community we can generalise and say that, when working on a LAN,
every user is performing a business activity. Different types of LAN users are using different types of
software to perform their business activities. In many cases, the same types of users are using
different software to perform the same business activity. Since standardisation and a vendor strategy
are two of the key result areas set by the Key User Group, we can standardise on the software we use to
perform common business activities; like word processing and Workstation/LAN software
development, and the vendor who supplies this software.

Printed 10/03/2019 10/03/2019 Page 79
LAN
DEVELOPERS
VENDOR
Use
LAN
VENDOR
LAN
BUSINESS Use
USERS
VENDOR
LAN
Manage
LAN
OPERATIONS
& SUPPORT
Figure 10: A diverse LAN environment

Figure 1 illustrates the diversity of a common LAN environment.
DEVELOPERS
SOFTWARE
VENDOR(S)
Use
END Use ADCO Conform to/Exploit

USERS LAN
Infrastructure
HARDWARE
VENDOR(S)
Manage
LAN
OPERATIONS
& SUPPORT
Figure 11: Standard Infrastructure, Alliance with hardware & software vendor(s)
Compare Figure 1 to Figure 2, where we define LAN Infrastructure standards and choose an alliance
with hardware and software vendors.

Printed 10/03/2019 10/03/2019 Page 80
The bottom line is one LAN Infrastructure. We can more easily manage our relationships with
vendors. We have defined the infrastructure we must manage. Our goal is to have vendors' products
to conform to, and where appropriate or desirable, to exploit, our LAN infrastructure. But not at the
expense of business flexibility.

Printed 10/03/2019 10/03/2019 Page 81
PC/LAN Technology Management Principles
So, how can we start on a path which can lead us to an ideal LAN environment? We have chosen to
set design principles as the means to achieve an ideal LAN environment. If we follow these
principles, we are guaranteed to achieve an ideal LAN environment.
PCs and LANs are not the "plug-and-play" lego bricks that we would all like them to be. The more we
treat them like that, the more unreliable the infrastructure become. In their current state of
development, PCs and LANs require lots of time, effort and skill to make them work for us. To
provide a reliable and cost-effective PC/LAN infrastructure in support of business activities, the
following principles are set by this design.
The LAN workstation platform will be standard and may not be

compromised.
This is a non-negotiable principle. It is key to the effective use of LAN’s at ADCO.
If this principle is not accepted, all IT/IS principles are null and void.
Description
LAN nodes/Workstations are the most populous device in the organisation. Today ADCO has
approximately 1000 of them, and every year we buy more. Supporting these devices is where most of
the time, money and effort goes in operating a LAN and it is in ADCO’s best interests to standardise
the workstations. To reduce support costs and eliminate unnecessary faults due to lack of proper
configuration management it is imperative to exercise more control over the physical configuration of
each and every workstation.
We need to change our view of a PC from a Personal computer to a Corporate computer. This means
that the hardware, operating environment and configuration will be standard and will not be
configured to meet individual preferences. Sounds draconian? Well, maybe! We're relying on the
new LAN technologies to give us the flexibility to control what needs controlling, and leave to
personal preference what should be left to personal preference. For example, there is no benefit in a
user exercising personal preference over the location of an operating system, or any other software,
provided that it loads and operates fast enough when the user wants to use it. It does make sense that
a user chooses the colour and layout of a graphical user interface.
What does it mean to "compromise the workstation"? Running OS/2 or UNIX when the standard is
Microsoft Windows for Workgroups and Windows/NT; Using LOTUS 1-2-3 when the standard
spreadsheet is Excel; Individuals making choices on how software will be installed or how the
operating system will be configured. These are all examples of "compromising the workstation".
Each time this happens, a support overhead is incurred.
If we give way on this principle, we leave ourselves open to a chaotic LAN environment because we
have so many workstations. In other words, we will be back to square one.
That is why we say that if this principle is not accepted, then this LAN Infrastructure design is null
and void. Similarly if the principle is accepted but not enforced, we'll have the same outcome.
Business Impacts
 Manageable installed base of workstations.
 Focused training for supporters & users
 Less choice and less management/admin. overhead
 Less purchasing overhead
 Fewer vendors to manage -> less overheads
 Users can become more expert, by using one operating system/environment
 Cost savings through bulk purchasing
 Focused skills

Printed 10/03/2019 10/03/2019 Page 82
The server platform will be standard, centrally managed and distributed
within the network.
Description
Systems software products like DBMS', Gateways and LAN Operating Systems are sensitive to the
hardware they run on because they exploit hardware features at a much lower level than application
software does. When we have many varieties of hardware, we get compatibility problems. When we
get problems on a server, up to 200 users may be affected. Problem diagnosis is complex.
By having a standard server platform (hardware and operating system) we minimise the risk of
failure. That means that if we do get hardware/software compatibility problems, then once we've
solved them, we've usually solved them for all of our servers.
Operating and supporting servers requires a higher degree of skill than supporting a workstation.
Skills of this nature are at a premium. By adopting central management of servers, we can pool
scarce skills and use them more effectively.
Distributing servers within the network means that we will make conscious decisions about server
deployment, rather than the de facto "one per LAN" deployment strategy.
Business Impacts
 The "right" number of servers to meet our needs
 Focused training for supporters & users
 Less choice
 Less purchasing overhead
 Fewer vendors to manage
 Operations staff become more expert - one operating system/environment
 Cost savings through bulk purchasing
 Focused pool of skills
 Less duplication of servers
 Common approach (Installation, Operation, Management)
LAN-based software services will be standard, centrally managed, and

distributed within the network.
Description
Operating and supporting LAN-based software services requires a higher degree of skill than
supporting, say, a word processor or a spreadsheet. Skills of this nature are at a premium. By having
more than one product to do the same job, e.g. two or three different DBMS' and two or three different
Network Operating Systems, we stretch our capacity to provide effective support. By defining
standard services, we can pool scarce skills and use them more effectively.
By adopting central management of LAN-based software services, we can begin to exploit some of the
more advanced features of these software products to our benefit.
Excessive capacity is caused by duplication of services, the "one per LAN" de facto standard. These
services are expensive and are individually under-utilised or not used at all.
Distributing LAN-based software services within the network means that we will make conscious
decisions about service deployment. You may have noticed that servers and services go hand-in-hand.
The same arguments apply here.

Printed 10/03/2019 10/03/2019 Page 83
Business Impacts
 The "right" number of services to meet our needs
 Users focus on exploitation and planning
 Cost savings through less duplication
 Pool premium skills
 Exercise management of LAN's (e.g. Capacity planning, Disaster Recovery, Business Continuity)
Remote management of Servers and Workstations.
Description
On large LANs and remote LANs it is not feasible to perform regular checks on every workstation for
adherence to standards, software piracy, currency of software and general well-being of the
configuration. Remote support will enable us to perform these checks and ensure that our
workstations are in a proper state for reliable operation. We can also reduce travel and/or walk-about
costs for support.
Remote management of servers enables us to deploy servers appropriately within the network whilst
retaining management control.
In both cases, we can extend the range of operation and support further out into the network without
having to move the skills out.

Printed 10/03/2019 10/03/2019 Page 84
Remote Software Installation, Configuration and Distribution (CID)
Description
Similar argument to Remote Management of Servers and Workstations. We can ensure that only legal
software is used. We can manage software upgrades more effectively by not having to visit every
workstation. We can standardise the way software is installed. We can manage what software is
installed.
Business Impacts
 Configuration & Installation
 Hardware and software configurations are predictable
 Standardised, resulting in ease of support
 Extend skills further into the network
 Improved service turnaround, through reduced time to diagnose problems
 The number of software problems due to configuration problems drops
 Reduced travel costs for support
 Distribution
 Management of software releases (e.g. Office automation applications)
 Fewer people needed to perform & manage software distribution
 Ease of support
Vendor solutions will conform to our LAN Infrastructure standards.
Description
Workstations
The bulk of support effort in a LAN environment is directed to workstations. This is the environment
that needs the most protection from deviations from standards since workstations are the most
populous device in our LANs.
Servers and Services

Non-standard servers and services increase the diversity and cost of our LAN environment. They
require special skills over and above the high level of skill already required.
Business Impacts
 Be aware of and manage dislocations
 Manage known dislocations, instead of attempting to manage a divergent infrastructure

Printed 10/03/2019 10/03/2019 Page 85
Flexibility/Constraints
Description
It is realistic to expect that extraordinary business requirements may result in a LAN-based business
system that deviates from our LAN Infrastructure standards. While every attempt should be made to
have vendor's products conform to our standards, here's how we propose to deal with those, hopefully
extraordinary, situations. There are three situations that we envisage:
1. The solution completely conforms to our LAN Infrastructure standards.
No problem
2. We can accommodate the solution without compromising our workstations, but the server and/or
services do not conform to our standards.
To protect the workstation platform from compromise, any vendor solution that deviates from our
workstation standards shall be capable of being encapsulated within a server and it is the vendor's
responsibility to guarantee that capability.
The server and/or service will be managed as a separate environment. That environment will fall
outside the scope of support infrastructure. The business unit requiring this solution will be
responsible for arranging support for this environment. Ideally, this support will be provided by
the vendor, since the organisation’s training and support will be directed to the standard LAN
infrastructure.
Every attempt should be made to mange the vendor to converge to our LAN infrastructure
standard.
3. The vendor's solution does not meet any of our LAN infrastructure standards.
The whole environment will be managed separately. That environment will fall outside the scope
of the standard support infrastructure. The business unit requiring this solution will be
responsible for arranging support for this environment. Ideally, this support will be provided by
the vendor, since the organisation’s training and support will be directed to the standard LAN
infrastructure.
The features and facilities of the environment shall be exploited solely in the context of the
business solution. For example: ADCO purchases a turnkey business solution which executes on
UNIX. If UNIX is not part of our LAN Infrastructure standard, then any internal systems
development on UNIX must be directly related to that business solution.
Every attempt should be made to manage the vendor to converge to our LAN infrastructure
standard.
Deviation from our LAN standards should be considered only to meet extraordinary business
requirements.

Printed 10/03/2019 10/03/2019 Page 86
Business Impacts
 To meet extraordinary business requirements
 The business is not constrained in its choice
 Vendors provide support for products
 Management of extraordinary solutions can be exercised
 Management of [extraordinary] costs can be exercised
 Workstation platform may not be compromised
 Conformance to coherent technology products
 Protect investment in training, support
 Maintain consistent look-and-feel of user interface, resulting in lower training costs and
avoidance of anomalies
 Encapsulation of non-standard features into a server
 Contains differences on a few servers as opposed to many desktops
 Protects desktop investment in training, support
 Vendor contains the differences - shifts responsibility to the vendor
 Vendor supplies the extraordinary skills required - cost implication for ADCO
 Extra cost is responsibility of business decision makers, not IT.
Illustrations
Workstation Workstation
ADCO NETWORK
Service
Service
Service
Service
ADCO NETWORK
Figure 12: A Network of Services
Figure 1 illustrates the Infrastructure from a user's perspective. There is just a network. No LANs
and no WAN’s from the user's perspective.

Printed 10/03/2019 10/03/2019 Page 87
Figure 4 illustrates servers in the network. Servers are located at appropriate points in the network to
meet service levels. For example, in a network control centre, or in a communications room on a
floor of a building, or on a particular LAN.
ADCO NETWORK
Standard
Server
Workstation
Standard Workstation
Service #1 Server
...
... Dedicated
Service #n Service
Standard
Non-Standard Server
Server
Service #1
Dedicated ...
Service ...
Workstation Service #n Workstation
ADCO NETWORK
Figure 13: Servers located in the network

Printed 10/03/2019 10/03/2019 Page 88

Tech Arch

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Tech Arch

Diunggah oleh

Hak Cipta:

Format Tersedia

ADCO

411510471.doc/ADCO Technology Architecture

PREFACE TO THE TECHNOLOGY ARCHITECTURE...................................................................

411510471.doc/ADCO Technology Architecture

SOFTWARE COMPONENTS WITHIN DOMAINS............................................................................

411510471.doc/ADCO Technology Architecture

411510471.doc/ADCO Technology Architecture

THE CLIENT-SERVER MODEL...........................................................................................................

A MODEL OF A UNIFIED TECHNOLOGY INFRASTRUCTURE...................................................

A MODEL OF TECHNOLOGY OWNERSHIP....................................................................................

SAMPLE SERVICE DEFINITION TEMPLATE..................................................................................

SAMPLE TEMPLATE FOR HARDWARE, SOFTWARE & API STANDARDS..............................

411510471.doc/ADCO Technology Architecture

IT/IS PRINCIPLES FOR STANDARDISATION AND MANAGEMENT OF NON-

PC/LAN TECHNOLOGY MANAGEMENT PRINCIPLES................................................................

411510471.doc/ADCO Technology Architecture

411510471.doc/ADCO Technology Architecture

Evolution of the Technology Architecture

411510471.doc/ADCO Technology Architecture

Business Application Human Strategic

Figure 1: A sub-optimised technology infrastructure

The need for a Technology Architecture

411510471.doc/ADCO Technology Architecture

Business Application Human Strategic

Technology Infrastructure. A Technology Architecture provides IT Management with a tool to

411510471.doc/ADCO Technology Architecture

Figure 2: Software technology architecture as a link

Who is affected by the Technology Architecture?

411510471.doc/ADCO Technology Architecture

411510471.doc/ADCO Technology Architecture

Vision and Scope

411510471.doc/ADCO Technology Architecture

Provides a platform for distributed applications

411510471.doc/ADCO Technology Architecture

Reuse existing IT infrastructure

Flexibility to adapt to changing IT and Business strategies (management of

411510471.doc/ADCO Technology Architecture

The need for a model

Business Application Human Strategic

Software Technology Infrastrastructure Model

Figure 3: The Software Technology Infrastructure Model

411510471.doc/ADCO Technology Architecture

Business Application Human Strategic

Software Technology Infrastructure Model

Software Technology Infrastructure

Desktop Database SNA

Figure 4: Software components in the technology infrastructure

411510471.doc/ADCO Technology Architecture

Description of the model

Software Technology Infrastructure Model

The Application Domain

The Support Domain

The Control Domain

The Infrastructure Management Domain

Content of the Domains

411510471.doc/ADCO Technology Architecture

Rules of the Model

Application Domain Rules

Support Services Domain Rules

Control Domain Rules

411510471.doc/ADCO Technology Architecture

411510471.doc/ADCO Technology Architecture

Organisational Success Factors

Technical Success Factors