Architecture Development Cycle

Key Points

The following are the key points about the ADM:

• The ADM is iterative, over the whole process, between phases, and within phases (see the

• TOGAF Standard - ADM Techniques)
  For each iteration of the ADM, a fresh decision must be taken as to:
  The breadth of coverage of the enterprise to be defined

• The level of detail to be defined
  The extent of the time period aimed at, including the number and extent of any intermediate time periods

• The architectural assets to be leveraged, including:
  Assets created in previous iterations of the ADM cycle within the enterprise
  Assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.)

• These decisions should be based on a practical assessment of resource and competence availability, and the value that can realistically be expected to accrue to the enterprise from the chosen scope of the architecture work

• As a generic method, the ADM is intended to be used by enterprises in a wide variety of different geographies and applied in different vertical sectors/industry types
  As such, it may be, but does not necessarily have to be, tailored to specific needs. For example, it may be used in conjunction with the set of deliverables of another framework, where these have been deemed to be more appropriate for a specific organization. (For example, many US Federal agencies have developed individual frameworks that define the deliverables specific to their particular departmental needs.)

Basic Structure

The basic structure of the ADM is shown in Figure 1-1.

Throughout the ADM cycle, there needs to be frequent validation of results against the original expectations, both those for the whole ADM cycle, and those for the particular phase of the process.

The phases of the ADM cycle are further divided into steps, which are defined in the detailed description of each phase.

The Requirements Management phase is a continuous phase which ensures that any changes to requirements are handled through appropriate governance processes and reflected in all other phases. An enterprise may choose to record all new requirements, including those which are in scope of the current Statement of Architecture Work through a single Requirements Repository.

The phases of the cycle are described in detail in the following chapters.

Note that output is generated throughout the process, and that the output from an early phase may be modified in a later phase. In the ADM, the status of outputs at each stage is defined.

Lifecycle of outputs

The lifecycle of outputs must be managed through a version numbering policy, adapted by the architect to meet the requirements of the organisation and to work with the architecture tools and repositories employed by the organisation.

In the ADM, documents which are under development and have not undergone any formal review and approval process are designated "draft". Documents which have been reviewed and approved are designated "approved" in accordance with the organisation's governance practices. Approved does not necessarily mean finalised. Documents may evolve during subsequent phases but may only be changed through an appropriate change control and governance process. This is used in particular within the ADM to illustrate the evolution of Baseline and Target Architecture Definitions.

How is ADM Iteration Realized in Practice?

An often-misunderstood element of the TOGAF framework is the ADM and the concept of iteration. The TOGAF ADM graphic provides a stylized representation that is often misinterpreted as a linear waterfall process model. This approach leads to some of the most confusing diagrams and explanations. The TOGAF ADM is a logical method that places key activity steps together for the purpose of understanding relationship of activity and clarifying information flow. The classic TOGA crop-circle diagram is a stylized path that demonstrates essential information flow.

The TOGAF ADM should not be understood as a processes model. The ADM graphic is a stylized representation showing essential information flows and is not a representation of activity sequence.

The important thing to realize is every time the EA team is undertaking any activity within the scope of the ADM it is executing a Phase and developing the contents of the EA Landscape. For example, if a Practitioner is working on roadmap development, the Practitioner is exercising the steps in the TOGAF ADM Phase E (Opportunities and Solutions). The Practitioner needs to consume the mandatory inputs and produce the mandatory outputs. This applies to all ADM phases.

Start with recognizing that the inter-dependent nature of developing a Target Architecture requires considering the entire architecture, resulting gaps, and resulting work to clear the gap simultaneously. No Practitioner can consider a change, without considering the impact on all other domains, the resulting set of gaps, and the resulting set of work to clear the gap.

Unfortunately, describing that level of interaction is not practical. To address the complexity, the TOGAF framework provides an ADM phase for each essential output. Best practice ensures

Practitioners use effective information inputs and produce useful outputs.

Depending on what a Practitioner is requested to develop, an architecture for the Practitioner's work plan will vary. Consider the impact on which phases of the ADM would be used for the following requests:

1. Given that the organisational design, customer interface, and processes are to be left unmodified, what other changes would allow "moving to the cloud"?
2. What changes are required to switch from more than 50 independent organisations pursuing small projects, to an integrated company capable of organising, and controlling, construction projects 100 times larger than the current average?
3. What changes are required to the core claims platform to allow a 300% growth in customers and transactions, and enable continuous change to policy terms?
4. Given that the ERP and current Finance & HR processes will be kept, what are the minimum changes to support allocating labor to capital projects?
5. How to integrate the acquisition with the minimum change, while sustaining both the current high-efficiency processes and the unique capability from the acquisition?
6. How to enable a third-party developer's agile approach, and Micro-services, on the customer intimacy project?
7. How to modernise a particular platform without impacting anyone outside IT?

Each of these requests has been addressed using the TOGAF framework, and the techniques.

Each started with a different purpose, and each traversed a distinct path that used a different configuration of the TOGAF ADM.

The only exception is Phase A; the Practitioner must start with Phase A. An Architecture Project must be initiated.

Phase A: The Starting Point

All architecture development needs to start with Phase A. Without the set-up inherent in Phase A

Practitioners can expect to slide off-course and fail to deliver useful architecture.

The set-up essentials of Phase A are:

• Define the scope of the Architecture Project
  What problem are you solving? In terms of the EA Landscape breadth and planning-horizon) and in terms of purpose, which will tend to confirm the necessary level of detail?
  Be completely clear where in the business cycle this architecture will be used.

• Identify stakeholders, concerns, and associated requirements
  Explore the EA Repository for superior architecture constraints and guidance. Do the Stakeholder Map. Be completely clear which stakeholders must be served and what they are worrying about.

• Assess the capability of the EA team
  Take a hard look at the EA team and confirm the ability of the team to deliver on this architecture development project. A good EA team covers gaps in experience, skill, and bias to deliver the architecture that is useful, overcoming weaknesses of few members of the team.

The completion essentials of Phase A:

• Key stakeholder agreement on a summary of the target and the work to reach the target
  Perform sufficient architecture development in all domains to enable you to communicate to the key stakeholders how the problem you have been assigned can be addressed and the scope of change to reach their articulated preferences. Be clear on the target, the value of the target, and the work to change.

Frankly, Phase A is routinely skipped, or skimmed. Good Practitioners know the key stakeholders agree on the summary target, the value, and the effort of change before any detailed work is undertaken. If key stakeholders won't agree at the outset, they are unlikely to agree after the Practitioners have performed a lot of work detailing what they do not want, delivered insufficient value, or will not agree to change.

Completing the outputs of Phase A requires exploring all of the domains - whether the exploration is to understand what should change, or where change is not an option to determine the impact of retaining current architecture.

Essential ADM Output and Knowledge

Phase	Output & Outcome	Essential Knowledge
Phase A: Architecture Vision	Sufficient documentation to get permission to proceed. Permission to proceed to develop a Target Architecture to prove out a summary target.	The scope of the problem being addressed. Those who have interests that are fundamental to the problem being addressed. (Stakeholders & Concerns) What summary answer to the problem is acceptable to the stakeholders? (Architecture Vision) Stakeholder priority and preference. What value does the summary answer provide?
Phase B, Phase C, & Phase D	A set of domain architectures approved by the stakeholders for the problem being addressed, with a set of gaps, and work to clear the gaps understood by the stakeholders.	How does the current Enterprise fail to meet the preferences of the stakeholders? What must change to enable the Enterprise to meet the preferences of the stakeholders? (Gaps) What work is necessary to realize the changes, that is consistent with the additional value being created? (Work Package) How stakeholder priority and preference adjust in response to value, effort, and risk of change. (Stakeholder Requirements)
Phase E: Opportunities & Solutions	A set of work packages that address the set of gaps, with an indication of value produced and effort required, and dependencies between the work packages to reach the adjusted target.	Dependency between the set of changes. (Work Package & Gap dependency) Value, effort, and risk associated with each change and work package. How stakeholder priority and preference adjust in response to value, effort, and risk of change.
Phase F: Implementation & Migration Plan	An approved set of projects1, containing the objective and any necessary constraints, resources required, and start and finish dates.	Resources available to undertake the change. How stakeholder priority and preference adjust in response to value, effort, and risk of change. (Stakeholder Requirements)
Phase G: Implementation Governance	Completion of the projects to implement the changes necessary to reach the adjusted target state.	Purpose and constraints on the implementation team. (Gap, Architecture Requirement Specification, Control) How stakeholder priority and preference adjust in response to success, value, effort, and risk of change. (Stakeholder Requirements)
Phase H: Architecture Change Management	Direction to proceed and start developing a Target Architecture that addresses perceived, real, or anticipated shortfalls in the Enterprise relative to stakeholder preferences.	Gaps between approved target, or preference, and realization from prior work. (Value Realization) Changes in preference or priority. (Stakeholder Requirements)

Iteration

The ADM provides a model of activity that supports producing the essential output by producing one or more work products. The central question determines whether there is a need for the essential purpose of a phase on a particular Architecture Project. If so, you will enter the phase at some point in time. If the essential purpose is not needed or has already been addressed, then this Architecture Project does not enter the phase.

Most commentary in the TOGAF Standard on the iteration of the ADM is designed to address the point that if the Practitioner does not have the information at hand in the EA Landscape, the information must be produced. These commentaries speak in terms of activity rather than output.

Instead of considering iteration in terms of re-sequencing and looping the ADM, the Practitioner should explore the EA Landscape. If the information required, in terms of subject, detail, time, and recency is available - move on. If not, produce the material required. To produce material, the Practitioner is exercising a TOGAF ADM phase.

As an example, see the stylized Gantt chart in Figure 10. This figure provides a process-oriented view of executing the ADM. The Gantt shows the inter-dependent nature of EA requires all ADM phases that develop a candidate architecture and test it for acceptance to be open simultaneously. The ADM phases stay open to address the information required; once it is provided they close. Also, regardless of where the Practitioner is in time or purpose or Architecture Project, if the Business Architecture is being developed the Practitioner is executing Phase B. Executing Phase B is all about addressing the stakeholder concerns from the perspective of the Business Architecture domain, identifying the gaps in the Business Architecture, and looking at impacts across the EA Landscape. The figure highlights that many of the steps in the ADM phases can be executed simultaneously. Good Practitioners will explore impacts and address stakeholder concerns across the entire architecture.²

Consider the different purposes and a cascade through time as shown in Figure 4. When the plan in the stylised Gantt chart in Figure 10 is applied to each purpose, it becomes clear that the Practitioner continually revisits the required phases, at the appropriate level of detail.

Most of the normal problem-solving models provide linear approaches with step gates. The linear approach helps us understand the process, and may represent the business cycle stage gates. However, they do not represent how people actually solve problems. Figure 11 is derived from Jeff Conklin's Wicked Problems & Social Complexity within Dialog Mapping (see Referenced Documents), and outlines a standard linear problem solving progression and how professionals typically address a problem. Testing the concept and potential implementation interactively is a best practice. Iteratively considering whether the high-level direction makes sense in terms of execution, and does execution make sense in terms of high-level direction?

All iteration is driven by the information needs of the current project. The process created is not dependent upon the work the EA Capability undertakes to produce, but the timing of completion. The essential question is when an EA Capability must deliver specific work products. Table 3 provides a summary of work products that are actively consumed by key Enterprise processes.

Architecture Governance

The ADM, whether adapted by the organisation or used as documented here, is a key process to be managed in the same manner as other architecture artefacts classified through the Enterprise Continuum and held in the Architecture Repository. The Architecture Board should be satisfied that the method is being applied correctly across all phases of an architecture development iteration. Compliance with the ADM is fundamental to the governance of the architecture, to ensure that all considerations are made and all required deliverables are produced.

The management of all architectural artefacts, governance, and related processes should be supported by a controlled environment. Typically, this would be based on one or more repositories supporting versioned objects, process control, and status.

The major information areas managed by a governance repository should contain the following types of information:

• Reference Data (collateral from the organisation's own repositories/Enterprise Continuum, including external data; e.g., COBIT® the IT4IT Reference Architecture): used for guidance and instruction during project implementation
  This includes the details of information outlined above. The reference data includes a description of the governance procedures themselves.

• Process Status: all information regarding the state of any governance processes will be managed
  Examples of this include outstanding compliance requests, dispensation requests, and compliance assessments investigations.

• Audit Information: this will record all completed governance process actions and will be used to support:

• Key decisions and responsible personnel for any architecture project that has been sanctioned by the governance process

• A reference for future architectural and supporting process developments, guidance, and precedence

The governance artefacts and process are themselves part of the contents of the Architecture Repository.
Architecture Governance is addressed in detail in the TOGA Standard - Enterprise Architecture Capability and Governance.

Scoping the Architecture

There are many reasons to constrain (or restrict) the scope of the architectural activity to be undertaken, most of which relate to limits in:

• The organizational authority of the team producing the architecture
• The obiectives and stakeholder concerns to be addressed within the architecture
• The availability of people, finance, and other resources

The scope chosen for the architecture activity should ideally allow the work of all architects within the enterprise to be effectively governed and integrated. This requires a set of aligned "architecture partitions" that ensure architects are not working on duplicate or conflicting activities. It also requires the definition of re-use and compliance relationships between architecture partitions.

The division of the enterprise and its architecture-related activity is discussed in more detail in the TOGAF Standard – Applying the ADM.

Four dimensions are typically used in order to define and limit the scope of an architecture:

• Breadth: what is the full extent of the enterprise, and what part of that extent will this architecting effort deal with?

• Many enterprises are very large, effectively comprising a federation of organizational units that could validly be considered enterprises in their own right
  The modern enterprise increasingly extends beyond its traditional boundaries, to embrace a fuzzy combination of traditional business enterprise combined with suppliers, customers, and partners

• Depth: to what level of detail should the architecting effort go?
  How much architecture is "enough"? What is the appropriate demarcation between the architecture effort and other, related activities (system design, system engineering, system development)?

• Time Period: what is the time period that needs to be articulated for the Architecture Vision, and does it make sense (in terms of practicality and resources) for the same period to be covered in the detailed Architecture Description?
  If not, how many Transition Architectures are to be defined, and what are their time periods?

• Architecture Domains: a complete Enterprise Architecture Description should contain all four architecture domains (Business, Data, Application, Technology), but the realities of resource and time constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive Architecture Description encompassing all four architecture domains, even if the enterprise scope is chosen to be less than the full extent of the overall enterprise

Typically, the scope of an architecture is first expressed in terms of breadth, depth, and time.

Once these dimensions are understood, a suitable combination of architecture domains can be selected that are appropriate to the problem being addressed. Techniques for using the ADM to develop a number of related architectures are discussed in the TOGAF Standard - Applying the ADM.

Architecture Alternatives

There is often more than one possible Target Architecture that would conform to the Architecture Vision, Architecture Principles, and Requirements. It is important to identify alternative Target Architectures and build understanding of different possibilities and identify trade-offs between the alternatives. Creating an architecture normally requires trade-offs among competing forces.

Presenting different alternatives and trade-offs to stakeholders helps architects to extract hidden agendas, principles, and requirements that could impact the final Target Architecture.

Method

It is most common that a single alternative does not exist that will meet all stakeholders' concerns. The TOGAF Standard (see the TOGA Standard - ADM Techniques: Architecture Alternatives and Trade-offs) provides a technique to investigate different alternatives and to discuss these with the stakeholders.

Commonly, alternatives are defined per domain. This is done to simplify the analysis of the different alternatives. Of course, the alternatives per domain can be merged into on overall analysis of the alternatives for the whole architecture. This approach is illustrated in Figure 1-2.

The first part of the method uses the vision, principles, requirements, and other information to select sets of criteria fitting for different alternatives.

The second part of the method defines alternatives based on the criteria and builds an understanding of each.

The third part of the method will either select one of the alternatives, or else combine features from more than one, to create the proposed alternative. Perform the following activities in just enough detail to support that decision. The method can be used for any phase at any level of an architecture.

^fig-1-2

What is governed and why

Target Architecture

The TOGA Standard provides a key concept to govern the Target Architecture: the Architecture Project.

The Architecture Project is used to direct and control the EA team to address issues in the Enterprise. An Architecture Project starts with a Request for Architecture Work. The primary control is Architecture Project management using the Statement of Architecture Work.

In short, the Practitioner is directed to develop an architecture within a controlled scope. Within that controlled scope, the Practitioner is directed to the stakeholder's preferences. Preferences are expressed in terms of objective, priority, and specification. Best practice requirements management chases objective and priority as the baseline. The governance test will ask whether the Practitioner is addressing the stakeholder's concerns.

Implementation Projects and Other Change

The TOGAF Standard provides two key concepts to govern Implementation Projects and other change: the Architecture Contract and the Architecture Requirements Specification.

The Architecture Contract is used to direct and control the implementation team to work towards a deliberant future. Regardless of the document structure an Architecture Contract takes in a Practitioner's organisation it will contain the same directional elements and provide a means to test compliance.

The Architecture Requirements Specification is used to direct and control the creativity of the implementation team. Every Architecture Requirements Specification enables control of the implementation team. Design, implementation, and other change choices can be tested against the Architecture Requirements Specification.

In short, the implementation team is directed to create changes with intentional value-based outcomes. Best practice governance enables the organisation to control value realisation.

Target Checklist

Use the following checklist to execute architecture governance. Good Practitioners understand that only stakeholders can approve architecture. A good governance process will require the Practitioner to demonstrate the following when assessing a Target Architecture:

If the answer to the last question is yes, the governance process is done. The architecture, associated view, architecture specifications, controls, and work packages are ready for publication in the EA Repository as an approved Target Architecture.
If the answer to the last question is no, then there is a decision on whether the Practitioner should rework the architecture or the Architecture Project should be canceled. Reworking the architecture typically requires the Practitioner to finally embrace the stakeholder's preferences.
Rework may require more advanced trade-off.

Architecture in an Agile Enterprise

There has been a great deal of conversation about aligning to agile implementation methods. Ink has been spilled trying to align the phases of the ADM to these development methods. All of this conversation has blurred the line between implementation and architecture. The TOGAF Standard aligns to agile development in Phase G. Full stop.

A good Architecture to Support Portfolio, or Project, will identify what products the Enterprise needs, the boundary of the products, and what constraints a product owner has. In short, a good architecture defines the Enterprise’s backlog.

Architecture to Support Project and Solution Delivery will have a set of constraints that limit the choices of the agile team. These constraints are where an individual product must bend to Enterprise issues and the parochial preference of a product owner is not valid.

Then Phase G, Implementation Governance: the Practitioner serves the stakeholders guarding the mission, vision, goals, and investment roadmap. In short, guarding Enterprise value.