The Open Group Architecture Framework (TOGAF)

TOGAF® is a step-by-step method for developing an enterprise architecture, using a set of prescribed tools. It is freely available on the Open Group website for use by organizations wishing to develop an enterprise architecture. The first version was developed in 1995, which was based upon the Technical Architecture Framework for Information Management (TAFIM), developed by the US Department of Defense. The current version is version 9.2[1]

The Open Group Architecture Framework (TOGAF®) is a framework for enterprise architecture that provides an approach for designing, planning, implementing, and governing an enterprise information technology architecture. TOGAF® has been a registered trademark of The Open Group in the United States and other countries. TOGAF® is a high level approach to design. It is typically modeled at four levels: Business, Application, Data, and Technology. It relies heavily on modularization, standardization, and already existing, proven technologies and products.[2]

History of TOGAF® [3]
TOGAF®was created as a Technical Architecture methodology. In 1995 it was developed by The Open Group into a comprehensive Enterprise Architecture framework - known as the Technical Architecture Framework for Information Management (TAFIM). TOGAF® 7, the "Technical Edition", was published in December 2001. A year after that TOGAF® 8 ("Enterprise Edition") was published. TOGAF® 8.1 was republished and updated in December 2003 and “TOGAF®™” officially became a registered trademark of The Open Group in 2005. TOGAF® underwent a further overhaul in November 2006, titled TOGAF® 8.1.1. The most recent version update, TOGAF® 9.1, occurred in December 2011, and is currently the most up to date framework, that is used by 80% of Enterprise Architects. TOGAF® 9.1 has been the most successful framework to date, reflected by the recent proliferation of its use within Enterprise Architecture and the fact that 16,000 of the 22,900 certified TOGAF®’s are 9.1 qualified. The Open Group have remained the owners and governing entity that determines TOGAF®’s professional direction since its inception in 1993, to now.

Components of TOGAF®
The Framework TOGAF® consists of the following components:

Technical Architecture: also called technology architecture; it describes all necessary hardware, software and IT infrastructure involved in developing and deploying business applications.

Adapting the TOGAF Framework[5]
With the business strategy and direction as basis, you can think about how TOGAF can be applied in your organization and which results you want to achieve with it. TOGAF is a very extensive and generic framework, and it is important to specify which elements of TOGAF are useful in the context of your organization and which are not that relevant. TOGAF itself recognizes this: the first step in TOGAF’s Architecture Development Method (ADM) is the Preliminary Phase. This phase is about defining “where, what, why, who, and how we do architecture” in the enterprise concerned (TOGAF 9.1, Sect. 6.2). In other words: you are going to adapt the TOGAF framework and customize it to the requirements of your own organization. However, this is not as easy as it may look. TOGAF suggests a number of steps in this Preliminary Phase which make sense, but the approach is still quite generic. Organizations may therefore find themselves struggling in this phase, resulting in lots of debates but little result. To get valuable results from this phase, we apply principles from Lean management to the architecture process: examine all activities and results for the value they add and eliminate any waste, avoid unnecessary sign-offs that cause delays, and continuously improve of your way of working. In our experience it is important to concentrate on three aspects:

Use a limited set of EA deliverables. TOGAF suggests many deliverables that can be produced. In our experience ‘less is more’: only a couple of key deliverables are enough to kick-start an EA initiative and get results.

To select and configure these key deliverables, the most important criterion is their potential business value. Who are going to use them, for which activities and to what expected benefit Especially in the early phases of an EA initiative it is crucial to show to different stakeholders (including business stakeholders) the added value of EA deliverables.

Learn by doing. It is impossible to define a complete EA framework before you start and execute this in a waterfall approach. It is better to start small, take an iterative approach, learn, and improve your way of working on the go.

TOGAF Version 9.2 - Changes and Improvements[6]
The TOGAF standard, version 9.2 brings a number of changes and improvements. An important change is the restructuring of TOGAF into a core and a number of additional guides, which together form the TOGAF Body of Knowledge. A general change is the refinement of the terminology, including the alignment with the ISO/IEC/IEEE 42010:2011 standard and other standards. The most interesting change is the enrichment of the business architecture part of TOGAF with business capabilities and value streams. These additions move TOGAF further away from the IT focus it had in the past. In this blog, I’ll further describe these two additions. The most interesting change is the enrichment of the business architecture part of TOGAF with business capabilities and value streams.

Business Capabilities: Business capabilities are not entirely new in TOGAF; the capability-based planning technique was already part of the previous version. In the new version business capabilities get even more focus and attention. This starts with more clarity on terminology, with a clear distinction between capabilities and business capabilities. A capability refers to an ability that an organization, person or system possesses. A business capability is a particular ability that a business may possess or exchange to achieve a specific purpose. A capability is thus a more general term, and also includes IT and architecture capabilities. A capability-based view of architecture puts emphasis on what the business needs in order to achieve its goals. It requires identifying, categorizing, and decomposing the business capabilities required for the business to have the ability to deliver value to one or more stakeholders. A business capability map is introduced to provide a self-contained view of the business that is independent of the current organizational structure, business processes, and information systems. It provides a level of abstraction that the organization understands, and is thus a very appropriate way to talk with people about the changes that are needed.

Value Streams: Value streams are totally new in TOGAF. A value stream is a representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user. They are a result of a breakdown of activities that an organization performs to create the value being exchanged with stakeholders. They provide context and a grouping for the business capabilities. They provide valuable stakeholder context into why the organization needs these business capabilities. For every stage in the value chain, the business capabilities that are needed can be identified. The result can be depicted in a new artifact called a value stream stages catalog. Value streams have the same advantages as business capabilities in terms of easy communication with business stakeholders. They enable communication in business terminology, in terms of things that people recognize. They can be refined into processes at a later stage. Similarly, they can be translated together with the business capabilities in an organization structure. An organization map can be used to show how the organization relates to the business capabilities and thus also to the value stream stages.

TOGAF® is a very rich framework that is highly complex to implement in its fullest.

Barroero et al. (2010) criticize the lack of true connectedness between business requirements and data, application and technology at a concrete level.

Deschamps et al. (2012) point to the lack of an extended research agenda in EA and EAM especially in bringing the disciplines of software engineering and enterprise engineering closer through selected and supported modelling methods.

Technologists might also claim that EA and TOGAF® are unrelated to actual methodologies of technical implementation (Homan and Tobey, 2006).

Mitra et al. (2015) emphasize the lack of human resource and organizational change management support in TOGAF® as well as other EA frameworks (Zachman and FEA) and propose a framework of Enterprise Transformation Architecture (ETA).

The lack of human-factor-attention in the EA frameworks, i.e. TOGAF®, is raising questions on the framework’s durability and sustainability, here Weiss et al.(2013)

Chung et al. (2009) discuss the necessity to institutionalize EA and EAM by addressing practices and encouraging transformation using the array of organizational instruments.