Skip to main content

The Federation Layer Concept

What Is It?​

A federation layer is not a shared library, not a monorepo, and not a microservices registry. It is a governance + capability boundary that sits between an enterprise's strategic center and its distributed delivery units (projects, BUs, squads, client teams).

It answers one question: Who owns what, and under what rules does everyone else consume it?

Why "Federation" and Not "Platform"​

The word "platform" implies a technical substrate. Federation implies sovereignty with constraints — project teams retain autonomy over their own domain, but must federate with the core on defined contact points.

Think of it like the EU model: member states (project teams) govern themselves, but monetary policy (e.g., security standards, data contracts, auth protocols) is federal.

Two Dimensions of the Federation Layer​

1. Technical Federation​

  • Shared infrastructure components (auth, logging, observability, CI/CD pipelines)
  • Common data models and contracts (APIs, schemas, event formats)
  • Approved technology standards (language versions, framework choices, cloud provider)
  • Reusable application-layer modules (not just infra — could be business logic fragments)

2. Non-Technical / Process Federation​

  • Governance policies (who can approve what, change management)
  • Inner-source contribution rules (how project teams contribute back to core)
  • Security and compliance mandates (non-negotiable, enforced by core)
  • Versioning and deprecation contracts (core cannot break consumers without notice)

The Key Insight: It Must Support EXISTING Systems​

A common mistake is designing the federation layer only for greenfield projects. In practice, enterprises have:

  • Legacy systems that cannot be re-platformed
  • Client-mandated tech stacks that don't fit the core's model
  • Projects mid-flight that need an on-ramp, not a rebuild

A real federation layer has adapters and incremental adoption paths, not just a clean API for new projects.

Mental Model: Three Rings​

[ CORE / FEDERATION LAYER ]        ← Owned by the central platform team
        |
[ SHARED DOMAIN MODULES ]          ← Owned by domain teams, governed by core rules
        |
[ PROJECT / DELIVERY TEAMS ]       ← Fully autonomous within their boundary

Each ring has defined rules about what flows inward (contributions) and what flows outward (consumption).

What Makes This Hard​

  1. Ownership ambiguity — "who maintains this?" becomes a political question, not a technical one
  2. Speed mismatch — core evolves slowly (stability > velocity); project teams move fast
  3. Trust gap — project teams distrust anything they didn't build; core teams distrust project team contributions
  4. The boomerang problem — core builds something, no one adopts it, it gets rebuilt 12 times in 12 projects

Core Thesis​

The federation layer only works if it is treated as a product — with its own roadmap, SLA, versioning contract, and customers (the project teams). The moment it is treated as a shared folder or an IT mandate, it fails.