HR Self-Service Portal in CSDM

This is the Modeler's own “HR Self-Service Portal” 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 smallest model in the series, and it starts from a process rather than a capability, because that is where most HR requests start: someone has to onboard a new hire by Monday.

Reading it top to bottom

Business layer. Two anchors instead of one. The Business Process “Onboard a new hire” depends on the HR portal, and the Business Capability “Workforce management” is provided by it. Processes say what the business does today; capabilities say what it needs to be able to do. Having both means an outage reads as “onboarding is down” and a portfolio review reads as “this is one of two applications under Workforce management.”

Design layer. The Business Application “HR portal” is the one that exists. Next to it, “Payroll (planned)” is also provided to the capability, and nothing sits beneath it: no Application Service, no software, no host. The Modeler raises a hint for that, which is the point of the example. A plan belongs in the model, flagged as a plan, so the capability shows what it is about to get as well as what it has.

Service layer. Employees reach the portal through the Business Service Offering “HR help — employees,” under the Business Service “HR help,” and that offering depends on the Application Service “HR portal — production.” Even with a single environment, the Application Service earns its place: it is the element the offering, the process and the API all meet at.

Functional layer. The “Payroll API” receives data from the production portal service. It is modeled as an API, a Functional-layer element, so the dependency is on the interface rather than on whichever application ends up serving it, which matters when the application it belongs to is still a plan.

What the shape buys you

• A business answer in two hops. If the production service fails, the walk reaches the HR portal application, the employee offering and the Payroll API, then the onboarding process, the Workforce management capability and HR help: six elements in two hops, and the first sentence of the incident is “onboarding is affected.”
• Plans that cannot be mistaken for deliveries. Payroll is in the model and the hint against it stays until a service appears beneath it. A slide deck cannot do that; a deployment does not need to.
• Integrations that survive a re-platform. The Payroll API is tied to the portal's service, not to its software, so replacing the portal behind the same service leaves the integration's dependency true.

Try it yourself

Open Blueprint Modeler, choose Examples › Application architecture › HR Self-Service Portal, 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.