1. Introduction

Fig. 1: Architecture Within The Enterprise

 

Enterprise Architecture provides:

The purpose of Enterprise Architecture is to optimize the business processes of an organization into an integrated environment that is responsive to change and supportive of the delivery of the business strategy (for People, Organization Process, Information, Technology), enabled by the effective use of information technologies and their application to business operation. It provides a strategic and specific context for the evolution and reach of digital capability in response to the constantly changing needs of the business environment.

The TOGAF Standard is a framework for Enterprise Architecture. It may be used freely by any organization wishing to develop an Enterprise Architecture for use within that organization (see 1.3.1 Conditions of Use). It is developed and maintained by members of The Open Group, working within the Architecture Forum (refer to www.opengroup.org/architecture). The original development of TOGAF Version 1 in 1995 was based on the Technical Architecture Framework for Information Management (TAFIM), developed by the US Department of Defense (DoD). The DoD gave The Open Group explicit permission and encouragement to create Version 1 of the TOGAF Standard by building on the TAFIM, which itself was the result of many years of development effort and many millions of dollars of US Government investment. Starting from this sound foundation, the members of The Open Group Architecture Forum have developed successive versions of the TOGAF Standard and published each one on The Open Group public website.

Nothing in TOGAF is mandatory and each enterprise will customize the TOGAF approach to meet their specific needs, including only those elements that are useful for that enterprise. TOGAF therefore supports both lightweight and agile implementations and more comprehensive and formal implementations, as required by each enterprise’s strategy and operational environment. Although all of the TOGAF documentation works together as a whole, it is expected that organizations will customize it during adoption, and deliberately choose some elements, customize some, exclude some, and create others. For example, an organization may wish to adopt the TOGAF metamodel, but elect not to use any of the guidance on how to develop an in-house Technology Architecture because they are heavy consumers of cloud services.

The Open Group already provide a full manual, the TOGAF Fundamental Volume (some 400 pages long) and a TOGAF Pocket Guide (some 106 pages long).

This introductory quick guide provides a shorter, more generalized overview of the TOGAF Standard, introducing  a new diagram set that provides the context for the main aspects of the TOGAF Standard and the flow through them in change activity. There are both soft and measurable benefits associated with the diagrams. It enables architects to rapidly access the TOGAF sections that are applicable to their immediate needs and provides new diagrams that more clearly explain TOGAF and how it is used. More information is available via the links shown in the menu on the left of the quick guide (displayed as link or link)

 

 

2. The Basics In Three Diagrams     

 

2.1 Change Perspectives

Fig. 2: Change Perspectives

 

TOGAF identifies three main change perspectives from which an enterprise's architecture is developed, deployed and changed:

 

2.2  Delivering Effective Change

 

 

Fig. 3: Delivering Effective Change

 

 

Change in each of the perspectives is enabled by identifying and provisioning the capability needed to describe and deliver the change and then creating and deploying the change into a live operational environment: using that capability.

In Fig, 3 the change cycle is presented in terms of the well-known generic quality change cycle of Plan, Do, Check, Act/Adjust (the Shewhart / Deming Cycle). Each element of this cycle is also mapped to the phases of the TOGAF Architecture Development Method (a specialized change cycle for architecture change), enabling the TOGAF approach to be integrated and interoperate with other change methods used within an enterprise.

 

 2.3  A Top Level View Of TOGAF


 

 

 

Fig. 4: The Main Aspects Of TOGAF

 

 

An overview of the main aspects of TOGAF that enable the delivery of effective change into an enterprise's architecture landscape:

 

Please click of the diagram for a connected diagram that provides a series of linked views of the text and the graphics to take you through th enext level of detail in describing TOGAF. 

  

  

3. TOGAF Change Activities (the ADM) & Organising Elements    



3.1 The Architecture Development Method The ADM

 

The TOGAF ADM describes a method for developing and managing the change lifecycle of an Enterprise Architecture, and forms the core of the TOGAF Standard. It describes a series of activities that need to be considered to fully understand and address architecture change starting with:

 

Fig. 6 Delivering Effective Change

 

   

Fig. 6 shows the main activities from phases from the ADM connected to the main TOGAF elements and deliverables for defining and implementing change into your solutions landscape. It includes the major organizing models in TOGAF, showing how architecture logical activity progresses and the key elements for controlling and managing that activity. These organising models are described below.

 

3.2 The Enterprise Metamodel Enterprise Metamodel     Potential Artifacts

 

 

The Enterprise Metamodel defines the types of entity to appear in the models that describe the enterprise, together with the relationships between these entities. For example, one type in an Enterprise Metamodel might be Role. Then the enterprise's Business Architecture models might include such instances of Role as Teller, Pilot, Manager, Volunteer, Customer, or Firefighter. Of course it would be an unusual enterprise that had all of these roles. It gives architects a starter set of the types of thing to investigate and to cover in their models and provides a form of completeness-check for any architecture modeling language, or architecture metamodel, that is proposed for use in an enterprise. Instances of these metamodel types will often be specific architecture and solution building blocks. 

 

A list of potential artifacts (shown above) is provided showing different outputs that help to define and document  the various building blocks  in solutions. They are classified in terms of catalogues, matrices and diagrams.

 

3.3 The Enterprise Continuum Enterprise Continuum


 

The Enterprise Continuum provides methods for classifying architecture and solution artifacts, both internal and external to the architecture repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures. It is as a view of the repository of all the architecture assets. It provides the classifications for architecture descriptions, models, building blocks, patterns, architecture viewpoints, and other relevant artifacts that exist both within the enterprise and in the IT industry at large, which the enterprise considers important for the development of architectures for the enterprise.


3.4 Architecture Repositories Architecture Repositories

 

 

The Architecture Repository is the physical manifestation, the file systems and tools, that hold and provide access to the architecture information needed by the enterprise. It stores the artifacts identified and classified by the Enterprise Continuum.

3.5 Architecture Capability Architecture Capability

 

 

Architecture Capability is the operational business ability to create and execute and architecture practice through organization structures, roles, responsibilities, skills, and processes. It is this capability that then defines, manages, enables, oversees and assures the required levels of architecture change for an enterprise.

 

3.6 Architecture Levels & Domains Architecture Levels   Architecture Domains

An architecture typically does not exist in isolation and must therefore sit within a governance and control hierarchy. Broad summary architectures set the direction for scope and integration and can be presented as : 


 


Architecture Domains

There are four architecture domains that are commonly accepted as subsets of an overall Enterprise Architecture (rreferred to as BDAT), which can be varied or added as needed :

There are many other domains that could be defined by combining appropriate views of the Business, Data, Application, and Technology domains. For example, risk, security, software, ecosystems and devices/machines.

A complete Enterprise Architecture should address at least the four architecture domains (Business, Data, Application, Technology), but the realities of resource and time constraints often mean there is not enough time, funding, nor resources to build a top-down, all-inclusive Architecture Description encompassing all four architecture domains.

Fig. 5 Architecture Domains, Architecture Levels & Architect Roles 

Architecture Descriptions will normally be built with a specific purpose in mind; a specific set of business drivers that drive the architecture development. For example, if the purpose of a particular architecture effort is to define and examine technology options for achieving a particular capability, and the fundamental business processes are not open to modification, then a full Business Architecture may well not be warranted. However, because the Data, Application, and Technology Architectures build on the Business Architecture, the Business Architecture still needs to be thought through and understood.

While circumstances may sometimes dictate building an Architecture Description not containing all four architecture domains, it should be understood that such an architecture cannot, by definition, be a complete Enterprise Architecture. One of the risks is a lack of consistency and therefore an ability to integrate. Integration either needs to come later with its own costs and risks, or the risks and trade-offs involved in not developing a complete and integrated architecture need to be articulated by the architect, and communicated to the relevant stakeholders.

  

  

4. Architecture Practices

This covers various aspects of architecture change activity that are needed to effectively implement an enterprise’s strategy by managing and evolving its enterprise’s architecture landscape and the implemented operational environment.
 

4.1 Architecture Requirements Architecture Requirements

 A statement of need, which is unambiguous, testable or measurable, and necessary for acceptability.

 

4.2 Architecture Techniques Architecture Techniques

There are many techniques that can be used when managing an enterprise architecture. These techniques are not mandatory but it is recommended that they be considered. They are illustrations of how such techniques could be performed. If you have a preferred effective way of carrying out any of these techniques rather than the illustrated one ,you should use that. Techniques illustrated in the TOGAF Fundamentals Volume include: Principles, Stakeholder Management, Architecture Patterns, Gap Analysis, Migration Planning, Interoperability Requirements, Business Transformation Readiness Assessment, Risk Management and Architecture Alternatives & Trade Off.

 

4.3 Architecture Styles Architecture Styles  

An architecture style is a combination of distinctive features related to the specific context within which architecture is performed or expressed; a collection of principles and characteristics that steer or constrain how an architecture is formed; such as service oriented architecture, pessimistic transactions or zero trust. The TOGAF framework is designed to be flexible and can be used with various architectural styles. Architectural styles differ in terms of focus, form, techniques, materials, subject, and time period. The TOGAF Standard is a generic framework intended to be used in a wide variety of environments. It is a flexible and extensible framework that can be readily adapted to a number of architectural styles.

 

4.4 Architecture Governance Architecture Governance      

Architecture Governance is the practice and orientation by which Enterprise Architectures and other architectures are managed and controlled at an enterprise-wide level. Architecture Governance typically does not operate in isolation, but within a hierarchy of governance structures. Governance iaims to ensure that business is conducted properly. It is less about overt control and strict adherence to rules, and more about guidance and effective and equitable usage of resources to ensure sustainability of an organization's strategic objectives. Architecture Governance is usually implemented within a defined framework that  can be adapted to the existing governance environment of an enterprise. The TOGAF Standard provides an illustration of such a framework to assist in identifying effective processes and organizational structures, so that the business responsibilities associated with Architecture Governance can be elucidated, communicated, and managed effectively.

 

4.5 Management Frameworks Management Frameworks

The TOGAF ADM is a generic method, intended to be used by enterprises in a wide variety of industry types and geographies. It is also designed for use with a wide variety of other Enterprise Architecture frameworks (although it can be used perfectly well in its own right, without adaptation). The TOGAF framework has to co-exist with and enhance the operational capabilities of other management frameworks that are present within any organization either formally or informally. In addition to these frameworks, most organizations have a method for the development of solutions, most of which have an IT component. The significance of information systems is that they bring together the various aspects (also known as People, Organisation, Processes, Information and Materials / Technology) to deliver a business capability. The main frameworks that need to be co-ordinated include, Business Management, Portfolio / Project / Change Management, Operations Management, Solution Development, Solution Implementation, and Solution Maintenance. These frameworks are not discrete and there are significant overlaps between them. Enterprise Architecture cannot narrowly focus on the IT implementation, but must be aware of the impact that the architecture has on the entire enterprise and all other relevant frameworks.

 

4.6 Architecture Roles & Skills Architecture Roles & Skills 

There are various roles and skills needed to successfully run an architecture practice within an enterprise. A Series Guide is provided that describes the main roles and the skills needed. This can be used as the basis of an effective architecture practice. It identifies three main architecture roles, Enterprise Architect, Segment (Domain) Architect and Solution Architect, and their associated activities, stakeholders and key performance indicators (see Fig.5). A Chief Architect role is also defined. This is a special case of an Enterprise Architect who represents architecture and its capability to an organization's strategic leadership and provides overall architecture related leadership to the enterprise.

 

 

  

5. TOGAF Standard Documents


This covers the three main document types that describe the TOGAF Standard (there are more types but for this quick guide we are just referencing these main three).

 

5.1 Fundamental Content  Fundamental Volume

The TOGAF Fundamental Volume provides essential “scaffolding” and established best practices that are stable and enduring. The concepts in the TOGAF Fundamental Volume are considered to be the universal concepts applicable to the TOGAF framework.

  

5.2 Series Guides Series Guide Library

These provide extended guidance to build upon the general content provided in the TOGAF Fundamental Volume content by providing guidance for specific topics, in particular how TOGAF may be used in different situations. Over time the extended guidance will expand as the professional body of knowledge that forms the TOGAF Standard expands with more stable best practice.

 

5.3 White Papers  White Papers Library

These provide additional information and examples about aspects of TOGAF about topics considered to be of interest by any member of the architecture forum of the Open Group.  

  

 

6. The Main Solution Outputs


The TOGAF ADM (see the section above on the ADM)  generates two main outputs for the desired change to an enterprise’s architecture landscape (the set of solutions an enterprise has to implement to deliver its strategy and day to day operations). These are the:

The solution definition for a cycle of architecture change (one complete cycle of the ADM) creates the specification of the Architecture Building Blocks and their integration in a proposed Solution Specification that fleshes out the Vision to a complete picture of what is to be addressed, in the one overall change cycle, documented in one or more deliverables, including one or more artifacts, describing one of more building blocks.

This proposed solution is then evaluated against the potentially available components that the enterprise can reuse, buy or build and is organized into one or more deployment units (of one or more transitions with one or more work packages) for each of the ADM cycles of change. Their performance requirements are finalized and put into an architecture implementation contract for the selected and specified Solution Builidng Blocks, addressing their acquisition, integration and deployment.

The deliverables, artifacts and building blocks are updated to include these agreed implementation aspects. The operational solution is the result of the implementation of this contact delivering the desired operational services, systems, sub-systems and solution building blocks into the business environment through as series of transitional and / or target architectures.


7. Performing Architecture  Work Architecture Abstraction


The TOGAF Standard recommends that architects should utilize the concept of abstraction levels to manage architecture change. Architecture effort can be divided into four distinct abstraction levels to answer fundamental questions about an architecture:


These abstraction levels are addressed by following the TOGAF ADM cycle with:

 

Remember that architects do not build or implement architecture, they specify and assure architectures (as described in the Architecture Roles and Skills Series Guide). Solution component specialists (usually working within one of the architecture segments / domain portfolios of change) perform the detailed design and build work, that implements the specifications produced by those performing the architect roles.

This is the same approach as taken by building architects who specify the overall structure and shape of a house, its performance targets, its building blocks and their integration and deployment into the emerging physical fabric of a house. The house architect role is not to perform the detailed design and build work (they are not glaziers, brick layers, carpenters, electricians, roofers or plumbers) it is to provide and govern the people performing the detailed design, build and deployment with the specifications that they should satisfy.

In the same manner the enterprise, segment and solution architect roles associated with TOGAF and the implementation of effective business systems with information technology are to specify and assure architecture to meet the requirements of the decision stakeholders requesting the change. They do not perform the detailed design and build roles. Those are performed by people with specific knowledge and expertise in the many different building block types needed to develop, deploy and operate all complex services and systems. The architect roles in TOGAF do not cover the high level design and build roles associated with specific solution component specialists such as business process designers, software developers, network designers, data management specialists or operations managers.

In different situations in different enterprises they may be more or fewer people that are available to perform these various architecture, design, build and operations roles. In very small organizations there may be one person performing all of them, in others there may be many people performing just one of these roles. In all of these situations there should be clarity on which role is being performed and who is performing that role. In most cases the skill and knowledge for the different roles is significant and may clash with the specific skills and knowledge needed for other roles. The skills and knowledge for each of those more specialized detailed design, build and operations roles is provided by the relevant standard bodies addressing those specific aspects. While there is often overlap and integration between the higher level specification and assurance activities of architects and the more specific detailed design and build activities of other roles and disciplines they should not be confused as being the same.



8. Selecting Work Products

 

In TOGAF there are three main logical documents that drive architecture change as the ADM change cycle progresses.:

A Request for Architecture Work starts the ADM cycle, with change focused on one of, or a combination of, the three architecture change perspectives; Strategic / Enterprise, Segment / Capability , and / or Solution.

As the architect responds to  that new Request For Architecture Work (in response to new or changing requirements that have been approved for response in Change Management (ADM Phase H) they work through the Preliminary Phase and the Architecture Vision Phase (ADM Phase A) for the initial work on that change. An Architecture Vision is produced (usually including at least a solution sketch, an outline activity plan and KPIs) that represents the agreement from all Stakeholders that the change should progress, be stopped, or needs more work before progressing.

If the change is to be progressed further then a Statement of Architecture Work is created, that identifies the activities to be undertaken and the work products expected to created, to complete the initial definition of the solution elements that will implement the change. The initial response to this statement (ADM Phases B / C / D) is to generate those work products in the form of deliverables and artifacts describing the required Architecture Building Blocks, for relevant domains. The next response (ADM Phases E / F) is to consider how to organize an implementation of the work products, in a migration plan of one of more transitions and work packages, describing the required Solution Building Blocks and the Architecture Contract (for implementation).

If progress towards implementation is approved, the migration plan is implemented with the relevant providers, the solution components are provisioned in line with the Solution Building Block specifications, (that are integrated into the appropriate systems and sub-systems and deployed into the live environment that will be executing the target services) and assured against the performance commitments identified in the Architecture Contract (for implementaion). The overall performance of the deployed systems, sub-systems, building blocks and services is then evaluated in the Change Management Phase (ADM Phase H).

TOGAF is a reference model from which the elements needed to carry out effective change are selected. In some cases few are needed in others many more, This depends on the type of change being actioned. The TOGAF ADM approach in Phases B / C / D proposes a first work step of identifying the required reference models, viewpoints and tools. When doing this only select those needed.  Identify the delivery styles (you may be using more than one delivery style in an ADM cycle of change) and the building block set  that will be if most use. The TOGAF Standard provides lists of potential deliverables, artifacts and building block types that should be considered for each change cycle of the TOGAF ADM.

More detail on this can be found in the TOGAF Series Guide: An Approach To Selecting Building Blocks, which is supplemented by a small booklet TOGAF Building Block Configurator Booklet.

 

 9.  The Most Appropriate Change Approach

Enterprise Architecture provides a foundation for integrated change within and between enterprises. In some cases, this may require robust approaches, ensuring that the solutions and the building blocks that make up the solution meet many regulatory and legal aspects and must work first time on deployment. In other cases, the solutions and the building blocks may have few constraints and can have variable but functional implementations that improve over time, navigating different levels of political, social, personal, and technical debt.

Having identified the nature of the change related to an enterprise’s current context, state, and vision (its mission, drivers, concerns, goals, objectives, and requirements) and change granularity; different more or less appropriate types of change can be identified. Fig. 7 shows characteristic profiles of change likely to be encountered across a reasonably large enterprise. They reflect the different risk and integrity concerns that must be considered before deciding on change lifecycles and practices.
   

Figure 7: Change Profiles



The three broad change profiles are identified as:


In most change situations there will be a significant, if not a greater number of transitions, implemented using the functional profile. Occasionally pure speed is needed. This is supported by the rapid profile. In some changes, careful robust profile approaches will be needed. The different change profiles require different levels of intentional and emergent architecture and governance. In any enterprise of scale and in any specific change of some complexity and scale, it is likely that all three of these change profiles will be relevant. Architects and Product/Project/Change Leaders should collaboratively and dynamically manage the changes in line with the most appropriate profiles. Different building blocks may be needed for the specific requirements and nature of each change ( the TOGAF Series Guide: An Approach To Selecting Building Blocks document provides characteristic sets of entities that identify the relevant types of building blocks that may be considered for the different change profiles).

The blending of Enterprise Architecture planning and discovery style techniques provides a context for the emergence and testing of direct client value using small, targeted units of change within the broader need to evolve and integrate solution components in an interoperable manner. The rapid profile provides an approach when change has to happen quickly with a higher risk of negative effects. The functional profile provides an approach when change needs to deliver real capability at standard delivery pace, (but can tolerate various forms of political, social, personal, or technical debt). The robust profile provides an approach when functional and non-functional requirements must be fully compliant, and risk must be minimized. This approach should be used for complex and risk averse change such as that to nuclear power stations, aircraft control systems, and drug development (when not in time extremis).

More detail on this can be found in the TOGAF Series Guide: An Approach To Selecting Building Blocks, and the TOGAF Series Guide: Enabling Enterprise Agility.