Introduction C4ISR CORBA EAP Federal Enterprise Architecture - Practical Guide FEAF ISO/IEC 14252 (IEEE Std 1003.0) NCR EAF RM-ODP SPIRIT TAFIM TEAF Zachman Framework
TOGAF is one of a number of architectures and architectural frameworks in use today. Many of the other architectural initiatives have a good deal in common with TOGAF. In the documents linked in the following list, these initiatives are briefly described and their relationships to the TOGAF elements are explored.
To go to a specific architectural framework, follow the hyperlink from the list below.
Alternatively, to browse a number of architectures or frameworks, you may find it more convenient to use the hyperlinks in the Contents frame opposite.
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 DoD domains, in order to ensure interoperable and cost effective military systems. It has emerged in recent years as a successor to TAFIM, which was officially withdrawn in January 2000.
The Framework is under revision to generalize it to apply to all functional areas of the Department of Defense. It is already being used in government areas beyond the Defense sector.
Figure 1: C4ISR Architecture Framework - Three Views of an Architecture
The impetus for the Framework was the realization within the US Department of Defense that DoD 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 DoD are interrelatable 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 Framework:
Whereas its Architecture Development Method forms a core part of TOGAF, guidance in the C4ISR 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 aspects 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 at the level of system design rather than architecture. Specific organizations tailoring the ADM to their own needs might decide to go 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 Object Management Architecture (OMA), often loosely referred to as the CORBA architecture, is an object-oriented application architecture centered on the concept of an Object Request Broker (ORB). The Object Request Broker 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 the section 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 IT (or Technology) Architecture as the recommended sequence.
Spewak's EAP methodology is analogous to TOGAF's Architecture Development Method:
EAP does not have a taxonomy of the various viewpoints and views, or a Foundation Architecture (Technical Reference Model and Standards Information Base).
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 U.S. federal agencies in initiating, developing, using, and maintaining their enterprise architectures (EA). 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 EA processes, products, and roles and responsibilities. The guide addresses how enterprise architecture processes fit within an overall enterprise life cycle: 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 diagram:
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 enterprise 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 current baseline and target business practices, organizational goals, visions, technology, and infrastructure.
The Federal Practical Guide’s enterprise architecture processes closely align with the life cycle 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) [PDF, HTML], Version 1.1, in September 1999. The FEAF promotes shared development for U.S. federal processes, interoperability, and sharing of information among U.S. 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 Technical Report (TR) 14252:1996, Guide to the POSIX Open System Environment, is a direct line ancestor of TOGAF. TOGAF was originally based on the US Department of Defense Technical Architecture Framework for Information Management, or TAFIM, which was itself a development of ISO/IEC TR 14252.
At the topmost level, ISO/IEC 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.
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 Framework was created to guide the development of systems, industry, and customer specific architectures.
The Reference
Model of 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 modelling 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:
1. The enterprise viewpoint, which examines the system and its environment in the context of the business requirements on the system, its purpose, scope and policies. It deals with aspects of the enterprise such as its organizational structure, which affect the system.
2. The information viewpoint, which focuses on the information in the system. How the information is structured, how it changes, information flows, and the logical divisions between independent functions within the system are all dealt with in the information viewpoint.
3. The computational viewpoint, which focuses on functional decomposition of the system into objects which interact at interfaces.
4. The engineering viewpoint, which focuses on how distributed interaction between system objects is supported.
5. The technology viewpoint, which concentrates on the individual hardware and software components which make up the system.
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 Architecture Development Method, Figure 2 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 Block 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 TeleMangement Forum (TMF). The SPIRIT Platform Blueprint Issue 3.0 is published by The Open Group.
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, that achieves portability and interoperability for large-scale 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 Technical Architecture Framework for Information Management was developed from ISO/IEC Technical Report (TR) 14252 - 1995, 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.
As of 7th January, 2000, TAFIM has been officially cancelled by the DoD. The TAFIM website has been archived at http://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 contributed extensively to the development of TOGAF, with the result that the two architectural frameworks have much in common. The TOGAF Technical Reference Model was largely derived from TAFIM, and the TOGAF Architecture Development Method was originally based on parts of TAFIM.
In July 2000, the Department of the Treasury published the Treasury Enterprise Architecture Framework. The TEAF provides (1) guidance to Treasury bureaus concerning the development and evolution of information systems architecture; (2) a unifying concept, common principles, technologies, and standards for information systems; and (3) a template for the development of the enterprise architecture.
The TEAF describes an architectural 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 architectural 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.
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 supports a close correlation between the Zachman Framework and the TOGAF ADM.
The Zachman Framework provides a 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 and Standards Information Base).
Copyright © The Open Group, 1997, 1998, 1999, 2000, 2001, 2002