6 Approach to the ADM

The TOGAF Architecture Development Method (ADM) is the core of the TOGAF Standard. This method sets the TOGAF framework apart from every other EA framework because it contains the “how”.

The path through and around the ADM phases to develop architectures for different purposes is not simple nor linear. The level of detail and specificity of each architecture is different. For instance, to develop an Architecture to Support Strategy, all that is needed is to follow a path from Phase A through Phase D at the strategic level. Not all the steps are executed, but logical entities that drive Business, Applications, and Technology Architectures are captured and defined. Architecture to Support Strategy provides an end-to-end view of the Enterprise and a candidate roadmap to achieve target state. The governance model, as articulated in the TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability (see Referenced Documents), is leveraged to trace the rest of the architectures and their alignment to target state.

6.1 Key Activity

All architecture development has a set of consistent key activity that is essentially unchanged for different purposes.

6.1.1 Stakeholder Engagement and Requirements Management

The TOGAF framework places requirements management and stakeholder engagement at the center of architecture development. Practitioners develop EA in accordance with the preferences and priorities of their organization’s stakeholders. Architecture is never sold to a stakeholder. Stakeholder preferences are never manipulated.

Stakeholders own the architecture and the value preference and priority the architecture is expected to enable. Practitioners must completely submerge their preferences, biases, and priorities. Practitioners must act for their stakeholders.

This is one of the most difficult activities a Practitioner must perform. Good Practitioners are passionately engaged in the future of their organization, as well as participating in defining and realizing the target state. Practitioners typically perform several roles: they will act as Subject Matter Experts (SMEs) and agents for their stakeholders in addition to developing architecture – see Chapter 15 for a discussion of roles. As an SME, the Practitioner is a source of expert advice. As an agent, the Practitioner may speak on behalf of a stakeholder. In order to be successful when performing these roles, the good Practitioner must understand when they are acting in a different role and behave appropriately.

Effective requirements management is dependent upon clear traceability from the organization’s vision, mission, business model, and strategies through the most detailed statement of requirement. In order to perform this, the Practitioner must carefully distinguish between direct effective support and loose association. Things that do not best enable the complete set of stakeholder preferences are distractions from the main chance.

When engaging with stakeholders, Practitioners must maintain the complete set of every stakeholder’s preference, and the implications of those preferences. Success requires abandoning absolute and entering the realm of satisficing. Bluntly, if there is a single obvious best answer, the organization’s stakeholders do not need an architecture.

Effective engagement is based upon effective communication. Effective communication is based on the concept of view and viewpoint. Different stakeholders have different concerns about the architecture. These concerns must be addressed and represented effectively to the stakeholder to enable the stakeholder to approve the Target Architecture (see Table 2).

6.1.2 Trade-Off

One of the most valuable activities a Practitioner will perform during architecture development is facilitating the stakeholders’ trade-off decision. Facilitating trade-off is often more valuable than finalizing an architecture description. Good architecture addresses complex problems. Complex problems[27] do not have clear, unambiguous best answers. Instead, they have reasonable compromises.

Trade-off requires a compromise between one stakeholder’s preferences as well as between different stakeholders’ preferences. Effective trade-off requires understanding value preference and priority as well as the scope of change necessary to realize the target.

As a rule, stakeholders underperform when that trade-off stands beyond their span of control or span of interest. In particular, stakeholders underperform when the trade-off involves the preferences of different stakeholders. Stakeholders typically overemphasize the institutional role and preferences of their portion of the organization.

Practitioners are most valuable facilitating trade-off between stakeholders and across organizational boundaries. This facilitation allows different stakeholders to effectively measure preferences, priorities, and costs that they do not intuitively understand. Best practice EA finds the best fit across competing preference, priority, and value. In facilitating the trade-off discussion, chase down all impacts and think through the end game needs. Work with the Enterprise risk management process to surface requisite dimensions. Think through all transition states. Leverage the architecture tool to handle the complexities of the EA Landscape and to accelerate the process.

Practitioners should not underestimate the value their organization receives from facilitation of trade-off across organizational boundaries.

6.2 Trade-Off Decisions

The most common interpretations of trade-off are “a balance achieved between two desirable but incompatible features; a compromise” and “losing one quality, aspect, or amount of something in return for gaining another quality, aspect, or amount”. In developing an Enterprise Architecture, trade-offs are never about compromises, but about a question of when or the context. When the context or the objective of the Enterprise is poorly analyzed, some choices will appear obvious or low-cost. Jumping to employ those choices as a viable candidate will result in sub-optimal achievement of the target or total failure of the initiative.

For example, when a Practitioner is exploring a candidate target architecture and discovers what appears to be an obvious improvement without a champion, they are likely to be jumping to a decision that is based on poor analysis. When faced with such circumstances, the Practitioner should look for the hidden value. Hidden value will never be described in terms of the obvious cost savings.

6.3 Phases B, C, and D – Developing the Architecture

Practitioners often find it surprising that the steps outlined in the TOGAF Standard to develop architecture in Phases B, C, and D are identical. The steps are identical because the approach to developing an architecture, confirming the work product developed fits, and confirming approval are identical. These steps are also mandatory. Steps can be skipped, but the final outcome could be at risk.

What changes from purpose to purpose, domain to domain, project to project, and EA team to EA team is the level of detail, precision, and formality. All Practitioners should use the steps as a checklist.

6.3.1 Select Reference Models, Viewpoints, and Tools

Avoid rework. Practitioners test with the following questions:

6.3.2 Develop Target, Baseline, and Gap

Just enough for the purpose. If the current state is accepted, the only reason to describe the baseline is to develop gaps. If stakeholders, or SMEs, dispute the current state, especially its fitness to objective, then describing current state to get an alignment is useful. Otherwise, let us re-iterate: only to the extent necessary to determine gaps.

Consider the limitation of restricting description to where there is a gap. If part of the EA Landscape will have no change, and is not needed for traceability, what useful reason is there for a Practitioner to spend time describing it?

A recurrent question is how to describe the current state. Frankly, use the exact same techniques as the candidate. Description using the same technique at the same level of detail enables identification of gaps. A gap is simply everything that changes.

6.3.3 Identify the Work to Reach the Target Considering Cost and Value

Without understanding the work required to reach the target, stakeholders will approve the impossible. Why wouldn’t they want telepathy helmets and self-manufacturing products if they were free and easy?

The Practitioner is accountable for guarding value. A target provides an increase in value, at a cost of change. If you do not have an understanding of the work to reach the target, how can a Practitioner represent to a stakeholder that any target is a good idea and addresses the organization’s preferences?

6.3.4 Resolving Impacts

Resolving impacts across the EA Landscape is one of the most important steps in managing the EA Landscape. The Practitioner explores the impact of their candidate architecture against other candidate architectures, transition states, the target state, and in-flight Implementation Projects. The Practitioner also works with the Enterprise risk management process to assess impact to the Enterprise’s risk. Altogether, this is one of the most complex activities for an engaged high-functioning EA team. It requires a functioning EA Repository and solid analytic and reporting software. Every organization is a set of constantly changing interconnected parts. All architecture descriptions are approximations.

In practical terms, the more complex the EA Landscape is, the more difficult, and the more necessary, resolving impacts is. Practitioners attempting to manage an EA Landscape without an effective model and analytic tooling will struggle to resolve impacts. All impacts need to be resolved in terms of value expectation which is based upon clear traceability from the work required to realize the Target Architecture through the gap to the expected value.

Without care and attention to addressing the impacts across the architecture landscape in all of its states, the Practitioner cannot have confidence that their candidate architecture best serves the Enterprise.

Manage the information volume down to the minimum and constantly chase the minimum set of concerns that visibly support value in the eyes of key stakeholders.

6.3.5 Approval

Without approval by the stakeholders, no implementation governance is possible, and no governance of more detailed architecture is possible. Without approval, the Practitioner has a documented opinion. Stakeholders, SMEs, implementers, and decision-makers also have opinions.

Real approval is complex. Real approval should be complex. The Practitioner is assisting their organization select the best possible path against a set of competing preferences over time. They have taken the time to explore options and impacts.

With an approved Target Architecture, the future is defined, traceability to the objective is available, and trade-off has been performed. Good architecture trade-off explores options, cost, and benefits to reach the optimal answer for an organization. Often that answer is a compromise between competing interests.

6.3.6 Minimum Needed and Look in the EA Repository

Practitioners start and finish with the contents of the EA Repository.

Whenever analysis, or reporting, is needed, the first stop is the EA Repository. Practitioners should apply the following tests:

It does not matter whether the EA Repository is a well-structured modeling and analysis tool or a collection of presentations, start with the EA Repository. Gather and analyze the minimum to address the question at hand. Questions that do not have a clear line of site to understanding the system to address a stakeholder concern are beside the point. Good Practitioners are not paralyzed by the potential analysis that could be done; they perform the analysis that must be done.

6.4 ADM Conclusion

The TOGAF ADM sets the TOGAF framework apart from every other EA frameworks because it contains how to develop and use effective EA. It is not a simple nor a linear path around the ADM phases to develop the architectures for different purposes. It is, however, filled with tasks that are mandatory. Again, to skip tasks undertakes risks.

return to top of page

Copyright © 2022 The Open Group, All Rights Reserved.
TOGAF® is a registered trademark of The Open Group
<<< Previous Home Next >>>