DGM · Technical Architecture
Shared Database Platform in CSDM
A shared PostgreSQL platform in CSDM 5: one Technology Management Service Offering, two Application Services on one cluster, one of them outside the offering.


This is the Modeler's own “Shared Database Platform” example, laid out for the page and exported from the same code that draws the canvas in Blueprint Modeler, so every element and relationship is one the CSDM 5 metamodel allows. It is the platform-team view: a database team offers PostgreSQL to the rest of the company, and two application teams build on it, one of them officially.
Reading it top to bottom
Business and design layers. The capability “Data management” is provided by two Business Applications, “Inventory” and “Reporting.” Each uses one Application Service, “Inventory — production” and “Reporting — production.” Nothing unusual so far; the interesting part is what the two services share.
Service layer, platform side. The database team is a Technology Management Service, “Database hosting,” with the offering “PostgreSQL — production.” That offering contains Inventory — production. It does not contain Reporting — production, and the Modeler raises a hint for a service with no offering above it. That gap is the example's lesson: Reporting consumes the platform without being in the platform's contract, so the database team's maintenance calendar has no reason to mention it.
Functional and infrastructure layers. Both services depend on one Application CI, the “PostgreSQL cluster,” which runs on pg-node-01 and pg-node-02. Inventory — production also depends on the “Data-center network,” a Network CI, which is the kind of dependency teams forget until the switch firmware changes.
What the shape buys you
- Shared risk made visible. If pg-node-01 fails, the walk reaches the cluster, then both production services, then the offering and both applications, then the capability and the technology service: eight of eight elements in four hops. The model says so because “Runs on” says so. If the cluster is meant to survive a node, model the cluster that way; a blast radius is only as honest as its relationships.
- A contract you can point at. The offering is where the database team's promises live: hours, backup, change windows. Every service inside it inherits them, and every service outside it, like Reporting, is a conversation waiting to happen.
- Cost with somewhere to land. A shared platform's cost is allocated through its offering to the services it contains. A consumer that is not in the offering is also not in the bill, which finance notices before architecture does.
Try it yourself
Open Blueprint Modeler, choose Examples › Application architecture › Shared Database Platform, and right-click any element for Show blast radius. The model file behind this figure is available to download and imports with Import… in the toolbar. Nothing here is a real system; the names are the example's.
Based on Blueprint Modeler class guide (classes, relationships and hints, each with its ServiceNow source); CSDM 5 white paper (ServiceNow Community). Drawn for this site; no client or employer material.