Everyone Named Their Services Differently. Now Nobody Can Find Anything.
CSDM gives you the framework. It doesn't give you the taxonomy. How your organization names, categorizes, and structures services within that framework is an architectural decision that either makes the service model navigable and consistent — or turns it into the world's most expensive directory of things nobody agrees on. Here's how to design it correctly.
The CMDB With Four Names for the Same Thing — and Three Services That Didn't Exist
The discovery came during what should have been a routine incident review. The operations team was trying to identify all services associated with the agency's case management capability. They searched the CMDB and found, depending on which team had done the modeling: "Case Management Service," "CM Application Service," "CaseManagementApp-PRD," and "Case Mgmt — Production." Four records. Probably the same underlying application service. Nobody was certain.
Digging further, they found the opposite problem in a different part of the CMDB: three Technical Services listed for an authentication capability that the platform team confirmed had been consolidated into a single platform eighteen months ago. The retired services had never been decommissioned in the service model. They were still showing up in incident routing, still appearing in change impact assessments, and still being listed as dependencies for applications that had long since migrated to the consolidated platform.
The CSDM structure was correct. The taxonomy was not. Every team had named services according to their own conventions, the governance process hadn't enforced consistency, and the service model had accumulated duplicates, orphans, and naming conflicts that made it unreliable for exactly the operational purposes it was meant to support.
The technology was fine. What was missing was a shared language for what everything should be called and how it should fit together.
✦ ✦ ✦
The Problem
CSDM Gives You the Layers. It Doesn't Tell You What to Put in Them.
This is a point that's easy to miss during CSDM implementations. The framework defines the hierarchy — Business Capability, Business Application, Application Service, Technical Service, Infrastructure CI — and the rules for how those layers relate to each other. What it deliberately does not prescribe is the specific taxonomy that any given organization should use within those layers.
That flexibility is appropriate. A state agency's service taxonomy will look very different from a financial institution's, which will look different from a healthcare system's. CSDM provides the container; each organization fills it according to its own architecture, terminology, and business structure.
But that flexibility is also where most implementations go wrong.
What Happens Without a Defined Taxonomy
Inconsistent naming breaks automation. Event management rules that route alerts by service name fail silently when different teams have named the same service four different ways. AI-driven operations tools that reason about services can't correlate records that should be related but aren't connected because the naming doesn't match.
Duplicate records proliferate. Without naming standards, two teams independently creating service records for the same application produce two records. Both are partially accurate. Neither is authoritative. Governance has no clear basis for merging them because there's no standard to adjudicate against.
Discoverability fails at scale. A service model that grows to hundreds or thousands of records without a coherent taxonomy becomes a search problem. Operational teams searching for services related to a specific capability find too many results, too few, or the wrong ones — and fall back on institutional knowledge and Slack messages rather than the tool that's supposed to replace them.
The solution is a designed taxonomy: explicit decisions about how services will be named, categorized, and structured before teams start building — and governance that enforces those decisions after.
The Explanation
How to Build a Taxonomy That Actually Works
A CSDM-aligned service taxonomy isn't a spreadsheet of approved names. It's a set of architectural decisions about categorization, naming convention, and hierarchy that are made once, documented clearly, and enforced through governance. Here's how to make those decisions well.
Decision 1: Anchor the Taxonomy in Business Capabilities, Not Systems
The most reliable way to build a taxonomy that stays coherent over time is to start from the top of the CSDM hierarchy and work down — beginning with the business capabilities the organization needs to support, then identifying the business applications that deliver those capabilities, then modeling the services those applications require.
The failure mode is building the taxonomy bottom-up, starting from existing systems and trying to map them upward. This approach produces a taxonomy that reflects how the technology was historically organized, not how the business thinks about what it does. It tends to preserve legacy naming conventions, miss capability alignment, and require restructuring every time the technology changes without the business changing.
Top-down design anchors every service to a business rationale. When a service can't be traced to a business capability, it's a flag — either the service is genuinely unnecessary, or the capability model is incomplete.
Decision 2: Name Services for What They Do, Not What They Run On
The most common naming mistake is giving services names derived from the technology that implements them rather than the function they deliver. "Oracle-DB-PRD-01" is a configuration item name. "Benefits Data Platform" is a service name. The first changes every time the technology changes. The second describes a stable business function and can survive a database migration without requiring the service record to be renamed.
A practical naming convention for most organizations follows a three-part pattern: [Domain] + [Function] + [Service Type].
- "PROD Benefits Eligibility Application Service."
- "TEST Identity Management Technical Service."
- "DEV Case Management Business Application."
The pattern is consistent, the names are descriptive, and they're meaningful to both technology teams and business stakeholders.
The corollary: avoid environment suffixes in service names. Services represent functions, not deployments. The production database and the staging database are the same service in different environments — not two different services. Environments belong in configuration item attributes, not service names.
Decision 3: Apply the Classification Test Consistently
The previous article in this series covered the distinction between Application Services and Technical Services in depth. In a taxonomy design context, the discipline is applying that distinction consistently across all teams, not just understanding it in the abstract. A governance checkpoint that asks "does more than one application use this?" before every new Technical Service is created catches most classification errors before they enter the model.
Decision 4: Require Taxonomy Review Before New Services Enter the CMDB
The taxonomy is only as good as the governance that enforces it. New services that bypass taxonomy review introduce the exact inconsistencies that taxonomy design is meant to prevent. Architecture review boards or CMDB governance councils should include a taxonomy alignment check as a standard step in the service introduction process — not an optional review for large initiatives, but a required gate for any new service record.
"A taxonomy isn't a naming convention document. It's a shared agreement about how the organization talks about what technology does. Get that agreement right and the CMDB becomes navigable. Get it wrong and every search is a guess."
— CMA Technology Practice
The Solution
The Taxonomy Document Nobody Ever Writes (Until After It's Needed)
The practical deliverable of taxonomy design is a document — or more accurately, a governed artifact — that teams consult when creating new service records. It answers four questions explicitly: What are the business capabilities this organization performs? How are those capabilities mapped to business applications? What naming convention governs service records at each layer? What are the classification rules that determine whether a service is an Application Service or a Technical Service?
Most organizations don't have this document. The taxonomy evolved organically — each team used their own judgment, nobody reconciled the results, and the service model accumulated inconsistencies that governance never addressed because there was no standard to enforce against.
Creating the document retroactively is harder than creating it in advance, but it's not impossible. The process is a taxonomy audit: review existing service records, identify inconsistencies, establish the standard that should have existed, and begin enforcing it for all new records while cleaning up existing ones on a prioritized schedule. Critical services first. Lower-priority domains later.
The governance integration is the same whether the taxonomy is new or remediated: new service records require taxonomy review before creation, the standard is documented and accessible, and service owners are trained on the convention so that compliance is the default rather than the exception.
Summary
Back to the Four Names for the Same Thing
The agency with "Case Management Service," "CM Application Service," "CaseManagementApp-PRD," and "Case Mgmt — Production" had a CSDM structure. What it didn't have was a taxonomy — a shared agreement about what that service should be called, how it should be classified, and what convention governed its name.
The fix was designing the taxonomy they should have had before implementation: a capability-anchored structure, a three-part naming convention, a classification rule applied consistently to every service, and a governance gate on new record creation. The four records were reconciled into one. The three obsolete Technical Services were decommissioned. Incident routing became reliable. Change impact assessments stopped producing false positives.
CSDM gives organizations a framework. The taxonomy is how an organization makes that framework their own — specifically, consistently, and in a way that every team, every tool, and every AI system that touches the service model can navigate without institutional knowledge to guide them.
Design the taxonomy before the CMDB. Govern it after. Everything in between works better.
