Hub-and-spoke architecture
Hub-and-spoke architecture
Ask any CMDB practitioner what kills asset databases and you will hear the same answer: duplication. Five schemas, five copies of the same people, five places where "who owns this server?" can have five different answers.
LaunchPad's service models are built to avoid exactly that. The catalogue is organised as a hub and spokes. One schema, Core, holds the master data that every other domain needs. Every other schema is a spoke: it covers its own domain in depth and reaches back to the hub for the things that should only exist once.
One hub for master data
The Core schema is the hub. It deliberately stays small: eight object types, each one a thing your whole organisation agrees on.
| Object type | What it holds |
|---|---|
| Person | The people in your organisation, with their team, status, and contact details |
| Team | The teams that own and support things, including escalation paths |
| Vendor | The suppliers you buy from and depend on |
| Location | Offices, data centres, and remote sites, with tier and compliance details |
| Department | Your organisational units |
| Cost Center | Where the money is accounted for |
| Application | The software portfolio your organisation runs |
| Business Service | The services your organisation provides and supports |
None of these belongs to a single operational domain. Security needs people. Vendor management needs cost centers. Cloud operations need teams. That is precisely why they live in the hub rather than being copied into every schema that wants them.
The full attribute detail is in the Core schema reference.
Spokes reference the hub
Every other service model is a spoke. A spoke models its own domain in full, and wherever it needs a person, a team, a vendor, or any other piece of master data, its template declares a cross-schema reference to the matching Core object type.
A few examples from the current catalogue:
- Cybersecurity's Security Asset has an Owner that points to Person in Core, and an Owning Team that points to Team in Core.
- Vendor Management's Contract has an Owner pointing to Person, and Spend records point to Cost Center.
- Cloud Native Infrastructure's Cloud Account is owned by a Team and funded by a Cost Center, both in Core.
The result is one record per person, one per vendor, one per location, referenced from every domain that cares about it. Update a person's status once and every spoke sees the change, because every spoke is looking at the same object.
Earlier template versions shipped local copies of these types instead. Standard CMDB, for instance, used to carry its own Person, Team, Vendor, and Location types. Current versions drop those copies and reference Core, which is why the templates are leaner than they used to be.
Deploy schemas on top of each other
The architecture is not just a diagram. It is how deployment actually works. You deploy schemas on top of each other: Core first, then whichever spokes your organisation needs, in any order, at any pace.
When you deploy a spoke and Core is already installed, the deployment wizard offers to link each external reference to your existing Core schema. Choose that, and the spoke arrives already wired into your master data.
No Core yet? Spokes still work standalone. The wizard can create local copies of the Core types a spoke needs, so nothing blocks a first deployment. The three reference modes page explains each option and when to pick it.
This is also what makes the catalogue composable rather than monolithic. You are not choosing between thirteen disconnected databases. You are choosing which domains to stack onto a shared foundation.
Categories describe behaviour, not pricing
The catalogue groups service models into five categories: Foundation, Operational, Specialised, Enterprise, and Governance. These are architectural roles in the hub-and-spoke model, not pricing levels. Pricing is per object across the whole product, so a category badge never changes what you pay.
| Category | Role in the architecture | Service models |
|---|---|---|
| Foundation | Hubs and starting points: where master data lives | Basic CMDB, Core Schema, Standard CMDB, Workforce Management |
| Operational | Day-to-day service operations layered on the foundation | Service Catalogue, Priority Matrix, SLA Management |
| Specialised | Deep coverage of a single technical domain | Cloud Native Infrastructure, Cybersecurity, Software Asset Management |
| Enterprise | Broad models for complex estates | Enterprise IT CMDB, Vendor Management |
| Governance | Oversight of the system itself | Documentation Management |
Foundation is worth a closer look. Core is the canonical hub, but it is not the only sanctioned starting point. Basic CMDB is the smallest possible entry, Standard CMDB is the general-purpose CMDB most teams begin with, and Workforce Management acts as an alternate people hub for organisations whose master data starts with HR rather than IT.
What this means for your rollout
Three practical consequences fall out of the architecture:
- Install Core early if you can. Every spoke gets more valuable when its references resolve to real shared objects instead of local copies or text.
- You do not have to. Each spoke stands alone when it must. The architecture rewards the hub, it does not require it on day one.
- Growth is additive. Adding a domain later means deploying another spoke against the hub you already have, not migrating what exists. The Expand flow applies the same logic to schemas already in production.
Where to next
- The three reference modes: the choice you make for each external reference at deploy time.
- Cross-schema sharing: the Assets setting that makes hub references work, and how LaunchPad manages it for you.
- Which schema should I choose?: pick your starting point.
- Core schema reference: the hub in full detail.