ARCHITECTURE MATURITY MODEL ("CRIB NOTES")

Architecture Maturity Model   

In the past years, the Capability Maturity Models have been extensively used by many organizations, for assessing their status and guiding the improvement of their IT related processes, mainly in the software and systems engineering areas.

« Such models provide the following benefits :

• They describe the practices that any organization must perform in order to improve its processes
• They provide a yardstick against which to periodically measure improvement
• They constitute a proven framework within which to manage the improvement efforts

The various practices are typically organized into five levels, each level representing an increased ability to control and manage the development environment. »

TOGAF 9 does not provide an « official » Maturity Model for Enterprise Architecture. It does provide, however, a quite detailed example, taken from the US Department of Commerce.

US DoC Architecture Maturity Model  

The DoC ACMM consists of six maturity levels and nine architecture elements.

The six levels are :

0 – none

1 – initial

2 – under development

3 – defined

4 – managed

5 – measured

The nine enterprise architecture elements are 

• architecture process 
• architecture development 
• business linkage 
• senior management involvement 
• operating unit participation 
• architecture communication 
• IT security 
• architecture governance 
• IT investment and acquisition strategy   

The table below describes in a brief way the maturity levels 1 to 5. Level 0 means « no enterprise architecture program ; no enterprise architecture to talk about. »  

Enterprise  Architecture Aspect	Level 1: INITIAL	Level 2: UNDER DEVELOPMENT	Level 3: DEFINED	Level 4: MANAGED	Level 5:  MEASURED
architecture process	Ad hoc; dependence on individual efforts ("heroes").	Clear roles and responsibilities are defined	EA process is largely followed	EA process is part of the culture. Quality metrics are captured.	EA process is under constant improvement effort
architecture development	Ad hoc, localized	Vision; principles; baseline and target architecture; TRM; standards framework	Gap analysis and migration plan are completed. Standards profile is fully developed	EA documentation is regularly updated. All architectures comply to standards.	Standards and waivers process encompasses all IT decisions
business linkage	Minimal	Explicit linkage to business strategies	EA integrated with CAPEX and investment control	CAPEX and investment control take EA as key input. Periodic re-examination of business drivers.	Business is involved in the continuous EA process improvement
senior management involvement	Minimal	Senior management is aware of EA effort	Senior management actively supports EA process and standards	Senior management directly involved in EA review process.	Senior management is involved in the continuous EA process improvement
operating unit participation	Minimal	Clear roles and responsibilities are defined	Most elements support and actively participate in EA process	The entire unit supports and actively participates in EA process	Feedback from unit drives EA process improvement
architecture communication	Documentation is on the web	Related web pages are kept up to date with EA deliverables	EA own web pages; they are kept up to date with EA deliverables	EA documentation is regularly updated	Architecture documentation is used by every decision maker in IT
IT security	Ad hoc, localized	Clear roles and responsibilities are defined	IT security architecture standards profile fully developed	Performance metrics are captured	Feedback from IT secutiry drives EA process improvement
architecture governance	No governance	Some adherence to existing standards profile	Explicit governance of majority of IT investments	Explicit governance of all IT investments	Standards and waivers process encompasses all IT decisions
IT investment and acquisition strategy	Minimal participation of EA	Some adherence to existing standards profile	IT acquisition strategy complies with EA; cost benefit analysis of projects	All planned IT acquisitions are governed by EA	No unplanned IT investment or acquisition activity

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] 

WHAT IS TOGAF ADM ("CRIB NOTES")?

TOGAF ADM (Architecture Development Method)

TOGAF ADM is the core of TOGAF. It is the only part of the TOGAF body of knowledge that is considered mandatory, if an architecture organization wants to be « TOGAF compliant ». 

The ADM describes the 10 activities that are required for developing and managing an Enterprise Architecture. The figure reproduced below presents an overview of TOGAF ADM. 

TOGAF ADM

Phase C activity is typically split in two : Data Architecture and Application Architecture.

It is expected that the generic ADM be customized for a particular organization. 

Open Group TOGAF working group’s materials describe ADM in full detail and in shortened forms. These « crub notes » briefly describe the purpose and outcomes of each activity, in my own words.

TOGAF ADM Approach  

One of the corner stones of TOGAF is the « ADM cycles ». In TOGAF, in a mature architecture practice, most of architecture work is organized in a succession of engagements, each one with its specific objectives and scope.

Two workstreams, though, are performed in a more continuous mode : the ADM activities tagged as « Preliminary » and « Phase H : Architecture Change Management ». The former encompasses the building and the management of the basic capabilities required for executing the architecture engagements. The latter encompasses the monitorization of the organization needs and of the stakeholders, in order for capturing new needs leading to new architecture engagements. 

In short, for TOGAF’s authors: 

• the changes and the added value come from the specific and unique architecture engagements,  framed by their objectives, scope, budget and callendar
• the continuous activities of the architecture team are essential, but they are enablers and do not generate change and new value by themselves

ADM : Preliminary Phase

The Preliminary Phase can be understood in two ways : 

• the initial setup of the architecture capability in the organization and the later evolution and management of this capability
• the update of such architecture capability, in order to complement it with the specific aspects required for a new architecture engagement  

In other parts of TOGAF (specifically in « Part VII - Architecture Capability Framework », «Establishing an Architecture Capability ») the initial setup of the architecture capability is presented as a full execution of the ADM cycle. However, in the description of the Preliminary Phase, both goals are combined. This minor overlapping is not a big issue and can be easily handled during the customization of TOGAF.

The maintenance and evolution of the architecture capabilities are continuous activities. On the other hand, before a particular engagement, it should be expected to spot certain capabilities related to the new engagement that should be reinforced, before the new ADM cycle starts.

In its « continuous process » version, the scope of the Preliminary Phase encompasses : 

• to identify the « architecture footprint » for the organization (i.e., the people executing architecture work and their responsibilities)
• to define and establish the architecture framework (i.e., to tailor the ADM, the Content Framework and the Enterprise Continuum)
• to define and establish the architecture governance model
• to integrate the enterprise architecture processes with the rest of management frameworks in the organization
• to select and implement supporting tools (such as the tool for implementing the Architecture Repository)
• to define the architecture principles, the standards and the reference models
• to assess the enterprise architecture maturity level

On the other hand, in its more sctrict « preliminary » version, previous to a specific new engagement, the scope of the Preliminary Phase encompasses : 

• to identify the key drivers and elements in the organizatonal context
• to identify the stakeholders and their concerns
• to define the requirements for architecture work
• to identify the areas of the current architecture capability that have to be updated or increased

Phase A: Architecture Vision

Purpose. Phase A has two groups of actors : the architecture team and the stakeholders. It is aimed at getting a clear understanding among both groups of the context, the business drivers and the business goals that are claiming for a new architecture engagement. The goals of Phase A are: 

• to establish the vision and the scope for the architecture engagement 
• to get buy-in and commitment of the stakeholders 

According to the spirit of TOGAF, the develoment work of the enterprise architecture team (Phases B to F) should not start until there is a clear understanding with the stakeholders, formalized by their signature of the outcomes of Phase A.

Outcomes of Phase A :

• Capability Assessment

o  Identifies the business goals and strategic drivers of the organization.  

o Defines what business capabilities (i.e. business functions) the organization will need to develop in order to fulfill its business goals and strategic drivers.

o Assesses the current capabilities and the implications of the new requirements for the organization.  

• Architecture Vision

o Defines the purpose of the new architecture engagement (i.e., how the new engagement will allow the organization to meet the new capability requirements). 

o « The Architecture Vision provides a first-cut, high level description of the Baseline and Target Architectures, covering the business, data, application and technology domains. » (that is, « pencil-sketches » or « version 0.1 » of these architectures).

o « A common practice is to draw a simple solution concept diagram that illustrates concisely the major components of the solution and how the solution will result in benefit for the enterprise ».

o Architecture vision aims at the communication with the stakeholders ; completeness and exactitud will come later, in the following phases B, C and D.  

• Statement of Architecture Work 

o Defines the scope of the engagement  

o Defines the target architecture value proposition and KPI’s (i.e., an agreement on how to assess the success of the architecture engagement, after it is completed)

o Identifies the business transformation risks and mitigation activities

o Develops initial high level plans

• Communications plan:  

o Identifies all stakeholders and their information needs

o Shows where, how and when the architects will communicate with them  

All Phase A deliverables are aimed at the stakeholders, whose understanding, buy-in and commitment must be granted, if the new architecture engagement is to be successful.

 

Phase B: Business Architecture

Purpose. Phase B defines the target business architecture and the roadmap components that are related to the business domain.

The business architecture is the structured collection of the following building blocks : 

• Business services (bound by a service contract) and business functions (not bound)
• Drivers/goals/objectives
• Organizations/actors/roles
• Locations
• Business processes (i.e. Process/Event/Control/Product)
• Contracts/Measures  

In Phase B, the following views of the business architecture are developed :  

• Baseline business architecture
• Target business architecture
• Gap analysis between the two
• Business roadmap for prioritizing activities

Outcomes of Phase B :

• Architecture Definition Document (chapters related to the business domain)  

o  Business footprint (high level description of people and locations involved)

o Business functions and their information needs

o Baseline business architecture v1.0

o Defines criteria for prioritizing these activities

• Architecture Requirements Specification (chapters related to the business domain)

o Functional requirements

o   Non-functional requirements

o   Assumptions, constraints, domain specific Business Architecture principles

o Policies, Standards and Guidelines

Phase C: Information Systems Architectures — Data Architecture

Purpose. Phase C (Data Architecture) defines the major types and sources of data necessary to support the business. It is NOT concerned with database design – what comes on a later phase, during software engineering.

All data management issues are of interest, including :

• Processes, services and application components that create and use the data
• Corporate standards
• Data transformations
• Data interfaces (with internal and external systems)
• Data migration
• Data governance

The data architecture is concerned with the following building blocks :

• Data entity / data component

In Phase C (Data Architecture), the following views of the data architecture are developed : 

• Baseline data architecture
• Target data architecture
• Gap analysis between the two
• Criteria for prioritizing activities in the roadmap

Outcomes of Phase C (Data Architecture) :

• Architecture Definition Document (chapters related to the data domain)
• Baseline data architecture v1.0
• Target data architecture v1.0
• Views for selected viewpoints
• Architecture Roadmap (chapters related to the data domain)
• Identifies the activities related to the data architecture domain
• Defines criteria for prioritizing these activities
• Architecture Requirements Specification (chapters related to the data domain)
• Functional requirements
• Non-functional requirements
• Assumptions, constraints, domain specific Business Architecture principles
• Policies, Standards and Guidelines

Phase C: Information Systems Architectures — Application Architecture

Purpose. Phase C (Application Architecture) defines the « application landscape » needed to support the business. It is NOT concerned with application systems design. The goal is to identify the logical application components, their relationships, and to describe each one with enough detail. 

All issues related to the applications are of interest, including :  

• Application and user location
• Application communication
• Manageability
• Process/system realization
• Application migration
• Software engineering

The application architecture is concerned with the following building blocks : 

• Application components
• Interface catalog

In Phase C (Application Architecture), the following views of the application architecture are developed :  

• Baseline application architecture
• Target application architecture
• Gap analysis between the two
• Criteria for prioritizing activities in the roadmap

Outcomes of Phase C (Application Architecture) :

• Architecture Definition Document (chapters related to the application domain)
• Baseline application architecture v1.0
• Target application architecture v1.0
• Views for selected viewpoints
• Architecture Roadmap (chapters related to the application domain)
• Identifies the activities related to the application architecture domain
• Defines criteria for prioritizing these activities
• Architecture Requirements Specification (chapters related to the application domain)
• Functional requirements
• Non-functional requirements
• Assumptions, constraints, domain specific Architecture principles
• Policies, Standards and Guidelines  

Phase D: Technology Architecture

Purpose. Phase D defines the « technology landscape » needed to support the business. As technology architecture defines the physical realization of an architecture solution, it has strong links to implementation and migration planning.

The technology architecture supports the cost assessment of different scenarios.

All issues related to the technology domain are of interest, including : 

• Physical locations
• Sizing and capacity planning
• Installation, governance and migration
• Performance
• Maintainability
• Availability

The technology architecture is concerned with the following building blocks :

• Technology standards
• Technology portfolio

In Phase D, the following views of the technology architecture are developed :

• Baseline technology architecture
• Target technology architecture
• Gap analysis between the two
• Criteria for prioritizing activities in the roadmap

Outcomes of Phase C (Application Architecture) :

• Architecture Definition Document (complete, including the technology domain)
• Baseline architecture v1.0
• Target architecture v1.0
• Views for selected viewpoints
• Architecture Roadmap (complete)
• Identifies the activities related to all domains
• Defines criteria for prioritizing the activities
• Architecture Requirements Specification (complete, including the technology domain)
• Functional requirements
• Non-functional requirements
• Assumptions, constraints, domain specific Architecture principles
• Policies, Standards and Guidelines  

Phase E: Opportunities & Solutions

Purpose. Phase E addresses the scope of the projects that will deliver the new architecture. Phase E is not concerned with the delivery aspects, which are examined in Phase F.  

In Phase E, the architecture team:

• reviews and consolidates the gap analysis done in Phases B, C and D
• identifies all work packages and organizes them into projects and portfolios
• develops a series of transition architectures, for moving incrementally from the baseline architecture to the target architecture
• creates portfolio and project charters

Phase F: Migration Planning 

Purpose. Phase F addresses the formulation of an implementation and migration plan, for executing the transaction architectures and the target architecture identified in Phase E. 

In Phase F, the architecture team : 

• estimate resource requirements, project timings and delivery vehicles for each project
• prioritize the migration projects (assessing cost, benefits and risks)
• generates the architecture implementation roadmap (time lined)  

Main outcomes of Phase F : will guide the implementation projects in Phase G 

• Architecture Definition Document (reviewed version)
• Architecture Requirements Specification
• Architecture Contracts
• Implementation and Migration Plan

  

Phase G: Implementation Governance

Purpose. To guide and monitor the implementation of the projects defined in Phase F. 

In Phase G, the architecture team:  

• guides development of solutions deployment and formulate recommendations
• governs and manages the Architecture Contracts
• performs enterprise architecture compliance reviews
• implements business and IT operations

Phase H: Architecture Change Management

Purpose : Though it appears as Phase H of the ADM cycle, Architecture Change Management can be better seen as a continuous activity, monitoring the new architecture resulting of the current architecture engagement in its entirety (that is, the whole enterprise architecture, not only the building blocks that were altered by the last engagement).

Phase H objectives are : 

• to monitor whether the baseline architectures are fit for purpose
• to assess the performance and business value of the architecture and to make recommendations for improvement
• to run the architecture change management process
• to operate the architecture governance framework

 

ADM Architecture Requirements Management

The requirements management process is executed on a continuous basis, meaning that it interacts with all processes in the ADM cycle.

The initial set of requirements in a new engagement (Phase A) is aimed at the architecture team, who needs to make sure they had good communication with the stakeholders.

The requirements generated in Phases B to F are aimed at the implementation teams in Phase G. They are formalized in the « Architecture Requirements Specification », one of the key inputs delivered to the implementation teams.

TOGAF does not mandate a specific process or tool. It is up to the organization to select their own options.

[END OF POST] 

TOGAF ENTERPRISE CONTINUUM ("CRIB NOTES")

TOGAF Enterprise Continuum 

The amount and variety of matters that are analyzed by an architect is overwhelming. The pace at which she or he works, challenging. The effectiveness and efficiency of her/his work frames the whole IT function.

In order to cope with the required performance, the architecture team have to build on previously existing knowledge - in the same way a physician does his daily work applying well established protocols and drugs. No architecture is developed from the scratch. During their engagements, the architects use diverse architecture and solution models – foundation models, industry models, etc. – that are extended and customized to the organizations’ needs. They represent invaluable knowledge, that has to be leveraged if the architecture team will produce assets that create value to the organization.

TOGAF gives formal status to this general practice and dedicates a framework to it : the Enterprise Continuum. The body of knowledge the architecture team reuses when they are working on an engagement requires a thoughtful and dedicated management. The share of their time the architecture team dedicates to building and managing this body of knowledge is well worth the effort later on, during the architecture engagements. Higher effectiveness is reached, time and effort are saved, risks and costs are lowered. Any time the architects dedicate to their professional development is benefitial ; the benefit is doubled if they identify new contents for the organization’s Enterprise Continuum.

The TOGAF Enterprise Continuum can be thought of as a bidimensional index, classifying the knowledge contents used by the architecture team in two dimensions : 

• Abstract – concrete (vertical dimension) 
• Generic – organization specific (horizontal dimension)

The Enterprise Continuum points to contents in the Architecture Repository or elsewhere (in other repositories in the organization or in external web sites).

The figure reproduced below depicts the general organization of the Enterprise Continuum.

ENTERPRISE CONTINUUM - OVERVIEW

The Enterprise Continuum is partitioned in three distinct continua : 

• Enterprise Context Continuum  
• Classifies contextual assets such as policies, standards, strategic initiatives, organizational structures and enterprise-level capabilities  

• Architecture Continuum 
• Represents a structuring of Architecture Building Blocks, from generic to organization-specific entities.  
• Foundation frameworks (e.g. TOGAF TRM and the whole TOGAF) 
• Common system architectures (e.g. TOGAF III-RM, OASIS WS-* standards) 
• Industry architectures (e.g. a logic data model for a particular vertical industry) 
• Organization-specific architectures  

• Solutions Continuum  
• Represents a structuring of the Solution Building Blocks, from generic to organization-specific entities.   
• Foundation solutions (e.g. ITIL, EDIFACT)   
• Common system solutions (e.g. a portal and content management product suite, an ESB product) 
• Industry solutions (e.g. a physical database schema specific to an industry) 
• Organization-specific solutions 

The figure reproduced below depicts the Architecture Continuum and the Solutions Continuum.

ARCHITECTURE CONTINUUM AND SOLUTIONS CONTINUUM

[END OF POST]