Product and platform operating models for architecture
The operating model is the way an organisation arranges its people, its work, and its decisions to get architecture done. Module 52 in this stage set out the classic model, where architecture is a central function that reviews projects. What follows builds on that and shows how the model changes when an enterprise moves from funding projects to funding long-lived products, and what happens to architecture when it does.
By the end of this module you will be able to:
- Explain the shift from a project operating model to a product operating model in plain language
- Define a product team and a platform team and say what each one owns
- Describe what an internal platform is and why teams build on one
- Place architecture inside product and platform teams as an enabling function
- Explain federated governance and how decision rights are split across the model
- Apply the product and platform model to London Grid Distribution's connections systems
Every connections release needed the central team. The queue, not the code, set the pace.
London Grid Distribution runs the systems that let a housing developer, a data centre, or an electric-vehicle charging operator apply to connect to the network. For years, the software behind those systems was funded and staffed one project at a time. A project would spin up, deliver a change, and disband. The people who understood the connections systems moved on. The next change started almost from scratch.
Because no team owned the connections systems for the long term, the central architecture team became the memory of record. Every release had to pass through it. That team was small and careful, and it did protect the network from unsafe change. But it also became the single lane every change had to queue in. A minor form update and a network-critical data change received the same review slot. Delivery leads learned that the constraint on their pace was not the difficulty of the work but the length of the queue at the centre.
When Ofgem tightened connections-service expectations, the queue became the problem. The enterprise could not move faster by adding people to the central team, because a bigger central team reviews more but still reviews everything. The bottleneck was structural. It was baked into the operating model, not into any one person's workload.
The enterprise did not need a better review process. It needed a different operating model: one where a long-lived team owns the connections product, most decisions are made inside that team within clear rules, and the centre keeps only the decisions that genuinely span the whole enterprise.
If a change is safe, well understood, and inside the rules, why should a central team still have to approve it?
That story is what a project operating model looks like when it runs out of road. What follows explains the model the enterprise moved to, and where architecture sits inside it.
71.1 The classic EA operating model, in one paragraph
Start with the model this stage has already taught, so the contrast is clear. In the classic operating model, architecture is a central function. It sets principles and standards, holds a target architecture, and reviews the projects that deliver change against that target. Module 52 covered this operating model in full, including the seven components an architecture capability needs. This module does not re-teach that content. It takes the classic model as the starting point and shows what changes when the unit of funding and ownership stops being a project.
The classic model has one structural weakness, and the opening story is it. Because delivery is organised as temporary projects, no team owns a system for its whole life. The central function ends up holding the knowledge and the decisions, which turns it into a review queue that every change has to pass through. That works while the volume of change is modest. It stops working when the enterprise needs many teams to move quickly at the same time.
71.2 The shift from project to product
A project operating model funds and staffs a temporary effort to deliver a defined output, then disbands it. A product operating model funds and staffs a long-lived team that owns a product for as long as the product exists, and keeps improving it. The plain difference is time: a project ends, a product team continues. That single change moves ownership, knowledge, and most decisions from a temporary group into a standing one.
In a product model, a productis anything that delivers value to a defined set of users and can be improved over time. London's connections system is a product in this sense: it has users, the developers and operators applying to connect, and it is never finished. A product team is the standing team that owns that product end to end, from the interface a developer uses to the data the change writes into the network model.
The shift from project to product is not a software fashion. It is a response to the bottleneck in the opening story. When a standing team owns the product, the knowledge stays with the team, most decisions can be made inside the team, and the enterprise no longer routes every change through a central queue. The question this module answers is what that does to architecture, which was the central function in the classic model.
The figure below sets the two models side by side and names the three things that move out of the temporary group and into the standing one.
What the shift from project to product actually moves
A project funds a temporary effort and then disbands it, while a product funds a long-lived team that owns the product for as long as it exists, so ownership, knowledge and most decisions move out of the temporary group and into the standing one.
71.3 Platform teams and internal platforms
A product model creates a second question almost immediately. If every product team owns its product end to end, does each team have to build its own identity checks, its own data pipelines, its own deployment tooling, its own monitoring? Doing that once per team is wasteful and, in a regulated utility, dangerous, because each team would solve resilience and security slightly differently. This is what a platform team exists to prevent.
A platform team is a team whose users are other internal teams. It builds and runs a shared capability, an internal platform, that the product teams build on instead of building their own. The internal platform packages the hard, shared work, such as authentication, data access, deployment, and monitoring, and offers it as a self-service product the other teams can consume without asking permission each time.
The key idea is that the platform is itself a product, with the product teams as its users. A good platform team measures its success by how easily product teams can build on the platform, not by how much control it holds over them. A platform that is hard to use, or that forces teams to raise a ticket for every request, has become another version of the central review queue from the opening story, just wearing a different name.
Common misconception
“A platform team is just the old central IT team with a new name.”
The difference is the operating stance. The old central team held control and reviewed what other teams did. A platform team offers a self-service product and is judged on how easily other teams can build on it. If the platform forces teams to queue for permission, it has slipped back into the central-review pattern the product model exists to remove.
An enterprise moves from a project operating model to a product operating model. What is the core change?
A platform team inside a product operating model builds an internal deployment platform. When is that platform team working well?
71.4 Architecture as an enabling function
Now place architecture inside this model. In the classic model, architecture was the central function that reviewed everyone. In a product and platform model, that stance would recreate the bottleneck. So architecture changes shape. It becomes an enabling function: a small central team whose job is to raise the capability of the product and platform teams, not to approve their every decision.
An enabling function works by publishing the guardrails that let teams decide safely for themselves. It sets the principles, the standards, the patterns, and the target architecture, and it makes those things easy to find and easy to follow. It puts an architect inside the product teams and the platform team, close to the work, rather than sitting apart and reviewing from a distance. When a team hits something genuinely new or genuinely cross-enterprise, the enabling function helps, and only then does the decision come to the centre.
The figure below maps where architecture sits. Read it top to bottom. The central enabling function holds the enterprise-level decisions and publishes principles and standards downward. The product teams hold their local design decisions inside those guardrails. The platform teams hold the decisions about the platform itself. The connectors show the two directions of the arrangement: the centre pushes guardrails down, and the teams raise exceptions back up when they meet something the guardrails do not cover.
71.5 Federated governance and split decision rights
The word that names how governance works in this model is federated. Federated governance means decision rights are deliberately split across levels, with a small set of decisions held at the centre and the rest delegated to the teams, inside published boundaries. It is the middle path between two failures: one central body deciding everything, which is the opening-story bottleneck, and every team deciding everything alone, which produces cross-enterprise divergence nobody can govern.
Federated governance rests on the same idea Module 53 introduced as: the explicit assignment of authority to decide specific kinds of question. In a product and platform model, the split usually runs like this.
- The centre holds enterprise-level decisions. Principles, standards, the target architecture, cross-team integration contracts, and anything that would create divergence or regulatory exposure if teams decided it differently. These cannot be delegated.
- Product teams hold local product decisions. How their product is designed and built, inside the published guardrails. No escalation is needed unless a decision falls outside those guardrails.
- Platform teams hold local platform decisions. How the internal platform is built and operated, again inside the guardrails, because the platform is their product.
The power of federation is predictability. A product team can tell, before it starts, whether a decision is theirs to make or the centre's. That predictability is what lets many teams move quickly at once without the enterprise losing coherence, which is the thing the classic central-review model could not deliver at scale.
Common misconception
“Federated governance means the central architecture team has given up control.”
Federation is not the absence of central authority. The centre still holds the enterprise-level decisions that cannot be delegated, and still publishes the guardrails every team works inside. What changes is that the centre stops deciding the things teams can safely decide for themselves. Holding fewer decisions, but the right ones, is a stronger position than reviewing everything and deciding little.
London Grid Distribution: moving connections to a product model
London Grid Distribution is a distribution network operator for Greater London, serving 2.3 million customers across 36,000 km of cable and 77 primary substations, regulated by Ofgem under RIIO-ED2. Its 4,000 staff run a network that must let new connections happen quickly and safely. The connections systems in the opening story are where the enterprise chose to move first, because that is where the project-model bottleneck hurt most.
The connections product team
The enterprise stood up a standing team that owns the connections product end to end: the interface a developer or charging operator uses to apply, the workflow that assesses the request, and the data the outcome writes into the network model. The team includes an architect, so architecture decisions happen inside the team, next to the work, rather than in a central queue. The team keeps improving the product instead of disbanding when a release ships.
The platform the team builds on
A platform team runs an internal platform that packages the shared, regulated work: identity and access, the approved way to read and write network-model data, deployment, and monitoring. The connections team builds on that platform on a self-service basis, so it inherits the enterprise's security and resilience posture by default rather than re-inventing it. That default is what makes the model safe in a regulated context: a product team cannot quietly diverge on the things Ofgem cares about, because the platform is the path of least resistance.
Federated decision rights
- The centre decides: the principles and standards, the target architecture for connections, the data contract with the network model, and anything affecting the ED3 business plan or a regulatory commitment.
- The connections product team decides: how the connections product is designed and built inside those guardrails, without escalation, unless a decision crosses a guardrail.
- The platform team decides: how the internal platform is built and run, inside the guardrails, because the platform is its product.
What changed
The queue at the centre shrank because the centre stopped holding decisions the connections team could safely make itself. The network stayed protected because the platform carried the security and data guardrails by default, and the centre still owned the data contract with the network model. The enabling architecture function measured itself by how rarely the connections team needed to escalate, which is the opposite of the old model, where a busy central team was mistaken for a healthy one.
London moves its connections systems to a product model. Why does the platform team carry identity, data access, and deployment as a self-service platform rather than letting each product team build its own?
In London's federated model, who decides the data contract between the connections product and the network model, and why?
Core distinctions
- A project operating model funds temporary efforts that disband; a product operating model funds long-lived teams that own a product and keep improving it.
- A platform team builds an internal platform, a self-service product for other teams, so product teams inherit shared, regulated capabilities instead of rebuilding them.
- In a product model, architecture becomes an enabling function: a small central team that publishes guardrails and sits inside teams, rather than a review queue everything passes through.
- Federated governance splits decision rights: the centre holds enterprise-level decisions that cannot be delegated, and teams decide locally inside the published guardrails.
- London moved its connections systems to a product model, with a connections product team building on an internal platform and the centre keeping the data contract and regulatory decisions.
Standards and sources cited in this module
The TOGAF Standard, 10th Edition (C220)
EA Capability and Governance: Architecture Governance and organisational placement
The core standard for architecture governance and how the capability is placed in the organisation, which federated governance splits across levels.
G184, The TOGAF Leader's Guide to Establishing and Evolving an EA Capability
Operating models and organisational placement
The primary TOGAF source for architecture operating models, taught in Module 52 and used here as the classic-model baseline rather than re-taught.
Skelton, M. and Pais, M., Team Topologies: Organizing Business and Technology Teams for Fast Flow
Platform teams and enabling teams
The primary source for the platform-team, internal-platform, and enabling-team patterns that this module applies to architecture.
Module 71 of 72 · EA Capability and Governance