Why Simplicity Wins: Scalable Service Governance with CSDM 5

[mikesisson]

When implementing CSDM, it’s tempting to go deep modeling every micro-feature of a Business Service because it feels thorough and “right.” (There may even be a microservice specifically delivering that function/feature) I’ve been there. But here’s the reality: that approach quickly turns into governance overload, fragmented reporting, and unrealistic SLAs.

Consumers don’t care about every technical detail…they care about outcomes. The key is simplicity: define what truly matters and treat everything else as degradation when impacted. This keeps reporting meaningful, scales governance, and makes conversations with consumers fair and honest.   “Although our (Business) services remained available holistically across our customer base, we apologize for the 45 minutes of degradation that occurred. You can be confident that we have identified the source of this degradation (Tech Service) and are taking the appropriate action to minimize future degradations from this source.”   This is an honest, reasonable approach to delivering High Availability percentages from a Service Perspective.

Model Comparison: Mortgage Service Complexity

Model 1: Over-Engineered (Too Granular)

Business Service: Mortgage Services

• Service Offerings:
• Mortgage Account Access
• View Account
• Make Payment
• View Amortization Schedule
• View Escrow Details
• View Tax Info
• Historical Payments
• Download Statements
• Request Payoff Quote

Issues:

• Dozens of offerings or sub-offerings for every micro-feature.
• Governance and reporting complexity skyrockets.
• SLA tracking becomes fragmented and meaningless.

Model 2: Simplified (Outcome-Oriented)

Business Service: Mortgage Services

• Service Offering:
• Mobile Mortgage Account Management
• Online Mortgage Account Management
• Core Outcome:
• Access Account (Unplanned Outage (Availability Consideration)
• Make Payment (Unplanned Outage (Availability Consideration)
• Additional Features: (Handled as degradation if impacted)

Benefits:

• Scalable governance.
• Clear SLA: “Can the customer access and pay?”
• Degradation classification for partial impacts (e.g., missing amortization view).

Why This Matters

If a customer can access their account and make a payment, the service is available - even if escrow or amortization views are temporarily missing.  With this stepped outcome approach - That’s a degradation outage type, not an outage (impacting availability). For clarity on outage types (Outage, Degradation, Planned Outage)

This approach keeps SLAs honest, reporting clean, and conversations fair. It’s like dining out: if your meal arrives with corn instead of potatoes, the restaurant doesn’t comp or discount the dinner…they acknowledge the issue and fix it. (Did you ultimately receive what you paid for?  The food you ordered from the menu offered to the standards of the restaurant- We should do the same.

Closing Thought

Complexity is the enemy of adoption. Start simple, measure what matters, and let governance grow with maturity. That’s how you achieve scalable service management and keep our consumers confident in the value we provide.  (Love the value stream and maturity based on value introduced in CSDM 5 Finally!!! Get the CSDM 5 White Paper HERE 

Question for the Community

How have you balanced simplicity and granularity in your CSDM journey? Have you found a sweet spot that works for both governance and consumer expectations?

Hope this gives food for thought for those struggling with the complexity like we have.  If so, give this a 'helpful' and I will share the continued journey and results.

Thanks

#CSDM #CMDB #DPM #SPM 

[Mathew Hillyard]

Hi Mike,

Thanks for your perspective on your CSDM journey.

It's important to correctly identify what each individual component is in a service, otherwise you will have too much granularity or simply a model that doesn't work properly. This typically manifests itself during the CSDM journey by failing to be able to successfully apply the proposed model to different use cases.

Using your "too-granular" example above, these belong in CSDM, just not as service offerings.

I would class these as steps in business processes modelled against the business service offering:

• Mortgage Account Access
• View Account
• View Amortization Schedule
• View Escrow Details
• View Tax Info
• View Historical Payments
• Download Statements
• Request Payoff Quote (maybe - could be a separate supporting service offering?)

"Make Payment" is however definitely a service offering - in fact it's one of the most important offerings for any financial services institution. What would happen if a customer could not pay down their mortgage (or more likely that a scheduled regular payment failed to clear?) It's also wider than just the mortgage service. In UK operational resilience legislation this would be referred to as an "Internal Service" that supports an "Important Business Service" (and is also often referred to as a "payment rail" based on direction, payment scheme and size of payment). All such services should be modelled via their business processes which identify the supporting services and all the (business) applications used, to identify and vulnerability test all in-scope CIs. Other regs around the world have similar definitions (e.g. Critical Functions in DORA).

Modelling detailed business processes isn't that great an experience in ServiceNow, so it may be better to model them in a dedicated tool, but it's important to reflect the key relationships - service and app dependencies - in ServiceNow.

So in summary I agree with your approach - being too granular with the service offerings would make managing the services next to impossible, but make sure everything identified has a home. This modelling can be really tedious for organisations - particularly teasing out which service offerings support other offerings, and which activities and applications belong in a business process - but it's really important for fully understanding how the organisation functions.

BR
Mat