TOGAF ARCHITECTURE CONTENT FRAMEWORK ("CRIB NOTES")

TOGAF Architecture Content Framework

Architecture development is under way. Wev’e got the architecture capability up and running. The architects are working on a number of engagements, applying the best of their skills and energy.

What will their work products look like ?

A few well known architecture frameworks deal with the enterprise architecture content domain. The Zachmann Framework and UK Ministry of Defense MODAF are two good examples. These frameworks have some material related to methodology and governance, but they concentrate primarily on the organization of the outcomes of the work products generated by the architects.  

TOGAF’s authors (The Open Group Architecture Forum) have dedicated a rich section of TOGAF to the organization and « framing » of the work products generated by the architecture team. TOGAF’s approach is based on real practice, kind of « bottom up ». Most enterprise architecture practitioners will immediately feel familiar with the organization of the contents proposed by TOGAF, even if they have been using a different framework or no framework at all, only his common sense.

TOGAF’s approach to Architecture Content is based on the following ideas : 

• The set of objects (« building blocks ») the enterprise architect deals with is limited and can be fully described in a model. This is the Content Metamodel.
• The Content Metamodel has to be flexible, in order to adjust to the different contexts found in the organizations.
• The architects produce « deliverables » and describe the « building blocks » (for sure !). However, they aren’t the only products that have to be managed. In order to reach effectiveness and efficiency, the intermediate, more atomic « artifacts » generated by the architecture work have to be managed as well. The artifacts have higher reusability than the final deliverables and building blocks.
• The enterprise architecture content represents the whole organization, and that is too much information. In order to get effective communication with the stakeholders and participants, the architecture contents has to presented in « views » that address the particular concerns of each interest group.  

« A TOGAF architecture is based on defining a number of architectural building blocks within architecture catalogs, specifying the relationships between those building blocks in architecture matrices and then presenting communication diagrams that show in a precise and concise way what the architecture is. »

The figure reproduced below depicts in a diagram the key roles that take part in the TOGAF Architecture Content Framework.  

TOGAF CONTENT METAMODEL - OVERVIEW

TOGAF Architecture Content Metamodel  

« The content metamodel provides a definition of all the types of building blocks that may exist within an architecture ». (« Building blocks » are presented below. If you are thinking of LEGO blocks, you are right. Business functions, data entities, application components and technology components are examples of building block categories.)

We’ve already seen that, while executing an ADM engagement, the architecture team will : 

• Define a « vision » for the engagement 
• Manage the requirements identified by architecture 
• Define the baseline architecture and the target architecture, for the four domains : business, data, applications and technology 
• Define the work packages, projects and programs to the executed 
• Govern the execution of those projects and programs 

The Architecture Content Metamodel presents the structured set of objects (or « building blocks ») that is generated by the architects executing the ADM. « The ADM describes what needs to be done to create an architecture and the content framework describes what the architecture should look like once it is done. »

TOGAF’s authors have created a metamodel made up of 32 entities. Minor inconsistencies among parts of the text reveal the intensity of the debate before reaching the current result. A few aspects of the metamodel are not completely clear. The final result is definitely invaluable for the enterprise architect. 

TOGAF Architecture Content Metamodel is a detailed data model, encompassing the 32 entities, their respective attributes and the relationships among them. Any enterprise architecture should fit in TOGAF content metamodel.

The figure reproduced below presents an overview of the TOGAF Architecture Content Metamodel.

TOGAF ARCHITECTURE CONTENT METAMODEL

The figure reproduced below presents the entity-relationship view of the full metamodel.

CONTENT METAMODEL - ENTITY-RELATIONSHIP VIEW

TOGAF Architecture Content Metamodel : Core Content and Extensions   

There is no « onse size fits all » in enterprise architecture. Each organization, in each phase, has a different context for the enterprise architecture engagements. Budget and time restrictions might impose restrictions on the scope.

A few examples of variable conditions that might apply : 

• The business drivers might be fully defined or they might be a rough draft  
• Business processes might be fully modeled, or their modeling might be out of scope 
• Services (meaning a Services Oriented Architecture) might be key to the modelling, or they might be not considered at all 
• Technology domain might be a key concern, or it might be out of scope

Other architecture content frameworks intended for specific organizations are very specific in their modeling of objects. This is the case with MODAF (intended for use in the UK Ministry of Defense) and DODAF (intented for use in the US Department of Defense). TOGAF is intended to be used by any kind of organization ; how to cope with the range of different contexts ?

The solution proposed by TOGAF is to structure the metamodel object types in a few groups. There is a « core » set of objects that are required in all contexts. To this core, a few optional groups can be added. If all optional groups were added, we’d get the complete model we’ve seen above.

One gets the feeling that the resulting grouping is not completely « natural », meaning that if the exercise of grouping the entities were repeated by a different work group, the result might have been different. Anyway, it is an excellent model to follow.

The picture reproduced below represents the core content metamodel and the six extensions.

TOGAF CONTENT METAMODEL - CORE AND EXTENSIONS

TOGAF’s architecture core content metamodel is made up of 17 entities. The remaining 15 entities (the full metamodel is made up of 32 entities) are distributed in the 6 optional extensions.

The 17 entities TOGAF authors consider mandatory in order to build an enterprise architecture are identified in the picture reproduced below. 

TOGAF CORE CONTENT METAMODEL

It stands to reason that the majority of the mandatory, « non negotiable » entities in the metamodel are the ones that make up the foundation of the architecture function and the ones that reflect the business domain. The 15 entities that are classified as « extensions » add detail to the description of the resulting architecture in the four domains (business, data, applications and technology).

TOGAF Architecture Content : Artifacts and Views 

The architects produce « deliverables » and « building blocks ». However, these products are the final outcomes and too coarse-grained to allow optimum content management. Before assemblying them, the architects produce a whole lot of more atomic work products, called « artifacts ».

An « artifact » is a piece of documentation that captures any aspect of the system analyzed by the architect and that is relevant to his work. While working on an existing or on a new system, the architect will deal with a whole lot of viewpoints, information and stakeholders ; he will have to: 

• Document aspects and components of the current system that are relevant to him, without getting lost in too much detail  
• Understand and document relatioships between aspects and components of the current system 
• Capture facts and scenarios, in order to present them to the stakeholders and participants 
• Detail to some degree the future scenarios 
• Describe aspects and components of the target solution (again, without getting lost in details 
• Understand and document relatioships between aspects and components of the target system 
• Convince all of the stakeholders of the quality of his ideas, talking to each one in his own language and addressing the concerns of his viewpoint 
• Relate his ideas to the company’s objectives

TOGAF Content Framework identifies a set of artifacts that typically is generated by the architects’ work. The artifacts are also called « viewpoints ». The combination of viewpoints make up the views of the architecture.

Three classes of artifacts are generated : 

• Lists 
• Matrices 
• Diagrams 

The picture reproduced below represents the artifacts (or « viewpoints ») identified in TOGAF.

TOGAF CONTENT METAMODEL - ARTIFACTS

Combinations of artifacts allow the architects to tackle the concerns of all of the atakeholders, each one of them requiring a specific view of the solution. The following views are identified in TOGAF. Additional views will be added, depending on the nature of the architecture being developed. 

• Business architecture view 
• Enterprise security view 
• Software engineering view 
• System engineering view 
• Communications engineering view 
• Data flow view 
• Enterprise manageability view 
• Acquirer view

TOGAF Architecture Content : Deliverables 

TOGAF proposes a taxonomy of deliverables that are typically produced during the execution of the ADM cycle. For each one, TOGAF describes the general organization and provides an elaborated template.

The deliverables enumerated by TOGAF are listed below. They are grouped by the ADM phases in which they are produced.

During the customization of TOGAF for a specific organization, the templates have to be extended and detailed ; a deliverable such as « Architecture Definition Document » can include just about any contents.

• ADM Preliminary Phase  
• Business Principles, Business Goals, and Business Drivers  
• Architecture Principles  
• Tailored Architecture Framework  
• Request for Architecture Work  
• Organizational Model for Enterprise Architecture  
• Architecture Repository  
• Phase A: Architecture Vision 
• Statement of Architecture Work  
• Capability Assessment  
• Architecture Vision  
• Communications Plan  
• Phase B: Business Architecture 
• Phase C: Information Systems Architectures — Data Architecture 
• Phase C: Information Systems Architectures — Application Architecture 
• Phase D: Technology Architecture 
• Architecture Definition Document 
• Architecture Roadmap  
• Architecture Requirements Specification  
• Phase E: Opportunities & Solutions  
• Statement of Architecture Work  
• Phase F: Migration Planning  
• Implementation Governance Model  
• Architecture Contract 
• Architecture Building Blocks 
• Phase G: Implementation Governance  
• Solution Building Blocks  
• Compliance Assessment 
• Phase H: Architecture Change Management  
• Change Request 
• Requirements Impact Assessment 
• ADM Architecture Requirements Management  
• Architecture Requirements Specification 

TOGAF Architecture Content : Building Blocks 

« An architecture is a set of building blocks depicted in an architectural model, and a specification of how those building blocks are connected to meet the overall requirements of the business.

The building blocks in an architecture specify the scope and approach that will be used to address a specific business problem. »

In other words, an « architecture description » is a model that :  

• identifies all of the building blocks in all of the categories in the Architecture Content Metamodel (17 categories, if only the core model is used ; 32 categories, if all of the extensions are used) : 
• all of the actors and roles
• all of the functions and processes
• all of the business services
• all of the application components
• all of the technology components
• etc.
• identifies all relationships between those building blocks
• describes each building block and each relationship in enough detail
• represents the set of building blocks and relationships in ways that can be understood by the stakeholders 

« Building blocks have generic characteristics as follows:

• A building block is a package of functionality defined to meet the business needs across an organization.
• A building block has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity)
• A building block has a defined boundary and is generally recognizable as « a thing » by domain experts.
• A building block may interoperate with other, interdependent, building blocks.
• A good building block has the following characteristics:
• It considers implementation and usage, and evolves to exploit technology and standards.
• It may be assembled from other building blocks. 
• It may be a subassembly of other building blocks.
• Ideally a building block is re-usable and replaceable, and well specified. »

The definition of the set of building blocks that make up an architecture is developed in two phases: 

• Architecture building blocks (ABBs) in phases A to F 
• Solution building blocks (SBBs) in phase G

« ABBs:

• Capture architecture requirements; e.g. business, data, application and technology requirements
• Direct and guide the development of SBBs »

“SBBs:

• Define what products and components will implement the functionality
• Define the implementation
• Fulfil business requirements
• Are product or vendor-aware”

Typically, several ABBs map to SBBs in a obvious way, that will be promptly identified by the architects and stakeholders.

The target architecture typically reuses to the maximum extent the building blocks already present in the baseline architecture. 

The picture reproduced below describes how the building blocks are developed during the ADM. 

TOGAF ADM AND THE "BUILDING BLOCKS"

[END OF POST]