What does your CSDM Model of Your Own ServiceNow Instance(s) Look Like?

[PierreDumoulin]

Hey Gang!

My team is starting to get into CSDM, mostly to revitalize and update our fairly basic business and application service records which are currently only glorified excel lists. While CSDM will eventually benefit my entire organization, I am looking to start small and set an example that others will be able to follow by creating a model of everything ServiceNow. ServiceNow has also grown quite a bit and we've been publishing more scoped apps so, SN is called upon to undertake a greater variety of responsibilities. I am also looking to reap some benefits in the change management area, as more detailed CIs would allow me to more precisely demonstrate which aspects of the solution are being affected by change-related activity. I would be extremely interested to hear about and see the different service models you've come up with and how the different entities relate to each other to draw a more complete picture I could draw some inspiration from.

Again, continued appreciation and gratitude to this community for your valued interactions!

[Sudhanshu Talw1]

Hi @PierreDumoulin 

In our organization, we are also implementing the CSDM. The CSDM implementation should be carried out in phases:

Crawl Phase: Introduce Business Applications[cmdb_ci_business_app] & Application Service

A business application is a base system Configuration Management Database (CMDB) table that stores your inventory, application portfolio, and their metadata.

These are non operational CI's & no incidents are raised against it.

All the Business Applications should be stored in [cmdb_ci_business_app] table.

Application Service:[cmdb_ci_service_discovered]

The application service is typically what the caller identifies when they report an issue with an application.

The application service ties all the elements of the CSDM together where applications are present.It is the heart of the CSDM which ties everything together.

These are related by consumes:consumed by relationship.

For a business application you can have multiple application services associated via consumes:consumed by relationship.

Advantages:

• Provides the minimum CMDB requirements required to provide Incident Management and Change Management.
• Serves as a foundation for using Application Portfolio Management (APM).

  When you use APM, your business application data is in the right place in the CMDB, which makes setting up APM faster.

• Serves as a foundation for using Service Mapping.

You can start from the CRAWL phase.

Further we have walk, run & fly phases as well.

CSDM

Thanks

Sudhanshu

[PierreDumoulin]

Hi Sudhanshu, thanks for commenting, this is very interesting. Those are good points, the whole thing can seem overwhelming at first and we are also looking to divide and conquer, as you suggest. I was wondering if you could give an example of some of the service entities you've specifically created to model ServiceNow within ServiceNow? Thanks for sharing!

[Ed Laar1]

Hi Pierre,

When modelling an application into CSDM I always take some basic starting points for myself:

Comply to CSDM definitions as this assures compatibility with other existing, updated and new application in ServiceNow

Keep the end-user in mind: what is an easy way for end-users to raise tickets? 

Keep the operational applications like Incident and Change in mind: What are OOB available fields when raising tickets.

What I should do to register ServiceNow into CSDM:

Create a Buisiness Service called something like IT Service Management

Create an Application Service called ServiceNow_Production and relate to the created Business Service

Create Application Services called ServiceNow_Prod_INCident management and ServiceNow_Prod_CHanGe management and relate to ServiceNow_Production. Alternative for this is to create, instead of Application Services, CI's for these applications (so a CI for ServiceNow_Incident Management_PROD and a CI for ServiceNow_Change Management_PROD)

In this way en end-user is always able to raise a ticket on for example  ServiceNow Incident Management Prod.

Relate to these Application Services or CI's (depends on how you set this up) the Technical Services representing the Support groups, SLA's (what are in fact OLA's as soon as you also create Business Services as the ticket SLA will come from Business Service at that time) and so on.

From my perspective: Technical Service on a ticket should be auto populated based on the selected Application Service or CI. Vica versa: When selecting a Technical Service only the related Application services and CI's should be selectable. Also there should be only one field on the ticket form to select or the Application Service or the CI to make everything less complicated for the end-users.

Hope this helps. Looking forward to your and other reactions.

Cheers,

Ed

[PierreDumoulin]

Hi Ed, thanks for chiming in, this is pretty much what I am trying to wrap my head around and providing a concrete example as you just did is massively useful. I was getting there, but I think you just allowed me to make more headway more quickly. I may have some follow up questions, but I'll compare this to the notes I took on my original design and see what comes up. Really appreciate your contribution sir, thanks so much!