It is time... CSDM 4.0 DRAFT White Paper

[scott_lemm]

We are pleased to formally release CSDM 4.0 as a DRAFT White Paper.

The CSDM 4.0 Draft White Paper accounts for the further evolution of the Common Service Data Model. You will quickly notice the following additions to CSDM:

• New CSDM Domain - BUILD
• Location Management
• Life Cycle Management

Other additions you will read in the CSDM 4.0 Draft White Paper include the following:

• New CMDB tables for Business Service and SDLC Component
• Expanded Service Portfolio
• Focus on Product Management
• Definitions for all new material

Why is it "DRAFT"? Great question!!! We wanted to get the white paper into your hands for review and comment. We will then take these comments into consideration for the final release of CSDM 4.0 White Paper. Additionally, some functionality is still evolving such as the CMDB form view for the new SDLC Component table in the CMDB and its related capabilities. 

As always, any questions or concerns please reach out to me directly.

NOTE: You will read this in the white paper but we want to reiterate it here - THERE IS NO RUSH TO UTILIZE THE NEW CONCEPTS OUTLINED IN CSDM 4.0 DRAFT WHITE PAPER. 

We are excited to share the draft paper and assist you on your journey with ServiceNow.

Thank you - from the CSDM Team!!!!

[ianmclayton]

Scott - thank you - what is the best way to provide feedback?  for example, recommendations on leveraging new features such as the Service Builder dialog?  Also - emphasizing where and how service commitments can be exploited and help better drive activities like incidents...

[VaranAwesomenow]

Dear Scott, Great content, is there a version for TSM (Telecom Service Management).

[Kieran Anson]

I think the only possible point of confusion is where it references "CMDB Schema App" - This is the CMDB CI Class Models App (sn_cmdb_ci_class).

Other than that, great to see location data getting some love outside of CSM, I can't count how many times I've had to add a type and source classification to the table for better reconciliation.

[schorsch]

Hi Scott,

just had a look on the draft whitepaper. Found there a discrepancy, so maybe revise this in the paper....

On page 22 (fig. 8): Mapping tables for Business Service "wrong"
Here is the table "cmdb_ci_service" defined with the "Service Classification" = Business Service but in page 3/page 20 the new table "cmdb_ci_service_business" is introduced for Business Services in CSDM 4.0. Sure the new table "cmdb_ci_service_business" is a child table of "cmdb_ci_service", so this is not completely wrong but this is confusing because on the same page (22) is for Technical Services the "cmdb_ci_service_technical" table defined where we have the same situation.

[Damhoej]

@scott.lemm This is awaited for some time.
It seems that there are a lot of customers that are upgrading their instances by moving to a new and fresh instance. Shouldn't those customers adapt CSDM 4.0 from start?

[Sameer32]

is there a page / portal to provide feedback? Appreciate if someone can provide a link to posting feedback.

[DaveHertel]

@scott.lemm Thanks for sharing this draft, definitely appreciate the continuing evolution of CSDM and I'm very happy to see that the plethora of 'status' fields is acknowledged with a plan to refine... and I'm glad to see locations getting much-needed refinement too.

One minor tweak/suggestion:  Page 7 mentions the 2 new life cycle fields

To be clear, the 2nd field is labeled: Life Cycle Stage Status.  Perhaps this edit can be clarified when v4 is finalized.

Dave

[schorsch]

Hi Scott,

sorry - again me. There is one more discrepancy in the whitepaper I just found, so maybe you can also take care about this....

On page 5 (fig. 2) a line is missing for the relationship from "Business Application" to "Application Service". In page 32 (fig. 15) this relationship is (still) defined, but missing on the CSDM overview picture. This should be added there because all other relationships (and references) between the "CSDM- entities" are contained in the picture.

[Michael W_ - Sw]

Interesting. Will read this, compare with CSDM 3.0 and try to grasp. 
One immediate comment: SDLC is a new acronym, I guess. What does it stand for?
It's not explained in the section for it, on page 14. 

"The SDLC Component is a configuration item that represents a unique development effort of code. 

"...a SDLC Component is a software part or element of a larger whole for an application or technology."

"A deployed instance of a SDLC Component of type “Application” would be an Application Service. A deployed instance of a SDLC Component of type “Infrastructure” would be any infrastructure CI..."

[Christian Prob2]

SDLC - Software Development LifeCycle - at least that is the common version and kind of makes sense here...

Christian

Please mark helpful or correct if deemed so. Thank you.

[Manu15]

Dear Scott,

great whitepaper. There is just on thing concerning SDLC Components, that is not totally clear to me.

SDLC Components are linked to Application Models. Is it necessary / sensible to link SDLC Components also to Software Product Models?

It would be great, if you could answer this question in a community post or a later version of the whitepaper.

[scott_lemm]

Feel free to email me directly.
Thank you,
Scott

[scott_lemm]

We are working on updating Product Views (how ServiceNow products utilize CSDM) as well as creating examples for various verticals.TSM falls into both as we will have a Product View as well as a Telecom vertical example created. Stay tuned 🙂 

[scott_lemm]

CSDM can meet each customer where they are. For existing customers we wanted to reinforce that there is no rush to migrate into CSDM 4.0. For new customers it is best to start within the latest guidance from CSDM. Again, we are flexible and want everyone to understand we are not forcing change.

[scott_lemm]

Great Question!!!

NOTE: we need to be holistic in our thinking. A single Product could be made up of several Components. Those component could be newly developing (application model) or existing solutions (software model) or configurations of infrastructure.

SDLC Component represents the Build effort(s) for a product and will be referenced by DevOps.

This build effort may include an existing/available software (example is the database software model needed for the Application)

This build effort may include a new development/effort where a version does not yet exist.

This build effort may include a configuration where no versioning exists.

This build effort may represent ongoing development of all future releases.  

That said, an SDLC Component could reference either an Application or Software Model. BUT, its primary value to DevOps will be tied to Application Models where true development is occurring. 

Feel free to reach out to me directly via email if desired.
Thanks,
Scott

[scott_lemm]

feedback can be posted here or emailed directly to me.
Thank you,
Scott

[Community Alums]

Page 14 of the document has the information below regarding SDLC. I think the bullet about Application is clear, as is the statement that "A deployed instance of a SDLC Component of type “Application” would be an Application Service". However, I don't quite follow the bullet or the statement about Infrastructure CIs. Infrastructure CIs that are part of an Application Service are clear, but as a type of SDLC component in and of itself is not. Could be expanded on, and possible shown in Figure 2 CSDM 4.0 Conceptual Model.

Types of SDLC Component:
• Application – examples include micro services and APIs
• Infrastructure – examples include database configurations and security configurations
A deployed instance of a SDLC Component of type “Application” would be an Application Service. A deployed instance of a SDLC Component of type “Infrastructure” would be any infrastructure CI for which the SDLC component represents that snapshot of its configuration details.

[kjh1138]

SDLC seems limiting -  why doesn't the concept extend to the technology stack/services as well? 

[kjh1138]

More general, but general but what is the relationship between the Business Application that generates/maintains an information object and the IO itself?  The  graphic only details the relationship between the the IO and BAs that use it ...

[Samuel von Hofs]

Great seeing this come out, so many nice additions!

Regarding SDLC Component and its BA/AS relationships:

There seems to be a couple of different ways to model an example such as a platform + platform apps using the new set of "Crawl objects":

1. Platform+app hierarchy of BA's > No SDLC > AS per instance of individual BA
2. Platform BA only > Platform+app hierarchy of SDLC > AS per isntance of individual SDLC
3. Flat BA list > Flat SDLC list > AS per instance of SDLC
4. ...

Good to have some options of course, but since you are also suggesting a bit more structured approach to the product tables data, I think it could help with some clarifications on how these best fit together. In this example, I'm thinking one option could be:

• BA for platform ref. Product Bundle
• SDLC ref. the individual products (platform apps represented as application models) of that Product Bundle
• AS ref. software models that represents version of those same application models.

So, is this always unique, or could some general guidance on model references for the "Crawl objects" be added?
I believe that could boost the perceived relevance of the SDLC Component for parties where Dev and Ops is still largely separated.

[Jimmie Odelius]

Hi Scott!

Glad to see that the much anticipated white paper is here albeit in draft version. I think it looks very well I did notice these minor things that can easily be fixed for a final version. It has a limited impact on the overall message of the CSDM though.

• P.18, Portfolio: Here the second sentance seems to be missing a word or should be restructured to be clearer what is meant. I don't understand "Portfolio(s) are used to manage like items together for a business."
• P.21: The abbreviation ERD is not defined anywhere in the document I think.
• P.21 Figure 8: Why does Business Service reference cmdb_ci_service and not the new table cmdb_ci_service_business?
• p.22-30: I think you could provide more information on who the foundation-fly implementation recommendation is for. E.g. I know for CSDM3 you released separate documents for implementing it for CSM which vastly changed what's included in each implementation step. To avoid confusion for customers I think a disclaimer saying that this is intended for ITSM (or a range of products) could be advantageous.

All in all though! Great work! It really improves on CSDM3 to make things more easily grasped which I know will help me, my collegues as well as our customers. 🙂

[AnimeshKAr1]

Hi! On page 31 (prescribed relationships) can a new entry be added for relationship between any two service offerings? Based on the CSDM Fly diagram, clearly two service offerings can be related. 

[Kevin20]

I see we are extending Service Offering to provide a distinct class/table for Business Service.

Any plans to do anything similar for Service Offering? It would be nice if there was some consistency between Services & Service Offerings 

[Dean4]

Hi Michael,

SDLC is short for Software Development Life Cycle.

Regards,

Dean.

[Bruno De Graeve]

hi Scott,

Find my comments included into attached PDF.

Looking forward to understand better how to use the SDLC Component and if we should create child classes for f.i. to describe an API or MicroService as they might have different attributes which cannot be reused.

What about adding an additional subtype, depending on the type and use form views to show certain attributes ? I personally opt for dedicated CI classes.

regards, Bruno

[dick1]

@scott.lemm Thanks for sharing. one question regarding locations.
you state that for leveling you can use the location types basically clear and good to see on what level you are. however for the level country. why create a seperate record in the location table as there is also a country table? Won't this create a kind of duplicate

[Constantine Kr1]

@scott.lemm Really excited about the updates to the Location Management with the addition of new fields, data sources and more. I have checked an OOB Rome instance, and I don't see the features yet as mentioned in the document. Will the new fields be available to install via a plugin or in a later release? Thanks 🙂

[Mark Bodman]

Hello,

Have you tried to add the new fields to the form you are using?  It's there for me: 

[Mike Stockman1]

Hi Michael, SDLC - Software Development Life Cycle.  Also think of the DevOps space when you are talking SDLC.

[Community Alums]

I think there could be more guidance about Location Management. For example:

• Whether adding custom location types is an acceptable practice.
• Whether extending the location table to handle new custom location types is an acceptable practice.
• How SN will hand the new location types that they have added; ie can we expect new tables extended from Locations for things like Site and Room? Or whether these will be new fields somewhere?

[rajivdua]

Wish to check the roadmap for future versions - Are you considering bringing a criticality attribute into relationship verbs as opposed to creating new types that are denoted with criticality?

This has been one of the area where clients have requirements that dependencies are critical or not.

[Bruno De Graeve]

FYI

New CSDM Workshop, Data Model Examples and a Data Modeling Workbook LIVE on Now Create!

Did you know that ServiceNow created and published a new workshop deck and data modeling "kit" that focuses on "Getting Started" with populating your CSDM data into the ServiceNow platform! This workshop covers the roles/personas and what data is essential for starting to align to CSDM.

Check it out, here! CSDM Workshop, CSDM Data Model examples and a CSDM Data Modeling Workbook

ServiceNow heard from our customers and partners that they want to have a more persona and role based information and tools to help them model their data. The workshop does include using the new Service Builder in creating those Services and related Service Offerings. Check it out on Now Create.

[zcurtin]

Can you tell me if the SDLC domain will have ties into tools like Jira at time of release?  Having insight to the code components (API, microservices, etc.) that are related to individual stories/epics would ease some of the burden we have had historically because of how we have had to represent these types of objects up until now.  

Another related question:  Right now we have both API and Microservices represented in Application Service class (because there was no where else to put them).  Will ServiceNow be providing a graceful way to migrate to the new domain?  

[Jimmers]

A lot of questions/comments on the SDLC. I too am excited to see this.  One question which has been ask of me, is "Are SDLC components available to use in the Change Process". Basically can SDLC be consumed as a "CI" in the Change.  Or is SDLC more like Business Application where they are not available to ITSM?

Cheers! Jim

[mikkojuola]

Hello Jimmers,

According to CSDM 4.0 whitepaper draft, the answer is "No". Here's what is written about the SDLC Component:

SDLC Component – New table in the CMDB through the CMDB Schema app version 1.33 in the App Store. Meant to represent the software part or element of a larger whole for applications and infrastructure. Related material may serve as representative of developmental details. If you require identifying the stratification of a Business Application or Digital Product, then the SDLC is recommended. This is NOT an operational CI and should not be used in incident, problem and change.

Maybe someone from ServiceNow can elaborate on this and explain why not. I would imagine that many customers would like to relate tickets to these components.

Best regards,

--Mikko

[scott_lemm]

Hello,

The new SDLC Component table will not directly relate to Jira but the ServiceNow products that utilize SDLC Component, for example DevOps, will have ties into Jira. It is our intention that ServiceNow DevOps and future Service Graph Connectors are utilized as an integration to existing toolsets such as Jira. This effort is done to help normalize the data into ServiceNow. 

Having API and Microservices in Application Service class remains correct to represent the deployed operational instances of these objects. The SDLC Component will not require a migration as it represents the build details of applications and their components while the Application Service represents the deployed instances of the applications. 

Hope this helps,
Scott

[scott_lemm]

Thank you @Jimmers for a great question.

As documented in the draft CSDM 4.0 white paper, the SDLC Component is not considered an operational CI for Incident, Problem, and Change.

Let me explain why:

The SDLC Component in the near future will be referenced by ServiceNow products that contain the details of how an application or its components are being developed. There is no version represented on the SDLC Component, it is version agnostic. The development details for the application/component may result in a version but only at the time of release. At that time the release process will identify where the change will occur. Most release efforts will be associated to an Application Service (an operational object representing a unique deployed instance). If that Application Service CI is existing then the release/change process will utilize that existing CI for the Change. If that Application Service is not existing, the process will create the Application Service to be utilized within the release/change. 

Summary:

• SDLC Component represents the Build activity details and NOT a deployed operating instance of software
• Application Service, most often, represents the unique deployed instance of an application or system thus making it the preferred object on a Change record

Hope this helps,
Scott

[Hendrik Odendaa]

Hi Michael

It's the acronym for Software Development Life Cycle.

Hope that helps.

[schorsch]

Hi Michael,
SDLC is the abbreviation for Software Development LifeCycle. At the end this is not really new, it is contained since a longer time in Service Now to Support Development (Scrum) of Software components.

[Nick Zitzer]

Love the work on all of this! One area where I think there is some opportunity to expand would be the concept of data ownership. In this model, we can see information objects linked to business applications, but I would argue that the data is owned by the business process (capability) and not the application, rather the data set is dependent on the application to manage and store said data.

For example, IT Change Management is a business capability. The process owner should be responsible for defining the requirements to the data needed to track/report/automate the change management process. This conceptual requirement is then translated into an application (ServiceNow Change app) that is used to facilitate that process and capture the data. This means that the information object (change request data) would be dependent on the business application to capture the data and the capability is dependent on the information object to fulfill its responsibility.

The reason I bring this up is the confusion many of my clients see with disparate data sets and systems and establishing ownership of a centralized data model to support a capability or process. For example, people may be tracking project data in MPP, SharePoint, Jira and want to move to ServiceNow, each of these systems own a portion of the data set but struggle to understand how to standardize to one model if the data is owned by the app, not the process.

Thoughts?

[mikkojuola]

Hi Nick,

In case you are interested in how the concept of "data ownership" can be included into this (or any other) data model, let me know and I can show you how things work with a Built on Now app called Data Content Manager. 

Cheers,

--Mikko

[Evan Miller]

I'm seeing what I think is an inconsistency in the white paper (please correct me if otherwise). In the Technical Service Offering definition, there is this paragraph at the end: "We recommend that each CI associated through the Dynamic CI group be related to only one Technical Service and Technical Service Offering. Having multiple Offerings with different SLA, OLA, Support Groups, and commitments will conflict with one another when using new features such as Data Synchronization introduced in Rome."

Doesn't this conflict with this other idea from the Dynamic CI Group definition: "Patch Management – It’s time to patch our 200 Linux servers again. In the Change we select our Dynamic CI Group for or Linux Servers and then have a business rule auto populate our 200 servers into Affected CI."

In explanations by Mark and Scott, with the Application Service Owner persona versus the Technical Service Owner persona, it seems like you are supposed to be able to have an infrastructure CI behind a Dynamic CI Group associated with more than one Technical Service Offering depending on the personas involved.

[Michael Gerochi]

Service Now Professional services has a Solution for Telecom Service Management which specifically focuses on Telecom services and the delivery lifecycle of this industry such as order management of circuits.  Contact them to find out more.  I believe the architect's name is Albert

[Paul Kilkelly]

@scott.lemm Unfortunately my brain is refusing to be reconciled to the idea of an 'application service' as an instance of an SDLC Component, simply because I've gotten used to thinking of an Application Service as an instance of a Business Application - and as a logical representation of the system of integrated parts that together make the Business Application real.  Also, ServiceNow has always described an 'Application' CI as an instance of code running on a single host (and therefore the Application Service is both the application CI and its host).  

Perhaps I'm stuck on an assumption that the deployment of an SDLC Component is a package of code to be installed on a host (or run in a container) - therefore an 'application' CI.  Can you help me get this straight?  

[Paul Kilkelly]

Nick, just my view but I don’t see that ‘Capability’ & ‘Process’ are the same concept (ServiceNow has a CI class for each of them). Neither should own a Data entity. Take the data entities for ‘Customer’, ‘Employee’, ‘Department’ or ‘Location’: they can be defined independently of a process, a capability, or a business application. Each data entity can be used by all three, without being owned by any of them. Data/Information Objects need their own governance to help your organisation build and leverage a common enterprise data model. That’s one of the keys to application and process rationalisation.  

[Melissa Hill]

Hi Scott - any update on this?  I am working in the Public Sector Space and I can see the new data model, but no examples.  We could really use some examples on what Products would be in this space.  Thanks!

[erikbartholdy]

any news on when it will not be in DRAFT state? 

[Michael Oosten1]

Hi, is there any news / documentation available on CSDM for GRC/IRM and CSDM for ESG?

Thanks!

[ianmclayton]

Is this THE Mr Oosten I know from our work together way back when?
Regardless, I'd like to ask how much emphasis is on ESG over there in Europe.  

And to help perhaps, (I feel a blog coming on) and from my experience as a product manager, suggest some context.....

E (Environmental): Which of the elements should get what priority when some seem very 'intangible'.  Do we need to count or guesstimate the carbon footprint of a product or service (from idea to use and then usage by consumers)?   "Count the clicks"

S (Social): Well customer success and data hygiene and security fit well into the product management formula.  The rest are somewhat intangible considerations.  Although there re some products and services that impact my 'mental health'. 🙂

G (Governance): lines up nicely with much of traditional GRC, although some elements fit into apps like HRSD, and partnering/finance.

[SwarnadeepNandy]

Hi Scott,

In the Foundation Phase, a new block "Business Process" has been added, which in my view aligns with ITIL v3 processes (maybe there is no strict guideline around it by CSDM), but in ITIL v4 it has been changed to Practice. So Will the notion of Business Process will also change to Business Practices?

Thanks for the fantastic CSDM 4 whitepaper.

Best Regards,

Swarnadeep Nandy