The Open Group OGEA-103: TOGAF Architecture Development in Practice
The Architecture Development Method is useful because it gives enterprise architects a disciplined way to move from a business need to a governed set of architecture changes. Its value is not that every engagement follows a perfect sequence of phases. Its value is that important questions are made explicit: why the work is being done, who cares about the outcome, what the current and target states are, what gaps matter, how change should be sequenced, and how implementation will remain aligned with the intended architecture.
That practical interpretation matters for anyone working with the current TOGAF body of knowledge. The TOGAF Standard, 10th Edition separates fundamental content from supporting Series Guides, which encourages practitioners to configure the method for the organization and the problem rather than treating the framework as a fixed delivery template. The OGEA-103 practitioner path reinforces that applied perspective by focusing on how the concepts work together in realistic architecture situations.
In a functioning architecture practice, the ADM is best understood as a decision cycle. It creates enough structure to maintain traceability while still allowing teams to iterate, revisit assumptions, and tailor depth to the risk and scope of the change.
Start with the decision the architecture must support
Architecture work becomes inefficient when the team starts by producing familiar artifacts before agreeing on the decision those artifacts are supposed to improve. A modernization program, merger, regulatory response, data strategy, platform consolidation, or product expansion may all require architecture, but they do not require the same scope or the same evidence.
The early ADM work should therefore define the problem, the stakeholders, the constraints, the business outcomes, and the boundaries of the engagement. A useful architecture vision explains what will be different when the work succeeds and which concerns must be resolved before the enterprise can commit to that direction. This is also where stakeholder engagement becomes architectural work: different stakeholders may accept the same target only if the architecture answers their specific concerns about value, risk, cost, timing, ownership, and operational impact.
Scope should be explicit enough to prevent accidental expansion. An engagement can cover one capability, one value stream, one business unit, a portfolio, or the whole enterprise. It can also focus on selected architecture domains. The important point is that the scope is chosen because it is sufficient to support the decision, not because a standard diagram set has to be completed.
Use baseline and target views to expose meaningful gaps
Baseline architecture is not an exercise in documenting everything that exists. The team needs enough current-state understanding to explain the constraints, dependencies, problems, and assets that affect the change. A target architecture should be equally selective: it must describe the intended future state at the level needed to make design and investment decisions.
Business, data, application, and technology views can then be developed with different levels of detail. A business architecture may need a capability map and value-stream view, while a technology architecture may need platform standards, integration boundaries, resilience requirements, and deployment patterns. The point is to make the important relationships visible.
Gap analysis is where those views become actionable. The team identifies what must be created, changed, retained, or retired. A useful gap is specific enough to influence a work package or architecture decision. Vague statements such as “modernize the platform” are difficult to govern; a gap such as “no authoritative customer identity service exists across channels” is concrete enough to shape architecture and investment.
Keep requirements alive throughout the cycle
Requirements management is not a single phase that finishes before architecture design starts. Requirements are discovered, refined, challenged, and sometimes retired as the architecture develops. A requirement that looked essential during initial scoping may prove too costly, conflict with another constraint, or become unnecessary when a different target option is selected.
Traceability matters because it lets the team explain why architecture decisions exist. A principle, control, data standard, integration pattern, or transition step should be connected to a stakeholder concern or requirement that justifies it. That same traceability helps later when delivery teams propose exceptions: the discussion can focus on the outcome that must still be protected rather than on blind compliance with an artifact.
Architecture principles are especially valuable here because they compress repeated requirements into durable guidance. When a principle has a clear rationale and implications, teams can apply it consistently without reopening the full architecture debate for every project.
Move from domain architectures to a coherent transition plan
Strong target architectures can still fail if the enterprise has no credible path from the current state to the future state. Opportunities and solutions work translates architecture gaps into candidate initiatives, work packages, transition architectures, and dependency relationships. Migration planning then evaluates sequencing against value, risk, cost, capacity, and organizational readiness.
This is where architecture roadmaps should become more than timelines. A roadmap needs to show why one change must happen before another, what intermediate states are acceptable, which capabilities are being improved, and where the plan depends on funding, procurement, skills, policy, data, or platform work outside the immediate program.
Capability planning provides a durable way to test that sequence. If the roadmap claims to improve a strategic capability, the enabling process, information, application, technology, people, and governance changes should be visible. That keeps the roadmap tied to business ability rather than becoming a list of technology projects.
Tailor the ADM instead of turning it into waterfall
The ADM is cyclical and configurable. Teams can iterate within a phase, move back to earlier work when assumptions change, run work in parallel, or apply the method at different levels of the enterprise. Treating each phase as a mandatory stage gate with a large document handoff can reproduce the delays that architecture is supposed to reduce.
Tailoring should respond to uncertainty and consequence. A low-risk change inside an established pattern may need only lightweight architecture work. A cross-enterprise platform decision with long-lived data, security, and operating-model consequences deserves deeper analysis and stronger governance. The method should scale with the decision.
This is also where architecture constraints should be stated early. Budget, regulation, legacy dependencies, latency, geography, contractual commitments, skills, and deadlines can eliminate options before detailed design begins. Making those constraints visible prevents teams from comparing target states that were never feasible.
Govern implementation without freezing the architecture
Implementation governance connects target architecture to delivery. Architecture contracts, compliance reviews, standards, patterns, decision records, and exception processes can all help, but the objective is not to prove that a project copied the target diagrams exactly. The objective is to preserve the architectural outcomes that justified the change.
Architecture governance should distinguish between decisions that create enterprise-wide consequences and decisions that delivery teams can make locally. Central review is most valuable when a choice creates a new precedent, crosses domains, changes shared platforms, weakens a strategic control, or alters a roadmap dependency. Routine implementation choices should remain close to the teams doing the work.
Exceptions are useful evidence. Repeated exceptions can reveal that a standard is impractical, a target state is incomplete, or the organization has developed a new constraint. Governance should therefore feed learning back into the architecture rather than treating every deviation as failure.
Let implementation evidence change the architecture
Architecture change management closes the loop. New strategy, regulatory changes, technology shifts, acquisitions, delivery discoveries, incidents, or operating-model changes can invalidate assumptions that were reasonable when the target was approved. A maintained architecture practice needs a way to decide whether the change is minor, requires a focused update, or justifies a new ADM cycle.
That decision becomes easier when assumptions are documented. If the target depends on growth rates, vendor capabilities, specific regulations, a sourcing strategy, or a particular operating model, the architecture team can monitor whether those assumptions remain true. The architecture then evolves because the environment changed, not because documents reached an arbitrary review date.
Project governance can provide useful signals here. Delivery risk, benefits realization, dependency failures, and recurring escalations often reveal architecture issues before a formal architecture review does.
Use practitioner judgment to decide what the method needs
The TOGAF practitioner mindset is less about remembering a diagram of phases than understanding what each part of the method contributes. Architecture vision provides direction. Domain architecture work explains the current and target states. Gap analysis identifies change. Opportunities and migration planning make the change executable. Governance protects intent during implementation. Change management keeps the architecture relevant.
Practitioners should also choose techniques based on the problem. Business scenarios can help clarify requirements. Stakeholder maps can reveal influence and concern. Risk analysis can change architecture priorities. Interoperability and security considerations can affect target options. The TOGAF Series Guides provide additional ways to configure the fundamental method for specific contexts rather than forcing one universal recipe.
The practical standard is whether the method improves decisions. If an artifact has no audience, a phase produces no new understanding, or a review does not change risk or direction, the architecture team should question the work. Conversely, when the ADM helps leaders understand tradeoffs, helps delivery teams see constraints, and preserves traceability from strategy to implementation, it is functioning as an enterprise change method rather than as architecture ceremony.
The most durable use of the ADM is not a single transformation project. It is an architecture operating rhythm that connects strategic planning, portfolio decisions, product and project delivery, technology standards, risk management, and investment governance. Different architecture efforts can run at different cadences while still sharing principles, capabilities, reference models, roadmaps, and repository content.
That operating model reduces repeated analysis. A project should not rediscover enterprise principles, shared data definitions, platform direction, or strategic capability priorities if those decisions already exist and remain valid. At the same time, the practice must make it easy for new evidence to challenge existing guidance. Reuse without feedback creates stale architecture; feedback without reuse creates fragmentation.
A mature architecture team therefore treats the ADM as a learning loop. Each cycle improves the enterprise’s understanding of its current state, desired direction, constraints, and change capacity. Over time, the repository becomes more than a collection of deliverables: it becomes a traceable record of decisions, assumptions, patterns, transitions, and lessons that make the next architecture engagement faster and better grounded.