The Open Group Architecture Principles Case Study

Case Studies


The Role of Case Studies | Dairy Farm Group (Hong Kong) | Department of Social Security (UK) | Litton PRC (US) | JEDMICS | Ministry of Defence (UK) | NATO (Belgium) | Police IT Organization (UK) | QA Consulting | Statskonsult (Norway) | Westpac (Australia)

The Role of Case Studies

One of the goals of The Open Group Architecture Forum is to provide a forum within which both customer and vendor organizations can exchange feedback and experience in the use of TOGAF.

All of this feedback is considered in the ongoing evolution of TOGAF within the Architecture Forum, and indeed much of it has already been incorporated in this current version of TOGAF.

It is important to emphasize that no case study can provide a complete blueprint for how another organization should go about using TOGAF. All organizations are different, and each organization should understand what TOGAF has to offer, and adopt and adapt the parts that are useful for its needs.

Nevertheless, over the years of its existence as an architecture framework, TOGAF has been used by a variety organizations around the world in major architecture developments, both in its entirety, and in an adapted form.

It is hoped that the case studies presented here will provide useful guidance to organizations intending to use TOGAF or considering using it to develop an enterprise IT architecture.

The formats of the case studies vary, between normal descriptive text, through presentations, and in some cases video.

The following case studies show TOGAF in use in a variety of situations.

Dairy Farm Group (Hong Kong)

The Dairy Farm Group Case Study1 illustrates extensive use of TOGAF as the basis of an enterprise-wide IT architecture to integrate many disparate business units.

The Dairy Farm Group (DFG) is a holding company in the Retail sector. It has a very strong presence in the Asia/Pacific region, and is the 71st largest retailing company worldwide.

DFG has a corporate goal to be the largest, most successful retailer in Asia/Pacific in its chosen markets. To support this goal, DFG has restructured from a federation to a unified group of companies, with a single corporate purpose business focus, and a single IT infrastructure.

The DFG Technical Program Architecture Group (TAPG) was chartered to develop a Technical Architecture for DFG, and chose TOGAF and its supporting methodology as the basis. Using TOGAF, the TAPG was able, in a very short period of time (from July through October 1998) to develop a world-class technical architecture.

It was particularly helpful to be able to point key suppliers to a published version of TOGAF, so that they could see an explanation of the methodology and refer to the TOGAF Standards Information Base (SIB).

This Case Study has its own web site at: www.opengroup.org/public/member/q498/DFG/dfg_frame.htm.

Department of Social Security (UK)

The DSS Case Study illustrates the use of TOGAF, both as the basis of a new architecture framework, and as a key tool in managing the outsourcing of service delivery, in that vendors and integrators were required to use TOGAF as the basis for their tenders, and to use it subsequently in the ongoing management of the IT architecture.

Organizational Context

The UK Department of Social Security (DSS) is responsible for the development, maintenance, and delivery of the UK's social security program and of the UK Government's policy for child support. The DSS currently employs around 90,000 staff and utilizes the largest civilian computer operation in Europe to provide services to its executive agencies, other government bodies, and various Independent Statutory Bodies. One of those executive agencies, the Information Technology Services Agency (ITSA), is responsible for providing the necessary IT systems and services, either internally or through contracts with the private sector.

Social Security spending is approaching £100 billion a year (1999), making it the biggest single spending department in government. At any given time, 70% of the population are in contact with the DSS. In 1998 the Department:

  • Dealt with 15 million benefit claims, and 33 million changes of circumstances
  • Made nearly a billion payments (a great deal of which were handled electronically)
  • Handled upwards of 160 million telephone enquires

Existing IT

Departmental IT systems have tended to be product-based rather than customer-centered. There are separate systems for each DSS agency. In the case of the Benefits Agency, there are separate systems for each benefit. Each benefit system has evolved as a series of processes, supported by its own IS/IT. These "Benefit Chimneys" support their own individual processes, and hold their own information. The consequence is unnecessary duplication and inefficiency, between processes and functions that are, or could be, common. This is especially the case in the way that the Department uses the information it holds. This belies the fact that these systems have data and functions in common.

Strategic Objectives

Recognizing the problems inherent in a product-based approach, a Corporate IS/IT (CISIT) Strategy was developed to support government objectives for a modern, more responsive social security service. IS and IT are crucial, not just to change the Welfare State, but to fundamentally change, for the better, the way that the DSS delivers services. Within the IS/IT arena the changes have shifted the focus to the definition, and purchase, of services rather than products, and promotes a new sourcing strategy. Private sector service providers are expected to a play a greater role in the development of the Department's new IS/IT systems to capitalize on their experience, expertise, and self-financing abilities.

The welfare system must be an active system. It must be simpler, more efficient, transparent, and easier to use. It must be better geared towards the needs of the people who actually use it, be they the general public or the Department's staff. IS and IT will have a key part in enabling these changes, in that any services must be:

  • More accessible and easier to use than they are now
  • More efficient and effective
  • More accurate and less vulnerable to fraud
  • Simpler and more flexible than they are now

Central to the Corporate IS/IT Strategy is the provision of a single logical data repository capable of supporting all of the Department's core business activities. This will reduce duplication of stored data and, thus costs to the taxpayer and the potential for fraudulent claims. It will also ensure that information common to different benefits only needs to be captured once, so providing an improved service to the public.

The data will be complemented by a set of shared systems which will carry out common functions which need to be consistent, such as capturing information, calculating entitlements, and making payments. Ultimately such functions are also expected to be shared, with the intention that they maximize flexibility for, and responsiveness to, policy changes.

Greater freedom is permitted in local business practices, but local systems are required to work with the common services to provide cohesive end-to-end support of social security administration.

The UK Government as a whole is looking to new technology to improve the way government services are delivered: the Prime Minister has pledged to increase the number of opportunities for customers to access DSS services electronically. Using its Corporate IS/IT Strategy, the DSS intends to position itself to optimize its use of new technologies in order to provide better, simpler services for DSS customers and staff alike.

It is also the intention of the DSS to modernize the links that exist with other government departments and other relevant organizations, such as Local Authorities. What is needed to be achieved in social security - flexible, easy-to-use and efficient services, based on common information - needs to be achieved across government. This is known as "joined up" government and is focussed around delivering the goals of government as a whole in a seamless, integrated way. This will enable staff to concentrate on delivering a better service to clients, whilst improving efficiency and effectiveness through IT support.

The Accord Project

Realizing the Department's IS/IT Strategy will be a large and complex task that will be delivered in stages, over a number of years. These strategic aims are being taken forward by a major procurement project - the ACcess to CORporate Data (ACCORD) project. Three private sector consortia (composed of major international companies) satisfied the criteria for participation in this procurement and all have been awarded IS/IT Services Agreements under which a range of IS/IT services may be purchased. These IS/IT services may be allocated for different time periods, at the end of which time the services must be capable of being recompeted and provided by a different service provider. The DSS, therefore, is required to manage multiple service providers. It must also ensure that their services, which may run in heterogeneous environments, are capable of interacting.

Given the scale of DSS operations, the transition to CISIT-compliant systems will take place on an incremental basis over a number of years. Thus, legacy and the new IS/IT systems will be required to run in parallel and interoperate.

The Need for a New Architecture Framework

Despite the importance of ACCORD IT developments, other initiatives, both sourced from within ITSA and via external procurement routes, will inevitably occur. This dictates the need for Departmental control and the setting of a context for any development. The Department will retain strategic and management control of its architecture via the use of an architecture framework. It is intended that this framework will:

  • Provide a classification and structuring scheme within which IT applications can be placed
  • Identify those architectural components which can be used, as required, in various combinations to construct operational (sub)systems
  • Provide the reference documentation for the architecture(s) of CISIT systems
  • Provide the vehicle whereby the principles and standards of the architecture(s) are described along with their dependencies/interdependencies
  • Provide a process for developing the architecture/solutions throughout the lifetime of CISIT systems
  • Document the different perspectives of the CISIT systems
  • Support the specification of requirements and evaluation of supplier bids
  • Support the development and monitoring of contractual milestones
  • Facilitate, through the documentation of the CISIT systems:
    • Better integration and interoperation of systems
    • Subsequent developments
    • Support re-competition (over time)
    • Change/contract management

The Department's legacy systems had been developed according to an in-house architecture framework. Rather than extend that framework, it was decided that a new architecture framework was required that more closely met the needs of the CISIT Strategy. The Department's Corporate IS/IT Architecture Framework (CISITAF) has been based on that produced by The Open Group, The Open Group Architecture Framework (TOGAF) because:

  • It provides a common set of vendor-independent terminologies for documenting the Department's technical requirements.
  • It has been widely accepted within the IT industry. Due to the nature of the Departmental context, this was seen as a key advantage of using TOGAF. All SPs would have their own preference for an architecture framework; e.g., ICL would utilize Open/Framework whilst IBM would prefer Open/Blueprint. However, TOGAF is vendor-neutral having been developed with input from many leading IT companies and cognizant of the other major frameworks.
  • It complements the architecture framework upon which the Department's legacy systems are based.

CISITAF Documentation Set

It would not be practical to document the whole CISIT architecture framework within a single document. The documents that will eventually comprise the CISITAF (they will be developed along different time lines) are shown in the following diagram.



Figure: CISITAF Documentation Set

Although the CISITAF tends to place a different emphasis on the elements, it includes all of those in the TOGAF base set, namely:

  • A Technical Reference Model (TRM)
  • A Standards Information Base (SIB)
  • An Architecture Development Process

supported by descriptions of the architecture from different views.

These have been supplemented by a new framework component: the Model Technical Architecture.

Technical Reference Model

Development of the CISITAF commenced with the definition of a Technical Reference Model (TRM). Use of the TRM aimed to ensure completeness of the architectural definition, by providing a taxonomy of common terms and definitions.



Figure: CISITAF Technical Reference Model

It identifies the IT infrastructure services that may be required on one or a number of application platforms within the CISIT architecture.

The set of services shown is based upon the TOGAF TRM with additions to reflect DSS-specific requirements. The additional services are telephony services and workflow services.

Conformance to this model does not mean that an application will implement all or only these named services without any additional facilities. The set of services used in any situation will be tailored to meet specific business needs.

Standards Information Base

The Standards Information Base (SIB) within TOGAF comprises a comprehensive list of the standards adopted by The Open Group.

The CISITAF SIB has the same aims of promoting interoperability and software portability. However, it will focus upon Departmental technical policies and standards, together with relationships between them, which may be used to assist in the selection of standards and products.

This document will be populated incrementally as appropriate standards are identified and agreed.

Architecture Development Process

The Architecture Development Process (ADP) will describe how the CISITAF will be developed and maintained. It will also outline the stages to be followed, roles and responsibilities of relevant parties, and the products to be produced throughout the process.

Documentation of the ADP is pending the resolution of various organizational and technical issues. It is intended that it will be progressed through an Architecture Control Service.

Architecture Views

The Architecture Views describe an IT system/subsystem from different perspectives to satisfy the requirements of diverse interest groups. The CISITAF makes use of the following Views:

  • Functional View
  • Management and Operational View
  • Security View
  • Builder's View
  • Data Management View
  • User View
  • Commercial and Contractual View
  • Computing View
  • Communications View

Essentially, these views are the same as those recommended by TOGAF, with two principal differences:

  • A consideration of operational aspects has been added to the Management View
  • A Commercial and Contractual View has been defined.

The Commercial and Contractual View is a necessary addition given that the DSS intends to implement the CISIT Strategy using a number of services/systems, potentially supplied by different service providers. It provides the perspective which concentrates on those metrics and processes that are required to support a (sub)system's commercial and contractual aspects and interface it successfully with (sub)systems provided by other service providers.

Model Technical Architecture

The CISITAF Model Technical Architecture (MTA) constitutes an addition to the standard TOGAF approach. It is complementary to the TRM in that it focuses on providing a number of models for features which may be implemented on one, or a number of application platforms. In addition, the models may be implemented by one or more IT infrastructure services on each application platform, which would reflect the TRM taxonomy.

The MTA describes the goal technical architecture for systems, which will be developed within the CISIT Strategy. Each architectural aspect is defined within a separate chapter, supported by what have been termed the "four Ps":

  • Policies are statements that (once agreed) must be adhered to in any specification, construction, and operation of a system within the CISITAF. Any proposal or bid will be assessed as to its ability to meet all of the policies.
  • Principles are the engineering principles that should be adhered to. Like all principles there are implementation options, but the underlying spirit of the principles must be adhered to.
  • Preferences are areas where the Department would prefer a particular mechanism, style, methodology, product, etc. The adoption of alternatives by service providers is possible, but convincing reasons for the adoption of any alternatives will need to be provided.
  • Propositions collect the hypotheses and ideas raised in the various areas of the model architecture. Service providers are required to consider the propositions and adopt them or articulate alternatives together with convincing reasons for the alternative.

Where more detail is required, there may be an architectural model, held as a separate document, giving more information regarding the architectural aspect, including the description, objectives, and rationale for that particular architecture. Aspects meriting such treatment include:

  • Component architecture
  • Transaction management
  • Data management
  • Security
  • Interoperation with legacy systems
  • Management Information Systems (MIS)
  • Directory services
  • Workflow management
  • Output services
  • Event management
  • Data networks

In addition, the MTA specifies a number of general engineering principles, or qualities, that must be exhibited by all CISIT deliverables:

  • Scalability
  • Resilience
  • Security
  • Serviceability
  • Availability
  • Manageability
  • Auditability
  • Interoperability
  • Flexibility
  • Suitability

Using the CISITAF

The ACCORD procurement has proceeded in a number of stages and the CISITAF has been used, to varying degrees, in all of them.

The specification of the technical requirements has been informed by the policies and principles detailed in the MTA. In their responses, service providers have been required to commit to adhering to all the policies and principles in the CISITAF. They have had to describe how their proposed solutions satisfy the general engineering principles.

In ascertaining the capabilities of different service providers, during the initial bidding stages of the procurement, to deliver ACCORD services, Architecture Views have provided the Department with a means of eliciting full and comparable descriptions of proposed solutions. These views also provided a concise description of the technical proposals that were invaluable in allowing staff not directly involved in the procurement to quickly gain of overview of the solutions. To assist the Department in carrying out technical compliance and technical assurance, a matrix had to be provided for each product used, which detailed how that product supports the CISITAF engineering principles.

From those consortia awarded an ACCORD IS/IT Services Agreement, one, Affinity, was selected to take the lead role in delivering the initial implementations of IS/IT services. At this stage, the service provider was required to be more explicit about their proposed solutions. The CISITAF is coming to the fore in finalizing the detailed technical requirements. The MTA and its subordinate models have been used as the basis for informed, detailed consultation with the service provider. These discussions have resulted in the production of the Technical Solution Statement within which the Architecture Views are being used to document the agreed system architecture.

Continuing use of the CISITAF has been assured for the duration of the ACCORD IS/IT Services Agreements. All Service Providers, who have signed such agreements, have committed themselves to using and assisting in the development of the CISITAF so that it encompasses changes in business and IS/IT strategy.

The Department has determined that the principal way in which this will be achieved is through an Architecture Control Service (ACS), operated jointly by the Department and lead service provider, with other service providers in supporting roles. In addition to the ACCORD initiative, there are also a number of other IS/IT developments planned or currently underway. The ACS will be the authority responsible for ensuring that all providers of CISIT services, including ITSA, comply with the CISITAF standards. This is intended to facilitate the integration and interoperation of systems from different sources and maintain flexibility in the choice of supply channels.

The Department has instituted an organizational structure in order to obtain senior commitment to the ACS. An Architecture Board has been established made up of senior officers representing both the Department's IS and IT and the Department's private sector partners. The IS/IT Architecture Board will drive the strategic IS/IT Architecture activities of the Department, maintaining very close links with the business vision via the involvement of the Modern Services Team. The DSS Architecture Board is supported by an Architecture Control Team that will carry out the day-to-day activities of the ACS, including:

  • Maintenance of the Architecture Vision
  • Communication of the vision
  • Co-ordination of the architecture definition
  • Input into the process of control; e.g., liaison between the architecture board and architecture working groups
  • Supporting services; e.g., secretariat and architects-R-US (selling architects into projects)

The aim of this team is not to try and create a single architecture team, but to control the architecture via the co-ordination of the other Departmental groups. This will be achieved by the establishment of architecture working groups that will carry out the detailed technical work with the support of the architecture control team and with the authority of the Architecture Board.

Amongst the initial activities of the ACS will be the agreement and documentation of the CISITAF architectural development process and the identification of IS/IT systems to support the ACS. It is envisaged that the CISITAF standards information base will emerge from the latter piece of work.

Litton PRC (US)

Litton PRC chose the TOGAF Architecture Development Method (ADM) as a basis for its revamped internal Architecture Design Process. The Litton PRC Case Study2 reviews the use of TOGAF within Litton PRC, and explains why TOGAF was chosen.

JEDMICS

The Joint Engineering Data Management Information and Control System (JEDMICS) Case Study illustrates the early stages of the ADM in use on a specific project.

Background

The JEDMICS, formerly known as EDMICS before the "joint" services status was added, is designed to provide a modern means of storing and retrieving engineering drawings and data in electronic repositories through the use of various optical, digital and magnetic mass storage devices, digitizing scanners, graphics hard copy devices, graphics display workstations, and communications devices. JEDMICS addresses the needs of the primary and secondary engineering repositories for the US Armed Services and the Defense Logistics Agency, including activities such as Navy Shipyards, Naval Aviation Depots, and Army and Air Force maintenance depots.

A key element of JEDMICS is the conversion of repositories for engineering data - which include both drawings and documents - into digital format and storing the data on optical disk to support changes in depot maintenance processes. These repositories will store 190 million engineering drawings and 500,000 technical publications. Such an extensive amount of data in JEDMICS repositories represents an enormous investment in labor and in the establishment of workflow processes to utilize that data. It is, therefore, critically important that the JEDMICS investment be kept technologically fresh. This puts tremendous emphasis on platform and software interchange and interoperability.

Definition of Existing Environment in Existing Terms

JEDMICS can be viewed as several subsystems: Input, Data Integrity, Index, Optical Storage, Graphics Display Workstation, and Output. The functional view of the JEDMICS architecture is shown in Functional View of Existing JEDMICS Environment .



Figure: Functional View of Existing JEDMICS Environment

The Input Subsystem is the primary entry point for scanning drawings, aperture cards, and documents into JEDMICS. The major hardware components include large-format scanners, dual-sided page scanners, and high-speed aperture card scanners.

The Data Integrity Subsystem provides for the processing of scanned images that temporarily reside on magnetic storage while awaiting quality assurance on Data Integrity Control workstations.

The Index Subsystem provides for the inquiry and access of image-related index information upon being scanned into the JEDMICS system.

The Optical Storage Subsystem provides for the storage of image data on both multiple disk autochangers, "jukeboxes", and standalone single-disk devices. The stand-alone units provide backup for the jukebox and, in addition, are a means for exchanging data between sites.

The Remote Output (Workstation) Subsystem provides the capability to access image and index data that resides in the Data Integrity Control and Optical Storage Subsystems. The Multifunction Graphics Display Workstation provides the ability to view an image and direct output to a hardcopy output device. The multifunction capability of this workstation allows the site to access different systems from the same hardware platform. The Engineering Graphics Display Workstation provides a true raster editing capability.

The Output Subsystem provides for a variety of output devices and media types for JEDMICS engineering data. Output capabilities include aperture card production, high-resolution hardcopy plotting, large-format printing, and high-speed printing.

The topology of the existing JEDMICS is shown in Existing Hardware Topology .



Figure: Existing Hardware Topology

Restatement of Existing Environment in TOGAF Terms

The existing JEDMICS environment follows a distributed computing architectural model. A client JEDMICS application on a workstation communicates with server applications on the Index Server and Optical Data Management Server to retrieve engineering data and display it at the workstation. The Input Subsystem works as a client communicating with the Data Integrity Subsystem server to enter engineering data into JEDMICS. The data, once subjected to quality control checks, is then transferred from the Data Integrity (Pending) Server to the Index and Optical Data Management Servers to be entered into JEDMICS permanent storage.

The Output Subsystem also acts as a client to the Index and Optical Data Management Servers to output JEDMICS data. Requests for output are initiated by the Workstation client and communicated to the Output Subsystem. The Output client application requests the data from the Index and Optical Data Management Servers and outputs it to aperture cards, tapes, printers, plotters, CD-ROMs, or any other output device available to JEDMICS.

The general diagram for the JEDMICS distributed computing model is shown in JEDMICS Distributed Computing Architecture .



Figure: JEDMICS Distributed Computing Architecture

The existing environment can be restated in TOGAF terms using Mapping of Services to Existing Architecture that maps the existing JEDMICS components into the standard application platform services.

 

 

Data

 

Optical

 

 

 

Input

Integrity

Index

Storage

Output

Workstation

Data Interchange

*

*

 

 

*

 

Data Management

 

*

*

*

 

 

Graphics & Imaging

*

 

 

 

**

 

Network

*

*

*

*

*

*

Object

 

 

*

*

 

 

Operating System

*

*

*

*

*

*

Software Engineering

 

 

 

 

 

 

Transaction Processing

 

 

*

 

 

 

User Interface

*

 

 

 

 

*

Table: Mapping of Services to Existing Architecture

The standard application platform services provided in JEDMICS perform the following specific functions:

  • Data Interchange: In JEDMICS, drawings are input to the system and output from the system in C4 format, which is a tiled, CCITT Group IV bitmap encoding format service. The Data Interchange services convert the bitmap from various scanned formats into C4 format and convert from C4 format to bitmap data that can be sent to common data output devices like printers and CRT screens.
  • Data Management: These services are satisfied by an Oracle Relational Database Management System (RDBMS) for the index data and Kodak KOSI optical disk management software.
  • Graphics and Imaging: Scanners and compression software services are used in the Input Subsystem and decompression software and imaging and drawing services are used by the Workstation and Output Subsystems.
  • Network: In JEDMICS all of the components use the functions provided by the TCP/IP protocol stack working over either an Ethernet or Token Ring network (depending on the user installation).
  • Object: The Index and Optical Storage Subsystems manage the drawing objects in JEDMICS and make use of Object Services.
  • Operating System: The Operating System Services are found on all of the JEDMICS subsystems.
  • Software Engineering: Although programming language compilers and GUI builders are used to develop JEDMICS, no Software Engineering Services map into existing subsystems.
  • Transaction Processing: The ORACLE RDBMS used by the Index subsystem provides these services.
  • User Interface: These functions are provided at the Input Subsystem and at the Workstation subsystem.

Views, Constraints, and External Environments

Operations View

In the Operations view, the key operational aspect of the system is the storage of engineering data and the retrieval by users of that data. JEDMICS is designed to be the authoritative repository for all DoD engineering data. The majority of the engineering data to be stored is in the form of drawings. Drawings consist of sheets and frames of data and can have accompanying documents associated with them. Drawings and drawing sheets can be revised and the coherent basis for each set of revisions among the drawings and drawing sheets must be made. Additionally, sets of drawings or individual sheets may be associated with each other to create sets that can be used for procurement, manufacturing, and maintenance of objects described by the drawings.

Because the JEDMICS is to serve as the authoritative repository of engineering data, strict quality controls are placed on all data entering the system. This quality control function is exercised by staging input to interim magnetic storage first, and then migrating the data to optical disk for permanent storage once it has been checked. Data placed in permanent storage may be accessed by local and remote users and viewed or printed as needed. Each piece of data in the system must be able to be accessed by drawing number, manufacturer, description, and weapon system.



Figure: Operations View
Management View

The management view of the system is that the user has a role in the system according to the function that they are performing. This view partitions the users of the system into the following categories:

  • System Supervisors: Control the operation of the system and assign privileges to other users.
  • Scanner Operators: Input data to the system.
  • Quality Assurance Operators: Check the quality of input data and edit as necessary.
  • Engineers: Edit the data and create new data.
  • Users: View and print the data but do not modify the data. Users can create their own associations of existing data for maintenance and procurement activities.




Figure: Management View
Security View

The security view has two types of security mechanisms. Each user has a unique user ID and password that allows him or her access to certain categories of data. In addition, each hardware device capable of inputting or outputting data has restrictions on the category of data on which it can operate. Data can be input, viewed, printed, and output only if both the user and the input/output device have the prerequisite access authority to the required categories.



Figure: Security View
Constraints

JEDMICS provides the means for the acquisition, storage, management, and distribution of engineering technical data as well as the wide variety of other published material related to the operation and maintenance of ships, airplanes, and weapons systems in the Services. With JEDMICS, this information is received, stored, accessed, and transferred digitally on optical disk.

The optical disk technology in JEDMICS is the cornerstone of the weapons system acquisition process improvements anticipated through CALS. The repositories of drawings maintained in JEDMICS are the source for the efficient distribution and sharing of the large volume of complex engineering drawings and technical data.

JEDMICS has replaced the current manual and semi-automated aperture card-based repository functions with a fully automated optical disk-based system that will enhance access, timeliness, and product quality for the primary government users of engineering drawings.

The current JEDMICS was constructed using an open systems approach to software development, the integration of commercial off-the-shelf (COTS) hardware/software, training, maintenance, site surveys, and system design plans. The JEDMICS contract included a technology refreshment clause that allowed for the incorporation of new technology as it became available. The system was initially deployed with VAX computers as the Index Server, Sun Sparc 1+ computer workstations for Editing Workstations, and Zenith 286 computers for the User Workstations. Because open system principles were adhered to during the JEDMICS design, the system has evolved to SGI Challenge POSIX index servers, Sun Sparc 5 Editing Workstations, and Pentium User Workstations. The latest software version fielded for the 36 systems in use supports both of these configurations (original VAX and current SGI), plus intermediate technical refresh configurations. Only minor software differences exist, and only because of the operating system differences between the VAX (non-POSIX compliant VMS operating system) and the SGI (POSIX-compliant IRIX operating system). A uniform software baseline is supported across all installations.

The major constraint is that the Target Architecture should be compatible with the existing hardware suite already fielded to users. COTS software already purchased and fielded with the earlier version of the JEDMICS software should also be retained in the Target Architecture. Specifically, the ORACLE RDBMS represents a significant investment and must be retained. COTS drawing viewers and editors as well as special-purpose hardware devices are not subject to redesign. The workstations and server computers have been refreshed periodically with new technology, but the current assets represent too large an investment to replace. Similarly, all of the data entered into existing JEDMICS sites must be transformed, with no loss of information, to a new Target Architecture.

The other constraints associated with the existing base of hardware and software are:

  • Existing large-format scanners which can scan paper, vellum, and mylar drawings
  • Existing dual-sided page scanners which can scan 8.5 x 11" documents at an effective rate of 1,200 pages per hour
  • High-speed aperture card scanners which scan at an effective rate of 350 cards per hour
  • All input scan devices capable of surpassing the contract-specified minimum resolution of 200 dots per inch, and support 512 x 512 tiling and software image compression based on CCITT Group IV algorithms
  • A magnetic disk storage system that temporarily holds scanned images while awaiting quality assurance on Data Integrity Control workstations - the primary processing steps include quality assurance verification of image and hollerith index data, and the migration of images to permanent optical storage
  • A COTS relational database and forms processing software used for the Index Subsystem
  • Optical Storage Subsystems used to hold image data on both multiple disk autochangers, jukeboxes (14-inch platters), and standalone single-disk devices (14" and 5.25"). The jukebox is capable of handling the storage for up to 6 million JEDMICS images. The stand-alone units provide backup for the jukebox and, in addition, are a means for exchanging data between sites.
  • Existing Workstation Subsystems that are used to edit and quality control scanned images - the multifunction capability of this workstation allows the site to access different systems from the same hardware platform; existing Engineering Graphics Display Workstations provide a true raster editing capability
  • Output devices that include aperture card production, high-resolution hardcopy plotting, large-format printing, and high-speed printing - the Aperture Card Plotters collectively have the capability to produce 200 aperture cards per hour from images stored on JEDMICS; the main feature of the high-Resolution plotter is the capability to output drawing sizes A through K

A final business process constraint is that the old and new software systems must coexist during the transition period of all 36 sites.

Goals

Besides the constraints that the existing COTS hardware and software impose, certain business goals and objectives also affect the Target Architecture. As part of the most recent change in system specifications, the JEDMICS customer has specified that the software be redesigned using object-oriented programming models and the DOD-STD-2167A lifecycle methodology. (The DOD-STD-2167A lifecycle is a formal "waterfall" software development model designed to produce maintainable, complete, and correct software systems). The motivation for using object-oriented programming models was the desire to increase the maintainability of the software in the future and to provide sufficient isolation layers to allow the system to evolve as a repository. Because of the aging base of fielded weapon systems, engineering data contained in JEDMICS repositories will still be providing long-term support to users well into the next century.

External Environments

The network used at each JEDMICS site is part of the local environment and, as such, the existing JEDMICS coexists with other networked systems and equipment. The new Target Architecture will also be required to fit into existing external environments without disruption of the site's other missions. JEDMICS, within certain limits, also must be portable to user provided workstations and other equipment such as printers and plotters. The data created using the existing JEDMICS software must be transferable to the new JEDMICS Target Architecture without any data loss and with a minimum of disruption.

Target Architecture

The Target Architecture for the new JEDMICS software followed a number of goals:

  1. Make maximum use of existing equipment
  2. Follow open system precepts for portability, interoperability, and vendor-independence
  3. Use object-oriented database techniques to isolate specific technology choices
  4. Use COTS software to lower conversion costs

Based on the analysis of the user functional requirements, the new JEDMICS subsystems were partitioned along object-oriented boundaries. The subsystems in the Target Architecture are:

  1. Session Management subsystem - handles all user-level interaction in a consistent manner.
  2. Distributed Object Management subsystem - manages all of the engineering data contained in JEDMICS regardless of specific location.
  3. Drawing Management subsystem - maintains all of the special relationships associated with drawings, drawing sheets, drawing revision, and accompanying documents.
  4. Input and Output subsystem - handles all input and output of data to JEDMICS in a uniform and consistent manner.

The target JEDMICS environment still follows a distributed computing architectural model. A client JEDMICS Session Management application on a workstation communicates with the Distributed Object Management server application to enter and retrieve engineering data on the Index Server and Optical Data Management Server. This engineering data is displayed at the workstation. The Session Management application can also communicate with the Drawing Management application to request or set the various drawing management relationships. The Input and Output application works as a client communicating with the Distributed Object Management server application to enter engineering data into JEDMICS. The Distributed Object Management server application makes use of an RDBMS (Oracle - existing) and a network data object manager (SQL*NET - new) to store data in JEDMICS.

The Input and Output Subsystem also acts as a client to the Distributed Object Management server application to output JEDMICS data. Requests for output are initiated by the Session Management application client and communicated to the Input and Output Subsystem. The Input and Output client application requests the data from the Distributed Object Management server application and outputs it to aperture cards, tapes, printers, plotters, CD-ROMs, or any other output device available to JEDMICS.

The general diagram for the new JEDMICS distributed computing model is shown in The New Distributed Computing Architecture .



Figure: The New Distributed Computing Architecture

The functional components of the new JEDMICS system architecture are shown in The New JEDMICS Functional Architecture .



Figure: The New JEDMICS Functional Architecture

Using object-oriented methodology, the functional architecture becomes simpler and more direct. The Target Architecture will use these standards for each of the Application Platform Services:

Service

Standard

Description

Data Interchange

MIL-STD-1840B, MIL-STD-28002

CALS data interchange

Data Management

ISO/IEC 9075

SQL data definition

Graphics & Imaging

MIL-STD-28002

CALS raster image format

Network

 

TCP/IP, TFTP

Object

X/Open G302

Object definition and registration

Operating System

IEEE Std 1003.1-1990

POSIX

Software Engineering

ISO/IEC 9899

Programming languages - C

Transaction Processing

 

 

User Interface

X/Open C150, C160, C320

X Windows and Motif API

Migration

The migration phase will require moving the 36 sites from their old system to their new Target Architecture. One of the elements that will simplify the transition is the decision to maintain all of the drawing images saved on optical media in their current raster format. While images remain the same, the index structure in the Oracle database will be radically changed. This will necessitate the transfer and conversion of all currently entered drawing index data into the new object-oriented database structure. A separate conversion effort will address these activities. The implementation of the conversion will require that both the old and new software architectures will be briefly run in the same user environment.

New software COTS products will be installed at the sites during migration, and translation software will be in operation to allow interoperability between sites running the old and new architectures.

Ministry of Defence (UK)

The UK Ministry of Defence (MoD) Case Study shows how the ADM can be used to develop an organization-specific architecture framework, allowing independent operating divisions to develop their own architectures while ensuring that they share a common core operating environment.

Executive Summary

The UK MoD recognizes the value of a standards-based approach to achieving interoperability between defense communications and information systems (CIS). It has established a CIS standards organization comprising the Defence CIS Standards Executive Group (DCISSEG), the Defence CIS Standards Committee (DCISSC), and the Defence CIS Systems Board (DCISB). The DCISSEG includes members from all the MoD sectors and formulates standards recommendations and guidelines based on achieving business goals of interoperability and reducing costs.

The DCISSEG has defined a Defence CIS Technical Reference Model (TRM) which is based on the NATO Open Systems Environment Technical Reference Model (NATO OSE TRM). The DCIS TRM meets the MoD's CIS requirements, and at the same time is open, aligned with the marketplace, and in a position to incorporate future developments in technology. Population of the DCIS TRM with appropriate open system standards has generated the Defence CIS Framework for Standards, Profiles, and Products (DCISF) which provides the basis for the design of all future MoD CISs.

The DCISF has been applied in the procurement of an operational system for the RAF. A standards-based architecture was derived from the DCISF and written into the project procurement specification. This proved to be effective in ensuring that the future system would be compliant with the DCISF. The approach was rather ad hoc, however, and highlighted the need to define architectures that could be used for communities of CISs. Such architectures are called Common Operating Environments (COEs) and the MoD is in the process of defining an initial COE that will be applicable to all operational CISs.

Laying the Foundations

The first step along the road to achieving communication and information system (CIS) interoperability in the MoD involved two key activities:

  1. Providing motivation for the work: The MoD recognized the need for a common reference model and standards framework for guiding CIS projects, with the aim of improving interoperability, portability, scalability, and cost-effectiveness of procurements. In order to exploit its emerging common user infrastructure, the MoD had to make use of COTS products based on open system standards.
  2. Creating a CIS architecture and standards organization within MoD: The Defence CIS Standards Executive Group (DCISSEG) and its parent bodies, the Defence CIS Standards Committee (DCISSC) and the Defence CIS Systems Board (DCISB), were charged with delivering the required reference model and standards framework. The core personnel were drawn from all MoD sectors, including the Procurement Executive, Navy, Army, and Air Force sectors. They provided the necessary seniority, experience, technical authority, and ability to communicate with a wide range of interested parties including potential users, project managers, policy-makers, and technical experts outside the group.

Constructing the Model

The next step was to define a DCIS TRM. A TRM is a model representing an abstraction of an IT system. It assists in understanding and identifying the basic building blocks of an IT system but is not populated with standards and does not contain guidance on application. The benefits arising from the use of a TRM include the following:

  1. It enables the technical strategy for future purchases and migration to be set out.
  2. It simplifies system procurement since it provides a ready-made structure for specifying CIS requirements.
  3. It exposes the interfaces between the building blocks of a system, leading to improved interoperability, application portability and software development, re-use, and maintenance.
  4. It provides a coherent view of the whole system, leading to a better understanding of issues such as security and management which are pervasive throughout the system.
  5. It permits existing systems to be described clearly and in a standard way.

There were several existing TRMs on which the DCIS TRM could have been based. The choice of TRM was guided by the following considerations:

  1. The TRM should be open, widely supported, and aligned with the marketplace.
  2. It should be capable of meeting the majority of military requirements.
  3. There should be a commitment by the "owners" of the TRM to maintain it and allow future developments in technology to be incorporated.

The above considerations led to the adoption of the NATO Open Systems Environment (OSE) TRM as the basis for the DCIS TRM. The NATO OSE TRM aligns well with The Open Group TRM, thus ensuring that the first of the above criteria is met. At the same time, the NATO OSE TRM has been developed within an international military context. Finally, NATO is committed to maintaining the TRM and keeping it in step with changing technology.

The following amendments were made to the NATO OSE TRM in order to meet with the UK MoD's requirements:

  1. A Physical Environment component was added, mainly to meet the needs of the Army sector.
  2. Elements within the Application Software Entity were re-grouped, in order to reflect MoD's view of support applications.

The DCIS TRM is represented in DCIS TRM .



Figure: DCIS TRM

Further information about the definition of the DCIS TRM can be found in Volume 2 of the DCIS Standards Guides.

Building the Framework

This step involved the population of the DCIS TRM with relevant open system standards wherever possible. The resulting framework is the Defence CIS Framework for Standards, Profiles, and Products (DCISF) as detailed in Volume 3 of the DCIS Standards Guides.

Population of the DCIS TRM required suitable standards to be identified and placed within each of the IT Service components of the TRM. The standards selected were intended to be neither exhaustive nor unique. A relevant standard would be included in the DCISF if it was judged to meet the following selection criteria (as applicable):

  1. Promotes interoperability
  2. Enables people portability
  3. Enables application portability
  4. Has market support
  5. Is technically consistent with the DCIS TRM and other DCIS standards
  6. Is consistent with other relevant MoD initiatives

The standards were categorized according to their status. For example, "Recommended" standards were assessed to meet the relevant selection criteria in full; "Emerging" standards met most of the selection criteria, but represent a higher risk, owing to their lack of maturity and stability.

The population of the TRM with open system standards was based on a consensus within the MoD CIS community. This consensus was achieved through a series of technical workshops held by DCISSEG, attended by representatives from each of the MoD sectors.

Defining an Architecture

This step involved the application of the DCISF to an MoD project. The purpose of this was two-fold:

  1. To offer the relevant project the benefits of using the DCIS TRM and DCISF
  2. To validate the DCISF through its application to a real project

The general benefits that are brought to a CIS procurement from the use of the DCIS TRM and DCISF include the following:

  1. Greater clarity and quality of the architecture and standards sections of the Invitation to Tender and the tenders
  2. Ease of tender assessment since a standard structure is adopted
  3. Improved technical communication with industry since a standard vocabulary is adopted

The project concerns an operational CIS being procured for the RAF. The project team sought advice from the RAF Sector Interoperability Authority (SIA) on the specification of technical standards for the system. The RAF SIA is the focus for IT architectures, standards, and interoperability within the RAF Sector and provides RAF representation within the DCISSEG. The RAF SIA were ideally placed, therefore, to apply the RAF Sector Technical Architecture Framework (RAF STAF), which is based closely on the emerging DCISF, to the project.

Key features of the system technical architecture are its graphical and geographical services, its interfaces with external systems, and its security requirements. The system standards specification was prepared by the RAF SIA in close consultation with the project team. The structure of the standards specification is aligned with the structure of the DCIS TRM, and the technical standards constitute a profile of standards from the DCISF, tailored to meet the system's requirements. The standards define an implementable and system-specific architecture, derived from the overarching DCIS standards framework. Thus, the system will be able to interoperate with future systems that are also compliant with the DCISF.

In conclusion, the application of the DCISF in defining a system-specific architecture for a real CIS project proved to be effective. The approach used was rather ad hoc, however, and this points to a requirement for a more systematic way of defining standards-based architectures for CIS. The answer is to define Common Operating Environments (COEs). A COE is an agreed specification derived from a framework of open standards which is applicable to CIS within a particular community. A COE is defined once, and applied many times, as CISs within a particular community are procured. The MoD is in the process of defining COEs, starting with an operational COE.

The Way Forward

The following future MoD CIS interoperability activities are identified:

  1. Maintain the DCIS TRM.
  2. Maintain the DCISF in line with MoD business requirements and market developments in CIS standards and products.
  3. Continue to apply the DCISF to CIS projects in the near-term, using the initial application to an operational CIS as a model.
  4. Complete the definition of the operational COE and begin to define other COEs as required. In particular, there is a requirement for an overall Defence COE, the Defence Interoperability Environment (DIE), which will provide Intranet-type services such as wide area networking and messaging to the vast majority of MoD CISs.
  5. Apply the MoD COEs to future projects.

NATO (Belgium)

NATO's example illustrates the development of Target and Transitional Architectures in the context of overall enterprise architecture.

Within NATO the two Strategic Commands (ACE and ACLANT) are equipped with different C2-systems: basically Allied Command Europe - Automated Command and Control System (ACE-ACCIS) for ACE and Maritime Command and Control System (MCCIS) for ACLANT.

In reaction to the NATO Washington Summit (April 1999) a double convergence between ACE and ACLANT on the one hand and between the Command and Control Systems and the Management Information Systems (MIS) on the other hand has been initiated in order to improve the interoperability and the cost-efficiency of these systems. As the combination of the C2-services and MIS-services is called Automated Information System (AIS), the common system target between the two Strategic Commands is therefore called Bi-SC AIS.

In practice the convergence is envisaged incrementally, whereas the first implementation target revolves around a common "core capability". Such a concept is close to The Open Group's Boundaryless Information Flow initiative and consists of harmonizing/standardizing the foundation IT services throughout the two command structures and also implementing common applications where possible.

The applications are categorized into:

  • Core applications, which are general-purpose applications that are built on the basis of "off-the-shelf" packages (typical examples are Military Message Handling, Document Management, or Enterprise Management)
  • Functional applications, which are business-specific applications in support of the military functions (typical examples are OPS-, INTEL-, or LOG- applications in support of operation control, intelligence, or logistics)

The breakdown of the overall AIS target into "implementation segments", the articulation of these segments, and the planning and management of their implementation, are of course many issues which cannot be successfully addressed without a sound and comprehensive architecture of the system targeted.

In order to avoid a "big-bang" development of such a Target Architecture, which would be almost mission impossible at this scale, the architectural process has been divided into two parallel development activities with different objectives and scopes, namely:

  • A high-level Target Architecture, describing the key objectives of the system for the next six years. Its development is mainly top-down out of the strategic objectives of the commands or the operational and policy requirements.
  • A Transitional Architecture, describing the services targeted for the near term and the transitions from the existing system baseline. Such a Transitional Architecture is developed as an extension to the previous architecture but also accommodates a bottom-up approach, in order to capture the migration constraints and the lessons learned from the fielded baseline.

The respective customers of these two kinds of architectures are the "stakeholders" on the one hand and the end users and implementors on the other hand.

As explained in Time Horizon : "In such an approach, the Target Architecture is evolutionary in nature, and requires periodic review and update according to evolving business requirements and developments in technology, whereas the Transitional Architectures are (by design) incremental in nature, and in principle should not evolve during the implementation phase of the increment, in order to avoid the "moving target" syndrome. This of course is only possible if the implementation schedule is under tight control and relatively short (typically less than two years)."

An Implementation Plan, which both considers the operational priorities and the architectural constraints, and consequently defines the optimal implementation sequence, is required to transition from an agreed high-level Target Architecture to a Transitional Architecture dedicated to the first implementation target.

The following figure illustrates the above considerations and stresses the role of the Architects, who mediate between the stakeholders and implementors and are supposed to maintain the consistency of the whole edifice. They typically aim to reduce the latent gap or lack of understanding between stakeholders and implementors that is caused by the increasing complexity of their respective activities.



Figure: Role of Architects vis-à-vis the Stakeholders and Implementors

The high-level Target Architecture of the Bi-SC AIS has been developed and endorsed in the years 2001 and 2002, and has entered a maintenance process, whereas the Transitional Architecture for the first Bi-SC AIS implementation target has been initiated.

The architectural consistency of these two architectures is largely based on the following factors:

  • They both use the same "NATO Architecture Framework" which is in fact a customization of the US-C4ISR (also described in C4ISR Architecture Framework) to the NATO context. The breakdown of the architectural descriptions into "operational", "system", and "technical" views, combined with the development of standard "architectural templates", establishes a common language between the architects and a sound means of communication with the stakeholders.
  • They also make use of the same "NATO C3 Technical Architecture". This is an architectural design and implementation guidance for the development of System and Technical Views of C3 (Command, Control, and Communications) systems. It includes a detailed TRM, an inventory of standards, and guidelines/directives to develop "interoperability profiles", implement system building blocks, and eventually select software products. The NC3TA is based on the US DoD TRM and DII COE, but has evolved to incorporate the needs of NATO nations as well as Australia and New Zealand.
  • Last but not least, there is a tight collaboration between the architects involved.

The adoption/customization of a comprehensive architectural methodology, which would formally relate all the architectural tasks and make the linkage with the implementation projects, is still an issue. There is still some risk for a Target Architecture to be misinterpreted by implementors, whereas its traceability with the strategic objectives and mapping with the operational requirements remain both critical.

The TOGAF ADM is considered as a valuable starting point for the methodology, due to its adaptability and comprehensiveness. The concept of system "building blocks" is perceived as crucial to manage the interdependency between the aforementioned Target Architectures and to communicate with the users and implementors. Moreover, the latest release of the ADM (Version 8) explicitly supports an incremental approach and makes use of the IEEE Std 1471 concepts (stakeholders, views and viewpoints, etc.) which are fully applicable to a large organization like NATO.

The current architectural development is based on the following paradigms.

The architectural description is broken down into three views:

  • Operation view (equivalent to the Business Architecture, in TOGAF terms)
  • System view (the combination of the Applications and Data Architecture)
  • Technical view (equivalent to the Technology Architecture)

The three architecture views are described in three distinct levels of abstraction (conceptual, logical, and physical) which enables a progressive development and facilitates the validation/exploitation of the architectural description. It is indeed no use developing a logical description of a view if the underlying concepts are not clear or agreed. The same way, a detailed physical description of a view, which deals with the site characteristics, is only possible when a common logical description is agreed.

The following figures describe the expected properties of the architectural rows and columns.



Figure: Expected Properties of the Architectural Model

Such a model, based on a 3-by-3 matrix, is also likely to facilitate the maintenance of the architectural descriptions and the consistency of the whole architectural process. A detailed mapping of this model with the aforementioned (NATO or US-C4ISR) "architectural templates" is available but exceeds the scope of this Case Study and is replaced by the following figure, which gives an overview of the internal structuring of the architectural description.



Figure: Overview of the Structuring of the Architectural Description

The linkage of architecture with its environment is perceived as follows.

Some underlying "principles and objectives", derived from the stakeholders' views, pertain to the whole architectural model, whereas the operational context, the feedback from the fielded baseline, the "state-of-the art", or the user or system requirements apply to the model as follows:



Figure: Linkage of the Architectural Description with its Environment

Police IT Organization (UK)

The UK Police IT Organization (PITO) used TOGAF as the basis for the Technical Architecture for its National Strategy for Police Information Systems (NSPIS).

The NSPIS Case Study includes a comprehensive approach to architecture views, and a methodology for ensuring interoperability between the building blocks of the final architecture.

Police IT

The UK has some 43 police forces. Each one has a different way of doing basically the same job and the authority to purchase what it likes, when it likes, and from who it likes. It is not surprising therefore that there is a whole variety of IT solutions to meet the business need. In addition there are national systems and networks that connect to the local force systems. The most notable is the Police National Computer connected over a facilities managed Police National Network.

Objectives of NSPIS

  • Interoperability
  • Openness
  • Scalability
  • Rationalize Data Structures
  • Effective Pricing
  • Modularity
  • Future Proofing

The police business has identified 38 varied application areas. The NSPIS applications include personnel, accounting, invoicing, case preparation, command & control, crime & incident reporting, custody, etc. The applications can be grouped into business domains. These domains or business groups are likely to contain some commonality of architecture and application functionality which distinguishes them from other domains. It is acknowledged that over time each domain will change due to new additions and re-arrangements of the current set.

In bringing solutions to market, we need to be aware of the high degree of interoperability demanded by the business, both between forces and between applications, both intra and inter-force in order to reduce cross-boundary effects. In order to move forward, the Home Office is not in a position to dictate how things should be. In essence there must be a local and central partnership, together with a commitment at all levels to support the formal strategy agreement. In order to achieve this, we must promote all aspects of the strategy not only to the local forces as the prime users, but to the suppliers who will need to be taken on board during application procurement.

Purpose

The purpose of the technical architecture is to:

  • Provide the format and documentation standards for the technical constraints applied to the NSPIS application procurements
  • Assist the application procurement process by describing an advocated set of technical development and software procurement options in a standard fashion
  • Describe the products and standards used by each NSPIS application

The NSPIS technical architecture is also intended as an aid to discussions with suppliers when it is important to ensure that:

  • Parties are clear on what constitutes conformance to the NSPIS technical architecture.
  • Queries on NSPIS technical issues and other requests are handled uniformly.
  • An appropriate level of liaison and negotiating presence is provided.
  • Change control records are kept and maintained.

The NSPIS technical architecture advocates services (i.e., components and products) that support the policy laid down by the technical design authority. Currently the architecture must conform to the following properties:

  • Multi-tiered client/server
  • Distributed
  • Modular/re-usable components-based
  • Based on common APIs
  • Able to interwork with other NSPIS systems/components
  • Multi-vendor; i.e., open and heterogeneous

The NSPIS technical architecture is based on The Open Group Architecture Framework Reference Model with additions made to reflect the set of services required by the NSPIS recommended applications.

The NSPIS technical architecture is, in principle, the optimum way to achieve the objectives of interoperable, portable, scalable systems by means of an advocated set of services using open architecture standards. However, practical consideration should also be given to each architecture components:

  • Degree of completeness - how tried and tested is the service?
  • Degree of certainty - how mature is the service?
  • Likely longevity - what is the predicted future market position of the service?
  • Cost - what is the life-time cost across the range of applications?

To provide a complete, cost-effective architecture, it may be necessary to pursue a "shades of openness" policy that includes the pragmatic use of proprietary products with an awareness of "lock-in" issues. Wherever possible, the NSPIS technical architecture will recommend a single choice of component with the lowest predicted obsolescence factor. Where a single recommendation is not possible, a range of advocated options that conform to the technical architecture may be given instead. Procured applications are required to adhere to the NSPIS technical architecture recommendations and standards profile outlined within this document. Furthermore, the framework will be used to assist in the development and evolution of all future NSPIS applications services requirements.

NSPIS Technical Architecture Manual

The NSPIS technical architecture is described in three volumes:

  • Volume 1: Overview has the rules and guidelines and defines the platform services. It covers the principles which form the basis of the NSPIS technical architecture and the way in which it is intended to be used and maintained. The appendix has a profile of available services and standards and contains general NSPIS requirements and a methodology for selection and conformance.
  • Volume 2: Generic Architecture contains the mandated platform services and the range of allowable standards. Also, the architectural requirements to satisfy the user requirements and the conformance criteria. This document is the technical architecture requirements and constraints for NSPIS application procurement.
  • Volume 3: Application-Specific Architecture is the supplier's response to the user and technical requirement and contains a complete list of platform services and the relationship between the components chosen, together with a description of the hardware and communication environment required to deliver the performance and scalability. The application-specific architecture describes the complete architecture for each application and forms the basis of the subsequent configuration management. There will be an application-specific architecture associated with each NSPIS application and it will contain all the elements recommended to implement the service provided under the NSPIS framework agreement. The supplier's application-specific architecture forms the basis of the technical evaluation and the conformance test quote. It informs the evaluation of future generic components and helps define acceptance and conformance tests.

The technical architecture documents are intended for use by members of the NSPIS community in NSPIS projects, and in any subsequent implementations including the maintenance and operations of NSPIS products. The NSPIS community includes:

  • IT Managers
  • Project Managers
  • NSPIS Program/Project Teams
  • Procurement and Contract Managers
  • Suppliers
  • Technical User Group
  • In-house Development Teams
  • Configuration Managers

Additionally, this framework may also be referenced by individual purchasers at force level. Teams using the NSPIS framework should remember that these guidelines are a coherent and integrated framework that should be used in their entirety. To use the criteria in an ad hoc fashion like a "pick-list" will represent non-compliance and compromise interoperability.

Applying the Framework

The NSPIS technical architecture is a set of components and a specification of how these components are connected to meet the overall requirements of NSPIS. The following are a set of principles for the application of a component-based approach:

  • The architecture need only contain components to implement those framework services that it requires.
  • Components may implement one, more than one, or only part of a service identified in the framework.
  • Components should conform to standards relevant to the services they implement.

At least four complementary and simultaneous mechanisms are seen as contributing to the definition of the components making up the overall NSPIS Architecture Framework, and each application-specific architecture.

These mechanisms are:

  • By theoretical debate, evaluation, and choice
  • Competitive procurement through infrastructure projects
  • Evaluation and selection of options provided by the application procurement process
  • Selection of components and APIs during application system build.

Under this arrangement, potential components and APIs of the technical infrastructure could be in one of the following states of procurement:

NSPIS Generic Architecture Components

Undefined

Optional

Mandated

NSPIS Application-Specific Components

Undefined

Optional

Mandated

At the award of contract we would expect to see the application-specific component being mandated but not necessarily immutable; i.e.:

NSPIS Generic Architecture Components

Mandated

Mandated

Mandated

NSPIS Application-Specific Components

Mandated

Mandated

Mandated

At system build, final decisions would be taken with reference to those components initially allowed freedom of choice (i.e., not defined or optional) and decisions made whether to embrace any of them in the NSPIS Generic Application Platform. At conformance testing, performance testing, and live running, a formal evaluation of the future status of all components would be made to update in particular the generic application component services by addition, subtraction, or substitution. Each procurement process will generate new releases of the technical architecture and each application system build and test will influence future changes. An overview of the role of the technical architecture in the procurement process is shown in the figure below.



Figure: Technical Architecture & Procurement Process Overview

All suppliers who respond to procurements are given the opportunity, indeed are required, to submit their application-specific architectures. This allows the opportunity to refine, further develop, and recommend alternatives or substitutes to the Generic Architecture.

There are four basic migration models that can be defined:

  • The Gateway Model

    A Force has two environments, a Force-specific environment and its NSPIS environment, and it gateways between these two environments.

    This model is applicable when the Force's current environment has no reasonable evolution to the NSPIS world, and the investment in current systems mean that a radical change to build a complete Force environment conforming to the NSPIS technical architecture is untenable.



    Figure: The Gateway Model
  • The NSPIS Environment Model

    A Force has an environment based on NSPIS-compatible operating systems and networks - e.g., UNIX and TCP/IP - but has NSPIS and legacy applications working on a variety of platforms at the middleware level within this environment.

  • The Application Platform Model

    A Force has not only an NSPIS-compatible environment, but conforms at the application platform level, with services and components compatible and based on the NSPIS technical architecture at the middleware level.

  • The Legacy Integration Model

    Force either modifies existing legacy applications or acquires non-NSPIS applications which use or replace interfaces defined within implemented NSPIS applications.

NSPIS Technical Reference Model

This section contains descriptions of the Application Platform component complete with approved or contender standard, service, and product names.

This section describes the Technical Reference Model (TRM), a more detailed view of the Logical Framework. The purpose of the TRM is to allow components of an existing or planned information system and the relationships between components to be recorded in a consistent manner.

The following diagram shows the TRM complete with the classes or types of services within the recommended categories on the Application Platform.



Figure: NSPIS Technical Reference Model

The set of services shown here is based upon TOGAF TRM with additions to reflect NSPIS-specific requirements. The additional NSPIS-specific services are Intranet Services, Telephony, MIS Services, Workflow Services, GIS, and Mobile Radio Services. These are services which would normally exist in more than one service category and/or in the Application Software tier. At this level of detail the framework depicts entities, interfaces, and service areas only and does not imply inter-relationships between the service areas.

Conforming to the model does not mean that each application will implement all or only these named services without any additional facilities. The intention of the NSPIS TRM is that applications will use a set of services tailored to their specific business area needs.

Each service within the application platform is described under four headings:

  • Mandated Components
  • Approved Components
  • Interoperable Components
  • Illustrative Components

The component definitions and standards profile are maintained as a reference as standard definitions for NSPIS suppliers and Police IT community. Inclusion does not imply selection. Conforming to the model does not mean that each application will implement all or only these named services without any additional facilities. The intention of the NSPIS TRM is that applications will use a set of services tailored to their specific business area needs.

Interoperability

It is important that the components on the application platform are able to interoperate and do not mutually interfere one with the other. To this end, suppliers fill in an interoperability matrix which contains rows of all the application-specific components and columns of all the application-specific components, other generic components, and any other components used by other NSPIS applications which are not already included. (See table below.)

 

 

Application-Specific

Other Generic

Other NSPIS

 

 

Components

Components

Components

Ref1

App Spec Compt 1

 

 

 

Ref2

App Spec Compt 2

 

 

 

Ref3

App Spec Compt 3

 

 

 

Ref4

App Spec Compt 4

 

 

 

etc.

 

 

 

 

Suppliers indicate by a tick whether they interoperate with the other components. If they do not interoperate directly but through another (intermediate) component listed, then the reference number of that intermediate component is inserted in the box. Where they do not interoperate, a cross is inserted.

Design templates for the Interoperability Processes in each application will be developed in conjunction with the application project teams before full proposals. Suppliers indicate the components involved in providing interoperability with other NSPIS applications, that is:

  • Desktop-to-application interoperability
  • Application-to-application interoperability
  • Application-to-database interoperability
  • Database-to-database interoperability

Technical Requirements and Views

Suppliers will be asked to respond to technical requirements under business, information, application, and engineering headings for each of the number of views.

The Requirement Views are a definition of the architecture in terms of the requirements that they set out to satisfy. Each requirement is broken down and considered under four headings: Business requirement, Information requirement, Application requirement, and an Engineering requirement. Within each of these requirements it will specify if it is:

M
Mandatory: suppliers must conform to a constrained or specified solution set.
R
Required: suppliers must provide a solution.
O
Optional: suppliers may provide and state how or give reasons for omission.

There are 10 views, each with the four requirements. They are: User, Organization, Management, Operations, Processing Platform, Integration, Data Management, Security, Contract, and Service Delivery. This produces an 4 X 10 matrix. (See below.)

 

Business

Information

Application

Engineering

User

 

 

 

 

Organization

 

 

 

 

Management

 

 

 

 

Operations

 

 

 

 

Processing Platform

 

 

 

 

Integration

 

 

 

 

Data Management

 

 

 

 

Security

 

 

 

 

Contract

 

 

 

 

Service Delivery

 

 

 

 

Table: Requirements Matrix

As well as taking account of all the requirement views when selecting, implementing, and using the components of the application platform, the selection must take account of how well the components work together and what effect the choice one might have on the freedom of choice of another service. To assist in this choice, the application platform before and after each choice is compared using the metrics generated from each analysis. The analyses include gap analysis, value analysis, and risk analysis.

Whilst suppliers and integrators have necessarily to be constrained in their choice of application platform to ensure interoperability and portability, it is important to its relevance over time that suppliers are given every opportunity to comment on and submit alternative preferred or more appropriate components. This is particularly important where standards are immature, difficulties of component interoperability are being experienced, or mandated and preferred components are nearing obsolescence or irrelevance. Similarly suppliers, IT departments, and users must be able to exploit new methods and technology paradigms and incorporate them into the architecture without compromising the current applications or architectures.

The Architecture in Action

Suppliers respond to the technical architecture at specific stages within the NSPIS application procurement and implementation cycle. Each differs in detail depending on the procurement route adopted for each application and the type of product sought.




Case Studies

Role    Summary


The Role of Case Studies

One of the goals of The Open Group's Architecture Forum is to provide a forum within which both customer and vendor organizations can exchange feedback and experience in the use of TOGAF.

All of this feedback is considered in the on-going evolution of TOGAF within the Architecture Forum, and indeed much of it has already been incorporated in this current version of TOGAF.

It is important to emphasise that no case study can provide a complete blueprint for how another organization should go about using TOGAF. All organizations are different, and each organization should understand what TOGAF has to offer, and adopt and adapt the parts that are useful for its needs.

Nevertheless, over the years of its existence as an architectural framework, TOGAF has been used by a variety organizations around the world in major architecture developments, both in its entirety, and in an adapted form.

It is hoped that the case studies presented here will provide useful guidance to organizations intending to use TOGAF or considering using it to develop an enterprise IT architecture.

The formats of the case studies vary, between normal descriptive text, through presentations, and in some cases video.


Summary of Case Studies

The following case studies show TOGAF in use in a variety of situations.

 

Dairy Farm Group (Hong Kong)

The Dairy Farm Group case study illustrates extensive use of TOGAF as the basis of an enterprise-wide IT architecture to integrate many disparate business units.

The Dairy Farm Group (DFG) is a holding company in the Retail sector. It has a very strong presence in the Asia / Pacific region, and is the 71st largest retailing company world wide.

DFG has a corporate goal to be the largest, most successful retailer in Asia / Pacific in its chosen markets. To support this goal, DFG has restructured from a federation to a unified group of companies, with a single corporate purpose business focus, and a single IT infrastructure. 

The DFG Technical Program Architecture Group (TAPG) was chartered to develop a Technical Architecture for DFG, and chose TOGAF and its supporting methodology as the basis. Using TOGAF, the TAPG was able, in a very short period of time, from July through October 1998, to develop a world class technical architecture.

It was particularly helpful to be able to point key suppliers to a published version of TOGAF, so that they could see an explanation of the methodology and refer to the TOGAF Standards Information Base. 

Formats:

  • This case study has its own web site. Specific formats:

An more recent update (2001) is also available.

Department of Social Security (UK)

The UK Department of Social Security (DSS) is responsible for the development, maintenance and delivery of the United Kingdom's social security programme. It utilises the largest civilian computer operation in Europe.

The DSS case study illustrates the use of TOGAF, both as the basis of a new architectural framework, and as a key tool in managing the outsourcing of service delivery, in that vendors and integrators were required to use TOGAF as the basis for their tenders, and to use it subsequently in the on-going management of the IT architecture.

Litton PRC (US)

Litton PRC chose the TOGAF Architecture Development Method as a basis for its revamped internal Architecture Design Process. The Litton PRC case study (PDF) reviews the use of TOGAF within Litton PRC, and explains why TOGAF was chosen.

Also, the JEDMICS case study illustrates the early stages of the Architecture Development Method in use on a specific project.

Ministry of Defence (UK)

The UK Ministry of Defence in its case study shows how the Architecture Development Methodology can be used to develop an organization-specific architectural framework, allowing independent operating divisions to develop their own architectures while ensuring that they share a common core operating environment.

National Health Service (UK)

The UK National Health Service is testing TOGAF for use as a standard framework for IT architectures.

It is hoped to provide a formal case study in the near future, explaining the use of TOGAF in the NHS. In the interim, contact information can be found on the NHS IM&T web site.

NATO (Belgium)

NATO's ACEACCIS example illustrates the use of architecture views in architecture development.

Police IT Organization (UK)

The UK Police IT Organization (PITO) used TOGAF as the basis for the Technical Architecture for its National Strategy for Police Information Systems (NSPIS). 

The NSPIS case study includes a comprehensive approach to architecture views, and a methodology for ensuring interoperability between the building blocks of the final architecture.

QA Consulting

QA Consulting are a UK consultancy and training company whose mission is to improves IT effectiveness within large organisations. The company's focus is on enhancing the skills of people - optimising human capital investment, and providing IT expertise that complements in-house skills. The company is the UK’s No.1 IT Trainer, with 400+ Courses, both Instructor-lead and Internet-based, covering both technical and business skills.

The QA case study explains the company's apporach to using TOGAF, and gives an example of a recent client engagement in the Travel industry using TOGAF.

Statskonsult (Norway)

Statskonsult is the Department of IT Planning & Co-ordination, in the Directorate for Public Management, within the Norwegian Government. It used parts of the TOGAF Architecture Development Method to develop an architecture for an IT infrastructure for the public sector in Norway.

Formats:

  • The case study explains the general background to the project.
  • The use of the TOGAF Architecture Development Methodology is explained in a separate presentation (PDF).

Westpac (Australia)

Westpac is a major Australian bank who have used TOGAF in collaboration with IBM, in much the same way as the UK Department of Social Security - i.e., as the basis of managing the technology components of a major outsourcing relationship.


Copyright � The Open Group, 1998, 1999, 2001


0 comments

Leave a Reply

Your email address will not be published. Required fields are marked *