This guide describes an approach to selecting Building Blocks from the TOGAF^® Content Metamodel based on three different types of business change, or “Change Profiles”. For each Profile, guidance is given for the selection of appropriate Building Blocks, and a checklist is presented to help evaluate the fitness for purpose of the resultant deliverables.

While this guide presents a potential approach to selecting Building Blocks, it does not address further tailoring the TOGAF Framework, for example, terminology tailoring. Guidance for tailoring the Framework may be found in other publications, such as:

• TOGAF^® Series Guide: The TOGAF^® Leader’s Guide to Establishing and Evolving an EA Capability (G184)
• TOGAF^® Series Guide: A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF^® ADM (G186)

This guide is intended to be complementary to the above publications, by providing an approach based on the Change Profiles for selecting Building Blocks when executing the TOGAF Architecture Development Method (ADM).

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. Figure 1 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 1: Enterprise Change Profiles

The three broad change profiles are identified as:

• Rapid (short time delivery-driven) – Near immediate implementations of simple components (e.g., extended prototyping such as Rapid Application Development (RAD)
• Functional (implementable capability-driven) – Fast cycles of component delivery for specific bounded functionality and time (e.g., Joint Application Development (JAD), Dynamic System Development Method (DSDM), Agile techniques)
• Robust (risk and architecture-driven) – Longer term delivery of complex, riskier, larger scale components, often interoperable across different enterprises, the breadth of an enterprise or part of an enterprise (e.g., managed projects or programs using approaches such as COBIT^®, SABSA^®, Prince 2^® or Managing Successful Programs (MSP))

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 (this 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).

Figure 2: Entity Relationship Diagram (ERD) of a TOGAF Transition Architecture

The TOGAF Standard describes Baseline, Target, and Transition Architectures. These reflect the current state, the desired final state, and the implementable units of intermediate solution components that progress towards an overall target state as shown in Figure 2. This describes the relationships between the different architecture viewpoints and their use, to implement new capabilities and solutions in response to an enterprise’s goals and objectives.

Because the TOGAF Standard is a general framework, agnostic to and inclusive of prevailing trends in the industry, it does not mandate any particular approach to this Architecture Landscape change, expecting that different enterprises and situations may necessitate different approaches to be used from those available at any point in time. Today, prototyping style change and Agile product development approaches are again common (as they were in the 1980s and early 1990s [Gilb, 1988; Arthur, 1992]).

Among the Agile concepts in support of this incremental delivery approach are Minimum Viable Products (MVP) and Minimum Marketable Product (MMP). Those apply the long-used considerations that it is important to gather feedback rapidly and develop iteratively and incrementally from learning, and it is not always possible to define in detail the target and more distant transition states. These Agile concepts can be aligned to the TOGAF Standard approach, as shown in Figure 3.

Figure 3: ERD of TOGAF Transition Architecture with MVP and MMP Concepts

A reasonably complete target description is often not possible when there are several unknowns at the start of a change. The TOGAF Standard suggests the use of aspirational progression as the change moves towards the target but the target changes as that movement occurs.

When the situation is associated with business and Architecture Landscape change, the enterprise may not be sure what real customer needs are and have to hypothesize and then validate those hypotheses. If internal and external conditions change too quickly (e.g., technology, politics, competitors) and randomly, this restricts the change horizon that can be predicted. However, when conditions associated with any specific change do vary, there may also be stable elements that can enable change to progress and are required for it to have any chance of success.

The role of Enterprise Architecture is to drive the change, assure enterprise-wide level thinking of solutions, and support for appropriate iterations and increments (some of which may be small and short, others may be large and long), with feedback shaping the Architecture Landscape. It is the function of strategy and Enterprise Architecture to reflect the reality of this balance between intentional direction, enforced change, and emergent capability.

In small scale change a Market Quality Product (MQP) can be used as an intermediate state between baseline and target or even as a target architecture. Architecture requirements may be prioritized in such a way as to support delivering a MVP with suitable non-functional requirements implemented. Architecture should provide appropriate means to integrate changing or new products with an existing Architecture Landscape and not allow too much of the various types of debt to accumulate. Appropriate architecture views can be created to ease the process using architecture patterns, and properly selected standards. An MVP may be a temporary step in a product roadmap, balancing between flexibility and speed, and avoiding over-architecting, when appropriate.

In large change, there may be several parallel MVPs delivered. Delivered MVPs modify an Architecture Landscape and the architect’s role is to assure the landscape is not scattered and evolves towards an effective state. Some of those decisions may be delegated to lower-level teams, but nevertheless the Architecture Landscape should be managed as a whole.

Consideration of the response to a changing climate is a good example of the more complex dance needed between the approaches of intention and emergence (also known as planning and discovery). Dealing with a changing climate requires that a long-term strategy has to be shaped that must respond to emerging climate threats and technological and political solutions that are not yet fully known, but for which action must be soon marshalled in relation to a 30-50 year target. We start with a high-level architecture vision of the target state (net zero emission, or even negative emission). We have also a Baseline Architecture, which is complicated with many interdepended elements, while immediate action is required, ill thought-out action wastes resources and may make things worse. Commitments to key components made too early limit what can be done later. Transition states need to address the potential for technology change (and other change) within each MVP as well as between MVPs. With complex change there is a need to balance the integration architecture over time with each implemented MVP. This enables future transitions to be progressed more easily, from each Baseline Architecture towards the evolving Target Architecture. Essentially this is developing a general concept described in the vision as goals, through enabling capabilities and ultimately to implemented MVPs.

An example of the difficulty associated with selecting early building blocks to address climate change is that of transport. If we are to increasingly use electric transport, we may need infrastructure such as easily replaceable batteries (not currently proposed), induction power delivery built into travel environments such as roads (not currently proposed), or accessible and timely charging points available to all (currently progressing too slowly with little thought for those who have no space for their own charging capability – such as those living in flats with no parking). Planning and investment into the building blocks and the supporting infrastructure is expensive and requires many tens of years to realize. However, that infrastructure must integrate with and interact with the transport modules (cars, lorries, planes, ships, etc.) and do so in a consistent and stable way. Those transport modules change continuously and there are few effective standards such that progressing the combination of the building blocks and the integrated environment is no easy matter.

The reality in these and many other situations is that we have to find the right blend of intentional and emergent architecture. We cannot just rapidly build isolated components nor restrict components to those predicted in a long-term plan. We can, however, blend the two approaches together to achieve the greatest effectiveness and better, rather than worse, Architecture Landscapes.

The TOGAF Enterprise Metamodel (Figure 4) identifies the types of entity (together with some of their important relationships) that you need to consider when generating the logical model, specifying a change (the Architecture Building Blocks (ABBs)) and creating their associated physical/operational implementations (the Solution Building Blocks (SBBs)). In addition, a set of viewpoints that contain these entities and their relationships; and a set of container deliverables managing the building blocks and artifacts during the change activity, will need to be identified. Using those selected viewpoints architects, create appropriate views containing building blocks relevant to the specific problem that the architecture deals with.

Figure 4: TOGAF Enterprise Metamodel (Source: [C220])

Table 1: Change Profile Groupings of Entities for which Building Block are Identified

Profile Inclusion	Domain	Metamodel Entities / Types of Building Blocks
Rapid	General	Location
	General	Requirement
	General	Work Package
	General	Constraint
	Business	Driver
	Business	Goal
	Business	Objective
	Business	Actor
	Business	Organization Unit
	Business	Course Of Action
	Business	Business Information
	Application	Physical Application Component
	Data	Physical Data Component
	Technology	Physical Technology Component
Functional +	General	Gap
	General	Principle
	Business	Business Capability
	Business	Value Stream
	Business	Business Service
	Business	Service Quality
	Business	Measure
	Business	Use Case / User Story
	Business	Process
	Business	Product
	Business	Role
	Data	Data Entity
	Application	Application Service
	Technology	Technology Service
Robust +	General	Assumption
	General	Principle (+ Policy & Standard)
	General	(Work) Capability
	Business	Business Model / Operating Model
	Business	Control
	Business	Contract
	Business	Event
	Business	Business Function
	Application	Logical Application Component
	Data	Logical Data Component
	Technology	Logical Technology Component

3.1 Choosing Configuring Change for Different Profile Viewpoints

Table 1 shows all the entities (types of building blocks) from the TOGAF Enterprise Metamodel plus two additional building block sets that are often used (Use Case/User Story, and Business Model/Operating Model, in the Business Architecture section). These are added as Use Cases/User Stories are often used to supplement/replace simple requirements statements. The overall Business Model/Operating Model provides the context for the other building blocks that are created by the Strategy team and fed into architecture, course of action, value stream, and business capability.

The metamodel identifies the different entities that should be considered when addressing change. ABBs are created/acquired/reused to describe and shape change based on the relevant entities. SBBs are created/acquired/reused to implement and deploy change into the operational environment.

When approaching change, which metamodel entities should be selected? Are the exact number for each profile of change selected in all circumstances? Table 1 provides starting points for configuring the different profiles of change. In some cases, some of the entities and their associated building blocks for more functional or robust change will be used for rapid change and vice versa. The table enables a minimal, maximal, or intermediate approach depending on the situation. It promotes consideration/justification of what has been left out or included for each change situation.

The table has been constructed to reflect choices made in many different real-world situations, reflecting the flavor that rapid change is fast implementation of minimal technical solutions, functional change is ensuring the business operability of implementations and robust change is minimizing the risk and negative impacts of implementations.

The rapid profile focuses on the creation of SBBs to deliver working services as quickly as possible and may result in many of the ABBs (the specifications) being left out. The executing solution is considered to “speak for itself” as it executes.

At the other end of the spectrum, the robust approach focuses on the creation of ABBs to ensure that the context and concept are fully understood before creating the SBBs (the implementations). In this situation the proposed architecture must “speak for itself” before it is created to ensure that any risks and threats associated with the change are fully addressed.

Table 1 provides a resource for consideration of which entities should be considered for a specific change and a basis for documenting the reasons for the choices made. Whichever choices are made they should be properly documented including the reasons for the choices and their implications.

3.2 Configuring Your Architecture Viewpoint for Rapid Change

The first section of Table 1 shows the set of entities to be considered as the basis for rapid style change. Once the context has been established, rapid change is approached using a very direct discovery and early implementation approach. The creation/build of the SBBs acts as a proxy for the identification of the requirements and constraints, and the logical ABBs as well as the creation of the implementable SBBs themselves.

This profile approach does not ignore the need to understand the change concept and develop an effective specification. It is an approach for exploring and developing the concept and the logical specification as well as the physical implementation in a compound activity. All of the work is merged together but still considered as separate logical aspects that need to be evaluated and assured. Political, social, personal, and technical debt is to some degree encouraged but it must never become so large that it cannot be paid down.

A fail-fast flavor drives the development of change in the plain sight of the solution clients. They must be comfortable that there may well be system operational failures and the possibility of failing to satisfy all of their needs. The trade-off is the promise of quickly adjusting the change to reflect rapidly changing priorities. A challenge is that standard fragmentation and knowledge management gaps tend to occur with this profile.

3.3 Configuring Your Architecture Viewpoint for Functional Change

The first and second sections of Table 1 show the set of entities to be considered as the basis for functional style change. Once the context has been established, functional change is approached using a client and capability-driven approach that emphasizes what is done rather than how it is done. It explores the requirements (often with use cases or user stories) in more detail prior to change solution specification. The focus is on the functionality of the change, allowing a lower level of precision for the technical aspects (which could include, political, social, psychological, or physical elements).

This profile approach prioritizes the behavior elements of the concept allowing the technical aspects to be developed to a “good enough” standard in the earlier units of the MVP and MMP. It acts as a vehicle for earlier delivery of capability to the client base than would be possible if all political/social/personal/technical aspects were addressed as encountered. The complete logical specifications are rarely completed with a more direct movement from the vision sketch and business service specifications to the solution implementation. The challenge in managing this approach is how to address the debt that starts to accumulate and can interfere with the exploitation of the emerging capability.

This profile of change is most often addressed using Agile style techniques and should have a balance of fail fast and right first-time outcomes that reflect the context and concept of the change. Functional change should always deliver real capability that addresses the client’s acceptance criteria and may also include significant quality standards associated with the desired functionality and realized business outcomes.

3.4 Configuring Your Architecture Viewpoint for Robust Change

The first, second, and third sections of Table 1 show the complete set of entities to be considered as the basis for robust style change. Once the context has been established, robust change is often approached using a problem, threat, or risk perspective that ensures change impacts are fully considered before implementation. Significant political/social/personal/technical debt is avoided where possible and there will usually be significant levels of assurance activity. The full set of relevant entities and associated building blocks must be considered, and each level of abstraction be explored in detail. Often specialized comprehensive approaches are used, such as COBIT or SABSA, which implement widely used international control, risk, and security standards. 

This robust profile approach incurs significant time ensuring that the context and concept are fully understood for each MVP before developing the logical specification, and before creating the physical solution components. It prioritizes the total impact of the change making sure that each element of change meets a specifically defined standard of operation and interoperability.

The right first-time flavor drives the development of change that must work the vast majority of the time. Note that even with highly robust change, such as to aircraft control systems, there are some real-world failures, but they are rare and rigorously followed up to reduce risk in the future. There will be significant activity out of sight of the client environment to ensure that each solution component and their interoperability can satisfy rigorous and extensive challenges that may well never happen.

The data and results produced by this assurance activity should always be made available to all stakeholders, irrespective of the political and social context. Again, the example of the approach with aircraft safety is probably the closest to this, with extensive “no-fault” investigation driving a significant degree of openness. All types of debt are rigorously challenged and eliminated where possible.

3.5 Dealing With Multiple Iterations of Different Profiles of Change

In any relatively large and/or complex enterprise there will be an Enterprise and Segment Level context and concept (a superior architecture in TOGAF Standard terms) within which relatively isolated and/or collaborating teams must work. If that superior architecture demonstrates that some change can be progressed independently from other change that is fine. Isolated change should never be attempted without a full understanding of the context and concepts within which it is being progressed. The granting of some localized decision-making rights, and the provision of end-to-end development and implementation capability within change teams is good practice. It should be done within the constraints of the overall context and concept at the Enterprise, Segment, and Solution/Capability levels of granularity. The management of this larger and more complex change, including selecting the right levels of intention and emergence, is the role of Enterprise and Segment Architects. They act as the conscience and custodians of the operable shape of an enterprise so that it can progress towards the aspirational target implied in its strategy. The goal is to implement significant and successful change in a manner that best fits the enterprise mission, vision, client environments, and markets.

3.6 What About Artifacts and Deliverables?

Once the entities and the associated building blocks have been identified, they will be documented by various artifacts and organized into specific deliverables to communicate and progress the change. The choices of these are significantly determined by an enterprise’s specific local change and documentation expectations. The TOGAF Standard provides lists, definitions, and descriptions for artifacts and deliverables that are shown in Appendix A and Appendix B. The TOGAF Standard does not mandate which of these you should be used rather it provides the lists as illustrations of what could be used once the nature of and approach to, a specific change, have been identified.

This document describes how the TOGAF Standard can be applied to both complex and simple change. It is an illustration of what you could do (not what you must do) to properly configure change activity and identify the entities leading to the building blocks needed to understand, create, and implement effective solutions.

When addressing change in a proportionate and targeted manner the TOGAF Standard identifies four levels of abstraction that must be considered when developing an architecture for an enterprise, a segment, or a solution (implementing capability). These are:

• Why: Context – the circumstances in which a change is being addressed (mission, current situation, drivers, goals, and objectives, etc.)
• What: Concept – the target of the change (the specific concerns, requirements, constraints, capabilities, sketches of a possible solutions, and KPIs, etc.)
• How: Logical – what is needed to achieve the desired outcomes and how they interact (activities, building blocks, components, interfaces, systems, and services, etc.) unconstrained by specific implementations (unless implementation constraints are part of the requirements)
• With What: Physical – the arrangement of physical components (note that not all implementation components are physical; some can be logical, such as culture, knowledge or understanding) into executable, maintainable, and usually evolvable groupings of implementable building blocks, systems, and services

This document provides suggestions for how to deliver effective evolution and management of an enterprise’s Architecture Landscape and operational activities, choosing specific approaches to change that best suit situations appropriate to the three specific profiles.

This part of the document describes how the TOGAF ADM can be applied to both complex and simple change. It is an illustration of what you could do (not what you must do) to properly configure change activity and identify the entities and associated building blocks needed to understand, create, and implement effective solutions. Please note that Table 2 does not show Phase H, which is starting point for the change. This is also the phase in which change is discovered and its implementation finally evaluated. The decision about the nature of the change is taken in Phase H, and there are two main possibilities:

• When a change does not impact on the Enterprise Architecture, it can be addressed using any relevant change management approach
• When a change does impact upon the Enterprise Architecture, the architecture development cycle is started

This choice is not only based on the size of the change but also on the architecture impact of the change. When the change cycle requires new capabilities in its execution the Preliminary Phase is executed to provide those capabilities. This ensures that the appropriate resources, processes, skills, and other elements of architecture capability are in place. More about establishing proper architecture capability can be read in: The TOGAF^® Leader’s Guide to Establishing and Evolving an Enterprise Architecture Capability.[1]

Table 2: Abstraction Levels and TOGAF Phases

Step Number	Table Column Heading	Description	TOGAF Phase	Phase Name
1	Establishing the Context for Change	Identify the nature of the change (mission, current situation, drivers, goals and objectives, concerns) and choose the type of approach for the unit of change.	A	Vision
2	Establishing the Context for Change	For that unit of change identify the architecture levels being followed or developed.	A	Vision
3	Outlining the Concept of the Change	Identify the Key Performance Indicators (KPIs) that need to be achieved to demonstrate success.	A	Vision
4	Outlining the Concept of the Change	Identify the target of the change (requirements, constraints and capabilities, possible solution sketch).	A	Vision
5	Identifying the Logical Change Elements	Identify the minimum set of deliverables needed to achieve the target solution.	B / C / D	Domain Specification
6	Identifying the Logical Change Activities	Identify the activities that need to be undertaken to develop the target solution.	E	Opportunities and Solutions
7	Identifying the Logical Change Elements	Specify the solution components, their integration, and the implementation constraints.	E	Opportunities and Solutions
8	Identifying the Logical Change Elements	Develop the implementation contracts and checklists to govern the progress towards the target solution.	F	Migration Planning
9	Delivering the Physical Realization of the Change	Oversee the development, implementation, and deployment of the solution.	G	Implementation Governance
10	Organizing for and Realizing the Benefits of the Change	Ensure that the checklists are satisfied and the KPIs are achieved.	H	Change Management

Table 2 shows a stripped down version of the abstraction levels and the TOGAF Standard phases that you should consider if you wish to apply the TOGAF Standard successfully. They can be applied to all types of change, from careful intentional and robust change to emergent and rapid change. Each subsequent section of the guide will show the table and which steps are being addressed in that section (in bold).

“Establishing the Context” should be focused on Step 1 and Step 2 of Table 2.

An Enterprise/Segment/Solution Architect, (referred to as an ESS Architect subsequently when the collective is needed) evaluates the goals and objectives for a change and identifies a balanced and integrated set of capabilities, building blocks, and solutions aimed at achieving the desired outcomes in an effective manner, which satisfies the stakeholders requesting the change.

The first two steps in implementing change, which align with Phase A of the TOGAF ADM, are to establish the context by identifying the current enterprise state, and its vision (usually reflected in its mission, drivers and concerns, and the derived goals, objectives, and requirements). These should then be related to three specific levels of architecture granularity that they may impact:

• Strategic Architecture – provides an organizing framework for operational and change activity and allows for direction setting at an executive level
• Segment Architecture – provides an organizing framework for operational and change activity and allows for direction setting and the development of effective architecture roadmaps at a program or portfolio level
• Capability Architecture – provides an organizing framework for change activity and the development of effective architecture roadmaps realizing capability increments at the component specification and solution implementation level

In a large enterprise, different types of architects work at these three levels (usually collaborating in a team or professional practice within an overall Enterprise Architecture framework), while in smaller organizations one architect may perform more than one, or all, of the roles.

• Enterprise Architects tend to work at the strategic level creating roadmaps, reference models, guidelines, and best practice across the broad scope of the enterprise
• Segment Architects tend to work at the portfolio or program level creating roadmaps, reference models, guidelines, and best practice for the relevant portfolio or program, and oversee more detailed building block, sub-system and system change-related change associated with the capabilities overseen by their segment
• Solution Architects tend to work at the capability and solution/component implementation level

They will sometimes be working within a broader context (a superior architecture) shaped by Enterprise and Segment Architects and sometimes in direct relationship to other specific stakeholders for change. They specify, shape, and govern implementation related change; ensuring that the capabilities that will be included within the change are properly transposed into the right building blocks, components, interfaces, sub-systems, and systems and will deliver the desired overall outcomes (usually described in terms of service level performance).

Note that the specialists in building blocks, components, sub-systems, and systems (for any relevant content such as process, people, software, hardware, networks, data, market knowledge, buildings, machines, etc.) work within the constraints identified by the architecture, which could be very limited and open, or much more specific and closed, providing the detailed design, build, and operations work that satisfies the architecture. The architecture roles integrate and work with the specialists and bind all of the specialist activity together such that the final executing solutions and services best satisfy their context and concept and deliver the desired outcomes. Figure 5 shows how the architecture levels, roles, and domains interact.

 

Figure 5: An ERD showing the Relationships between Architecture Levels, Roles, and Domains

Execute “Outlining the Concept”, as per Step 3 and Step 4 of Table 2.

Once the context has been established the next two steps establish the specific concepts that will be used to address the change, these two steps also align with Phase A of the TOGAF ADM.

Some set of performance expectations, or measures, is needed to represent the outcome desired by the commissioning stakeholders. During the concept steps these are usually recorded in the form of KPIs that describe the things to be achieved, when they should be achieved by, and the level of performance expected (they should be Specific, Measurable, Actionable, Reliable, and Time-Bound (SMART)). The KPIs should be outlined before identifying the target concept of the change and will often be gradually revised as the possible change solution implementation emerges.

In many cases there will be a superior architecture (an Enterprise, Segment, or Solution/Capability-Level Architecture within which the change must happen). This will have been established in the context steps and provides a set of constraints within which the change should progress.

The inputs to the development of the change concept follow on from those identified in context development, adding more specific requirements and constraints. An evaluation of the context and these additional elements enables a specific set of capabilities to be identified that will be needed to support the change. Once those capabilities are understood, a sketch of the possible solution and its main building blocks can be developed to enable all stakeholders to generate an opinion on whether the sketch is likely to address their concerns. The concept steps generate this vision and the KPIs, which must be reviewed and approved or otherwise by the relevant stakeholders.

The possible solution and associated building blocks can be described using each enterprise’s specialization of the TOGAF Enterprise Metamodel (see Figure 4) at a level of detail that makes sense for the nature of the change, the required depth of the vision, and the understanding of the stakeholders. The elements of the metamodel that should be considered will be discussed and suggested in detail in the next section on “Configuring the Change”. When developing the concept, a high-level sketch form of these building blocks and their interactions will often be used.

The time taken to develop an agreed concept depends on the nature of the change and the scope and reach of the desired solution. A longer example is the robust change profile context and concept of a commercial Nuclear Fusion Reactor. Teams exploring this possibility have been working for 20 years but are still exploring what the relevant building blocks and their integration should be and what the realistic values for the KPIs might be. They have not yet been able to move to what the actual operable and marketable solution should contain; either logically or physically. There is no approval yet from the various stakeholders that there is a basis for a logical solution specification let alone a physical solution implementation. This change has been unable to move forward and complete the logical solution definition and is still in the context and concept development stages. A shorter example is the changes made to the social networking service X (formerly known as Twitter) since the takeover by Elon Musk. A new context and concept were quickly established, and progress made on implementing change into the live operational product. While this change is of the more functional change profile (incurring what many people consider is significant political, social, personal, and technical debt) it has moved all the way through to conceptual realization within a few months and many iterations of implemented change.

Once the context and concept are agreed by the relevant stakeholders a change can move into one or more sets of logical definition of the complete set of building blocks and components for that unit of managed change. These logical solution steps can be represented as an MVP that can be progressed towards an MMP.

The focus of “Configuring the Change”, is as per Steps 5, 6, and 7 of Table 2.

Once the context/concept has been established the next three steps identify the logical ABBs that will be used to implement the concept, progressing the MVP. These three steps align with Phases B-E of the TOGAF ADM.

As the MVP progresses and is tested against client expectations it needs to achieve the status of an MMP (something that will be accepted by its client base in addressing their concerns and needs). If that client expectation testing identifies that changes are needed to the MVP, they should be applied, and the MVP adjusted to define the MMP (see Figure 3).

The TOGAF Enterprise Metamodel (see Figure 4) identifies the types of entity (together with some of their important relationships) that you need to consider when generating the logical model specifying a change (the ABBs) and creating their associated physical/operational implementations (the SBBs). In addition, a set of artifacts that describe these entities and their relationships; and a set of container deliverables managing the building blocks and artifacts during the change activity, will need to be identified. Lists of those are in Appendix A and Appendix B. In most cases, an Architecture Repository is maintained to store and make available the artifacts and deliverables that describe the entities, including their logical specifications. These are referred to in the TOGAF Standard as work products and stored in the Architecture Landscape of the Repository. When the physical/operational implementation components of the changing solution are planned and subsequently created/acquired and deployed their configuration and location information is stored in the Solution Landscape of the Repository.

You should choose the building blocks relevant to the specific business change and selected profiles as described in Chapter 3.

Execute “Checklists and Governance for Change Profiles” as per Step 8 of Table 2.

As the logical specifications for each transition state defined as MVP/MMP are established the next step (usually performed concurrently with steps 5-7) identifies the resources to be used to develop and deploy the transition and the time and cost needed to perform the creation and implementation of the transition. This step aligns with Phase F of the TOGAF ADM.

The major deliverables finalized in this step are the Architecture Definition Document, the Architecture Requirements Specification, the Architecture Transition Roadmap, and the proposed Architecture Contracts. These are populated with the logical building blocks and any artifacts needed to describe and explain those architecture, how they work together and how they should be organized for creation and implementation. Again, see the appendices for the artifacts and deliverables to be considered. Once the set of building blocks, artifacts, and deliverables is finalized a checklist can be finalized and used to identify what needs to be completed and the status of that completion.

The checklists identify two major groupings: one for Phases A-F that checks whether the specifications and plans for solution creation and implementation are complete and realizable, and one for Phases G-H to confirm the effective implementation of that realizable architecture.

The first one addresses whether the right things are being done and the second one addresses whether the right things were done well, the solution was created and implemented as specified (plus addressing any changes that occurred during the implementation), and the outcomes and the service-level performance were achieved.

Table 3 shows the checklist for the first eight steps, and which elements should be included for the three different profiles of change. Table 4 (shown in Chapter 11) shows the checklist for Steps 9 and 10, and which elements should be included for the three different profiles of change.

Table 3: The Different Change Profile Checklists Steps 1-8

Step	TOGAF Phase / Domain	Checklist Item	Rapid	Functional	Robust	Passed
Step 1	Phase A: Vision	Are customer needs clearly understood and agreed?	Y	Y	Y
		Is the architecture maturity at the required level for the change?		Y	Y
		Is the impact on the enterprise business model and operating model identified and addressed?			Y
		Are both functional and non-functional requirements defined?		Y	Y
Step 2	Phase A: Vision	Are the architecture profiles for each unit of change understood and applied?	Y	Y	Y
Step 3	Phase A: Vision	Are the KPIs defined?	Y	Y	Y
Step 4	Phase A: Vision	Have the proposed solution overviews/sketches been created?	Y	Y	Y
		Have the reuse/purchase/creation properties of the expected solution components been approved?			Y
		Are the ROM outline plan and estimates completed?		Y	Y
		Has the vision been signed off by all relevant stakeholders?	Y	Y	Y
		Have all enterprise and segment guidelines (principles, policies, and standards) been reviewed and any divergences approved?		Y	Y
Step 5	Phase B: Business	Have all business capabilities relevant to the proposed solutions been identified?		Y	Y
		Have all actors, processes, and business services relevant to the proposed solutions been described?		Y	Y
		Have all information entities relevant to the proposed solutions been described?	Y	Y	Y
		Have all service level performance and quality requirements been identified?		Y	Y
		Have all business operational support, maintenance and governance processes and resources been identified?			Y
		Have all the relevant business principles, policies, and standards been reviewed and any divergences approved?			Y
	Phase C: Data	Have all logical data entities been defined in an ERD?			Y
		Have all logical data storage mechanisms and locations been identified?			Y
		Have all logical message exchange formats and contents been defined?			Y
		Have all logical data query mechanisms and controls been defined?			Y
		Have all data management and governance process and resources been identified?			Y
		Have all data principles, policies, and standards been reviewed, and any divergences approved; for example, personal data?			Y
	Phase C: Application	Have all logical application components and their offered interfaces been identified?			Y
		Have all logical application interaction patterns been identified?			Y
		Have all logical application execution environments, domains and locations been identified?			Y
		Have all application operational support, maintenance, governance processes, and resources been identified?			Y
		Have all the relevant application and software principles, policies and standards been reviewed, and any divergences approved?			Y
	Phase D: Technology	Have all logical technology components and their interfaces been defined?			Y
		Have all logical technology interaction patterns been identified?			Y
		Have all logical technology execution environments, domains and locations been identified?			Y
		Have all technology operational support, maintenance, governance processes, and resources been identified?			Y
		Have all technology principles, policies, and standards been reviewed, and any divergences approved?			Y
	Phase X: Security	Have the required security components, locations, and policies been identified?		Y	Y
		Have all security operational support, maintenance, governance processes, and resources been identified?		Y	Y
		Have all security principles, policies, and standards been reviewed and any divergences approved?			Y
Step 6	Phase E: Opportunities and Solutions	Have all Transition Architectures been identified?		Y	Y
		Have the activities for each relevant Transition Architecture been identified?		Y	Y
		Have the relevant stakeholders signed off the Transition Architectures?		Y	Y
Step 7	Phase E: Opportunities and Solutions	Have all solution components and their interactions been identified for each relevant Transition Architecture?		Y	Y
		Have the relevant stakeholders signed off the solution component specifications for each Transition Architecture?			Y
		Have all the relevant principles, policies, and standards been reviewed and any divergences approved?		Y	Y
Step 8	Phase F: Migration Planning	Have all solution component providers been identified together with their outline contracts and commitments?		Y	Y
		Have the risks been identified and evaluated?		Y	Y
		Have all operational support, maintenance, governance processes, and resources been identified?		Y	Y
		Has the expected value been finalized?		Y	Y
		Have the detailed plans and estimates been completed?			Y
		Have the relevant stakeholders approved the detailed plans and estimates?			Y
		Have the relevant stakeholders approved the proposed outline contracts and commitments?		Y	Y

Execute “Realizing physical (and Some Logical) Deliverables” as per Step 9 of Table 2.

Once Step 8 is completed and the next step has been agreed, Step 9 provides organization support, oversight, and governance of the creation and implementation activities performed by the solution component and operations specialists. The Solution Architect overseeing this activity finalizes and gains signatures to any specific architecture contracts and ensures that all governance and assurance activities have been carried out and completed. The information in support of the checklist is collected to confirm the effective implementation of the reliable architecture and the satisfaction of the contractual commitments. The checklist is used to assure that the right activities and outcomes have been achieved as Step 9 progresses. The review of the checklists and confirmation of successful delivery is addressed in the next step.

The focus of “Conceptual Realization – Assuring the Benefits” is on Step 10 of Table 2.

This final step executes as each Transition Architecture is implemented for each MVP/MMP for each product or program. Table 4 shows the final elements of the checklist addressing the success, or otherwise, of the implemented solution as it progresses through the evolving cycles of change. It focuses on the achieved of all contracted commitments, including overall service level performance, satisfaction of the KPIs and a more generalized perception from the relevant stakeholders that the realized business value is in line with their expectations (however general or specific).

Table 4: The Different Change Profile Checklists Steps 9-10

Step	TOGAF Phase / Domain	Checklist Item	Rapid	Functional	Robust	Passed
Step 9	Phase G: Implementation Governance	Have the physical solution component providers agreed and signed their contracts and committed to the agreed delivery approach?			Y
		Have the physical solution components been acquired and tested against their specifications and contracts?			Y
		Have the physical solution components been implemented into their operational environments in support of the agreed service levels?	Y	Y	Y
		Have the physical solution components been tested and assured in their operational environments and are they supporting the service level agreements?	Y	Y	Y
		Have the risks been addressed and properly mitigated?		Y	Y
		Have the relevant stakeholders signed off the implemented solution components and services?	Y	Y	Y
		Have the physical solution components and the associated operational services been accepted into operational management and support by service operations?		Y	Y
Step 10	Phase H: Change Management	Have all contractual commitments, tests and service levels been reviewed and assured?	Y	Y	Y
		Have the KPIs been achieved?	Y	Y	Y
		Is the new solution delivering expected or greater than expected value?	Y	Y	Y

Table 5: Architecture Artifacts by Domain

Domain	Artifact
General	Constraints Catalog
General	Environments and Locations Diagram
General	Location Catalog
General	Principles Catalog
General	Requirements Catalog
General	Requirements Impact Assessment
Business	Actor/Role Matrix
Business	Application/Function Matrix
Business	Application/Organization Matrix
Business	Actor/Role Matrix
Business	Application and User Location Diagram
Business	Benefits Diagram
Business	Business Capabilities Catalog
Business	Business Capability Map
Business	Business Event Diagram
Business	Business Footprint Diagram
Business	Business Glossary Catalog
Business	Business Interaction Matrix
Business	Business Model Diagram
Business	Business Service/Function Catalog
Business	Business Service/Information Diagram
Business	Business Use-Case Diagram
Business	Capability/Organization Matrix
Business	Conceptual Data Diagram
Business	Contract/Measure Catalog
Business	Data Entity/Business Function Matrix
Business	Driver/Goal/Objective Catalog
Business	Environments and Locations Diagram
Business	Functional Decomposition Diagram
Business	Goal/Objective/Service Diagram
Business	Information Map
Business	Organization Decomposition Diagram
Business	Organization Map
Business	Organization/Actor Catalog
Business	Process Flow Diagram
Business	Process/Application Realization Diagram
Business	Process/Event/Control/Product Catalog
Business	Product Lifecycle Diagram
Business	Project Context Diagram
Business	Role Catalog
Business	Role/Application Matrix
Business	Stakeholder Catalog
Business	Strategy/Capability Matrix
Business	Value Chain Diagram
Business	Value Stream Catalog
Business	Value Stream Map
Business	Value Stream Map
Business	Value Stream Stages Catalog
Business	Value Stream/Capability Matrix
Application	Application and User Location Diagram
Application	Application Communication Diagram
Application	Application Interaction Matrix
Application	Application Migration Diagram
Application	Application Portfolio Catalog
Application	Application Use-Case Diagram
Application	Application/Data Matrix
Application	Application/Function Matrix
Application	Application/Organization Matrix
Application	Application/Technology Matrix
Application	Interface Catalog
Application	Process/Application Realization Diagram
Application	Processing Diagram
Application	Role/Application Matrix
Application	Software Distribution Diagram
Application	Software Engineering Diagram
Application	Solution Concept Diagram
Data	Application/Data Matrix
Data	Conceptual Data Diagram
Data	Data Dissemination Diagram
Data	Data Entity/Business Function Matrix
Data	Data Entity/Data Component Catalog
Data	Data Lifecycle Diagram
Data	Data Migration Diagram
Data	Data Security Diagram
Data	Logical Data Diagram
Technology	Application/Technology Matrix
Technology	Enterprise Manageability Diagram
Technology	Environments and Locations Diagram
Technology	Network and Communications Diagram
Technology	Networked Computing/Hardware Diagram
Technology	Platform Decomposition Diagram
Technology	Technology Portfolio Catalog
Technology	Technology Standards Catalog

The TOGAF Standard provides a list and definitions for the artifacts that should be considered in support for the entities and associated Building Blocks chosen for each specific solution. Please refer to the TOGAF Standard 10^th Edition [C220] Architecture Content.

Table 6: Architecture Deliverables

Deliverable
Architecture Building Blocks (ABBs)
Architecture Contract
Architecture Definition Document
Architecture Requirements Specification
Architecture Principles
Architecture Repository
Architecture Roadmaps
Architecture Vision
Business Goals and Objectives
Business Principles
Business Drivers
Capability Assessment
Change Request
Communications Plan
Compliance Assessment
Implementation and Migration Plan
Organization Model (for Enterprise Architecture)
Request for Architecture Work
Requirements Impact Assessment
Solution Building Blocks (SBBs)
Statement of Work
Tailored Architecture Framework

The TOGAF Standard provides a list and definition for the deliverables that provide containers for the entities associated building blocks and artifacts chosen for each specific solution. Please refer to the TOGAF Standard Foundation documentation for more detail on these.

“The ADM is a generic method for architecture development, which is designed to deal with most system and organizational requirements. However, it will often be necessary to modify or extend the ADM to suit specific needs. One of the tasks before applying the ADM is to review its components for applicability, and then tailor them as appropriate to the circumstances of the individual enterprise. This activity may well produce an “enterprise-specific” ADM.”

The TOGAF Standard [C220], §Fundamental Content Applying the ADM.

“The TOGAF Standard includes the TOGAF Enterprise Metamodel which captures the entities and relationships that are likely to be encountered in the majority of enterprises. This may be used as the basis for developing an Organization-Specific Metamodel. When developing an Organization-Specific Metamodel, architects may choose not to include entities and relationships from the TOGAF Enterprise Metamodel which are not relevant and/or add additional entities and relationships.”

The TOGAF Standard [C220], §The Content Framework and The Enterprise Metamodel.

Acronyms & Abbreviations

ABB	Architecture Building Block
ADM	Architecture Development Method
COBIT	Control Objectives for Information and Related Technologies
CTO	Chief Technology Officer
DSDM	Dynamic System Development Method
DXP	Digital Experience
ERD	Entity Relationship Diagram
ESS	Enterprise/Segment/Solution
JAD	Joint Application Development
KPI	Key Performance Indicator
MMP	Minimum Marketable Product
MQP	Market Quality Product
MSP	Managing Successful Programs
MVA	Minimum Viable Architecture
MVP	Minimum Viable Product
RAD	Rapid Application Development
SABSA	Sherwood Applied Business Security Architecture
SBB	Solution Building Block
SMART	Specific, Measurable, Actionable, Reliable, and Time-Bound

[1] Refer to: www.opengroup.org/library/g184.