Every ServiceNow customer right now is being asked the same question by their leadership:
“What is our AI strategy on the platform?”
Now Assist, AI Agents, predictive intelligence, agentic workflows… The roadmap is crowded with capabilities competing for budget and attention.
ServiceNow events are now called AI Summits. It looks like ServiceNow is only about AI. I consider, in the context of ServiceNow, that AI should be boosting underlying processes, and to properly boost them, the foundation must be solid.
As such there is one item that should sit above every shiny new feature: a properly implemented Common Service Data Model (CSDM), and specifically the v5 model that ServiceNow released. It is not glamorous. It will not resonate to the executive leadership. And it is, without exaggeration, the single highest-leverage investment your platform team should make this year.
Why CSDM should rank higher than AI on your roadmap
Every AI capability ServiceNow ships feeds on the same input: structured, trustworthy data about your services, applications, and the relationships between them. When that data is wrong, fragmented, or only partially populated, AI does not fix the problem, it amplifies it. A model that cannot tell which Business Service supports a payroll outage will not magically learn to triage that outage just because you bought your 3 million AI intents for NowAssist.
CSDM is the schema that makes everything else on the platform make sense. ITSM uses it to attach incidents to the right service. ITOM uses it to know what an alert actually impacts. SPM uses it to map demand to applications. SAM and HAM rely on it to attach license and asset records to something meaningful. Take CSDM out of the picture and every one of those processes ends up running against custom concepts, orphaned offerings, or a custom categorization that no providers will be able to support in a SIAM set-up. Putting an AI layer on top of that is like building a penthouse on a sand beach.
So when prioritisation conversations come up internally, our position is clear: CSDM v5 belongs ahead of any new AI capability on the roadmap. Not because AI does not matter, but because AI without CSDM does not work.
What CSDM v5 actually brings
CSDM v5 is not a rewrite of v4. It is a clarification and a more mature model. The model now distinguishes more cleanly between the technical areas, application layer, and the service domains. It also uses the right labelling such as Service Instance instead of Application Service, a really smart modification that helps in explaining the model. I also like the terminology around Technology Management Service and Technology Management Offering that helps in the different SIAM transformation projects that we have been participating.
The practical advantages show up quickly:
- A single source of truth for what supports what. Incident, change, problem, request. Every process consumes the same map.
- Cleaner impact analysis. When an Application Instance fails, you can trace upward to affected Business Services and Offerings without scripting your way out.
- Healthier ITOM. Discovery, Service Mapping, and Event Management produce data that lands in the right place.
- Real cost transparency. SAM, HAM, and SPM finally have something meaningful to attach financial data to.
- A defensible architecture. When auditors, regulators, or your own CIO ask “how do you know?” you can show them.
| Concept | CSDM v4 | CSDM v5 |
|---|---|---|
| Deployed running unit | Application Service | Service Instance Clearer label — it is an instance of a service, not a service itself. Easier to explain the model to stakeholders. |
| Technology layer — service view | Not explicitly named | Technology Management Service Explicit terminology that supports SIAM transformation projects and multi-provider governance. |
| Technology layer — offering view | Not explicitly named | Technology Management Offering Companion to Technology Management Service. Enables cleaner separation of service delivery from service consumption in SIAM setups. |
| Overall approach | v4 model | Clarification, not a rewrite A more mature model — distinguishes more cleanly between technical areas, application layer, and service domains. |
ServiceNow makes it look complicated. It is not.
If you have ever read the official CSDM documentation, you have seen the diagrams: dozens of tables, six domains, multiple lanes, “Build and Integration”, “Design and Planning”, “Ideation & Strategy”, “Service Consumption”, “Service Delivery”, “Foundation” It can take a week before the audience feel they understand it. That complexity is mostly documentation complexity, not model complexity.
Strip away the labels and CSDM is essentially a small set of tables, key definitions, a few mandatory relationships, and a handful of ownership rules. Most customers are surprised to learn that the operational core they need to adopt is much smaller than the full reference picture suggests.
Start small: the minimum foundation
You do not have to implement all of CSDM v5 to be live on CSDM v5. You need a clean, well-mapped foundation that the rest of the platform can build on. In practice, that minimum for ITSM is four entities and the relationships between them:
- Business Service — what the business consumes
- Business Service Offering — the specific level of that service
- Business Application — the application that delivers it
- Application Instance — the deployed unit of that application
Get those four right (defined, owned, mapped, and populated with quality data) and you have a foundation strong enough for ITSM, ITOM and SAM to consume. Everything else (Technology Management Service, Technology Management Offering, Business Capability, Product idea, …) extends naturally from this base.
CSDM is a never-ending exercise
This is the part that surprises clients the most. Going live on CSDM is not a project completion event. It is a steady-state operational discipline. Being live means three things, in this order:
- Entities are properly defined — clear semantics, clear class, clear scope.
- Entities are mapped — relationships exist and reflect reality.
- Tools (and process) exist to maintain the model — catalog items, dashboards, audit reports, ownership review cycles.
Without the third leg, the model decays within a single quarter. New applications appear, owners leave, services are renamed, and the catalog drifts. CSDM only stays useful as long as the team has the means to keep it useful.
What an implementation project actually looks like
A typical Aloha Cloud CSDM engagement covers five workstreams:
- Migration to a CSDM v5-compliant model. We define the Business Services, Business Service Offerings, Business Applications, and Application Instances; identify their owners and managers, their support groups, their change groups; ensure accountability and proper mappings between layers.
- Process alignment. We make sure the underlying ITSM, ITOM, SAM and SPM processes consume the CSDM data correctly and that the platform behaves as expected against the new model.
- Maintenance tooling. Catalog items for onboarding new entities, dashboards for completeness and ownership, and audit reports for drift detection.
- Adoption and enablement. Our team trains users on how the data model is structured and, more importantly, how to consume it from their day jobs.
- Integration update. We update inflight integrations — discovery sources, CMDB feeds, SaaS connectors — so they land data exactly where CSDM expects it.
How Aloha Clouds is engaging today
Aloha Cloud is currently leading two CSDM v5 implementations where the ITSM processes are actively consuming the new model. Both customers came in with the same picture: incidents and changes attached to inconsistent, duplicated, or generic CIs; no clear ownership; custom tables; significant technical debt. The data was simply not trustworthy enough to support a solid, consistent AI initiative. Today, both are operating on a clean foundational layer with the tooling to maintain it, and, just as importantly, with the confidence that any AI capability they layer on next will sit on data they can defend.
That outcome is not accidental. Our architects have all been deeply exposed to CSDM v4 and v5, and that experience matters: modeling decisions in this space are reversible only at significant cost, so getting them right at the start is largely a function of seniority.
For customer teams who want to build the same depth in-house, we recommend the ServiceNow Data Foundation course. ServiceNow itself has now made it a mandatory step for earning and renewing the Certified Implementation Specialist (CIS) certifications. A clear signal that even the vendor treats CSDM and CMDB quality as a precondition for any successful implementation.
Talk to us about a CSDM v5 readiness assessment
If your platform team is being asked to deliver AI capabilities on top of a CMDB you do not fully trust, the right next step is not a new CAPEX investment in AI, where the ROI will be limited. It is rather a CSDM assessment and alignment. We can usually tell within a couple of weeks what the gap looks like, what the minimum foundation effort would be, and how to sequence the work so business value lands quickly.
Reach out to the Aloha Clouds team at alohaclouds.com to start the conversation.
About the author
Lilian Mével
