Stage 2. Preliminary Phase and Architecture Vision: phase summary

6 min read 5 sections 7 key points

Stage 2 settles everything that must be true before anyone draws a target-state diagram. Across the eight modules you defined the enterprise boundary, mapped stakeholders to concerns, wrote principles that carry implications, framed the real problem as a business scenario, fixed scope along four dimensions, established sponsorship and governance, and converged it all into an Architecture Vision and a Statement of Architecture Work. The London Grid Distribution case ran through every module so the techniques produced one coherent kickoff pack rather than eight separate exercises.

The enterprise boundary is a design decision, not the org chart

The Preliminary Phase decides where architecture authority begins. The enterprise boundary is the set of actors, obligations, interfaces, and decision rights that materially shape the work, which is wider than any single org chart and narrower than everything the company touches. The most common error is treating the organisational boundary as the architecture boundary, which leaves out regulators, system operators, and delivery partners. For London Grid the effective boundary pulls in internal functions like planning, connections, operations, cyber, and telecoms, plus Ofgem obligations, NESO planning interfaces, public data-publication expectations, and external contractors whose work enters the data, while commercial and retail functions and long-term DSO ambitions sit outside the first cycle.

The stakeholder chain runs to concerns, viewpoints, and views

TOGAF's stakeholder management technique runs identify, classify, find concerns, select viewpoints, produce views, and maintain engagement. A concern must be specific enough to shape what the architecture shows, and a viewpoint is a set of conventions for what an audience needs to see, not a diagram template. One master diagram for everyone usually answers the wrong question for every audience. For London Grid this means distinct blocs, Ofgem, NESO, operations, cyber security, the connections team, and applicants, each carrying a different concern that needs a different view.

Principles, scenarios, and scope make the problem concrete

A principle earns its place only when its four parts, name, statement, rationale, and implications, create real consequences for design and exceptions; values describe beliefs and change nothing. The London principle set, Evidence before exposure, Safety and operability first, Interoperability by design, and One published truth per date, each responds to a named pressure and routes exceptions through the Architecture Board or operations leadership. The G176 business scenario then separates symptoms from the root problem: London Grid's connections process averages 90 days against an Ofgem target of 65, with manual re-entry at two of five handoffs and a planning tool predating CIM. Scope is set deliberately across breadth, depth, time, and domains, prioritising business and data architecture over a three-year horizon because process handoffs and data-quality failures are the root causes.

Sponsorship is authority, not permission

G184 separates an organisation that has approved an architecture function from one that genuinely sponsors it. Real sponsorship provides three things passive endorsement does not: access to people and forums, a defined path for architecture conclusions into delivery governance, and conflict-resolution support that does not default to the larger budget. The maturity model runs from Level 0 None, where decisions are ad hoc, through Level 1 Initial, where outputs exist but have no path into delivery and the capability disappears if one architect leaves. The kickoff aims for proportionate governance: enough structure to survive the first contested decision, with room to mature.

Vision and Statement of Architecture Work do different jobs

The Architecture Vision sets aspirational direction; the Statement of Architecture Work is the formal commission that defines scope, approach, schedule, governance, and outputs. Phase A is weak when it produces inspiration but no commission, because delivery teams then cannot tell what work was authorised. The final module assembles the London pack so every artefact traces to every other: each principle traces to a tension in the scenario or stakeholder map, and each concern appears in the scenario, vision, or work statement, or is explicitly deferred. Coherence, not the existence of the documents, is what protects Phase B from inheriting confusion.

Watch out for

  • Drawing the enterprise boundary around the org chart, which leaves out regulators, system operators, and delivery partners that shape the architecture
  • Writing principles that read like corporate values, approved and then ignored because they create no design constraint
  • Treating scope as a form to fill in rather than a design choice; putting everything in scope so nothing reaches decision-grade depth
  • Producing a polished vision with no Statement of Architecture Work, so the team has direction but no agreed commission to proceed

Key takeaways

  • The enterprise boundary is defined by what shapes design and governance decisions, not by reporting lines; for London Grid it includes Ofgem, NESO, and external contractors
  • A TOGAF principle needs name, statement, rationale, and implications; without implications it is a value that changes no decision
  • London Grid's worked scenario: connections average 90 days against Ofgem's 65-day target, with manual data re-entry at two of five handoff points
  • Scope has four dimensions, breadth, depth, time, and domains; the first London cycle uses a three-year horizon and prioritises business and data architecture
  • G184 distinguishes permission from sponsorship; real sponsorship provides access, a path into delivery governance, and conflict-resolution support
  • The Architecture Vision sets direction while the Statement of Architecture Work is the formal commission that authorises governable work
  • A coherent kickoff pack means every artefact traces to every other; existence of the documents is not the same as coherence

With the boundary, stakeholders, principles, scenario, scope, governance, vision, and work statement in hand, the scenario practice puts you in front of realistic situations to apply these techniques and catch the common mistakes before the timed stage assessment.

Start the scenario practice