TOGAF Practitioner Case-Study Workbook

These eight original cases mirror the eight published Practitioner topic areas. They do not reproduce protected examination questions.

How to work each case

Use SCOPE before writing an answer:

1. Stakeholders — who cares and who decides?
2. Context — what phase, level, scope, evidence, and constraints exist?
3. Outcome — what result or decision must the work enable?
4. Proportion — what is the smallest sufficient response?
5. Evidence — what preserves traceability, trade-offs, and feedback?

For each case:

• write your answer before reading the model response;
• explain why at least one tempting response is weaker;
• name the ADM phase or supporting technique involved; and
• state what evidence would prove success.

Case 1: Establishing the Enterprise Architecture Context

Scenario

Northstar Foods has acquired four regional manufacturers. Each business has its own product catalog, supply-chain processes, applications, infrastructure, and technology standards. The board wants lower operating cost and a single view of inventory. The new CIO creates a five-person Enterprise Architecture team and asks it to "standardize everything within six months."

Business presidents fear losing their ability to serve local markets. Product teams worry that a new central review board will delay releases. Finance wants fast savings, while operations warns that several factories rely on old equipment that cannot be replaced immediately. No architecture mandate, decision-right model, repository, or connection to portfolio funding exists.

Your tasks

1. What is the real problem behind the request to standardize everything?
2. What should the lead architect establish before launching broad domain work?
3. How should decision rights balance enterprise coherence with local autonomy?
4. What would make a good first pilot?
5. Name three measures that would show the architecture capability is useful.

Worksheet

• Outcome:
• Scope and level:
• Key stakeholders and concerns:
• First architecture decision:
• Minimum content:
• Governance and feedback:

Case 2: Stakeholder Management

Scenario

CityLink, a public transport authority, is designing one mobile ticket across bus, rail, and ferry services. The customer director wants an effortless journey. The finance director wants fraud controls. Accessibility groups need the service to work for passengers with disabilities. The privacy officer worries about travel histories. Operations teams need offline validation when connectivity fails. Private transport partners want to keep control of their customer relationships.

The sponsor asks the architecture team for a target design in three weeks. Engineering proposes creating an application diagram first because it is the fastest artifact to produce.

Your tasks

1. Why is an application diagram a weak starting point?
2. Create a stakeholder-and-concern map for the case.
3. Which viewpoints would help resolve the most important conflicts?
4. Who should decide the trade-off between convenience, privacy, and fraud?
5. How should agreed concerns become traceable requirements?

Worksheet

• Highest-influence stakeholders:
• Highest-impact stakeholders:
• Conflicting concerns:
• Required views:
• Decision owner:
• Traceability path:

Case 3: Phase A — The Starting Point

Scenario

ClearWater Utilities wants predictive maintenance for pumps across 80 sites. Executives agree that unexpected failures are costly, but they disagree about the engagement boundary. Operations wants new field processes and sensors. Data leaders want ownership and quality rules. Technology leaders want a cloud analytics platform. Procurement wants to start vendor selection immediately.

The program manager asks the architect to begin Technology Architecture so a platform choice can "make the scope real." There is no agreed success measure, stakeholder map, readiness view, or Statement of Architecture Work.

Your tasks

1. What should happen before detailed Technology Architecture?
2. Define the business outcome and three measurable success indicators.
3. Describe the scope using breadth, depth, time horizon, and domains.
4. What belongs in the Architecture Vision?
5. What must the Statement of Architecture Work authorize and control?

Worksheet

• Driver and desired outcome:
• Scope:
• Stakeholders:
• High-level baseline and target:
• Risks and readiness:
• Authorization required:

Case 4: Developing Business, Data, Application, and Technology Architectures

Scenario

Harbor Health operates twelve clinics. A patient may register separately at each clinic, repeat medical history, and receive conflicting appointment messages. Leaders want a joined-up patient journey without replacing every system at once.

Clinic managers want local flexibility. Clinicians need safe and timely information. Patients want control over communications. The data team has found four patient identifiers and no clear owner for contact data. Applications exchange nightly files. Several clinics have unreliable network links.

Your tasks

1. Describe a target Business Architecture for the patient journey.
2. Identify the most important Data Architecture choices.
3. Define the Application Architecture responsibilities without choosing products prematurely.
4. Identify Technology Architecture enablers and constraints.
5. Show two cross-domain dependencies that must remain visible.

Worksheet

• Target value stream:
• Capabilities and ownership:
• Data entities and owners:
• Application services:
• Technology services:
• Cross-cutting security, privacy, and resilience:

Case 5: Implementing the Architecture — Phases E, F, and G

Scenario

Beacon Retail has approved a target architecture for unified customer orders and stock. The gap list contains 70 changes across data, applications, infrastructure, operations, training, and supplier contracts. Every business unit calls its own changes "critical." The transformation budget can fund only half the work this year.

One team proposes building the new customer application immediately. Another warns that stock data is too unreliable to support the promised experience. Delivery teams ask what evidence will be needed at architecture reviews.

Your tasks

1. How should Phase E turn the gap list into coherent work packages?
2. Propose useful Transition Architectures.
3. What evidence should Phase F use to prioritize the roadmap?
4. How should Phase G connect architecture requirements to delivery?
5. What information must a justified exception contain?

Worksheet

• Work packages:
• Dependencies:
• Transition states:
• Prioritization criteria:
• Compliance evidence:
• Exception rule:

Case 6: Phase H — Architecture Change Management

Scenario

Atlas Insurance implemented a cloud claims architecture eighteen months ago. Operational evidence now shows high cost during catastrophe events. A new privacy law limits data retention. A machine-learning service can improve fraud detection, but introduces explainability and model-risk concerns. One delivery team also requests a minor API version change.

Leaders disagree about whether every change should launch a full ADM cycle. The repository contains the approved target, but decisions and exceptions have not been updated since launch.

Your tasks

1. Classify the four change signals by likely response.
2. Which change may be ordinary maintenance?
3. Which changes justify a partial or new ADM cycle?
4. What Architecture Landscape and Governance Log updates are needed?
5. Which outcome and risk measures should be monitored?

Worksheet

• Change signal:
• Materiality:
• Scope of response:
• Decision authority:
• Repository update:
• Revisit trigger:

Case 7: Requirements Management

Scenario

GreenGrid is modernizing the systems that balance renewable energy supply and demand. Requirements are kept in separate spreadsheets by engineering, security, operations, and suppliers. Many statements have no owner, source, priority, or verification method. A new regulator rule arrives after the target architecture has been approved.

The program manager wants to add the rule to one spreadsheet and continue delivery. The chief architect suspects it may affect data retention, operational processes, supplier contracts, platform capacity, and the migration sequence.

Your tasks

1. What attributes should every controlled requirement have?
2. How should the new rule enter Requirements Management?
3. What should a requirements impact assessment examine?
4. How should traceability reach implementation evidence?
5. When should architecture work be revisited?

Worksheet

• Requirement statement and source:
• Owner and priority:
• Affected stakeholders and domains:
• Affected decisions and work packages:
• Verification method:
• Change history and approval:

Case 8: Supporting the ADM in an Agile Digital Enterprise

Scenario

BrightLearn runs a digital education platform with 30 autonomous product teams. Teams deploy many times per day. Enterprise architects currently review large solution documents at the end of delivery, so teams see architecture as slow and irrelevant. Shared identity, learner data, AI safety, and platform cost need enterprise coherence, while most user-interface choices do not.

The CTO wants architecture integrated into product planning and delivery without creating a central approval queue.

Your tasks

1. How should the ADM be tailored for short product learning cycles?
2. Which decisions should be centralized, federated, or delegated?
3. Which lightweight artifacts and automated evidence are useful?
4. How should security, AI risk, and cost be integrated across domains?
5. How can operational evidence feed Phase H and future roadmaps?

Worksheet

• Architecture level and cadence:
• Enterprise guardrails:
• Delegated decisions:
• Minimum artifacts:
• Automated evidence:
• Feedback measures:

Model responses

Use these to find gaps in your reasoning, not to memorize sentences.

Model response 1: Context

The real problem is not a lack of standards; it is missing enterprise direction, authority, portfolio connection, and a safe way to balance shared outcomes with regional needs. Start by establishing a minimum architecture capability: mandate, sponsor, scope, tailored method, principles, roles, decision rights, repository, and integration with portfolio and delivery governance.

Use a federated model. Enterprise authority owns decisions with material cross-business impact—shared inventory meaning, integration, security, and technology lifecycle. Regions retain bounded market and delivery choices.

A strong pilot has visible business value, manageable scope, willing stakeholders, reusable learning, and real dependencies. One inventory flow across two businesses is better than an enterprise-wide documentation exercise. Measure decision time, reuse, delivery rework, risk reduction, outcome progress, and stakeholder trust.

Model response 2: Stakeholders

Start with stakeholder analysis because the architecture exists to address concerns and enable decisions. Map influence, impact, decision authority, and engagement. Useful viewpoints include customer journey and accessibility, privacy and information lifecycle, fraud and control, offline operational resilience, partner responsibility, and financial value.

The sponsor should ensure the relevant accountable authorities resolve the trade-off with evidence; engineering alone should not decide it. Turn resolved concerns into owned, measurable requirements and trace them to target choices, work packages, tests, operational measures, and review.

Model response 3: Phase A

Use Phase A before detailed domain development. Agree the outcome—fewer unplanned failures and safer, more predictable maintenance—then define measures such as outage hours, maintenance lead time, and failure-detection accuracy.

Scope the sites and business processes, required detail, planning horizon, and Business, Data, Application, and Technology domains. The Vision should show the problem, stakeholders, high-level baseline and target, value, requirements, constraints, risks, and readiness. The Statement of Architecture Work authorizes objectives, scope, method, plan, roles, governance, deliverables, acceptance, assumptions, and change control.

Model response 4: Architecture Development

The Business target is one joined-up patient journey with clear clinical, administrative, and communication responsibilities while preserving justified local variation. Data choices include patient identity resolution, ownership, consent, quality, lifecycle, and a trusted contact source.

Application Architecture should define services such as patient identity, appointment, notification, and clinical-information access before products. Technology must enable secure identity, resilient connectivity, integration, monitoring, and recovery. Cross-domain dependencies include consent rules driving data and notification behavior, and connectivity constraints affecting application resilience and clinic process.

Model response 5: Implementation

Phase E groups related gaps into outcome-oriented work packages, reconciles cross-domain dependencies, considers solution building blocks, and defines safe Transition Architectures. A sensible sequence establishes trustworthy stock before customer promises, then reservation, then richer fulfillment.

Phase F uses value, cost, risk, dependency, readiness, resources, and delivery evidence—not stakeholder volume—to prioritize. Phase G agrees responsibilities, review points, and required automated or manual evidence. An exception records exact scope, rationale, risk, compensating controls, owner, authority, expiry, and remediation or exit.

Model response 6: Change

The API version may be maintenance if bounded and compatible. The cost problem may need targeted architecture work. The privacy law has mandatory cross-domain impact and may require a partial cycle. Machine learning may require a new or expanded cycle because it changes capability, data, technology, risk, and governance.

Update relevant baseline and target states, requirements, decisions, standards, exceptions, risks, and debt. Monitor cost, performance, compliance, model quality, explainability, incidents, and business outcomes. Use materiality, scope, urgency, and risk to choose maintenance, partial iteration, or a new cycle.

Model response 7: Requirements

Each requirement needs an identifier, clear statement, rationale, source, owner, priority, status, acceptance or verification method, relationships, and change history. Register the regulation as a sourced requirement, analyze it, and assess its effect on stakeholders, domains, architecture decisions, gaps, work packages, risk, cost, and sequence.

Trace it from source to requirement, decision, architecture element, work package, implementation control, test or review evidence, and operational measure. Revisit affected ADM work whenever the impact invalidates approved assumptions, target choices, roadmap, or governance.

Model response 8: Supporting the ADM

Use small ADM cycles aligned with product horizons and continuous discovery. Centralize cross-enterprise identity, learner-data semantics, AI safety, and material platform-risk decisions. Federate domain choices and delegate local, reversible user-interface decisions.

Use brief visions, principles, decision records, domain contracts, roadmaps, and machine-checkable standards. Automate evidence through delivery pipelines, security tests, policy checks, observability, and cost controls. Feed incidents, performance, usage, risk, cost, and customer outcomes into Phase H and future planning.

Scoring rubric

Score each case from 0 to 4:

A strong readiness target is at least 3 on every case, not merely a high average.