Frequently Asked Questions explains that there are four kinds of ``architecture'' that are commonly accepted as subsets of an overall enterprise architecture:
The combination of Data Architecture and Applications Architecture is also referred to as the Information System Architecture.
TOGAF was originally designed to support the last of these - the Technology Architecture. Over its years of evolution, however, it has acquired many of the facets of a framework and method for enterprise architecture. As of TOGAF Version 8, these different facets have been integrated, and TOGAF has undergone a major redevelopment, with the result that it is now a fully-fledged enterprise architecture framework.
With Version 8.1, the numbering scheme for successive releases of TOGAF has been modified, to include a major and minor release indicator. Version 8.1 builds on the base established in Version 8, by adding new information in a number of areas.
TOGAF in its Enterprise Edition remains what it has always been, namely an architectural framework - a set of methods and tools for developing a broad range of different IT architectures. It enables IT users to design, evaluate, and build the right architecture for their organization, and reduces the costs of planning, designing, and implementing architectures based on open systems solutions.
The key to TOGAF remains a reliable, practical method - the TOGAF Architecture Development Method (ADM) - for defining business needs and developing an architecture that meets those needs, utilizing the elements of TOGAF and other architectural assets available to the organization.
A number of enterprise architecture frameworks already exist and are widely recognized, each of which has its particular advantages and disadvantages - and relevance - for enterprise architecture. They are discussed in Part IV: Resource Base, Other Architectures and Frameworks .
Although a number of enterprise frameworks exist, there is no accepted industry standard method for developing an enterprise architecture. The goal of The Open Group with TOGAF is to work towards making the TOGAF ADM just such an industry standard method, which is neutral towards tools and technologies, and can be used for developing the products associated with any recognized enterprise framework - such as the Zachman Framework, Federal Enterprise Architecture Framework (FEAF), Treasury Enterprise Architecture Framework (TEAF), and C4ISR/DoD Framework - that the architect feels is appropriate for a particular architecture.
The TOGAF ADM therefore does not prescribe any specific set of enterprise architecture deliverables - although it does describe a set by way of example. Rather, TOGAF is designed to be used with whatever set of deliverables the TOGAF user feels is most appropriate. That may be the set of deliverables described in TOGAF itself; or it may be the set associated with another framework, such as the Zachman Framework, FEAF, etc.
In fact, TOGAF has always done this: it does not prescribe a specific set of ``architecture views'', but describes an example taxonomy of the kinds of views that an architect might consider developing, and why; and it provides guidelines for making the choice, and for developing particular views, if chosen.
With the migration of TOGAF to an enterprise architecture framework, this flexibility becomes even more important. TOGAF is not intended to compete with these other frameworks; rather, it is intended to perform a unique role, in distilling what these other frameworks have to offer, and providing a generic ADM that can be adapted for use with any of these other frameworks.
The Open Group's vision for TOGAF is as a vehicle and repository for practical, experience-based information on how to go about the process of enterprise architecture, providing a generic method with which specific sets of deliverables, specific reference models, and other relevant architectural assets, can be integrated.
As governance has become an increasingly visible requirement for organizational management, the adoption of governance into TOGAF aligns the framework with current business best practice and also ensures a level of visibility, guidance, and control that will support all architecture stakeholder requirements and obligations.
The benefits of architectural governance include:
In particular, increased visibility of decision-making at lower levels ensures oversight at an appropriate level within the enterprise of decisions that may have far-reaching strategic consequences for the organization.
In particular, enterprise architecture increasingly represents the core intellectual property of the enterprise.
Studies have demonstrated a correlation between increased shareholder value and well-governed enterprises.
Further detail on architecture governance is given in Part IV: Resource Base, Architecture Governance .
Two of the key elements of any enterprise architecture framework are:
With some exceptions, the majority of enterprise architecture frameworks focus on the first of these - the specific set of deliverables - and are relatively silent about the methods to be used to generate them (intentionally so, in some cases).
Because TOGAF is a generic framework, as mentioned above, and intended to be used in a wide variety of environments, it does not prescribe a specific set of deliverables; rather it talks in general terms about the types of deliverable that need to be produced, and focuses instead on the methods by which these should be developed.
As a result, TOGAF may be used either in its own right, with the generic deliverables that it describes; or else these deliverables may be replaced by a more specific set, defined in any other framework that the user architect considers relevant.
In the latter case, the user architect will adapt and build on the TOGAF ADM in order to define a tailored method and process for developing these more specific deliverables. Guidelines for adapting the TOGAF ADM in such a way are given in Part II: Architecture Development Method (ADM), Adapting the ADM .
As a generic framework and method for enterprise architecture, TOGAF also complements other frameworks that are aimed at specific vertical business domains, specific horizontal technology areas (such as security or manageability), or specific application areas (such as e-Commerce). The concept of leveraging other relevant architectural assets in this way is known within TOGAF as the Enterprise Continuum.
TOGAF embodies the concept of the Enterprise Continuum (described in Part III: Enterprise Continuum), to reflect different levels of abstraction in an architecture development process. In this way TOGAF facilitates understanding and co-operation between actors at different levels. It provides a context for the use of multiple frameworks, models, and architecture assets in conjunction with the TOGAF ADM. By means of the Enterprise Continuum, architects are encouraged to leverage all other relevant architectural resources and assets, in addition to the TOGAF Foundation Architecture, in developing an organization-specific IT architecture.
In this context, the TOGAF ADM can be regarded as describing the process of moving from the TOGAF Foundation Architecture to an organization-specific architecture (or set of architectures), leveraging the contents of the Enterprise Continuum along the way, including the TOGAF Foundation Architecture and other relevant architectural frameworks, models, components, and building blocks.
TOGAF thus does not seek to compete with or duplicate other frameworks. What TOGAF does seek to provide is a practical, industry
standard method of doing enterprise architecture - leveraging all relevant assets in the process - that is freely available and
supported by a number of different architecting consultancies, and that is sufficient for an organization to use ``as-is'' or to
adapt as the basis of an enterprise architecture method for other, deliverables-focused frameworks.
return to top of page
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.