Overview
Architecture Development covers Phases B (Business Architecture), C (Information Systems Architectures, meaning Data and Application) and D (Technology Architecture). These phases turn the agreed Architecture Vision into baseline and target descriptions, find the gaps between them and identify candidate roadmap components.
All three phases share a common pattern of steps: select reference models, viewpoints and tools; develop the baseline description; develop the target description; perform gap analysis; define candidate roadmap components; resolve impacts across the Architecture Landscape; conduct a formal stakeholder review; finalize the architecture; and create or update the Architecture Definition Document. The syllabus asks you to understand that pattern, to understand risk and security considerations in these phases, and to apply the information needed for business principles, goals and drivers. It then has an Applying-level pair of outcomes for each phase (the information needed and applying the phase) and a final outcome on the outputs of Phases B, C and D.
How it's tested
Scenarios here are design situations. You are asked which step comes next, how to use a model, how to react to a gap or conflict, or what to deliver. The best option follows the common step pattern, uses relevant reference models and viewpoints, and checks impacts and stakeholder agreement before finalizing.
-
Baseline or target first
Options differ in sequencing. When much is changing or little baseline exists, developing the target first and describing only the relevant baseline is usually more efficient.
-
Impact across the landscape
The design affects other projects or architectures. Strong options assess cross-impacts and coordinate rather than finalize in isolation.
-
Right content in the right phase
Options place data, application or technology decisions in the wrong phase, or skip formal review. The best answer respects the purpose of each phase.
In Phase C a manufacturer's architects find that the target application design duplicates a customer service being built by another programme. Finalizing the design now would be quick, but it ignores the common step to resolve impacts across the Architecture Landscape. The best option compares both designs, proposes reuse where possible, records the decision through governance and then completes the formal stakeholder review.
Learning outcomes 9
Official learning outcomes from the The Open Group outline, in outline order.
4.1 Understand the steps applicable to all phases of architecture developmentBloom level 2. The common step pattern in Phases B, C and D.
- What it means
- Phases B, C and D follow the same core steps: select reference models, viewpoints and tools; develop baseline and target descriptions; perform gap analysis; define candidate roadmap components; resolve impacts across the Architecture Landscape; conduct a formal stakeholder review; finalize the architecture; and create the Architecture Definition Document.
- What to understand
- The order of baseline and target development can vary: target-first is common when the change is large, and the baseline is described only as far as needed. Candidate roadmap components feed Phase E. Resolving impacts and the formal stakeholder review protect the wider landscape and stakeholder agreement before the architecture is finalized.
- How it shows up
- Questions often ask what to do next in a phase; locate the step and pick the option that matches it.
- Common confusion
- Believing the baseline must always be fully documented before the target.
4.2 Understand risk and security considerations in architecture developmentBloom level 2. Security and risk work inside Phases B, C and D.
- What it means
- Each development phase has security-specific activities: in Phase B, identifying security-relevant business actors, assets, processes and legal obligations; in Phase C, classifying and protecting data and defining secure application interactions; in Phase D, selecting security services, infrastructure controls and standards.
- What to understand
- Risk assessment informs which controls are needed and how much residual risk is acceptable. Security requirements are added to the Architecture Requirements Specification and traced to stakeholders. Security considerations may change gaps and roadmap components, for example adding identity services or data masking as work packages.
- How it shows up
- Look for options that integrate security analysis into the current phase rather than deferring it.
- Common confusion
- Thinking security analysis belongs only in Phase D.
4.3 Apply the information needed to develop business principles, goals and driversBloom level 3. Grounding the Business Architecture in business motivation.
- What it means
- Business principles, goals and drivers explain why the business wants to change and constrain how it may change. They come from strategy documents, the Request for Architecture Work, Phase A outputs and stakeholder input, and are confirmed or refined in Phase B.
- What to understand
- Drivers are the internal or external forces motivating change, goals are high-level statements of intent, and objectives make goals time-bound and measurable. Business principles guide decisions. Tracing architecture elements back to drivers and goals lets you justify design choices and prioritize gaps later.
- How it shows up
- Scenarios with unclear or conflicting goals reward options that confirm drivers and goals with stakeholders before deepening the design.
- Common confusion
- Mixing up drivers, goals and objectives, or treating architecture principles as business principles.
4.4 Apply Phase B: Business ArchitectureBloom level 3. Developing the business baseline and target.
- What it means
- Phase B describes how the enterprise needs to operate to reach its goals: organization, business capabilities, value streams, business services, functions, processes, roles and information. You use viewpoints and techniques such as capability mapping and value stream mapping to develop baseline and target and find gaps.
- What to understand
- The Business Architecture is usually the first architecture developed in the cycle and drives requirements for data, applications and technology. It should be detailed enough to show stakeholders how business change will happen. Business scenarios and the gap analysis technique are commonly used here.
- How it shows up
- Best options keep Phase B focused on business capabilities and operations, and avoid selecting applications or technology prematurely.
- Common confusion
- Using Phase B to choose software products.
4.5 Apply the information needed for Phase C: Data and Application ArchitecturesBloom level 3. Inputs to Information Systems Architectures work.
- What it means
- Phase C needs the Business Architecture, the Architecture Vision, principles, the draft Architecture Definition Document and Architecture Requirements Specification, relevant reference models from the repository, and existing data and application descriptions.
- What to understand
- Business information needs and processes from Phase B define what data and application support is required. Reference models and patterns from the Architecture Repository and TOGAF Library can accelerate design. Missing business information suggests revisiting Phase B rather than inventing assumptions in Phase C.
- How it shows up
- Options that proceed in Phase C despite major gaps in business information often score low; iteration back to Phase B may be the better choice.
- Common confusion
- Thinking Phase C can be completed using only an application inventory.
4.6 Apply Phase C: Data and Application ArchitecturesBloom level 3. Developing data and application baselines and targets.
- What it means
- Phase C defines the major types and sources of data and the logical application components that process data and support the business. Data Architecture covers entities, ownership, data management and migration; Application Architecture covers components, their interactions and their relation to business processes.
- What to understand
- Data and Application work can be done in either order or together. Data migration and data governance often need explicit attention when systems are replaced. Application components are described logically at first, independent of products, so that later phases can choose solutions against requirements.
- How it shows up
- Scenarios involving system replacement reward options that address data migration, ownership and quality, not just application functionality.
- Common confusion
- Assuming Data Architecture must always be completed before Application Architecture.
4.7 Apply the information needed for Phase D: Technology ArchitectureBloom level 3. Inputs to Technology Architecture work.
- What it means
- Phase D draws on the Business and Information Systems Architectures, technology principles, existing technology descriptions, technology standards and reference models, and requirements such as performance, availability, security and regulatory constraints.
- What to understand
- Technology choices exist to support the application and data architectures, which in turn support the business. Non-functional requirements captured earlier are central here. Standards from the repository constrain choices and support interoperability across the enterprise.
- How it shows up
- Prefer options that derive technology needs from application, data and non-functional requirements rather than from vendor preference.
- Common confusion
- Starting Phase D from a preferred platform rather than from upstream architectures.
4.8 Apply Phase D: Technology ArchitectureBloom level 3. Developing technology baselines and targets.
- What it means
- Phase D describes the logical and physical technology components and platform services needed to deploy application and data components, including infrastructure, middleware, networks, hosting and security services, along with the standards they must follow.
- What to understand
- Gap analysis in Phase D often reveals platform consolidation opportunities and dependencies that strongly affect migration planning. Technology Architecture also addresses operational concerns such as resilience, capacity and support. Its outputs complete the picture used by Phase E to identify solutions and work packages.
- How it shows up
- Look for options that address non-functional and operational requirements and check impacts on other architectures before finalizing.
- Common confusion
- Treating Phase D as procurement rather than architecture.
4.9 Apply the outputs of Phases B, C and DBloom level 3. Deliverables that leave the development phases.
- What it means
- The main outputs are the updated Architecture Definition Document with baseline and target descriptions and views, the Architecture Requirements Specification with gap analysis results and requirements, refined principles, and draft Architecture Roadmap components for each domain.
- What to understand
- The Architecture Definition Document describes the architecture; the Architecture Requirements Specification holds the quantitative statements a solution must meet, including interoperability, constraints and assumptions. Both are drafts until the cycle approves them. Roadmap components from each phase are consolidated in Phase E.
- How it shows up
- When asked what to hand over, choose the document that matches the purpose: descriptions in the ADD, measurable requirements in the ARS.
- Common confusion
- Confusing the Architecture Definition Document with the Architecture Requirements Specification.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Common development steps
Reference models and viewpoints, baseline, target, gaps, roadmap components, impacts, stakeholder review, finalize, ADD.
- Remember
- Same pattern in Phases B, C and D.
- Tested as
- Identifying the next step in a scenario.
- Trap
- Skipping impact resolution or stakeholder review.
-
Target-first approach
Develop the target first and describe only the baseline needed to find gaps.
- Remember
- Useful when large change is planned.
- Tested as
- Sequencing options.
- Trap
- Insisting on full baseline documentation.
-
Business drivers, goals and objectives
Drivers motivate change, goals state intent, objectives make goals measurable.
- Remember
- Architecture elements should trace to them.
- Tested as
- Justifying and prioritizing designs.
- Trap
- Using the terms as synonyms.
-
Business capability and value stream
Capabilities describe what the business does; value streams show how value is delivered to stakeholders.
- Remember
- Core Phase B techniques.
- Tested as
- Choosing Phase B analysis tools.
- Trap
- Confusing capabilities with processes.
-
Phase C ordering
Data and Application Architectures can be developed in either order or in parallel.
- Remember
- Choice depends on the situation.
- Tested as
- Options that impose a fixed order.
- Trap
- Assuming data always comes first.
-
Data migration
Moving and transforming data when applications are replaced.
- Remember
- Addressed in Phase C.
- Tested as
- Replacement scenarios.
- Trap
- Treating migration as a later technical task only.
-
Non-functional requirements
Performance, availability, security, scalability and similar qualities.
- Remember
- Central to Phase D decisions.
- Tested as
- Technology scenarios.
- Trap
- Selecting platforms on vendor preference.
-
Architecture Definition Document
Deliverable holding the core architecture descriptions across domains.
- Remember
- Describes; does not specify measurable criteria.
- Tested as
- Output questions.
- Trap
- Swapping it with the ARS.
-
Architecture Requirements Specification
Quantitative statements a compliant implementation must meet, plus gap results, constraints and assumptions.
- Remember
- Grows through B, C and D.
- Tested as
- Output and compliance scenarios.
- Trap
- Treating it as a narrative design.
-
Resolve impacts across the landscape
Check the effect of the proposed architecture on other architectures and projects.
- Remember
- A common step before finalizing.
- Tested as
- Overlapping programme scenarios.
- Trap
- Optimizing one project in isolation.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Phase B vs. Phase C vs. Phase D focus
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Phase B: Business Architecture | Capabilities, value streams, organization, processes and business information | How the business operates | Choosing software here |
| Phase C: Data and Application | Data entities, ownership, migration and logical application components | Information systems supporting the business | Fixing a data-first order |
| Phase D: Technology | Platform services, infrastructure, security services and standards | Technology to deploy information systems | Starting from vendor preference |
Architecture Definition Document vs. Architecture Requirements Specification
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Architecture Definition Document | Descriptions, models and views of baseline and target | Qualitative view of the architecture | Using it as the compliance yardstick alone |
| Architecture Requirements Specification | Measurable requirements, constraints, assumptions and gap results | Quantitative criteria for implementation | Filling it with narrative descriptions |
Baseline-first vs. target-first
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Baseline-first | Describe current state, then design target | Suits incremental change in well-understood areas | Over-documenting areas that will be retired |
| Target-first | Design target, then describe only relevant baseline | Suits large change or poorly documented baseline | Ignoring constraints the baseline imposes |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Full baseline first
- What candidates pick
- Document the entire current business before any target design.
- Why it looks right
- It feels methodical.
- Why it's wrong
- When the change is large, a target-first approach with only the baseline needed for gap analysis is more efficient.
Clue to watch for Time pressure, major transformation or poor existing documentation.
-
Vendor-led Phase D
- What candidates pick
- Adopt the strategic vendor's reference platform as the target technology.
- Why it looks right
- It is quick and has executive backing.
- Why it's wrong
- Technology must be derived from application, data and non-functional requirements and the agreed standards.
Clue to watch for A vendor relationship is mentioned alongside unclear requirements.
-
Isolated finalization
- What candidates pick
- Finalize the target because the project's own stakeholders approved it.
- Why it looks right
- Local approval seems sufficient.
- Why it's wrong
- Impacts across the Architecture Landscape must be resolved, especially when other programmes overlap.
Clue to watch for Another programme or shared service is mentioned.
-
Pushing on with missing business input
- What candidates pick
- Make assumptions about business processes and complete Phase C.
- Why it looks right
- It keeps the schedule.
- Why it's wrong
- Iterating back to Phase B to fill real gaps avoids building on wrong assumptions.
Clue to watch for Phase C team finds business information is missing or contradictory.
-
ADD for everything
- What candidates pick
- Put measurable performance criteria only in the Architecture Definition Document.
- Why it looks right
- It is the main deliverable.
- Why it's wrong
- Measurable criteria for compliance belong in the Architecture Requirements Specification.
Clue to watch for The question mentions criteria that implementers must meet.
-
Security in one place
- What candidates pick
- Leave security requirements for the Technology Architecture.
- Why it looks right
- Many controls are technical.
- Why it's wrong
- Business and data security concerns such as data classification and legal obligations arise in Phases B and C.
Clue to watch for Sensitive data or regulated processes appear in a Phase B or C scenario.
Answer framework
Locate the scenario in the common step pattern, then test each option against it.
- Identify which phase the scenario is in and which common step it has reached, such as baseline, target, gap analysis or stakeholder review.
- Check that the needed inputs from earlier phases exist; if business information is missing in Phase C or D, prefer options that iterate back.
- Confirm that design choices trace to business drivers, goals, principles and requirements rather than preference or vendor influence.
- Look for impacts on other architectures, programmes, security and data migration, and favour options that resolve them before finalizing.
- For outputs, choose the deliverable whose purpose matches: descriptions in the ADD, measurable criteria in the ARS, and candidate roadmap components for Phase E.
Practice question
Want more like this? The TOGAF Practitioner practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
This is the largest Applying-level area, so give it a solid block of study time. Begin with the common step pattern. Write the nine steps on a card and learn their order and purpose; most Phase B, C and D scenarios ask you to place yourself in that sequence.
Next, study each phase separately for its objectives, inputs and specific focus. For Phase B, practise business capability maps and value streams on a simple example. For Phase C, note why data and application work can run in either order and what data migration involves. For Phase D, connect non-functional requirements to platform and infrastructure decisions.
Third, study the two key deliverables. Write a short description of what goes into the Architecture Definition Document and what goes into the Architecture Requirements Specification, and test yourself on which one a given item belongs in.
Then add security and risk. For each phase, write two security activities. Finally, practise scenarios in which a design conflicts with another programme or lacks business input. Ask yourself whether the best move is to resolve impacts, iterate back to an earlier phase, or proceed. That judgement is what separates 5-point answers from 3-point answers here.
FAQ
Does The Open Group publish a weight for Architecture Development?
No. Architecture Development is one of eight syllabus areas for the 8 OGEA-102 scenarios, with no published share. It has the most Applying-level outcomes, so expect it to feature in more than one scenario.
Must Phase B always come before Phase C?
Phase B normally comes first because it drives requirements, but the ADM is iterative, and teams can iterate between phases when information is missing.
Can Data and Application Architectures be done in parallel?
Yes. The TOGAF Standard allows either order or parallel development in Phase C, depending on the organization's situation.
Which deliverable holds measurable requirements?
The Architecture Requirements Specification. The Architecture Definition Document holds the descriptive models and views.
What does resolving impacts across the Architecture Landscape mean?
Checking how the proposed architecture affects other architectures, programmes and shared services, and resolving conflicts or reuse opportunities before finalizing.
Are reference models like the TRM still used in TOGAF 10?
Reference models remain usable in Phases C and D; in the 10th Edition several are published as Series Guides or in the TOGAF Library rather than in the Fundamental Content.
Where do roadmap components go after Phase D?
Candidate roadmap components from Phases B, C and D are consolidated in Phase E into the Architecture Roadmap and work packages.
Other Enterprise Architecture & IT Governance certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 4 knowledge
You have covered the common steps, security and the specifics of Phases B, C and D. Test whether you can find the right next step in a design scenario.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the TOGAF Practitioner AI tutor Get any concept explained your way