TOGAF EA Practitioner study materials
TOGAF EA Practitioner study resources

The Vendor Design Arrives First

TOGAF EA Practitioner · Put your knowledge to work in context.

All case studies

The Vendor Design Arrives First

At a university, the CIO sponsors a 'Student 360' programme with a £4.2m budget and an 18-month window. Seven faculties run their own student-record systems; three core systems overlap. At kick-off, the CIO hands the architect a 60-page vendor design and says: 'Turn this into the architecture. Skip the vision - everyone knows what we need.' The Registrar, Faculty Deans, Data Protection Officer and Students' Union all have different definitions of '360'. Scope is not agreed, and no measurable outcomes exist. The vendor design assumes real-time sharing of sensitive data across all faculties.

1. Why should the architect not accept the vendor design as the architecture, and what Phase A work is still needed?

Read the worked answer

The vendor document is a solution design, not an architecture. It answers 'how' before the university has agreed 'what' and 'why'. Phase A still needs a stakeholder map and concerns, business scenarios with measurable outcomes, a capability assessment, agreed scope and constraints, a high-level Architecture Vision, and a Statement of Architecture Work defining deliverables, plan, roles and acceptance criteria. Without these, the £4.2m programme cannot test whether the vendor design fits, cannot evaluate change requests, and has no basis for the Data Protection Officer's constraints. Accepting it would make the vendor's assumptions the de facto architecture.

2. How should the architect use stakeholders and business scenarios to resolve the '360' ambiguity?

Read the worked answer

Use a stakeholder map to show that the Registrar (records integrity), Deans (faculty autonomy), Data Protection Officer (lawful sharing) and Students' Union (consent and transparency) have conflicting concerns, not one 'everyone knows' requirement. Run business scenarios: a student changes faculty, a dean needs a cohort view, a student requests their record. For each, capture actors, triggers, desired outcome and measures. This exposes which data must be shared in real time and which can be batch or federated. Then negotiate in/out scope with the CIO and Deans, and record agreed definitions and constraints in the Architecture Vision and Statement of Architecture Work. The vendor design is treated as an input to be tested, not approved.