| You are here: | ||
| <<< Previous | Home | Next >>> |
TOGAF is one of a number of architectures and architecture frameworks in use today. Many of the other architectural initiatives have a good deal in common with TOGAF. In the following sections these initiatives are briefly described and their relationships to the TOGAF elements are explored.
The acronym C4ISR stands for Command, Control, Computers, Communications (C4), Intelligence, Surveillance, and Reconnaissance (ISR). The C4ISR Architecture Framework Version 2.0 is a framework giving comprehensive architectural guidance for all of these related US Department of Defense (DoD) domains, in order to ensure interoperable and cost-effective military systems. It has emerged in recent years as a successor to the Technical Architecture Framework for Information Management (TAFIM), which was officially withdrawn in January 2000.
The C4ISR Architecture Framework is under revision to generalize it to apply to all functional areas of the DoD. It is already being used in government areas beyond the Defense sector.
The impetus for the C4ISR Architecture Framework was the realization within the DoD that Defense organizations across the world were developing architectures representing specific contributions and relationships with respect to overall DoD operations, but that significant differences in content and formats were inhibiting the ability to rationalize or compare different architecture descriptions. In turn, disparate and unrelatable architecture products were leading to non-integrated, non-interoperable, and non-cost-effective capabilities in the field.
The C4ISR Architecture Framework is intended to ensure that the architecture descriptions developed by the various commands, services, and agencies within the DoD are inter-relatable between and among each organization's operational, systems, and technical architecture views, and are comparable and integratable across joint and multi-national organizational boundaries.
In particular, the C4ISR Architecture Framework:
Whereas the Architecture Development Method (ADM) forms a core part of TOGAF, guidance in the C4ISR Architecture Framework concerning the process of describing an architecture - i.e., what steps to perform and in what order - has intentionally been kept to a minimum. There are several reasons for this:
The most critical aspect of the guidance is that the purpose for building the architecture description should be clearly understood and articulated up front. This purpose will influence the choice of what information to gather, what products to build, and what kinds of analysis to apply.
A major structural concept in the C4ISR Architecture Framework is the three sets of "views" (Operational, System, Technical). The use of the term "view" in the C4ISR Architecture Framework is different from the use of the term in TOGAF, although there is a rough correspondence:
A number of the products (deliverables/artifacts) defined in the C4ISR Architecture Framework have no equivalent in the TOGAF ADM because the ADM does not go down to the level of detail that these particular C4ISR products address. These C4ISR products are at the level of system design rather than architecture. Specific organizations tailoring the ADM to their own needs might decide to go to this level of detail, however (typically, by including them in the Target Architecture step in Phases B, C, and D).
The Object Management Group's (OMG) Object Management Architecture (OMA), often loosely referred to as the CORBA architecture, is an object-oriented Applications Architecture centered on the concept of an Object Request Broker (ORB) (see www.omg.org/gettingstarted). The ORB acts as a switching center, locating objects, storing interface definitions and object implementations, and relaying messages between objects in a distributed heterogeneous environment.
CORBAservices are a low-level set of common object services available to all objects, covering functions like object creation and deletion, naming, security services, and many others.
Horizontal CORBAfacilities are higher-level functions such as distributed documents or printing, suitable for use in a wide variety of market sectors.
Domain CORBAfacilities are vertical market-specific interfaces which will provide common facilities for applications within a particular market sector.
The CORBA architecture, or OMA, is an application-level architecture which focuses exclusively on issues affecting distributed object-oriented systems. It is entirely consistent with TOGAF, and depends on the presence of lower-level facilities such as those described by TOGAF for operating system support, communications, and so on.
Object-based service categories in TOGAF are called out in Object-Oriented Provision of Services .
Steven Spewak's Enterprise Architecture Planning (EAP) is a set of methods for planning the development of Information, Applications, and Technology Architectures (the recommended approach being to develop them in that order), and for aligning the three types of architecture with respect to each other. The goal is to ensure that such architectures form the blueprints for sound, implementable systems that solve real business problems.
The overall EAP methodology involves the following "steps":
The EAP methodology thus positions the four types of "architecture" in the sequence: Business Architecture, Data Architecture, Applications Architecture, and Technology Architecture as the recommended sequence.
Spewak's EAP methodology is analogous to the TOGAF ADM:
EAP does not have a taxonomy of the various viewpoints and views, or a Foundation Architecture (Technical Reference Model (TRM) and Standards Information Base (SIB)).
The US Federal CIO Council published A Practical Guide to Federal Enterprise Architecture (Version 1.0) in February 2001, in a cooperative venture with the General Accounting Office (GAO) and the Office of Management and Budget (OMB). The purpose of this document is to provide guidance to US federal agencies in initiating, developing, using, and maintaining their enterprise architectures. This guide offers an end-to-end process to initiate, implement, and sustain an enterprise architecture program, and describes the necessary roles and responsibilities for a successful enterprise architecture program. The guidance presented in the practical guide should be tailored by each federal agency according to its needs.
This guide focuses on enterprise architecture processes, products, and roles and responsibilities. The guide addresses how enterprise architecture processes fit within an overall enterprise lifecycle; namely, by describing in detail how the enterprise architecture processes relate to enterprise engineering, program management, and Capital Planning and Investment Control (CPIC) processes, as summarized in the following figure:
At the initiation of its enterprise architecture program, each agency should establish the scope of its enterprise architecture and formulate a strategy that includes the definition of a vision, objectives, and principles. The following figure summarizes the enterprise architecture processes.
Executive buy-in and support should be established and an architectural team formed within the organization. The team defines an approach and process tailored to agency needs. The architecture team implements the process to build both the Baseline and Target Architectures. The architecture team also prepares a sequencing plan for transitioning systems, applications, and associated business practices, based on gap analyses and business drivers. Projects are selected and controlled in the CPIC and the enterprise engineering and program management processes and are guided by, and compliant with, the enterprise architecture. Lastly, the architecture is maintained through a continuous modification to reflect the agency's baseline and target business practices, organizational goals, visions, technology, and infrastructure.
The Practical Guide's enterprise architecture processes closely align with the lifecycle phases of the TOGAF ADM. In addition, the Practical Guide adds steps such as establishing an enterprise architecture policy and principles.
The US Federal CIO Council published the Federal Enterprise Architecture Framework (FEAF) (Version 1.1) in September 1999. The FEAF promotes shared development for US federal processes, interoperability, and sharing of information among US federal agencies and other governmental entities. The FEAF provides direction and guidance to federal agencies for structuring an enterprise architecture. The FEAF describes eight components of an enterprise architecture:
The FEAF also provides direction for establishing "federal segments", which are cross-agency business areas (such as international trade, grants, common patient records) that transcend federal agency boundaries. These federal architectural segments collectively constitute the Federal Enterprise Architecture.
The FEAF partitions a given architecture into Business, Data, Applications, and Technology Architectures, as shown in the following figure. The FEAF currently includes the first three columns of the Zachman Framework and the Spewak Enterprise Architecture Planning (EAP) methodology.
The following figure shows the FEAF Architecture Matrix, which names the enterprise architecture products to be developed for each cell. Version 1.1 of the FEAF does not prescribe the contents or approach for developing these work products.
The FEAF contains guidance analogous to the TOGAF Foundation Architecture and architecture viewpoints and views. The rows of the FEAF matrix (which correspond to the Zachman Framework) do not directly map to the TOGAF structure, although the ADM mapping to the Zachman Framework supports a close correlation between the FEAF and TOGAF. The columns of the FEAF matrix correspond directly to three of the four architecture domains covered by TOGAF (TOGAF also covers Business Architecture).
ISO/IEC TR 14252:1996, Guide to the POSIX Open System Environment, is a direct line ancestor of TOGAF. TOGAF was originally based on the US DoD Technical Architecture Framework for Information Management (TAFIM), which was itself a development of ISO/IEC TR 14252.
At the topmost level, ISO/IEC TR 14252, TAFIM, and TOGAF share a very similar high-level reference model. ISO/IEC TR 14252 does not include a diagram giving a detailed breakdown of the Application Software, Application Platform, or external environment entities, but the remainder of the document breaks down the Application Platform into a number of similar, though not identical, areas.
TOGAF includes a considerable amount of material on architecture development which is lacking from ISO/IEC TR 14252, while ISO/IEC TR 14252 includes a considerable amount of detail in service category definition and in the recommended lists of standards and specifications.
The architectural approach taken in ISO/IEC TR 14252 is broadly similar to that of TOGAF, in that the architecture reference model diagram implies no structure among the service categories, leaving that to individual system architectures and real-world implementations.
The description of the NCR Enterprise Architecture Framework, including a comparison with TOGAF, is hosted on NCR's own web site (see www3.ncr.com/architecture/togaf).
The NCR Enterprise Architecture Framework is based on NCR's architecture practice Global Information Technology Planning (GITP), and NCR's architecture model Open Cooperative Computing Architecture (OCCA 6). The Enterprise Architecture Framework was created to guide the development of systems, industry, and customer-specific architectures.
The ISO Reference Model for Open Distributed Processing (ITU-T Rec. X.901 | ISO/IEC 10746-1 to ITU-T Rec. X.904 | ISO/IEC 10746-4), commonly referred to as RM-ODP, provides a framework to support the development of standards that will support distributed processing in heterogeneous environments. It is based, as far as possible, on the use of formal description techniques for specification of the architecture.
RM-ODP uses an object modeling approach to describe distributed systems. Two structuring approaches are used to simplify the problems of design in large complex systems: five viewpoints provide different ways of describing the system; and eight transparencies identify specific problems unique to distributed systems which distributed system standards may wish to address. Each viewpoint is associated with a language which can be used to describe systems from that viewpoint.
The five viewpoints described by RM-ODP are:
RM-ODP is very tightly focused on problems relating to interactions between the objects making up distributed information processing systems, while TOGAF embraces the full spectrum of systems, whether distributed or not. As such, TOGAF coverage is a superset of that provided by RM-ODP. However, the relationship between the viewpoints described by RM-ODP and the TOGAF views is not an obvious one, and there is some danger of confusing the two.
In fact, each RM-ODP viewpoint is an examination of a distributed system at a different level of detail, while TOGAF adopts the ANSI/IEEE Std 1471-2000 approach to views as representations of a whole system from the perspective of a related set of concerns. This makes it impractical to try to compare the set of TOGAF views with RM-ODP viewpoints.
A better comparison can be made between the RM-ODP viewpoints and the different levels of detail used by TOGAF in the examination of building blocks. In Building Blocks and the ADM , Iteration between the Four Levels of Modeling shows how the iterative process of building block definition can be divided into the Business Process level, the Technical Functionality and Constraints level, the Architectural Model level, and the Solution Model level.
The mapping between the building blocks example and ODP viewpoints is as follows:
|
Business Process level |
<==> |
Enterprise and Information viewpoints and Technical Functionality and Constraints level |
|
Architectural model level |
<==> |
Computational viewpoint |
|
Solution level |
<==> |
Technology and Engineering viewpoints |
The Service Providers' Integrated Requirements for Information Technology (SPIRIT) Platform Blueprint is a specification that was developed within the Network Management Forum, now known as the TeleManagement Forum (TMF - www.tmforum.org). The SPIRIT Platform Blueprint Issue 3.0 is published by The Open Group (see www.opengroup.org/bookstore/catalog/sp.htm).
SPIRIT is a joint effort between telecommunication service providers, computer system vendors, and independent software vendors, with the goal of producing a common, agreed set of specifications for a general-purpose computing platform. The objective is to provide a core set of specifications for use in each company's purchasing of software components for general-purpose computing platforms. The SPIRIT specifications are based predominantly on widely accepted industry standards.
SPIRIT defines a practical, tested selection of specifications, most of which are referenced within the TOGAF Standards Information Base (SIB), that achieves portability and interoperability for largescale systems. The focus of SPIRIT is on ensuring that the SPIRIT selections are agreed upon by the vendor side for implementability and on the user side for procurability.
The US Department of Defense (DoD) Technical Architecture Framework for Information Management (TAFIM) was developed from
ISO/IEC TR 14252:1996, Guide to the POSIX Open System Environment (IEEE Std 1003.0), and was used as the basis of TOGAF Version 1.
As a result, there is a strong resemblance between the three.
On January 7th, 2000 TAFIM was officially canceled by the DoD. The TAFIM web site has been archived at www-library.itsi.disa.mil/tafim.html, where it will continue to be available for information and reference purposes only. A number of new documents have been developed that supersede specific TAFIM subject areas. These are:
TAFIM was the parent of TOGAF, and the US Defense Information Systems Agency (DISA) contributed extensively to the development of TOGAF, with the result that the two architecture frameworks have much in common. The TOGAF Technical Reference Model (TRM) was largely derived from TAFIM, and the TOGAF Architecture Development Method (ADM) was originally based on parts of TAFIM.
In July 2000, the Department of the Treasury published the Treasury Enterprise Architecture Framework (TEAF). The TEAF provides:
The TEAF describes an architecture framework that supports Treasury's business processes in terms of work products. This framework guides the development and redesign of the business processes for various bureaus in order to meet the requirements of recent legislation in a rapidly changing technology environment. The TEAF prescribes architecture views and a set of essential and supporting work products to portray these views. The following figure illustrates the TEAF framework.
The TEAF's functional, information, and organizational architecture views collectively model the organization's processes, procedures, and business operations. By grounding the architecture in the business of the organization, the TEAF defines the core business procedures and enterprise processes. Through its explicit models, a TEAF-based architecture enables the identification and reasoning of enterprise and system-level concerns and investment decisions.
The TEAF separates enterprise architecture information into Enterprise Architecture Direction (drivers, policies, program roadmap), Enterprise Architecture Description, and Enterprise Architecture Accomplishment (transition strategy, technical forecasts, and insertion). The Enterprise Architecture Description is a matrix, with columns being views (functional, information, organizational, and infrastructure) and rows being perspectives (planner, owner, designer, builder). Many of the TEAF work products are also in the C4ISR Architecture Framework. However, TEAF introduces the Information Assurance Trust Model, Information Assurance Risk Assessment, and the Enterprise Architecture Roadmap. The Enterprise Architecture Roadmap summarizes the scope of the bureau's enterprise architecture, the drivers, governance plan, approach and methodology, and program plan.
Many of the observations made in describing the relationship of the C4ISR Architecture Framework to TOGAF apply also to the TEAF. Namely, the TEAF is prescriptive as to what work products should be produced, and the term view/perspective is used differently.
The Zachman Framework is a framework providing a view of the subjects and models needed to develop a complete enterprise architecture. This framework is described in detail at the ZIFA web site (see www.zifa.com/zifajz02.htm).
An alternative source is the University of Nebraska at Omaha, which gives a very detailed and highly readable description of the Zachman Framework.
The Zachman Framework is a widely used approach for developing and/or documenting an enterprise-wide Information Systems Architecture. Zachman based his framework on practices in traditional architecture and engineering. This resulted in an approach which on the vertical axis provides multiple perspectives of the overall architecture, and on the horizontal axis a classification of the various artifacts of the architecture.
The purpose of the Framework is to provide a basic structure which supports the organization, access, integration, interpretation, development, management, and changing of a set of architectural representations of the organization's information systems. Such objects or descriptions of architectural representations are usually referred to as artifacts.
The framework, then, can contain global plans as well as technical details, lists, and charts as well as natural language statements. Any appropriate approach, standard, role, method, technique, or tool may be placed in it. In fact, the Framework can be viewed as a tool to organize any form of metadata for the enterprise.
The ADM mapping to the Zachman Framework (see ADM and the Zachman Framework) supports a close correlation between the Zachman Framework and the TOGAF ADM.
The Zachman Framework provides a very comprehensive and well-established taxonomy of the various viewpoints, models, and other artifacts that an enterprise may want to consider developing as part of an enterprise architecture. (The recommendation of the Zachman Framework itself is that all the cells be covered.)
The current recommended set of viewpoints in TOGAF does not cover all 30 cells of the Zachman Framework. However, with TOGAF it is possible to develop viewpoints and views to cover other aspects of the Zachman Framework as necessary.
TOGAF recommends some viewpoints that are not included in the Zachman Framework; for example, the security and manageability viewpoints. The selection of viewpoints needs to be determined by the purpose of the architecture, and the TOGAF ADM defines a process for driving that selection.
The vertical axis of the Zachman Framework provides a source of potential viewpoints for the architect to consider. The horizontal axis could be regarded as providing a generic taxonomy of concerns.
The Zachman Framework says nothing about the processes for developing viewpoints or conformant views, or the order in which they
should be developed. It does not provide a method such as TOGAF's ADM, or a Foundation Architecture (Technical Reference Model
(TRM) and Standards Information Base (SIB)).
return to top of page
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.