| You are here: | ||
| <<< Previous | Home | Next >>> |
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.
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.
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.
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:
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.
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:
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.
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.
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:
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 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.
Although the CISITAF tends to place a different emphasis on the elements, it includes all of those in the TOGAF base set, namely:
supported by descriptions of the architecture from different views.
These have been supplemented by a new framework component: the Model Technical Architecture.
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.
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.
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.
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.
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:
Essentially, these views are the same as those recommended by TOGAF, with two principal differences:
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.
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":
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:
In addition, the MTA specifies a number of general engineering principles, or qualities, that must be exhibited by all CISIT deliverables:
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:
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 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.
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.
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.
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 .
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 .
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 .
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 |
* |
|
|
|
|
* |
The standard application platform services provided in JEDMICS perform the following specific functions:
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.
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:
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.
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:
A final business process constraint is that the old and new software systems must coexist during the transition period of all 36 sites.
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.
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.
The Target Architecture for the new JEDMICS software followed a number of goals:
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:
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 .
The functional components of the new JEDMICS system architecture are shown in 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 |
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.
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.
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.
The first step along the road to achieving communication and information system (CIS) interoperability in the MoD involved two key activities:
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:
There were several existing TRMs on which the DCIS TRM could have been based. The choice of TRM was guided by the following considerations:
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:
The DCIS TRM is represented in DCIS TRM .
Further information about the definition of the DCIS TRM can be found in Volume 2 of the DCIS Standards Guides.
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):
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.
This step involved the application of the DCISF to an MoD project. The purpose of this was two-fold:
The general benefits that are brought to a CIS procurement from the use of the DCIS TRM and DCISF include the following:
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 following future MoD CIS interoperability activities are identified:
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:
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:
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.
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:
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:
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.
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.
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:
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.
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.
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.
The purpose of the technical architecture is to:
The NSPIS technical architecture is also intended as an aid to discussions with suppliers when it is important to ensure that:
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:
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:
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.
The NSPIS technical architecture is described in three volumes:
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:
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.
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:
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:
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.
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:
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.
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.
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.
Force either modifies existing legacy applications or acquires non-NSPIS applications which use or replace interfaces defined within implemented NSPIS applications.
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.
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:
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.
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:
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:
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 |
|
|
|
|
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.
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.
All NSPIS suppliers need details of each other's application-specific architectures to enable interoperability and consistency of change control. Mechanisms to achieve the desired level of co-operation and visibility of design are required from the NSPIS supplier community, PITO, and NSPIS application projects. These mechanisms are set up and further developed in conjunction with existing NSPIS suppliers and those suppliers short-listed and subsequently awarded NSPIS contracts. The selection and subsequent implementation of each NSPIS application platform informs subsequent selections and direction. NSPIS suppliers and the conformance testing agency are contributors to the debate with PITO and the Technical User Group.
QA Consulting are a UK consultancy and training company whose mission is to improves IT effectiveness within large organizations. The company's focus is on enhancing the skills of people - optimizing 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 Study3 explains the company's approach to using TOGAF, and gives an example of a recent client engagement in the Travel industry using TOGAF.
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 (ADM) to develop an architecture for an IT infrastructure for the public sector in Norway.
The Case Study explains the general background to the project. The use of the TOGAF ADM is explained in a separate presentation.4
In Norway, over 35% of the population are experienced in navigating the Internet. The Norwegian government intends to leverage this knowledge by using the Internet to deliver more effective and cost-efficient public administration services. Termed the Public Sector Network, this initiative is a joint venture between Norway's Ministry of National Planning and Co-ordination and the Norwegian Association of Local and Regional Authorities. The objective is to create a national Internet-based infrastructure that will enable the public administration (both local and central government) to transform from a traditional paper-based, bureaucratic organization into an easily-approached, responsive online body. Initially, over 100 paper-based reporting mechanisms between public bodies are being targeted for conversion to online systems. The aim is to convert every applicable service by 2001.
Through the Public Sector Network, the Norwegian people will be able to manage their relationship with the public administration in the fields of taxation, welfare, and other public administration functions. As a result, the Norwegian government will deliver improved service levels and significantly reduce its costs on currently labor-intensive, paper-based tasks. Consequent savings can then be allocated to furthering the public good in areas such as health care and education.
In helping to establish the Public Sector Network, an ongoing relationship has been established between the Norwegian Ministry of National Planning and Co-ordination and The Open Group.
The Open Group will serve as a central resource that tests, brands, and guarantees compatibility with IT DialTone specifications, products, and technologies. In this capacity, The Open Group will contribute substantially to the Norwegian Public Sector Network and similar projects around the globe.
Creating a national infrastructure such as the Public Sector Network poses a number of challenges. There are currently many point-solutions, technologies, and products from a growing number of suppliers. But how do companies wishing to utilize the Internet understand the benefits and risks associated with each one? Which ones work with each other, conform to agreed standards, or will remain relevant in five years' time? How do companies avoid making proprietary decisions that could erode the required benefits of the Internet?
"The more common approach to this project would have been to build one big government network that is planned, constructed, and managed centrally. However, this approach is not very flexible and would almost certainly have required the costly duplication or replacement of existing infrastructure - in fact it would probably have failed. It's really a challenge to match the formal, juridical framework with the needs of the marketplace, especially under the European Union rules for public procurement," says Gard Titlestad, Head of the Secretariat for IT Standardisation.
"The alternative is to adopt a more "open" approach that protects the vast investment of public money in existing infrastructure and enables the ongoing integration of new technology from a broad range of suppliers. To do this we identified the need for a common framework - an industry-agreed reference point by which to identify standards, products, and technologies that provide consistent features and attributes, such as security and reliability - now and in the future. A solution is to work closely with The Open Group to assist in the delivery of its IT DialTone architecture."
To ensure that the Public Sector Network remains flexible and maximizes the use of the latest market developments in technology and service, the project is based on a framework agreement. The IT DialTone set of technologies provides the framework with a reference point and an agreed approach to the development and implementation of Internet standard specifications, technologies, and products. In turn, this framework guides the procurement policies of each municipality and government department, guaranteeing a consistent approach to the network implementation. Yearly re-negotiation of the framework will consistently reflect market development dynamics.
Joseph De Feo, Former President & CEO of The Open Group said: "The Norwegian Government is leading Europe in the charge to realize the true social potential of the Internet. As part of this process they have identified the benefits of basing their future infrastructure development on robust, industry-agreed standards not on proprietary solutions, which they realize could eventually erode the country's ability to communicate freely with the world if alternative, non-compatible decisions are made by other governments, companies, or organizations."
With the Public Sector Network, Norway leads the world in creating a national, Internet-based infrastructure to administer public services and improve government operational efficiency. The country's proactive steps guarantee the construction of an effective, supplier-independent, and flexible national online resource.
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.
The Westpac Case Study5 gives an overview of the approach used and reactions.
The TOGAF document set is designed for use with frames. To navigate around the document:
Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063.