Sponsorship, governance, and capability kickoff

Many architecture efforts begin with executive enthusiasm and die at the first delivery conflict. The usual cause is weak sponsorship. Someone has said yes to architecture in principle, but nobody is prepared to back its consequences in practice. TOGAF Series Guide G184 addresses this directly. It distinguishes between an organisation that has approved an architecture function and one that has established an architecture capability with real authority behind it.

The distinction matters because architecture produces conclusions that are sometimes uncomfortable. A target-state design might require a programme to change its platform choice. A data-authority model might expose that two departments are publishing contradictory figures. A principle might block a convenient shortcut. If the architecture team has no mechanism to bring those conclusions into delivery decisions, the conclusions will be ignored and the architecture function becomes a documentation exercise.

Real sponsorship provides three things that passive endorsement does not. First, access: the architecture team must be able to reach the people, evidence, and decision forums it needs. Second, authority: architecture conclusions must have a defined path into delivery governance, not merely an advisory channel. Third, conflict-resolution support: when architecture and delivery disagree, there must be an escalation mechanism that does not simply default to whoever has the larger budget.

G184 makes a further point that is easy to miss. Sponsorship is not a one-time announcement. It is a continuing commitment. The sponsor must remain actively engaged as the architecture capability encounters resistance, as scope is challenged, and as the first real trade-off decisions arrive. A sponsor who endorsed the capability in January but is unavailable in March has not provided sponsorship. They have provided a press release.

G184 describes the establishment of an EA capability as something that must be planned and governed, not assumed to emerge. The guide identifies several components that together constitute a functioning architecture capability. Understanding each one is important because organisations that skip components almost always discover the gap at the worst possible moment: during a contested decision.

1. Sponsorship and mandate. The capability must have a named executive sponsor who provides continuing authority, access to enterprise decision forums, and political backing. The sponsor is accountable for ensuring that architecture conclusions have a path into delivery governance. Without this, the capability is advisory at best.

2. Operating model. The architecture capability needs a defined way of working: how architecture work is initiated, how it is reviewed, how conclusions are communicated, and how exceptions are handled. The operating model does not need to be elaborate at kickoff, but it must exist. G184 recommends starting with a minimum viable operating model and maturing it as the capability proves its value.

3. Roles and skills. G184 (complemented by G249, Architecture Roles and Skills) identifies the roles that an architecture capability needs. At a minimum, the kickoff must establish who leads the architecture work, who governs it, and who maintains the evidence base. Additional roles (domain architects, security architects, data architects) can be added as the capability matures, but the core accountability roles must exist from the start.

4. Governance structure. Architecture conclusions must be reviewed and either accepted, modified, or rejected through a defined process. G184 recommends establishing at least one governance forum (which may be a lightweight Architecture Board or review body) with explicit terms of reference. The forum must have the authority to record decisions, grant exceptions, and escalate disputes.

5. Repository and evidence discipline. The architecture capability needs a defined repository where artefacts, deliverables, decisions, and evidence are stored and maintained. G184 treats the repository as part of the operating model, not as an optional document store. Without it, architecture work is not reusable and cannot be audited.

6. Maturity assessment and evolution plan. The capability should be assessed against a maturity model (G184 provides one, as does G203) so that the organisation understands where it is starting from and what it is aiming towards. The evolution plan sets realistic milestones for capability growth rather than demanding full maturity on day one.

The critical insight from G184 is that all six components are interdependent. A strong sponsor without a governance structure has no mechanism to use their authority. A mature governance structure without a repository has nothing to govern against. A repository without defined roles has no one accountable for its quality. The capability works as a system, not as a collection of independent parts.

G184 (supported by the more detailed G203, Architecture Maturity Models) defines a maturity model that helps organisations understand where their architecture capability sits today and what it would take to reach the next level. The model uses five levels. Each level builds on the previous one and addresses a specific set of weaknesses. Understanding all five is important because many organisations are told to "improve maturity" without being told what that actually means in operational terms.

Level 0: None. No architecture capability exists. Architecture decisions are made ad hoc by whoever has the most influence at the time. There is no repository, no governance, and no defined roles. Decisions are not recorded in any structured way and cannot be traced or audited. This is the starting point for most organisations before they begin any formal architecture work. The main risk at this level is inconsistency: every programme makes its own design choices without reference to any shared direction, leading to duplication, incompatibility, and wasted investment.

Level 1: Initial. Some architecture work is happening, but it is informal, inconsistent, and dependent on individual initiative. An architect may produce useful work, but the outputs are not governed, not stored in a shared repository, and not referenced by delivery programmes as a matter of course. The key characteristic of Level 1 is that architecture outputs exist but have no defined path into delivery decisions. If the individual architect leaves, the capability effectively disappears. The main risk at this level is fragility: the architecture function depends on specific people rather than on institutional structures.

Level 2: Under development. The organisation has recognised the need for architecture capability and has begun to establish it. Basic roles are defined, a governance forum is forming, and some architecture standards are documented. However, the capability is not yet consistent across the organisation. Some programmes reference architecture outputs; others do not. Governance exists on paper but is not yet enforced. The repository is partially populated. The key characteristic of Level 2 is that the structures are in place but not yet habitual. The main risk is that the capability can be bypassed when it is inconvenient, because enforcement mechanisms are weak.

Level 3: Defined. The architecture capability has a documented operating model, established roles, a functioning governance forum, and a maintained repository. Architecture outputs are referenced by delivery programmes as standard practice. Exceptions are recorded and managed through the waiver process. Compliance reviews happen at defined checkpoints. The key characteristic of Level 3 is consistency: the architecture capability operates the same way regardless of which architect or programme is involved. The main risk at this level is complacency. The structures work, but the organisation may stop investing in capability improvement because things seem to be running smoothly.

Level 4: Managed. The architecture capability is measured, monitored, and continuously improved. Metrics exist for architecture coverage, compliance rates, reuse of building blocks, and the time taken to produce and review architecture outputs. The governance forum uses data to identify weaknesses and allocate improvement effort. The repository is actively curated. Architecture is embedded in enterprise planning and investment decision-making, not treated as a separate discipline. The key characteristic of Level 4 is that the organisation can demonstrate the value of architecture through evidence rather than assertion. Few organisations reach Level 4 consistently across all domains, and maintaining it requires ongoing executive attention.

Level 5: Optimising. The architecture capability is fully integrated into the organisation's operating model and continuously adapts to changing business needs. Architecture methods, tools, and governance are regularly reviewed and updated. The capability proactively identifies architecture issues before they become delivery problems. Innovation in architecture practice is encouraged and measured. Level 5 is aspirational for most organisations and represents a state where architecture is so embedded in the culture that it influences every significant enterprise decision automatically.

The maturity model is not a league table. Reaching a higher level is not automatically better if the organisation does not need that level of capability for its current challenges. A small organisation with a single architecture programme may be well served at Level 2 or 3. A large regulated enterprise with multiple concurrent programmes and cross-domain dependencies will need Level 3 as a minimum and should be working toward Level 4.

G184 identifies specific requirements for effective architecture sponsorship. Each one addresses a failure mode that is common enough to deserve explicit attention.

Requirement 1: Named accountability. The sponsor must be a named individual, not a committee or a role title that rotates. Architecture needs a single point of accountability that delivery teams can identify and that the architecture team can rely on. When sponsorship sits with a committee, contested decisions are deferred rather than resolved.

Requirement 2: Decision-forum access. The sponsor must ensure the architecture team has access to the forums where enterprise-level decisions are made. This includes investment boards, programme steering groups, and executive committees where platform choices, budget allocations, and strategic direction are settled. Architecture that cannot reach these forums cannot influence outcomes.

Requirement 3: Escalation authority. There must be a defined escalation path for situations where architecture conclusions conflict with delivery preferences. The sponsor must be prepared to convene resolution discussions rather than allowing delivery to overrule architecture by default. This does not mean architecture always wins. It means the dispute is resolved through a governed process rather than through informal power dynamics.

Requirement 4: Resource commitment. The sponsor must secure the resources (people, tools, time) that the architecture capability needs. This includes not only the architecture team itself but also the time of subject-matter experts, stakeholders, and governance participants. Architecture work that depends on borrowed time from people whose primary accountability lies elsewhere will always be deprioritised when delivery pressure increases.

Requirement 5: Visible endorsement. The sponsor must be visibly associated with the architecture capability in enterprise communications. This is not about marketing. It is about signalling to the rest of the organisation that architecture conclusions carry executive backing. When delivery teams see that the sponsor is engaged, they are more likely to treat architecture outputs as inputs to their own decisions rather than as optional advice.

Requirement 6: Continuing engagement. Sponsorship is not a one-time event. The sponsor must remain engaged as the capability encounters its first real challenges: scope disputes, principle exceptions, evidence gaps, and delivery conflicts. A sponsor who launches the capability and then disengages has provided a press release, not sponsorship.

When any of these requirements is absent, the architecture capability develops a characteristic weakness. Without named accountability, decisions are deferred. Without forum access, architecture is invisible to decision-makers. Without escalation authority, delivery overrules architecture by default. Without resource commitment, architecture work is always deprioritised. Without visible endorsement, the wider organisation treats architecture as optional. Without continuing engagement, the capability erodes at the first sign of friction.

The Preliminary Phase should establish enough structure for architecture work to begin credibly. That does not mean recreating a mature architecture office in week one. It means establishing the minimum set of roles and governance paths that allow the work to be trusted, reviewed, and reused.

Sponsor. Provides mandate, backing, escalation path, and access to enterprise decision forums. The sponsor must be senior enough to convene the right people and to back architecture conclusions when they create friction. In most organisations this means a director-level or C-suite executive who sits on the investment board or programme steering group.

Lead architect. Frames the work, manages coherence across artefacts, and protects the method from drifting into disconnected deliverables. The lead architect is accountable for the quality, consistency, and traceability of the architecture pack. They are the primary interface between the architecture team and the governance forum.

Architecture decision forum. Reviews proposals, records exceptions, and links architecture conclusions to delivery or governance action. At kickoff this may be a lightweight review body rather than a formal Architecture Board. The key requirement is that the forum has explicit authority to accept, modify, or reject architecture proposals, and that its decisions are recorded and traceable.

Repository steward. Maintains the evidence base, source discipline, and traceability of architecture assets in the repository. This role is often underestimated. Without a steward, the repository degrades into a document dump where nothing can be found, nothing is current, and nothing is trustworthy. The steward ensures that artefacts are versioned, that decisions are linked to evidence, and that the repository supports rather than hinders governance.

Domain leads (deferred). Specific domain architects (business, data, application, technology, security) can be added as the capability matures and as the ADM cycle moves into Phases B, C, and D. At kickoff, it is more important that the core accountability structure works than that every domain has a named lead.

The governance kickoff is the point at which the architecture capability moves from intention to operation. The following questions must be answered before the first Architecture Vision work begins, because every answer shapes how Phase A and later phases will be governed.

1. Who sponsors the work and what decision rights sit behind that sponsorship? The sponsor must be named, the decision rights must be explicit, and the escalation path must be documented. A sponsorship statement that says "the CTO endorses the architecture programme" without specifying what that endorsement authorises is not sufficient.
2. How will architecture conclusions be reviewed, accepted, or challenged? There must be at least one governance forum with explicit authority. The terms of reference should specify who participates, how often the forum meets, what decisions it can make, and how disputes are escalated.
3. Where does the working repository live and who is responsible for keeping it trustworthy? The repository location, access controls, versioning policy, and stewardship accountability must be defined. An architecture repository that no one maintains is worse than no repository at all, because it creates a false sense of evidence.
4. Which roles are mandatory now and which can mature later without breaking the work? The kickoff must distinguish between roles that are essential immediately (sponsor, lead architect, repository steward, at least one governance participant) and roles that can be added as the capability grows (domain architects, compliance reviewers, portfolio coordinators).
5. How will the architecture capability interact with existing delivery governance? Architecture governance must connect to programme and project governance. If these are separate with no touchpoints, architecture will be bypassed whenever delivery pressure increases.
6. What is the initial maturity target and how will progress be measured? The kickoff should include an honest assessment of current maturity (usually Level 0 or Level 1) and a realistic target for the end of the first ADM cycle (usually Level 2 or early Level 3).

Early capability work should be sized to the actual enterprise problem. The goal is not to recreate a fully mature enterprise architecture office in week one. The goal is to establish enough structure that architecture judgements can be trusted, reviewed, and reused. G184 is explicit about this: the operating model should be proportionate and should evolve as the capability proves its value.

That means simple governance is often better than ornamental governance. One credible forum with explicit authority is stronger than several committees with vague purpose. One well-maintained repository is more valuable than five document stores that no one trusts. One named sponsor with real decision rights is more useful than a governance charter signed by twelve executives who never attend the review meetings.

The opposite failure is equally dangerous. When teams fear bureaucracy, they sometimes remove every governance control. That usually leaves architecture unable to influence delivery at all. The answer is not no governance. It is proportionate governance with real authority behind it.

A practical test: after the kickoff, can the architecture team explain in one paragraph who sponsors them, where their work is stored, how it is reviewed, and what happens when their conclusions conflict with a delivery decision? If they cannot, the kickoff has not established enough structure. If that paragraph takes two pages, the kickoff has established too much.

The London case cuts across planning, operations, cyber, telecoms, data governance, regulatory interfaces, and delivery. That means the sponsor must be able to convene and back decisions across those boundaries. Passive endorsement from one function would not be enough. In London Grid's case, the sponsor would need to be at director level or above, with authority that spans the operational, IT, and regulatory governance structures.

Current maturity assessment. London Grid is starting from approximately Level 0 to Level 1. Some architecture-like work has been done in individual programmes (network planning models, data-quality initiatives, cyber-risk assessments), but there is no shared repository, no governance forum, and no defined path for architecture conclusions to reach delivery decisions. The ad hoc work is useful but fragile and not reusable.

Realistic target. By the end of the first ADM cycle, London Grid should aim for Level 2, with the structures in place and the first evidence of consistent use across at least the connections-modernisation programme. Level 3 (consistent operation across all programmes) is a reasonable 18-month target once the first cycle has demonstrated value.

The kickoff checklist for London Grid:

• Sponsor: A director-level executive with authority across operations, IT, and regulatory governance. Named, with documented decision rights and an explicit escalation commitment.
• Lead architect: One named individual accountable for the coherence and quality of the architecture pack. This person manages traceability between the business scenario, the principles, the scope statement, and the forthcoming Statement of Architecture Work.
• Governance forum: A lightweight Architecture Review that meets fortnightly during the first cycle. Participants include the sponsor (or delegate), the lead architect, the repository steward, and rotating domain representatives from operations, cyber, data, and regulatory affairs.
• Repository: A single, version-controlled evidence base. The steward ensures that every artefact is traceable to a decision, every decision is linked to a governance review, and every principle exception is recorded with its rationale.
• Delivery integration: The architecture governance forum is linked to the connections-modernisation programme board. Architecture conclusions are a standing agenda item at programme steering meetings, not an occasional input.
• Maturity target: Level 2 by end of first cycle. Level 3 as an 18-month objective.

This is proportionate governance. It does not create a large bureaucracy. It establishes enough structure that the architecture pack produced in Modules 8 through 14 can be reviewed, challenged, stored, and used as a foundation for Phase B. If the kickoff cannot survive the first contested decision about where data authority sits or which platform the connections portal should use, the governance is too weak. If the kickoff requires six months of committee formation before any architecture work begins, the governance is too heavy.