5 Coordination Across the EA Landscape and EA Team

This chapter will address the following questions:

• What to expect in a well-run Architecture Repository & EA Landscape
• How is ADM iteration realized in practice?
• How to work in the context of superior architecture
• How are multiple states managed (candidate, current, transition, and target)?

5.1 What to Expect in a Well-Run Architecture Repository & EA Landscape

Note: In order to provide concrete examples of working in a repository, this Guide presents a few screenshots using a modeling tool. These represent one way that the challenges of a managing an EA Landscape can be met. As outlined in Section 1.3, this Guide does not mean to suggest that the referenced tool, techniques, and literature are definitive. These examples are intended to illustrate the TOGAF concepts. Other tools and techniques are available.

The TOGAF Standard identifies a broad set of materials that will be contained within the Architecture Repository. As a Practitioner, you will be directly concerned with the Architecture Landscape, Reference Library, Standards Library, Architecture Requirements Repository, and the Compliance Assessments in the Governance Repository. Typically, these are implemented by a modeling and analytic tool, and a file repository.

Figure 6: TOGAF Architecture Repository

A high-functioning EA team cannot deliver without using modeling and analytic software. Some Practitioners sketch diagrams casually as initial steps in understanding a system, or explaining one. Maintenance of a collection of sketches is not practical. It does not matter where they use a marker and 11” x 17” paper or spend hours connecting objects in drawing software, these sketches are not modeling and do not provide a meaningful contribution to the EA Landscape. Further, the gaps and errors inherent in casual sketching preclude considering the sketches as a model.

Do not confuse the guidance about managing an EA Landscape and EA Repository with commentary on effective communication. Most things an EA Capability needs to represent are complex. Visualization of complex situations to support the Practitioner, the stakeholder, and others that need to be communicated with is critical. Hand sketches are one of the most powerful communication tools available to a Practitioner. Beyond ideation it is a serious error to present poorly thought-out visualizations to stakeholders and decision-makers. This Guide strongly recommends the inclusion of information visualization skills in any EA team to address the needs of different communities – decision-makers, implementers, and stakeholders. One of the most significant challenges to developing a high-functioning EA team is overcoming poor information management and information presentation practice.

A significant factor that results in a well-run sustainable EA Repository is the ruthless minimization of information gathered and maintained. Any information that is not required for the current Architecture Project, or supports minimal traceability, should not be captured. EA teams routinely drown in an information overload after capturing and maintaining extraneous information – information that is typically only useful for more detailed architecture analysis or implementation. Good Practitioners will not confuse ruthless minimization of work with skipping necessary work: all stakeholders’ concerns must be addressed. Leading Practitioners will understand that stakeholder management is necessary and attention to non-key stakeholders is rarely on the critical path.

The three most powerful components of an EA Repository are the Architecture Requirements Specification, controls, and gaps. Managing the transition from levels of detail can be greatly simplified when, instead of modeling for the sake of building a comprehensive end to end model, its integrity is preserved, avoiding incomplete analysis for areas of the architecture where sufficient detail is not available. When there is sufficient detail to guide and constrain, the Practitioner’s work is done.

The test of sufficiency is a function of fitness for purpose. Best practice governance has the architect demonstrate that the views produced for the stakeholders and any constraints and guidance are derived from the architecture. Stakeholders approve views, not architecture descriptions.

More detail is always available to be captured and represented in the architecture model; additional model kinds; additional refinement. When a Practitioner models for the sake of modeling, there is no endpoint. The test of success is whether the stakeholder’s concern can be addressed. As an example, the Enterprise is attempting to improve agility – can the view demonstrate to the satisfaction of the stakeholder that this Target Architecture and all associated change delivers agility? When sufficient information is gathered, and analyzed to demonstrate agility, the Practitioner is done. When the implementer can be provided with a list of gaps that need to be filled, Architecture Requirements Specifications, and controls that must be followed, the Practitioner is done. Do not do the work that comes after the decision, or activity that you are currently architecting to support.

A high-functioning EA team will be supported by modeling and analytic software, as well as a document management system. Whether these software functions are provided in a single suite or a set of software tools is not material. A Practitioner requires the linkage between any models and documentation, as well as a space to perform necessary analysis to develop their candidate architecture.

What is produced is either a work product that is actively consumed or the intermediate work products the Practitioner needs to produce the requested work product. Table 3 provides a summary of work products that are actively consumed by key Enterprise processes.

Table 3: Partial List of Work Product Alignment with Key Processes

Practice Supports	Architecture to Support Strategy	Architecture to Support Portfolio	Architecture to Support Project	Architecture to Support Solution Delivery
Phase A Work Product: Vision	Key deliverable Before framing of a strategic planning session Refresh before initiation of program budgeting	Key deliverable Before start of budget planning	Often not used Activity to produce a vision overlaps with portfolio/program candidate architecture and roadmap Technique may be used at initiation of business case	Limited use Primary use is early in implementation cycle (via internal providers or execution partners)
Phase E Work Product: Candidate Architecture	During strategic planning session Refresh as required in program budgeting	Key deliverable Before start of budget planning Primary use is stakeholder acceptance of target and definition of gap	Before project initiation and finalization of business case Primary use is creation of Architecture Requirements Specification	Before engagement of execution partners (including internal providers) Primary use is creation of Architecture Requirements Specification
Roadmap	During strategic planning session Refresh as required in program budgeting	Before start of budget planning Refresh as required to support budgeting and program management	Limited use Can be used as an input to projects with multiple interactive changes	Before engagement of execution partners (including internal providers) Primary use is identification of required change, and preferences of how to execute change, to manage solution delivery partner selection and engagement
Phase F Work Product: Architecture Contract & Architecture Requirements Specification	Likely not used	Limited use	Key deliverable Before completion of project initiation	Key deliverable Before engagement and contracting
Implementation & Migration Plan	Likely not used	During portfolio budgeting Refresh as required to support budgeting and program management	Key deliverable Before project start	Key deliverable Before engagement and contracting
Phase G Work Product: Compliance Assessment	Likely not used	Likely not used	Key deliverable At key points in project that allow reporting to stakeholders and obtaining decisions for non-conformance	Key deliverable At key points in project that allow reporting to stakeholders and obtaining decisions for non-conformance
Phase H Work Product: Value Assessment	Before governance review, framing a strategic planning session and program budget	Key deliverable Before governance review and program budgeting Refresh as required to support program management	Limited use Scope of significant architecture change and value often does not cleanly align to projects	Limited use Scope of significant architecture change and value often does not cleanly align to solution deployment

Successful Practitioners will strictly follow the first step of the architecture development phases (Phase B, Phase C, and Phase D) that says to select appropriate viewpoints. In order to select viewpoints, the Practitioner needs to know the stakeholder and concern. From these, the viewpoint that addresses the stakeholder/concern pair will identify the information necessary to address the stakeholder’s concern. Any information that is not required information to address a stakeholder concern should not be gathered and analyzed. Extra information is pointless.[20]

When the Practitioner focuses on effective communication with stakeholders, implementers, and decision-makers, pointless activity is eliminated.

5.1.1 What to Expect in a Well-Run EA Repository: EA Landscape

One of the most challenging aspects of a well-run repository is managing transitions over time. In most simple terms, every architecture will exist in up to four states. The current state is what exists in the Enterprise today; this baseline provides the reference for all change. The target state[21] is what stakeholders have approved; this state provides the reference for governing all change activity. Transition states are partially realized targets between the current state in the target state. The candidate state is what has been developed by the EA team but has not been approved for a status sufficient to govern change.

In practice, transition and candidate states create the most complexity in an EA Repository. Conceptually exploring gaps is easy; only look at what changed between the current and target states. Consider the four characteristics of the EA Landscape: breadth, depth, time, and recency. Now mix in multiple states. Now mix in that as time progresses the architecture can change. Now mix in that different Architecture Projects can work on the same subject at different times and different levels of detail. Variability is the nub of the information management problem. To be able to see the best set of required changes, the Practitioner must ruthlessly minimize the information maintained, and maximize the use of decision records.

Figure 7: Example EA Repository

Figure 7 is a screenshot from an EA Repository. A common current state description of the architecture is maintained in the repository. This common current state is periodically updated and used as the basis of all gap analysis. The governance test is that the current state reasonably represents what is. The repository also contains a consolidated target state and several transition states. When Architecture Projects come to a close, their architecture descriptions are moved into the consolidated target state. As the current state, the consolidated target is used in all gap analysis. While there is variance between transition states in the consolidated target, the Practitioner is in a position to assess whether the current project is moving towards the Enterprise’s preference.

Architecture under development creates an additional information management challenge. For every Architecture Project, create a separate container in the EA Repository. This container allows the Practitioner freely to explore candidate target state options, different trade-off decisions, and impacts without affecting any other Practitioner’s work. A well-run EA Landscape will perform its modeling and analysis to support the decisions/questions at hand only to the extent necessary and nothing more. These Practitioners understand and execute with the notion that more detailed work would come from another architecture cycle, post-decision to discuss implementation. Figure 8 has separate architectures for an Architecture Project exploring a Portfolio, Project, and Solution Delivery.

Figure 8: Multiple Candidate Architectures

Figure 7 and Figure 8 provide an example. Different EA modeling and analytic software, or even a different approach in an EA tool, would have different screenshots. The essential component is ensuring that the EA Repository supports different states, and provides flexibility for an architect to explore a potential future without impacting any other architect’s work.

Supporting documents maintained must clearly identify their state. Without this ability, the Practitioner is pragmatically uncertain whether the document they are looking at is relevant, valid, or useful. They must readily allow the Practitioner to determine their recency. In practice, a candidate or target, or distantly realized current state architecture might be useful to the Practitioner. Usefulness is predicated on the “self-identification” of state and timeline. Without such markers, each supporting document is nothing but noise.

5.1.2 What to Expect in a Well-Run EA Repository: Reference Library

The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the Enterprise.

The Reference Library of a well-run EA Repository is filled with accelerators. Accelerators speed time to market. A recurrent theme in this Guide is ensuring sufficient architecture work is produced to support decisions and actions about the Enterprise’s change activity. The most precious resource in change activity is time.

There is a broad set of reference materials used by a Practitioner. Broadly there will be two sets of reference material distinguished on whether they are directly used in architecture development, or provide background material. The first are materials that are used within the EA Landscape. These will include reference models, reference architectures, and patterns. These reference materials provide proven approaches. Proven approaches are accelerators, as they do not need to be explored with the same rigor as a novel approach. For example, the IT4IT Reference Architecture and APQC’s Process Classification Framework.[22] In both cases there is no need to invent a novel set of processes. This type of reference material provides a complete starter set, simplifies communication, and enables re-use within the EA team. Each Practitioner will use the same terms to describe a problem. Figure 9 provides an example of reference material available in an EA Repository to improve architecture development.

Figure 9: Reference Material in Modeling and Analytic Tool

Patterns, and other Architecture Building Blocks (ABBs), are typically indistinguishable to a Practitioner from other reference material in the EA Landscape. Whether brought in from reference sources, or created inside the organization, they provide a consistent and known way of approaching a problem.

The second set are documentary reference materials. This material may include white papers, discussions of EA Landscape reference material, templates, stock material, and guides. Again, reference material is an accelerator. Communication between Practitioners is improved when they have access to consistent background thinking. Communication outside the EA team is improved with consistency.

Figure 9 is a screenshot showing different reference architectures, and reference models, as discrete architectures. Maintaining discrete architectures allows the architect to be able to compare how the reference architecture was used in the current candidate or target against the base reference material. In longer-lived repositories, it is common to find multiple overlapping reference architectures. Consider an organization that uses APQC’s Process Classification Framework as a base reference model. Should they implement a mainstream ERP, they will likely have work produced in the ERP vendor’s process classification and the system integrator’s process classification. Later, when the same organization adopts the IT4IT Reference Architecture, they will likely have another process classification.

Maintaining each of these has a clear reference in the modeling, and analytic software will allow future architects to understand the decisions made during architecture development and implementation governance, especially when only part of a reference is brought into architecture development and maintained in the architecture. This Guide acknowledges the need to integrate an architecture tool with tools supporting planning, solution delivery, solution validation, etc. A Practitioner may have to refer to documentation in such tools on occasion or provide appropriate traceability. The family of tools and integration is beyond the scope of this Guide.

Reference architectures, planning data, analytic data, etc. are normally supported by detailed documentation managed in a document management system. A Practitioner concerned with the purpose and rationale for complete or partial use of such data will seek the supporting documents, to use them appropriately for modeling or analysis. Do not get swayed by looking at whether the Practitioner is likely to read them when creating the links to the document management system.

5.1.3 What to Expect in a Well-Run EA Repository: Standards Library

In a well-run EA Repository, the Standards Library will perform two functions. First, it provides a repository for the standards that the architecture must comply to. Second, it provides a repository for the standards imposed on all implementations by the architecture. The distinction is critical. One is used to test the architecture; the second is used to test an implementation.

In practice, these two sets of standards have to be separated. A simple example is provided by the PCI standards. An Enterprise that uses credit cards is subject to PCI standards. No Enterprise with a good EA will simply place PCI standards in a repository for an implementation to comply with. The question of how to comply is inappropriate for an implementation team. The compliance with PCI may be as simple as a standard derived from the EA that requires the use of a third-party payment processor ensuring that PCI subject information is not in the hands of the Enterprise. The latter is a standard derived from the EA.

It is common to extend the Standards Library to include selected products and third-party services. This pragmatic choice simplifies the governance of Implementation Projects where, in addition to an architecture requirement specification or control, there exists a product or service that conforms. To further the example above, rather than the Architecture Requirements Specification requiring the use of the third-party payment processor, a specific third-party payment processor can be placed in the Standards Library.

Where specific products and services are placed in the Standards Library, it is best practice to trace those choices directly to the Architecture Requirements Specification or control that brought these products and services to life. Without traceability to the architecture, product or service selection can be viewed as an arbitrary choice. One of the traps of architecting through product and service standards is the lack of traceability to the requirement or risk. When there is simply the specification of a product or service as an arbitrary choice, the governance process is dramatically complicated because alternative products or services can be considered on criteria other than those that lead to an architecture supported decision.

5.1.4 What to Expect in a Well-Run EA Repository: Architecture Requirements Repository

Managing requirements to the entire EA Landscape is one of the most complex activities facing the Practitioner. The first challenge is simply the breadth of detail; the second challenge is the overlapping nature of managing requirements across the EA; the third challenge is maintaining the repository over time; and potentially the fourth is integrating with other repositories.

One thing that is important to consider is that requirements appear radically different depending upon the purpose of the architecture and the level of detail. As an extreme example, Practitioners with experience in solution delivery architecture and implementation may not recognize requirements for architecture developed to support strategy as requirements. Practitioners used to implementation tend to be looking for very granular requirements to express statements of need. Be agile, be efficient, integrate the new division, and protect the market-leading differentiators are all examples of key requirements for Architecture that supports Strategy and Portfolio.

Leading practices find that a large number of requirements for Architecture that supports Portfolio and Project are normally captured in the form of scores. Ask the stakeholders to assess the required efficiency, maturity, automation of a process, application, service or capability; score the required business fit or technical fit of applications; and score the preferred lifespan of the infrastructure. Best practice is to use a scale of one to five to capture their assessments. All of these scores are requirements; they clearly state the preferences of the stakeholders.

An important question in any requirements repository is whether these are architectural requirements or implementation requirements. The distinction can be fine, but it is a distinction with a very large difference. One of the tests that can be used for distinguishing between architecture and implementation design is whether the description can only be done one way, or can it be realized multiple ways. The former tends to be architecture, while the latter is implementation design. When an Architecture Repository is integrated with a requirements repository for implementation, use appropriate integration options to maintain traceability and integrity.

Many architecture requirements are remarkably long-lived. Especially when the requirement is articulating aspects of the Enterprise that differentiate it. When does a market leader who leads through customer experience want to relax the requirement requesting best-in-class customer experience? The real challenge for the Practitioner is translating market-leading customer experience into clear architecture specifications applied to components in the architecture. Herein lies one of the mental challenges when architecting for different purposes – the line between a requirement and a specification may be in who stated it. A requirement into a portfolio architecture aimed at market-leading customer experience may result in an architecture specification requiring that the information object “customer preference” be a common information object to the CRM, customer portal, and service desk. That specification reads like a requirement to the architect supporting solution delivery of the new CRM.

Requirements from higher in the organization also tend to be discussed using different names. It is common to speak of objectives and mandates, and treat them with special reverence. Likewise, the distinction between types of requirement – functional versus non-functional, business requirements versus technical requirements – is treated very seriously. In the final analysis, whether a requirement is a mandate, a non-functional requirement, or a business requirement, from the perspective of a Practitioner it is a statement of need that will be addressed in the context of the superior architecture and the set of objectives provided by all stakeholders.

One central activity Practitioners typically are not comfortable doing is assessing the validity of requirements. When the Practitioner has a well-described strategy, a portfolio that identifies gaps, and gap-filling work packages, it becomes easy to look at a requirement being injected in the project or solution delivery architecture and assess whether this requirement is in conformance with what the Enterprise priority is or whether this requirement conflicts with the superior architecture. Consider a portfolio initiative focused on improving agility for customer experience: this portfolio will identify a set of projects explicitly designed to improve some aspect of the customer experience and improve the ability of the Enterprise to change. As time progresses close to execution, it is common for requirements not aligned with the project’s purpose to be injected into the process. The central element of requirements management is good governance. Practitioners are guardians of the statements of value.

When Practitioners have a good architecture identifying the target and transition steps along the way, requirements, and architecture specifications, may vary over time; be different in the target and the transition architectures. Imagine a portfolio roadmap that deliberately sacrifices customer experience for agility in the first transition. Then in the second transition the priority switches and agility is sacrificed for customer experience. The conformance test to architecture requirement, and guidance on priority, switches. This Guide deliberately uses the term “sacrifice” because inherent in this requirements repository is clarity of precedence and priority. When clarity of precedence and priority is not available, data to guide trade-off early in the cycle is absent, hindering progress. Just as the assessment of precedence and priority shifts context to other decisions where a set of preferences are well defined and is closer to the organization most suited to make the choice.

Explicitly link the architecture specification to requirements, and trace the requirements to a stakeholder/concern pair to track the value and preference. This traceability is used in governance to assess how well the design and implementation choices address the stakeholder’s value preferences.

Best practice EA Repositories facilitate traceability at every step of the architecture to the direction and priorities of the Enterprise. Practitioners are delivering some of the highest value when they are engaged in requirements management and trade-off. All smart stakeholders want all, want more, and for free. All smart stakeholders know they can’t have it all, nor can they have it for free. What stakeholders don’t know – and what the role of the Practitioner is – is to assist the stakeholders in understanding what they have to give up in order to realize different sets of preferences.

A Practitioner with a well-run EA Repository is in a position to maintain a comprehensive set of requirements in context. Requirements in context enable the Practitioner to work actively for the preferences of the stakeholders rather than architecting to a subset of the preferences of the stakeholders; or worse a set of preferences that the Practitioner personally prefers.

5.1.5 What to Expect in a Well-Run EA Repository: Compliance Assessments

Most EA Repositories are missing the most important component of a compliance assessment: gaps, Architecture Requirements Specifications, controls, and views that address concerns stakeholders find interesting. A well-run EA Repository will contain all of the components necessary to perform effective compliance assessments as well as the compliance assessments.

The first step of compliance assessment is clarity on what compliance will be assessed against. Best practice compliance assessments are tightly linked with the TOGAF concept of an Architecture Contract. The Architecture Contract identifies what an Implementation Project is expected to deliver and the set of constraints the project operates under. Without clearly documented expectations and constraints the Practitioner has failed the implementation team.

A well-run EA Repository will contain the equivalent of an Architecture Contract for every Implementation Project. See Appendix D for an example of an Architecture Contract. With clarity on expectation and constraint, compliance may be assessed.

TOGAF Phase G identifies two areas where compliance is assessed. The first is the scope of the project. Second is the actual implementation, whether designed or the performance change. Phase H contains a further value-based compliance assessment.

The first assessment in Phase G considers the scope of the Implementation Project compared to the gap, or work package, expected to be filled. The work package identifies which gaps are going to be filled. The singular purpose of the work package is clarifying the work necessary to address the gaps in the architecture. Good roadmaps developed as part of an Architecture Project support portfolio will house well described work packages. Well described work packages are clear about gaps being filled, and the implementation strategy, or approach, of how the gap will be addressed. Where there is no architectural significance, no good Practitioner will bother constraining an Implementation Project with unnecessary guidance or constraint through the implementation strategy. Where the approach to addressing the gap is significant, a good Practitioner will always provide the appropriate guidance of constraint.

Performing scope, and implementation approach, compliance is the first step in protecting value. A good EA will provide clarity about the best path to maximized value for the Enterprise. Typically, maximized value to the Enterprise will not align with parochial preferences of the Implementation Project sponsor, or the implementation team. Frankly, if there was alignment, there would not be a need for an EA team. It follows that assessing the scope of an Implementation Project is the first place to protect value. Waiting until the project is funded and underway is indistinct from developing architecture after the decision; see Chapter 15.

The second Phase G compliance assessment confirms whether specific Architecture Requirements Specifications have been followed. The TOGAF concept of an Architecture Requirements Specification identifies what must be, what must be done, and what is prohibited. It provides the set of constraints on more detailed architecture development, design, and implementation.[23]

Phase H’s compliance assessment is based on value realization. Typically, expected value will not be realized for a significant period of time after an Implementation Project has declared victory. Using the linkage provided by the Architecture Contract, recurrent value realization assessments can be performed. Maintaining the linkage from specification to stakeholder expectation facilitates consistent review.

Although a well-run EA Repository will be focused on demonstration of realizing value, traditionally most attention is placed on rule-following compliance. While rule-following is important, it tends to struggle with a consistent demonstration of value, unless it is assumed the value of following the rule is self-evident. Rule-following compliance assessment is common where the Architecture Requirements Specification eliminates all design and implementation choice. Focusing assessment on rule-following is also most likely to be tied to requests for relief from the rule because the total cost of the rule is not in alignment with available value; see Chapter 15.

Best practice is to go beyond simple compliance with the statement, to include compliance with intent. The purpose is again to protect the expected value of the Target Architecture. When a constraint is connected to a stakeholder requirement, the compliance assessment is able to assess how well the design and implementation choices deliver on expected value. Compliance assessments that indicate the implementation will fail to enable expected value are key inputs to future architecture development.

5.2 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 TOGAF 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 organizational 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 organizations pursuing small projects, to an integrated company capable of organizing, 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 Microservices, on the customer intimacy project?
7. How to modernize 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.

5.2.1 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.

Practitioners should not be surprised if there are multiple potential targets after the initial exploration. Having more than one approach to addressing the problem is acceptable to key stakeholders. It facilitates better trade-off when performing more detailed analysis. Keep in mind that until the target is finalized, the Practitioner is exploring the best potential future, not selling a particular future.

5.2.2 Essential ADM Output and Knowledge

A summary of the essential outcome and output is provided in Table 4. Keep in mind that the essential output is what stakeholders, sponsor, and boss’ boss’ boss wants. No-one wants an architecture; they want guidance on planning and executing an effective change. Practitioners use an architected approach to providing the best available guidance on effective change. The essential outcomes and outputs are derived from the objectives of the phase – the statement of why a Practitioner should perform this activity.

What the Enterprise values and consumes is typically different than what the Practitioner produces. Practitioners deliver an essential output. It is provided as views, roadmaps, architecture specifications, controls, and other useful things. Architecture is developed, and the EA Landscape populated. To do this, Practitioners require a set of essential knowledge. The Enterprise consumes effective guidance about and the ability to govern change.

Read Table 4 in conjunction with Table 3 to confirm whether for a particular purpose the output of the phase is already in existence, needs to be created, or is extraneous to the current Architecture Project. Good Practitioners will adjust their work accordingly. Table 4 lists only key outputs and outcomes. For an exhaustive list, refer to the TOGAF Standard. In order to achieve these outcomes, the Practitioner may have to perform more activities or create more deliverables than those listed in the table below. The intent is to keep the focus on what is pursued, not what is done.

Table 4: Essential ADM Outputs, Outcomes, 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: Migration Planning	An approved set of projects,[24] 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)

5.2.3 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.[25]

Figure 10: Stylized Architecture Development Gantt Chart

Consider the different purposes and a cascade through time as shown in Figure 4. When the plan in the stylized Gant 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?

Figure 11: Problem Solving Approach (Derived from Conklin’s “Wicked Problems”)

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.

5.2.4 ADM Plan for Architecture to Support Strategy

The path to developing an Architecture to Support Strategy is a configured journey through the ADM. This path follows this journey:

• Understand context – evaluate capabilities
• Perform assessment and analysis
• Define approach to target state
• Finalize Architecture Vision/target state

The processes iterate through the ADM to deliver an architecture that clarifies a Target Architecture roadmap of change over a three to ten-year period. The roadmap will identify change initiatives and support portfolio and programs. It will set terms of reference for the initiatives and identify synergies. A key use is governing the execution of strategy via portfolio and programs.

Figure 12: Sample Project Plan to Develop Architecture to Support Strategy

5.2.5 ADM Plan for Architecture to Support Portfolio

The path to developing an Architecture to Support Portfolio is a configured journey through the ADM. This path follows this journey:

• Group work packages to themes
• Balance opportunity and viability
• Run up to budget
• Drive confidence of delivery

Figure 13 provides a sample project plan to provide Architecture to Support Portfolio. This project plan is explored in Chapter 8.

The processes iterate through the ADM to deliver an architecture that refers to a single portfolio.[26] The boundary and purpose of the portfolio are derived from the superior architecture. It will identify projects that comprise the portfolio. The project terms of reference and approach are identified. A key use is governing the execution of projects within the portfolio.

5.2.6 ADM Plan for Architecture to Support Project

The path to developing an Architecture to Support Project is a configured journey through the ADM. This path follows this journey:

• Ascertain dependencies
• Balance options and suppliers
• Finalize scope and budget
• Prepare for solution delivery governance

Figure 14 provides a sample project plan to provide Architecture to Support Project. This project plan is explored in Chapter 9.

The processes iterate through the ADM to deliver an architecture that refers to a single project. The boundary and purpose of the project are derived from the superior architecture. The EA will identify discrete gaps and work packages that have been packaged into a project that delivers measurable value on the architecture roadmap. Further, the measures of compliance with the architecture are provided. Architecture for this purpose will create the Architecture Contract. A key use is ensuring value realization of the Implementation Project.

5.2.7 ADM Plan for Architecture to Support Solution Delivery

The path to developing an Architecture to Support Solution Devlivery is a configured journey through the ADM. This path follows this journey:

• Align implementers
• Guide delivery
• Realizing the solution

Figure 15 provides a sample project plan to provide Architecture to Support Solution Delivery. This project plan is explored in Chapter 10.

The processes iterate through the ADM to deliver an architecture that facilitates solution delivery. (See Section 4.1.4 for a discussion of the distinction between Enterprise and Solution Architecture.) This architecture is used to constrain how the change will be designed and delivered. It will clarify the purpose, gaps, and expected value that constrain all design and implementation. It will provide the controls and architecture requirements used to test conformance. It directly facilitates governance of implementation and operational change in the context of value realization.

Figure 13: Sample Project Plan to Develop Architecture to Support Portfolio

Figure 14: Sample Project Plan to Develop Architecture to Support Project

Figure 15: Sample Project Plan to Develop Architecture to Support Solution Delivery

5.2.8 Iteration Conclusion

At the start of this chapter, this Guide suggested that many Practitioners interpret the TOGAF ADM as a process model. If you did and continue to carry that notion, stop and think. The classic TOGAF diagram of the ADM is not an activity diagram. The TOGAF ADM is a logical method that places key activity steps together for the purpose of linking activity and information flow to produce specific outputs.

The important thing to realize is every time a Practitioner undertakes any activity within the scope of the ADM it is developing the contents of the EA Landscape. It is developing the EA Landscape through iteration. The phase being executed is the appropriate domain. If you remain stuck on trying to put the ADM in a one-pass linear order, you will draw bizarre looping phase diagrams. Think of the steps as a checklist.

5.3 Operating in the Context of Superior Architecture

The superior architecture always guides and constrains the development of more detailed architecture. As a quick summary, superior architecture is the less detailed approved target that overlaps in terms of breadth. This quick summary is complicated by the different states the superior architecture may actually exist in the EA Landscape.

The superior architecture may not perfectly align to detail, breadth, time-horizon, and recency. Further, the superior architecture may be in some mixture of current, transition, and target state.

Practitioners must treat the superior architecture as guides and constraints to current architecture development. Stakeholders have already approved the superior architecture in the EA Landscape; barring a material change, the Practitioner accepts prior work as cornerstones to build a current workaround.

Where there is a material change, both the current Architecture Project and the changes to the superior architecture must be properly approved and published through the governance process.

5.4 Managing Multiple States (Candidate, Current, Transition, and Target)

The Practitioner must track transition states across two characteristics: the first being time, and the second being a conformance test. Theoretically, it might be preferable to use transitions to track the value resting places and changes in conformance. Good practice is to architect to value resting states; a state where the Enterprise can receive value if all change activity is suspended. However, the pressure of the budget cycle forces us to use time as a pragmatic transition marker. Tracking to change in conformance facilitates the Implementation Project and operational change governance. To the extent possible, minimize transition states.

When considering transition states, the Practitioner needs to keep in mind the distinction between an Architecture Requirements Specification and an implemented system. Using the EA Repository as a CMDB confuses implementation record keeping and architecture. Practitioners have to keep in mind that many implementations or operational changes are not architecturally significant. See Chapter 15 for a discussion of the different roles involved in developing and using architecture.

5.5 Where are ABBs?

The TOGAF concept of the Architecture Building Block (ABB) is the effective Practitioner’s friend. A good ABB facilitates time-to-market and completeness. As with most TOGAF definitions, knowing that an ABB is “a constituent of the architecture model that describes a single aspect of the overall model” doesn’t immediately tell us what they look like in an EA Repository.

An ABB will look like whatever it must be to describe part of the overall architecture – efforts to carefully define the contents and structure of this concept will flounder on the variability and scope of what can be described within an EA Landscape. A building block is part of a greater whole that accelerates the effective description of the candidate architecture.

In some cases, it will be a re-usable description of part of the architecture; using it again enables the Practitioner to simply adopt a known successful way to address a problem. In this case, the ABB is complete in all regards, providing a complete description, and constraints that address repeated requirements. In other cases, it will not have the constraints and specifications predefined. In this latter case, the components of the description will be complete, but the detail will vary depending upon the requirements.

return to top of page

---

---