Recommended resources
The freely available resources this lesson will direct you to.
Welcome back. In the previous lesson, you distinguished repeating an ADM cycle from revisiting phases or refining work within a phase. One reason an enterprise may undertake multiple cycles is that a broad architecture cannot answer every detailed delivery question.
This lesson looks at where an ADM cycle can be applied: at a strategic, segment, or capability level. You will see how the same method supports different scopes of decision-making, using the customer-case handoff example from earlier lessons. This is important for Foundation study because an architecture level is not an ADM phase or an architecture domain.
One method, different scopes
Suppose an enterprise wants to improve how customer cases move between teams. A single architecture effort could try to describe everything, from enterprise-wide priorities down to the handling of individual case notes. That would be unwieldy: leaders deciding what to invest in need different detail from a team preparing a particular capability for delivery.
Instead, architecture work can be undertaken at different levels:
| Level | Main question | Typical degree of detail |
|---|---|---|
| Strategic architecture | What direction should the affected enterprise pursue? | Broad enough to establish shared goals and constraints |
| Segment architecture | What should change in a defined area of the enterprise? | Detailed enough to coordinate related processes and systems |
| Capability architecture | How should a particular capability be developed or changed? | Focused enough to guide subsequent delivery decisions |
These are levels of architecture work, not three mandatory stages that every initiative must pass through in order. Nor does “strategic” necessarily mean documenting every part of the enterprise. It means establishing a sufficiently broad context for the area affected by the change.
The following short reading describes the three levels. It discusses agile delivery as one possible setting; for now, concentrate on the distinctions in scope and detail, rather than treating its references to sprints as rules for every ADM engagement.
Enterprise Architecture, TOGAF 10 & Enterprise Agility - Towards AI
Read the three-level explanation in Enterprise Architecture, TOGAF 10 & Enterprise Agility, published by Towards AI, to see how broad direction relates to more focused architecture work.
Find the subsection beginning “The TOGAF framework ‘does’: recommend that the ADM be adapted to meet the needs of the enterprise; agility is one such need.” In its three-level list, read the level descriptions. Begin with the paragraph introducing the model; finish with the Capability Architectures paragraph, just before “ADM Levels and Phases Mapped to Agile Concepts.” Focus on what each level enables the next level to decide.
This is a third-party explanation, useful for building the concept rather than memorizing as official exam wording. Its central point is that a higher-level architecture provides context, while a more focused architecture develops the decisions needed within that context.
Notice that the diagram has three axes, not just three stacked labels. Level concerns the kind of decision and degree of detail. Breadth concerns how much of the enterprise is in scope. Time reminds us that architectures may address different planning horizons. The drawing is a way to reason about scope, not a rule that every strategic effort has exactly the same breadth or duration.
Following one change through the levels
Return to the customer-case handoff. At the strategic level, the organization might establish a direction such as “provide a more consistent customer experience across service channels while protecting sensitive information.” Architecture work at this level could identify the affected areas, common principles, important constraints, and broad initiatives. It should give the organization enough context to make investment and priority decisions without prematurely specifying every handoff.
A segment architecture could then focus on customer service. It might describe how several receiving and sending teams handle cases, where ownership changes, what case information they need, and which applications must work together. This is narrower than the strategic direction but broad enough to coordinate changes that no single team can settle alone.
A capability architecture could focus on improving case-history access. It might define the required behavior and interfaces for retrieving relevant history, the kinds of notes that require restricted access, and constraints that delivery teams must satisfy. It is close to implementation, but architecture is not identical to writing the code or configuring a product. Its job is to make the important design decisions and constraints clear.
The levels are connected by decisions, not merely by document size. For example, a strategic concern about protecting sensitive information shapes the customer-service segment’s access requirements. The case-history capability then works out more specific access needs. If that focused work reveals that the segment’s proposed handoff is unworkable, the finding needs to be communicated back to the segment architects. Higher levels guide lower levels; lower levels can also expose a reason to refine higher-level decisions.
“Capability” here means an ability the enterprise needs, such as making appropriate case history available to a receiving team. It does not mean that capability architecture is limited to Technology Architecture. Understanding that ability may require business, data, application, and technology decisions.
The ADM can be used at each level
The previous lesson’s example of a broad ADM cycle informing a focused cycle now has a clearer interpretation. An engagement concerned with strategic direction may use the ADM to establish and develop that architecture. Another engagement can apply the ADM to a customer-service segment; a further one can apply it to case-history access. Each has its own agreed scope and draws on relevant work already done.
The repeated ADM diagrams are the key feature of this image. There is not a special “strategic ADM” followed by a different “capability ADM.” The ADM is a method that can be applied at any of these levels. Its activities are tailored to the purpose and scope of the engagement: a strategic effort may emphasize direction and broad options, while a focused capability effort may need much more detail on the architecture that will guide delivery. Applying the ADM at a level does not require every engagement to produce identical outputs or spend equal effort in every phase.
Keep two distinctions separate:
- Level asks how broad or focused the architecture engagement is. Strategic, segment, and capability answer this question.
- Phase asks what kind of ADM work is being done. For example, Phase A establishes an Architecture Vision, while Phases B, C, and D develop Business, Information Systems, and Technology Architectures.
A segment-level engagement can undertake Phase A to agree its vision and scope, and it can undertake Phases B, C, and D to develop the relevant architectures. A capability-level engagement can also address business needs, data, applications, and technology. Phase B is not “the strategic level,” and Phase D is not “the capability level.”
This also connects to iteration. Starting a distinct, focused ADM engagement informed by a broader completed engagement is an example of iteration between ADM cycles. Revising a segment engagement’s Phase B work after its Phase C work reveals a conflict is instead iteration between phases within that engagement. The level tells you the scope of the architecture; the scale of iteration tells you what work is being repeated or revisited.
Key takeaways
The ADM can operate at strategic, segment, and capability levels. Broad architecture establishes direction and context; more focused architecture develops decisions for a defined area or capability. The levels should remain connected so that guidance reaches focused efforts and discoveries can be fed back. None of these levels is an ADM phase or one of the Business, Data, Application, and Technology Architecture domains.
Next, you will examine why an enterprise partitions its architecture—and how dividing the work can make a large architecture landscape manageable without losing coherence across its parts.