Scale Through Federation

C21.1 — Draw an ownership map, not an org chart

An org chart shows reporting relationships. Federation needs a different record.

For every policy, Factory Asset, Work Center, evidence service, scarce specialist capability, and line outcome, name:

• who defines it;
• who funds it;
• who operates it;
• who consumes it;
• who assures it;
• who can change or deprecate it;
• who can approve an exception;
• who carries the consequence of failure; and
• who can leave.

The same party need not own every decision.

A central group may own a security control specification while a shared capability team owns the control implementation and each Production Line remains accountable for operating its service safely. A community may maintain guidance while no community member holds approval authority. A line may consume a shared deployment service without transferring responsibility for the release decision.

This separation matters because “the platform owns it” can hide several incompatible meanings. It can mean the platform defines an interface, operates a service, pays a bill, accepts risk, or decides what another team may do. Those are different rights.

Parnas's modularity argument supports concealing change behind stable decisions and interfaces.C21-A01 Cataldo and colleagues show that technical dependencies create coordination requirements that work structures and communication must address.C21-A02 Neither source prescribes a federated enterprise. Together they justify a narrower rule: dependency and change should determine the interface and coordination record, not proximity on an org chart.

Chapter 18 owns formal governance design. Chapter 21 applies that discipline to the move from one line to many.

Stable interfaces are negotiated boundaries

An interface is more than an API.

It includes:

• the capability offered;
• eligible consumers and supported use cases;
• data and identity obligations;
• service and recovery expectations;
• version and compatibility policy;
• evidence available to consumers;
• support and escalation paths;
• change notice;
• migration and retirement; and
• the conditions under which a consumer can operate differently.

Boundary resources can let independent actors participate while an infrastructure owner retains control. Eaton and colleagues' study of Apple's iOS ecosystem found that those resources evolved through distributed accommodations and rejections, and that power had a dual role in the process.C21-A03 Engert and colleagues found mandated, supported, and autonomous modes of self-organization in two enterprise software platform ecosystems, each with a different tension between owner control and complementor autonomy.C21-A04

These are external platform ecosystems, not internal Production Lines. Their useful warning is that an interface encodes power. The owner decides what becomes easy, possible, costly, reviewable, or forbidden. Consumers therefore need more than documentation. They need a visible path to influence the roadmap, challenge a non-fit, observe service evidence, and exit.

“Stable” does not mean frozen. It means that change is versioned, communicated, evidence-bearing, and bounded by explicit compatibility and migration responsibilities.

C21.2 — Operate shared capability as a service

A shared capability is not shared because a central team built it. It is shared when consumers can obtain and use it through a credible service relationship.

The service record should include:

1. consumers and problems served;
2. scope and exclusions;
3. interface and access route;
4. service, recovery, security, privacy, and accessibility expectations;
5. support and escalation;
6. roadmap and prioritization method;
7. funding, price, or chargeback;
8. current performance, demand, incidents, and consumer evidence;
9. integration and migration obligations;
10. exception and local-capability routes; and
11. retirement, switching, and exit.

The CNCF Platforms White Paper recommends treating an internal platform as a product shaped with users. It emphasizes self-service, optional and composable capabilities, user research, feedback, observable cost, and the risk of resistance when adoption relies on mandate.C21-R01 This is practitioner guidance, not proof that the pattern produces value.

GOV.UK provides a public operating example. Its Digital Service Platform offers Forms, Pay, Notify, and a Prototype Kit as separately consumable capabilities rather than an all-or-nothing bundle.C21-R02 At the July 2026 evidence freeze, Notify's live page reported 13.1 billion messages since May 2016, 1,754 organizations, and 12,480 services.C21-R03 Those numbers demonstrate use and operational volume. They do not establish consumer outcomes, comparative delivery improvement, or total cost.

Adoption is demand evidence. It is not a verdict.

C21.3 — Choose what to share with a decision record

The choice is not “centralize or decentralize.” At least four routes may be legitimate:

• central — one owner defines and operates the capability;
• federated — common policy and interfaces with several coordinated operators;
• distributed — multiple owners interoperate through agreed contracts;
• local — a line owns the capability within declared boundaries.

Compare the routes using prompts, not a composite score:

Commonality

How similar is the demand across lines? A capability used in superficially similar workflows may still carry different user, language, data, latency, accessibility, or legal obligations.

Consequence

Would inconsistent implementation create material harm, rights impact, security exposure, financial loss, or loss of interoperability? High consequence may justify stronger shared coherence without requiring one operating team.

Scarcity

Is expertise genuinely scarce, or merely concentrated by prior organization design? Centralizing scarce capability can protect quality, but it can also create a queue and prevent learning elsewhere.

Context and regulation

Which regional, sector, contractual, supplier, data-residency, workforce, and operational conditions change the answer?

Interoperability

What must remain compatible across lines, and what can vary without transferring integration burden to users or neighboring services?

Queue and service cost

Include central operating cost, consumer waiting, integration, migration, local adaptation, support, incident coordination, lock-in, switching, and exit. A low unit price can coexist with high consumer burden.

Reversibility and evidence

Can the organization change route? Is the evidence strong enough for a mandate, or only for an optional offer and another test?

The result is a reasoned allocation with owners, assumptions, dissent, review dates, and disconfirming evidence. It is not a mathematically optimized topology.

A common standard can have contextual assurance

Federation does not require identical review everywhere.

GOV.UK's service-assessment guidance routes high-volume or cross-organization services to cross-government panels and other services to departmental panels. It describes lighter assurance for lower-volume forms using an assured platform, voluntary assessment, local-government peer review, and contextual adaptation of the Service Standard.C21-R04

The thresholds are policy choices, not proven causal boundaries. The transferable mechanism is explicit routing:

• shared criteria remain visible;
• the review owner changes with scope and consequence;
• an assured shared capability can reduce duplicate review;
• local risk can still trigger additional assurance; and
• adaptation must preserve evidence about the user and service.

An exception record should state:

• the standard path and the non-fit;
• affected people and obligations;
• local decision and risk owners;
• equivalent controls or the accepted difference;
• evidence and monitoring;
• dependencies and interoperability impact;
• review or expiry date; and
• return, replacement, or retirement path.

An exception is not a favor from the center. It is a governed decision whose consequences remain visible.

C21.4 — Treat shared-service failure as federation evidence

The strongest evidence in this chapter is counter-evidence.

The UK National Audit Office's 2026 review examined five government shared-service clusters. It reported improved governance and planning, but found no central owner with a clear mandate to secure onboarding, no sufficiently strong technical lead, inconsistent ERP configurations and data convergence, fragmented governance of interdependencies, and risks to interoperability, time, budget, benefits, and cost.C21-R05

HM Treasury had cumulatively committed £1.15 billion to three centrally funded clusters, including £846 million for the 2026–29 spending-review period.C21-R05 The number demonstrates material commitment, not value delivered. The audit's lesson is not “centralize more” or “let every department opt out.” It is that cluster autonomy, common standards, onboarding authority, technical coherence, interdependencies, funding, and outcome evidence must be designed together.

The U.S. GAO's 2026 review supplies a separate comparison across four federal shared-service areas. Among the selected agencies, officials identified operational and legal fit, legacy technology, implementation complexity, resource pressure, opaque pricing, inconsistent service-level information, and lock-in concerns.C21-R06 Seventeen customer agencies from seven agencies had discontinued a cybersecurity shared service; other records described a provider switch and insourcing. Four of eight selected agencies said they lacked information needed for clear provider decisions, particularly about pricing and lock-in.

All eight selected agencies reported savings, but GAO could not verify the claims because comprehensive baseline and cost data were absent.C21-R06 That is precisely the evidence boundary a federation programme must preserve.

GAO's earlier DOD portfolio review found inconsistent use of required metrics among software-developing programmes and gaps in performance reporting.C21-R07 Shared policy without comparable evidence can create the appearance of coherence while leaving leaders unable to judge the system.

These public programmes are not Software Manufacturing federations. They show why ownership, adoption, interface, service, cost, local fit, and exit cannot be treated as implementation detail.

Communities connect learning; they do not own decisions by implication

Communities of practice can carry patterns, review experience, incident learning, migration knowledge, and local concerns across lines. They can reveal when several “exceptions” point to a defective standard.

But a community can also become hidden governance:

• attendance becomes access;
• consensus substitutes for accountable decision;
• the loudest or best-funded region defines “common”;
• unpaid maintainers carry shared work;
• disagreement disappears from the record; and
• advice becomes mandatory without appeal.

For every community, state its purpose, membership, stewardship, decision rights, funded work, artifacts, and escalation path. If it has no authority, say so. If it maintains a standard or asset, name the accountable owner and the consumer route for change.

Community activity is not evidence of organizational learning. Preserve what changed, for whom, on what evidence, and with what consequence.

C21.5 — Scale the evidence system with the factory

Federation increases the number of places where success can be declared without being demonstrated.

A scale review should examine:

• line outcomes and harms;
• shared-service performance and incidents;
• consumer satisfaction, burden, waiting, and workarounds;
• adoption, retention, rejection, and exit;
• central and local cost;
• integration and migration;
• exceptions, expiry, and return;
• regional and affected-group distribution;
• maintainer and specialist load;
• dependencies and common failure modes; and
• missing, conflicting, and disconfirming evidence.

Do not average these into a federation score.

The decision may be to expand a shared offer, split a service, add another operator, narrow a mandate, fund local capability, redesign an interface, retire a common asset, or stop further federation. A local implementation that outperforms a shared service may be evidence for improvement, not disloyalty. A shared service with high adoption but rising consumer burden may be a constraint, not a success.

Federation remains provisional. Its topology should change when demand, evidence, technology, law, workforce, or organizational boundaries change.