Enterprise architecture is a management practice that was initially developed within the IT discipline to manage the complexity of IT systems, as well as the ongoing change constantly triggered by business and technology developments.
Today, one of the primary reasons EA is adopted in organizations worldwide is to promote alignment between business requirements and IT solutions. EA is expanding into other business disciplines, as well: to enable business strategy development, improve business efficiency, facilitate knowledge management and assist with organizational learning, to name a few.
In order to effectively implement EA in organizations, architects are increasingly looking for best practices and frameworks to assist them. One of the few architecture frameworks publicly available to guide architects in their implementation is TOGAF. Put simply, TOGAF is a comprehensive toolset for assisting in the acceptance, production, use and maintenance of enterprise architectures. It is based on an iterative process model supported by best practices and a reusable set of existing architectural assets. Since it was developed by members of The Open Group Architecture Forum more than 10 years ago, TOGAF has emerged as arguably the de facto standard framework for delivering enterprise architecture.

 History of TOGAF

TOGAF was developed and is currently maintained as a standard by The Open Group, a vendor- and technology-neutral consortium focused on a diverse range of open standards and affiliated certification programs, as well as advancing the profession of enterprise architecture. The first version of TOGAF, developed in 1995, was based on the U.S. Department of Defense Technical Architecture Framework for Information Management (TAFIM). Starting from this sound foundation, The Open Group Architecture Forum has developed successive versions of TOGAF at regular intervals and published each one on The Open Group public Web site.
Each version of the TOGAF standard is developed collaboratively by the members of the Architecture Forum - currently more than two hundred corporate members, including vendor and customer organizations. The development is carried out by architecture practitioners with the content based on proven best practices that evolved within the participating member companies.
The initial seven versions of TOGAF addressed technology architecture based on the adoption of architecture in businesses at the time each was written. In 2002, Version 8, the “Enterprise Edition,” was published, with refreshes to Version 8.1 in 2003 and Version 8.1.1 in 2006. It expanded the scope of TOGAF from a purely technology architecture to an enterprise architecture by including business and information systems architecture in the new version.
In 2004, The Open Group launched a TOGAF certification program for individuals and organizations. Anybody who wants to be certified as a having knowledge of TOGAF can either attend a certified training course presented by a training provider or complete an online examination. There has been a popular uptake of this program by architects globally over the past five years, with more than 9,400 certified practitioners as of January 2009, emphasizing that TOGAF is one of the leading architecture frameworks worldwide.

What’s New in TOGAF 9?

After the publication of TOGAF 8.1.1, the Architecture Forum began its work on TOGAF Version 9 (publicly available in February 2009). In order to meet the needs of TOGAF users, a survey was conducted in the first quarter of 2007 to determine the requirements for the next version. Three prominent views were expressed in this survey:

  • The need for closer alignment with the business,
  • The desire for simple implementation and greater usability and
  • The next version of TOGAF should be an evolution rather than a revolution.

These views provided the required direction for the developers of TOGAF 9 to get started on the next revision. Emerging architecture trends, such as SOA and the emphasis on security, were also considered, as well as alignment with The Open Group vision of “Boundaryless Information Flow.” Considering the number of certified practitioners and the broad adoption of TOGAF, the principle of evolution rather than revolution was a key driver in the development of TOGAF 9. For that reason, the phases of the Architecture Development Method (ADM) as presented in TOGAF 8 remain the same for TOGAF 9. This will simplify the migration process for organizations that implemented TOGAF 8, as well as for certified practitioners.
In order to simplify the implementation of TOGAF 9, a modular structure is introduced in the new version. Whereas TOGAF 8 had a resource base that presented a mixture of best practices, the content of TOGAF 9 is more logically structured into seven distinct parts:

  • An overview of TOGAF and a definition of core concepts used in TOGAF.
  • The ADM, which provides the generic method for architecture development.
  • Guidelines and techniques for implementing TOGAF.
  • The Architecture Content Framework, a major addition to the standard that guides the architect in structuring and managing the architecture repository and deliverables.
  • Generic architecture reference models in parts 5 and 6.
  • Guidance on setting up an architecture capability in an organization.

The Architecture Content Framework is a recommended framework that provides a reference model to architects that can be applied in any industry. Introducing this content into TOGAF has provided a more consistent definition of architecture deliverables. This is, however, a recommended framework and is not considered a core element of TOGAF, providing the flexibility for organizations to use alternate content frameworks that are more industry-specific or have already been implemented in their companies. To promote closer alignment with business objectives, more detail was added to the architecture implementation phases of the ADM that assists architects in planning their role out of architecture. Additional guidelines were also added to address topics such as risk and change management.
Service-oriented architecture and security architecture are addressed in part 3 of TOGAF 9 to indicate how the standard can be used to address these two specific architecture styles. For implementation purposes, SOA is considered a style of architecture, so the ADM can be used to implement SOA just as it can be used for any other architecture.
In an effort to provide more guidance on how to implement TOGAF, two valuable sections were added in part 3, the first addressing how to apply iterations to the ADM and the second explaining how the ADM can be implemented at various levels in the organization. These sections emphasize the generic nature of the ADM and show that it can be applied to define the IT strategy or to define the more detailed architecture for a solution to be implemented. The ADM can be used on an enterprise, divisional or project level.

Migrating to TOGAF 9

The migration to TOGAF 9 should be fairly simple for organizations that have already adopted and implemented TOGAF 8. The two key focus areas are the Architecture Content Framework and the Architecture Implementation phases of the ADM.
If an organization has already adopted an alternative framework to structure its architecture repository and deliverables, the TOGAF 9 Architecture Content Framework provides a reference framework to determine the state of its existing repository.
Whereas more focus was placed on architecture development in TOGAF 8, TOGAF 9 provides more detail on architecture implementation to guide organizations in refining their existing architecture process.

Implementing TOGAF 9

Architecture should not be treated as a project in an organization, but rather as a sustainable, embedded capability that delivers business-appropriate and valued deliverables that enable business capabilities. Establishing this capability is not an easy task, and many businesses have attempted this without success. TOGAF 9 provides a comprehensive framework that guides architects in establishing a comprehensive architecture capability based on specific business requirements.
The three key aspects that should be considered in establishing the capability are the architecture process, the architecture repository and the architecture organization. TOGAF 9 addresses all these aspects based on best practices that have been implemented by Open Group member organizations. These three aspects are interdependent and cannot be implemented in isolation.
The ADM provides a generic architecture process that has already been implemented in a number of companies globally. The intent behind the ADM is to provide a generic process as a guideline for the architect, but one that can be tailored to align with the management processes and practices within each organization. Factors to consider when implementing the ADM are the program and process management processes, the change management process, the product and system development processes, and the corporate and IT governance practices and policies. The architecture process should have interfaces to all of these. The architecture footprint and the positioning of architecture within the organization will also impact the implementation.
The second aspect deals with the architecture deliverables that will be stored in an architecture repository. The repository should be seen as a virtual repository and is not necessarily only one physical repository. The Architecture Content Framework and the reference models in TOGAF 9 provide excellent guidance for implementing a logically structured repository. Again, these are generic frameworks and other industry frameworks should be considered. Using the ADM does not prescribe the use of the Architecture Content Framework. Any classification framework appropriate to the organization can be considered. The architecture process would, however, indicate the type of deliverables that should be developed and stored in the architecture repository. TOGAF 9 also provides guidance on the selection of architecture repository solutions.
Establishing the architecture organization should provide clear roles and responsibilities, including the required governance structures. TOGAF 9 provides guidance on the various architecture roles and skills required, as well as recommendations on architecture governance. The architecture organization should be referenced both in the architecture process to indicate responsibility for activities, as well as in the architecture deliverables to indicate ownership.
Clearly, the three aspects should be implemented simultaneously. The capability should, however, evolve over time to grow in maturity and adapt to the needs of the organization. At certain stages of the maturity cycle more emphasis would be placed on a certain aspect than on others. At the beginning phases of the capability more emphasis might, for instance, be placed on the architecture deliverables, whereas the process or organization would be more important at later stages.
TOGAF has evolved over the last 15 years into a comprehensive architecture framework that is based in practice and adopted globally as the de facto standard for architecture development and implementation. TOGAF 9 was developed in response to requests from existing users to provide a more accessible and easier framework to implement, addressing the key aspects of establishing a sustainable and business-appropriate architecture capability in organizations.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access