Stage 2 summary. Preliminary Phase and Architecture Vision

The Preliminary Phase is often dismissed as setup work, and that description is dangerously weak. It decides whether the architecture effort starts with a controlled enterprise definition or with a vague brief that expands every week. C220 Part 2 gives the phase two objectives, determine the Architecture Capability the organisation wants and establish that capability, and six steps to get there: scope the enterprise organisations impacted, confirm governance and support frameworks, define and establish the architecture team, identify and establish architecture principles, tailor the TOGAF framework, and plan the tools and techniques. The common thread is readiness.

Tailoring deserves particular care because it is so often done by omission. Tailoring means conscious, recorded decisions about which parts of TOGAF to use, modify, or defer, weighed against organisational maturity, existing frameworks such as ITIL or SABSA, the scale of the work, and the regulatory context. Skipping a phase without recording why is not tailoring. It is uncontrolled omission, and when governance gaps appear later nobody can say whether they were deliberate.

The phase ends with a concrete handoff, not a state of mind. Phase A depends on five outputs existing: a sponsor-issued Request for Architecture Work, an Organisational Model for Enterprise Architecture, a Tailored Architecture Framework including Architecture Principles, an Initial Architecture Repository, and an Architecture Governance Framework. If any of them is missing or unclear, the Preliminary Phase is not complete, whatever the pressure to move on.

The word enterprise in enterprise architecture does not automatically mean the whole company. TOGAF uses it for the scope of the effort, the set of actors, obligations, interfaces, and decision rights that materially shape the work. Four boundaries usually get conflated. The enterprise boundary is an architecture concept, defined by what shapes design and governance decisions. The organisational boundary is the reporting structure on the org chart. The programme boundary is the funded initiative, a management construct. The solution boundary is the specific system a delivery team will build. Pick the wrong one and the failures follow: a programme boundary misses dependencies outside its funding, an org chart misses regulated interfaces, and a solution boundary loses the enterprise perspective entirely.

Regulated sectors widen the real boundary. An electricity distributor answers to Ofgem, to the National Energy System Operator, to industry code bodies, and to public data-publication expectations, none of which appear on its org chart and all of which directly shape data models, process designs, and evidence requirements. The disciplined move is an influence test: include an actor or an obligation in the effective boundary when it materially constrains the design or the governance, even when it sits outside the internal organisation.

For London Grid Distribution's first cycle, the boundary pulls in planning, connections, operations, digital and data services, cyber security, telecoms, and regulatory affairs, together with Ofgem obligations, NESO planning interfaces, public data-publication expectations, and the external contractors whose work enters the data. Commercial and retail functions, long-term DSO ambitions, and exploratory innovation projects stay outside the first cycle, visibly and with a recorded rationale.

The stakeholder management technique in C220 Part 3 runs in a fixed sequence: identify stakeholders, classify them, identify their concerns, select viewpoints, produce views, and maintain engagement for the rest of the cycle. Four terms carry the chain. A stakeholder is a person, team, or organisation with an interest in the system. A concern is the specific issue that matters to them. A viewpoint is the camera angle, the conventions defining what that audience needs to see. A view is the photograph, the representation actually produced. Skip a link and the output weakens.

The word doing the work is specific. Cost is not a concern, but whether the integration cost of replacing a legacy system exceeds the benefit of faster response times is. The module's method for finding real concerns is to ask what decision the stakeholder must make, what failure worries them most, what evidence would earn their trust, and what they would challenge if the architecture proceeded without them. TOGAF's stakeholder categories, corporate functions, end-user organisation, project organisation, systems operations, and external stakeholders, are a checklist against missing a group, and in a regulated enterprise the external category matters most because a regulator's compliance interest is nothing like a consumer's service interest.

One master diagram for every audience is the warning sign that viewpoint selection never happened. Executives need investment logic and accountabilities, operations needs service impact and transition risk, regulators need evidence trails and obligations, and technical audiences need data boundaries and interface contracts. For London Grid that means distinct blocs, Ofgem, NESO, the executive team, operations leadership, network engineers, cyber and telecoms teams, applicants, and third-party data users, each needing a different showing of the same change.

A value expresses what the organisation believes. A principle shapes what it will and will not do when choices become difficult. TOGAF makes the difference structural by requiring four components: a name, a statement, a rationale, and implications. The implications are where a principle earns its place, because they say what changes in design, governance, exceptions, and evidence when the rule is applied seriously. The standard also provides 21 example principles in four categories, business, data, application, and technology, and they are starting points to adapt, not prescriptions to adopt.

The stress test is practical. Put the principle in front of a realistic trade-off, ask what a team would have to do differently if it were enforced, ask what evidence would show compliance or a justified exception, and ask whether it could ever be legitimately overridden through a formal waiver. A principle that passes every test without creating tension is too broad, and one that cannot be tested in a governance review is decoration. Four hard-edged principles outperform fourteen decorative ones, and occasional push-back is the signal that a principle is doing real work.

London Grid's principle pack holds five, each answering a named pressure. Evidence before exposure responds to regulatory trust, so nothing reaches Ofgem, NESO, or the public without a defined evidence-quality gate. Safety and operability first gives operations leadership a veto over changes affecting live network control. Interoperability by design makes open standards such as CIM the default. One published truth per date makes every published figure reference the single authoritative record. Cyber spans OT, IT, and telecoms treats the three estates as one security perimeter. Exceptions route through the Architecture Board with documented justification.

A business scenario is a structured description of a real business problem, and Series Guide G176 is its home. It is not a user story, which describes one feature for one user. It is not a strategy statement, which says where the organisation wants to go. And it is not a requirements document, because requirements are derived from the scenario later. G176 works through a structured process: identify, document, and rank the problem, describe the business and technical environment, define the desired objectives, identify the human actors, identify the computer actors, document roles, responsibilities, and measures of success, and refine the result with stakeholders until it is fit for purpose.

The technique's value is the ladder it forces you down. A symptom is what people complain about, such as a connections process being too slow. A root cause explains why, such as manual data re-entry where an upstream system publishes no structured output. The scenario supplies the full enterprise context, who experiences the problem, under which conditions, with which constraints, and what better looks like in measurable terms. Bad scenario work comes in two flavours, fiction writing with no system names or thresholds, and slogan recycling that restates the strategy without new specificity.

The London scenario shows what earned specificity looks like. Connection applications pass through five handoff points, and at two of them data is re-entered manually from PDF attachments. Average response time is 90 days against a regulatory target of 65, Ofgem publishes league tables that affect regulatory standing, and the network planning tool predates CIM. The scenario names eight human actors and five computer actors. The test for readiness is blunt: could an architect read it and explain which scope decisions follow?

Scope changes the kind of answers a team can honestly produce, which is why TOGAF treats it as a design decision rather than a form to fill in. Four dimensions define it. Breadth says how much of the enterprise is covered. Depth says how detailed the work must be, and the architecture landscape gives it three levels, strategic, segment, and capability. Time sets the planning horizon. Domains says which of business, data, application, and technology architecture are in play. Each dimension is a trade-off, and every choice should trace back to the decisions the business scenario says the architecture must support.

The ADM is built for multiple passes, through iteration, running the cycle again to deepen or extend the work, and partitioning, dividing the enterprise into segments with coordination between them. That is what makes a controlled first scope safe. Over-scoping is the most common silent failure: every domain declared critical, none reaching decision-grade depth, and stakeholders losing faith when the architecture cannot answer specific questions. Starting broad with a plan to narrow later rarely narrows. The discipline is to set scope specific enough to guide change, open enough to reveal dependencies, and to record deferrals explicitly in the Statement of Architecture Work.

London Grid's first cycle applies the method directly. Breadth covers the functions and regulated interfaces around connections and data publication. Depth is segment level for business architecture, capability level for data architecture where the root causes live, and strategic level for technology. Time is a three-year horizon, long enough for the improvement targets and one or two transition architectures, short enough to shape decisions due in the next 12 to 18 months. Business and data architecture take priority, and the recorded exclusions, DSO transition, commercial and retail systems, detailed platform selection, and smart meter integration, keep the cycle honest.

Many architecture efforts begin with executive enthusiasm and die at the first delivery conflict, and Series Guide G184 explains why. An organisation that has approved an architecture function is not the same as one that sponsors it. Real sponsorship provides three things passive endorsement does not: access to the people, evidence, and forums the team needs, a defined path for architecture conclusions into delivery governance, and conflict-resolution support that does not default to whoever has the larger budget. The guide's requirements go further, a named individual rather than a committee, decision-forum access, escalation authority, resource commitment, visible endorsement, and continuing engagement. A sponsor who launches the capability and then disengages has provided a press release.

G184 describes six interdependent components of a working capability: sponsorship and mandate, an operating model, roles and skills, a governance structure, a repository with evidence discipline, and a maturity assessment with an evolution plan. At kickoff the operating model can be minimal but must exist, a named sponsor, a lead architect accountable for coherence, an architecture decision forum with explicit authority, and a repository steward, with domain leads added as the capability matures. Proportionate governance is the aim. One credible forum with real authority beats several committees with vague purpose, and the test is whether the structure would survive the first contested decision.

Maturity is assessed on a six-level ladder from Level 0, none, to Level 5, optimising, and targets should be proportionate to the enterprise challenge rather than aimed at the top by default. London Grid starts at roughly Level 0 to 1, useful ad hoc work with no shared repository or governance path, so the kickoff aims for Level 2 by the end of the first ADM cycle and Level 3 as an 18-month objective, with a fortnightly Architecture Review linked to the connections-modernisation programme board.

C220 gives Phase A exactly two objectives: develop a high-level aspirational vision of the capabilities and business value to be delivered, and obtain approval for a Statement of Architecture Work. Everything else the phase does is a step towards those objectives, from establishing the architecture project and confirming stakeholders, drivers, and principles, through evaluating capabilities and assessing readiness for business transformation, to defining measurable value propositions and KPIs, pairing each transformation risk with a mitigation, and securing approval of the work statement. Certification exams test the distinction between the objectives and the steps, so keep the two lists separate.

The two deliverables answer different questions for different audiences. The Architecture Vision explains where the enterprise is heading and why, traceable to concerns and drivers, and its audience is the sponsors who endorse direction. The Statement of Architecture Work is the formal commission, covering scope and explicit exclusions, approach and method, deliverables, roles and resources, schedule and milestones, governance and review arrangements, constraints, assumptions and dependencies, and acceptance criteria. A work statement without exclusions is an implicit promise to cover everything. Phase A also produces a Capability Assessment, an honest picture of what the enterprise can do today against what the change demands, and a Communications Plan naming who is kept informed and through which routine.

Traceability is what holds the pair together. Backwards, every element of the vision connects to a stakeholder concern, a business driver, or a scenario finding. Forwards, every commitment connects to a named deliverable and a review point in later phases. A vision that cannot be traced to evidence is rhetoric, and a work statement that cannot be traced to direction is paperwork. For London the value proposition is measurable rather than asserted: response time from 90 days to the 65-day target, and contradictory publication incidents counted per quarter.

The final module assembles everything the stage produced and holds it to one standard: coherence. A coherent kickoff pack is one where every artefact traces to every other while each adds something the others do not. The scenario adds problem specificity, the principles add decision rules, the stakeholder map adds accountability, and the work statement adds governance and boundaries. Three questions test it. Does every concern in the stakeholder map appear in the scenario, the vision, or the work statement, or get explicitly deferred? Does every principle trace to a tension visible in the scenario or the stakeholder map? Does the work statement's scope align with the vision's direction and the scenario's problem?

The London pack contains six artefacts: the boundary statement, the stakeholder concern map, the principles pack, the business scenario, the Architecture Vision, and the Statement of Architecture Work. They form a chain. The scenario explains why the effort exists, the boundary what the first cycle is responsible for, the map whose concerns must be answered, the principles how trade-offs are governed, the vision the direction of change, and the work statement what is authorised now, roughly 22 weeks of first-cycle work with governance reviews at each phase boundary.

The working test is the one to remember. Someone unfamiliar with the project should be able to trace any single concern from the stakeholder map through the scenario to a principle to the vision to a deliverable in the work statement without the thread breaking. Existence of the documents is not coherence. A pile of well-written artefacts that never reference each other leaves Phase B to inherit confusion, and the most dangerous version looks finished.

The case runs through every module, and each module leaves an artefact behind. Module 8 draws the boundary, internal functions from planning to regulatory affairs inside, Ofgem obligations, NESO interfaces, and contractors at the regulated edge, commercial functions and DSO ambitions deferred. Module 9 maps the stakeholder blocs and their distinct concerns. Module 10 writes the five principles, each answering a named pressure. Module 11 documents the connections scenario, 90 days against a 65-day target with manual re-entry at two of five handoffs. Module 12 scopes the cycle to a three-year horizon prioritising business and data architecture. Module 13 stands up proportionate governance aiming for Level 2 by the end of the first cycle. Module 14 converges it all into the Architecture Vision and the Statement of Architecture Work.

The point of the walkthrough is the connections between the artefacts, not the artefacts themselves. Each principle traces to a tension in the scenario or the stakeholder map, each concern is addressed or explicitly deferred, each scope choice points back to a root cause, and the work statement matches the vision it commissions. That traceability is what the techniques were for, and it is the standard every later stage will assume.