CSDM Domains: Where Does This Thing Actually Belong?

CSDM gets a lot easier once you stop thinking of it as one giant diagram that you're supposed to memorize.

Instead, think of it as a way of organizing different kinds of information about an organization.

A company has business needs.

Those needs are supported by capabilities.

Capabilities are supported by applications and technology.

Services are provided to consumers.

Technical infrastructure keeps those applications and services running.

All of those things are connected, but they aren't all the same thing.

CSDM gives ServiceNow a structured way to represent those different perspectives.

And one of the ways CSDM does that is through domains.

If the word "domain" makes you immediately think of DNS, don't worry. ServiceNow is talking about something much more interesting here.

In CSDM, domains help organize data according to its role and purpose within the overall model.

Why Divide Things Into Domains?

Imagine walking into a warehouse where everything your company owns has been thrown into one enormous room.

Servers are next to laptops.

Contracts are next to business applications.

Business services are next to databases.

Someone has helpfully labeled a box:

"IMPORTANT STUFF"

That's not a particularly useful organizational strategy.

Now imagine the warehouse is divided into clearly defined areas.

Technology goes here.

Business information goes there.

Service-related information has its own area.

The contents are still connected, but they're easier to understand because they have context.

That's essentially the idea behind organizing CSDM information into different areas or domains.

The point isn't to create more boxes just for the sake of having boxes.

The point is to make the meaning of the data clearer.

The Business Perspective

Let's start at the top.

A business doesn't wake up in the morning thinking:

"I hope our configuration items are properly populated today."

The business has goals.

It needs to sell products.

Serve customers.

Process payroll.

Manage employees.

Deliver products.

Comply with regulations.

Those activities require business capabilities.

A business capability describes something the organization needs to be able to do.

For example:

• Customer Support

• Financial Management

• Human Resources

• Order Management

• Supply Chain Management

These aren't necessarily applications.

They're things the organization needs to be capable of doing.

That distinction is important.

Capability vs. Application

Suppose a company has a capability called Order Management.

The organization might use several applications to support that capability.

Perhaps it has:

• An online ordering application

• An inventory application

• A payment system

• A shipping application

The capability existed as a business need.

The applications are technology used to support that need.

This is one of the central ideas behind CSDM.

The business need and the technology supporting that need are not automatically the same thing.

If you mix them together, it becomes much harder to understand the environment.

Why Capabilities Matter

Imagine an executive asks:

"Which applications support our customer service capability?"

That's a very different question from:

"Which servers do we have?"

The first question starts from the business.

The second starts from technology.

Both are valid.

CSDM helps connect those perspectives.

That connection becomes particularly valuable when organizations need to understand the impact of technology decisions on the business.

If an application is being retired, for example, you may want to know which capabilities and services depend on it.

That's much more useful than simply knowing that the application exists.

Business Applications Fit Into the Picture

We've already touched on business applications, but now we can place them in a larger context.

A business application is something the organization uses to support business activities or capabilities.

Suppose the company has:

Customer Support capability

and uses:

Customer Support Platform

The application supports the capability.

But the application itself isn't the capability.

That sounds like a small distinction.

In a large organization, it isn't.

If the company replaces the Customer Support Platform, the capability doesn't necessarily disappear.

The technology changes.

The business still needs to perform customer support.

That's why keeping these concepts separate is useful.

Services Are Another Layer of the Story

Now let's introduce services.

A service represents something provided to a consumer.

The consumer might be:

• An employee

• Another department

• Another business unit

• An external customer

For example, an organization might provide:

Email

Employee Onboarding

Customer Support

Payroll

Online Ordering

These are things consumers actually use or depend upon.

That's different from saying:

"We have 42 servers."

Nobody wakes up and says:

"Thank goodness the company still has 42 servers."

They care about what those servers allow the organization to provide.

Services and Capabilities Aren't the Same Thing

This is another distinction worth understanding.

A business capability describes what an organization needs to be able to do.

A service describes something provided to a consumer.

Those concepts can be related without being identical.

For example:

A company may have a Human Resources capability.

One of the services supporting employees might be Employee Onboarding.

The capability describes an organizational ability.

The service describes something being provided.

That difference can become important when you're trying to understand where a particular piece of information belongs in the model.

Service Offerings Get More Specific

We've already encountered service offerings, but they're worth revisiting here because they fit naturally into the service perspective.

Suppose an organization provides an Email Service.

It might provide different offerings based on the consumer or requirements.

For example:

Standard Email

Executive Email

Contractor Email

The exact structure will depend on the organization.

The important idea is that a service offering represents a specific offering of a broader service.

If the question describes something specifically being offered to a particular consumer or group, pay attention to that distinction.

Technical Services

Now let's move in the other direction.

A business service is viewed from the perspective of the consumer or business.

A technical service is concerned with technology that supports the delivery of services.

This is where the model starts getting particularly useful for IT teams.

Imagine employees consume an email service.

Behind that service might be several technical capabilities and components.

There could be:

• Mail servers

• Databases

• Network infrastructure

• Identity services

• Cloud infrastructure

• Security controls

The consumer doesn't need to understand all of that.

IT does.

CSDM provides ways to represent these different perspectives and connect them.

Technical Services Aren't Just "Servers"

Here's an easy mistake.

A technical service isn't simply another name for a server.

A server is a technical component.

A technical service represents a service provided from a technology perspective.

For example, an organization might provide a Database Platform Service to application teams.

The applications depend on the service.

The service may rely on a collection of technical infrastructure.

The individual servers are components supporting the overall capability.

Again, the model is about relationships and meaning.

The Business and Technical Worlds Meet

This is where CSDM starts to become really useful.

Imagine the business provides an online shopping service to customers.

That service depends on an application.

The application depends on application services.

Those application services depend on technical infrastructure.

Now something fails.

A network component goes offline.

If the relationships are modeled properly, ServiceNow can potentially help answer:

"What does this technical failure affect?"

The answer might eventually reach all the way up to:

"The customer-facing online shopping service is affected."

That's the kind of connection organizations are trying to establish.

Think About the Direction of the Question

CSDM questions can become easier if you notice which direction the scenario is traveling.

If you're starting with:

"What does the business need to accomplish?"

You're likely dealing with capabilities and business concepts.

If you're asking:

"What does the organization provide to consumers?"

You're moving into services and service offerings.

If you're asking:

"What applications support the business?"

You're moving toward business applications.

If you're asking:

"What technical components support the application?"

You're moving deeper into the technical side.

The model connects these perspectives.

The exam may test whether you can recognize the role of the thing being described.

A Business Example

Imagine a retailer.

The retailer needs to be able to process customer orders.

That's a business capability:

Order Management

The organization provides customers with an:

Online Ordering Service

The service may have a particular:

Service Offering

The service is supported by a:

Business Application

That application depends on:

Application Services

Those services depend on:

Technical infrastructure

Now we've gone from something the business needs to do all the way down to the technology making it possible.

That's the kind of chain CSDM helps organizations represent.

Why This Is Better Than a Flat List

Without this structure, someone might simply create records for:

Order Management

Online Ordering

Order Application

Web Server

Database

and call it done.

But what do those records mean relative to one another?

That's the important question.

CSDM encourages the organization to define the role of each piece and establish appropriate relationships.

Now the data isn't just a collection of nouns.

It tells a story.

The business needs to process orders.

The organization provides an ordering service.

A specific application supports that service.

Technical components support the application.

Suddenly the CMDB becomes much more useful for understanding the environment.

Domains Help Establish Context

This is the real reason to care about CSDM domains.

A domain provides context around the type of information you're dealing with.

You don't want a business capability being treated like a server.

You don't want a business application being treated like a service offering.

You don't want a technical component being confused with the business service that depends on it.

The model helps establish those distinctions.

And once the distinctions are clear, the relationships become much more meaningful.

CSDM and Portfolio Management

This structure becomes particularly valuable when organizations need to make decisions about their application and service portfolios.

Imagine leadership asks:

"Which applications support this business capability?"

You can potentially use the modeled relationships to answer.

Then they ask:

"Which services depend on those applications?"

Again, the relationships matter.

Then:

"Which applications are expensive to maintain?"

Now you're combining service and application information with financial or operational information.

This is where structured service data becomes much more valuable than simply having a list of applications.

Application Rationalization

Here's a practical reason organizations care about all of this.

Imagine a company discovers that it has six different applications performing almost the same business function.

Without a structured model, those applications may simply appear as six unrelated records.

With better service and business context, the organization can start asking:

"What capabilities do these applications support?"

"Which services depend on them?"

"Who uses them?"

"Which ones are redundant?"

"Which ones are strategic?"

"Which ones should be retired?"

This process of evaluating applications and deciding which ones should be retained, replaced, consolidated, or retired is often referred to as application rationalization.

CSDM can provide valuable data for that kind of analysis.

The Same Technology Can Support Multiple Things

Here's another reason relationships matter.

One application may support several business services.

One technical service may support multiple applications.

One infrastructure component may support multiple application services.

So don't assume the model is always:

one thing → one other thing.

Real environments are much more interconnected.

This is another reason a flat list of CIs doesn't tell you nearly as much as a well-modeled set of relationships.

CSDM Isn't Trying to Hide the Technical Details

Sometimes people hear all this business terminology and assume CSDM is designed primarily for executives.

Not at all.

The technical information is still important.

Servers matter.

Databases matter.

Networks matter.

Applications matter.

Cloud resources matter.

The point is to give those technical components context.

An engineer investigating an outage may need to know exactly which server is broken.

A service owner may need to know which business service is affected.

An executive may only need to know that a critical customer-facing capability is unavailable.

They're looking at the same environment from different perspectives.

A useful CSDM implementation helps connect those perspectives rather than forcing everyone to use the same one.

A Common Mistake: Treating Names as Meaning

Suppose someone creates a record called:

Customer Service

That name alone doesn't tell you what it represents.

It could be:

A business capability.

A business service.

A business application.

A service offering.

A department.

A team.

Someone's favorite label.

The name isn't enough.

You need to understand what the record represents.

This is why CSDM terminology matters.

It's not just vocabulary for certification exams.

The terminology establishes meaning.

Another Scenario

Let's say the organization gets a request:

"We need to retire the Customer Portal application."

His first question shouldn't be:

"Okay, which CI do I delete?"

That would be a spectacularly bad starting point.

The organization should want to know:

What business capabilities does it support?

Which services depend on it?

Which service offerings are affected?

What application services are involved?

What infrastructure supports those application services?

Who owns the application?

What happens to the consumers if it disappears?

Now the decision is based on business and technical context rather than simply deleting a record.

That's the kind of value structured service data can provide.

Why CSDM Makes Reporting Better

Consider a report that simply says:

"Number of applications: 1,247"

That's interesting.

But what if you could instead answer:

"How many applications support our most critical business capabilities?"

Or:

"Which business services depend on applications scheduled for retirement?"

Or:

"Which services have no clearly identified supporting application?"

Those are much more useful questions.

The quality of the answers depends on the quality and structure of the underlying data.

CSDM helps provide that structure.

Don't Try to Memorize the Whole Model as a Giant Diagram

This is where you get permission to avoid one of the worst possible study strategies.

Don't stare at a giant CSDM diagram and try to memorize every box and arrow as if you're preparing for a geography bee.

Instead, understand what each type of thing represents.

Ask:

Is this something the business needs to be capable of doing?

Think capability.

Is this something being provided to a consumer?

Think service.

Is this a specific version or offering of that service?

Think service offering.

Is this an application used by the organization to support business activity?

Think business application.

Is this a technical service or technical capability supporting applications and services?

Think technical side.

Once you understand the purpose of each concept, the model becomes much easier to navigate.

A Very Important Distinction

Here's one worth putting a mental highlighter around.

Business application ≠ business service

A business application is technology used to support business activities.

A business service is something provided to a consumer.

They can be closely related.

They can even have similar names.

But they represent different things.

For example:

Customer Support Platform

could be the application.

Customer Support

could be the service.

One is technology.

The other is something being provided.

The distinction becomes particularly important when a scenario asks which type of information should be represented or related.

Another Important Distinction

Business capability ≠ business service

A capability describes something the organization needs to be able to do.

A service describes something provided to a consumer.

A company might have a capability called:

Financial Management

and provide services such as:

Payroll

Expense Management

Financial Reporting

The capability and the services are related, but they're not interchangeable.

And One More

Service ≠ Service Offering

A service is the broader thing being provided.

A service offering represents a specific offering of that service.

Think of the service as the umbrella.

The offerings are the particular ways that umbrella is provided to consumers.

Again, the exact implementation depends on the organization.

The important thing is understanding the relationship between the concepts.

Why This Matters to CIS-DF

The CIS-DF exam isn't simply checking whether you've heard the term CSDM.

You need to understand why organizations use a common service data model.

That means recognizing that:

Business information and technical information represent different perspectives.

Applications, services, capabilities, and infrastructure are not interchangeable concepts.

Relationships connect those concepts.

Consistent definitions make reporting and analysis more meaningful.

Good CSDM implementation helps organizations understand how technology supports the business.

That's a much more useful understanding than memorizing a picture.

The Mental Model

Here's the version I'd keep in your head while studying.

Start with the business.

What does the organization need to be capable of doing?

Then think about the services provided to consumers.

Then think about the applications that support those business activities.

Then think about the technical services and infrastructure that keep those applications operating.

The exact CSDM model contains more detail than that, but this gives you a framework for understanding why the pieces exist.

The important thing isn't that every piece lives in a separate little box.

The important thing is that each piece has a defined meaning and can be connected to the other pieces appropriately.

The Big Takeaway

CSDM is ultimately trying to solve a fairly human problem.

Different people look at the same organization and see different things.

A business leader sees capabilities and services.

A service owner sees offerings and consumers.

An application owner sees applications.

An infrastructure engineer sees servers, databases, networks, and cloud resources.

All of them are looking at the same organization.

CSDM gives ServiceNow a common structure for connecting those perspectives.

So when you see a CSDM question on the CIS-DF exam, don't immediately start hunting through your memory for a diagram.

First ask:

"What does this thing actually represent?"

Is it something the business needs to do?

Something being provided?

A specific offering?

An application supporting the business?

Or technology supporting the application?

Once you answer that, the correct place in the model usually becomes much easier to recognize.

And that's really the secret to CSDM.

Don't memorize the boxes.

Understand why the boxes exi