CSDM Service Offering Types and Identification

[Juan Osorio]

First off big kudos to @Venni Mäkäräinen for his spot on CSDM & Request Catalogue - service offering and catalog item association article. This article expands on his work and provides the different service offering types and a model to identify them. All of this ties into the CSDM model and Service Offerings that are manifested as requestable Catalog Items in the Service Catalog. But how do you approach and identify all the Service Offerings and Service types?

ServiceNow has what is called Service Modeling...

What is Service Modelling?

A common way to arrange services, categorizing technologies into service offerings that help model the specific impacts the organization needs to manage, there driving greater service visibility.

The specific areas to look at to identify the different variables for service offerings, to allow enterprise manage consumption / reporting in underlying technology:

• Business Processes
• Process stage (i.e., customer journey, process phase, chevron, or activity)
• Product Lines
• Brands
• Ways of accessing a service or different service channels
• Ownership
• Service Commitments
• Technology architecture / Technology types / brands, features & or platforms
• Environment

Service Definition Process - High level

Service Modeling Decision Tree Guidance

[matt barrett1]

Thanks Juan for the information, I had a question around the terms business application and application service from what you have described.

If we move away from internal IT, and use the servicenow for the product side of the business, not all service its going to be application based.

If we say the product being sold by the business is infrastructure based - for example fibre connectivity - there is no application and its not for internal employees to subscribe and order. The business application and application service terms don't make sense, equally saying this is a Technical Service because this is what's offered by "IT" is also wrong.

Therefore do you change the class labels to better reflect what it is or tell the users that its an application service even if its not an application?

Business Application = The managed product

Application Service = The managed service

Otherwise what is described make sense for documenting the types of services and offering that are provided.

Would be good to get some further feedback about non-internal IT

[nkouloungis]

Do organizations apply a consistent service offering type across services OR is the approach to service offerings different depending on the service?

[mikesisson]

@nkouloungis 

- Guiding Principle:  Structure offerings based on how they’ll be consumed and maintained.  Let decision-making needs drive the offering type and granularity.

- At our organization, the approach to Service Offerings is moving to a contextual and purpose-driven mindset, not one-size-fits-all.

We ask:
"Is this offering built for a unique purpose...regional, business line-specific, or functionally distinct?"
This helps us determine the right level of granularity and how the data should be structured to support decision-making.

 

Key Considerations:

• Business Service Offerings:
  Engage with business stakeholders to understand how they’ll use the data. The goal is to strike a balance between granularity and maintainability. Always ask:
  “What decisions will this data help you make?”

• Technical Service Offerings:
  Collaborate with Tech Service Owners and App Service Owners. Understand how the offering supports consumers and what insights they need. Ask:
  “What are you doing with this data, and what decisions does it inform?”

Why This Matters:

• The structure of your offerings should be fit for purpose, serving both the consumer/stakeholder and the owner.
• These decisions impact how data rolls up into EA Workspace and DPM Workspace, where it must support strategic decisions.
• Start with a few offerings conceptually. You don’t need every module in place, just enough to have meaningful conversations and iterate based on feedback.

Thanks,

Mike