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!!!!

[Inactive_Us1692]

I would urge caution here as Practices within ITIL 4 for are a larger construct that include processes and are not a direct replacement. Practices take into account all of the dimensions of Service Management:

• Organizations and People
• Information and Technology
• Partners and Suppliers
• Value streams and Processes

My caution from here is that these other dimensions are likely to be attributes of the CIs rather than being represented as CIs themselves.

David Nottingham

[Sarah72]

@scott.lemm @Mark Bodman  We have found the CSDM to be really useful and have adapted it (v3.0) for our organisation.

We already made the change in our documentation, but I would suggest that the CSDM not be comprised of "Domains" - we used "Dimensions" instead.

I realise most ServiceNow customers may not use domain separation, but for those that do, Domain is a loaded concept. You could explain that  CSDM Domain ≠ ServiceNow Domain, or change the CSDM documentation next version, to avoid confusion.

[Glyn Tomkins]

@scott.lemm  valuable content. 

I think that there is also a typo in regards to the SDLC component in that diagram too.  in page 2, what's new, it refers to cmdb_ci_sdlc_component, however the table on page 22 misses the _ci. 

regards

[Mark Bodman]

Hello Sarah,

Domains are a common way to separate our details when modeling, we are just using what's commonly used in architecture practices. In software practices, in master data management,  in business modeling, and many other practices. We wouldn't want to adopt something that is not a standard practice in modeling information to describe the CSDM domains.

[ianmclayton]

Late to this - but I agree with Mark.  Good question and healthy discussion.  

My 2c - I'd suggest....
A domain is a separation of something - a partitioning method to establish major boundaries based upon perhaps scope of content, or governance, or total responsibilities.  Rather like a kingdom (kings domain). (its 2D)

A dimension is more of a perspective based view, has 'coordinates', and is a measurable attribute of a space. For example, length, width, and height are dimensions.  A dimension can describe an element of a domain, or something spanning many domains, perhaps like zip code area.   A dimension can support a particular operational aspect.  (its 3D)

[ianmclayton]

Oh hit enter too quickly -

In the Universal Service Management Body of Knowledge (USMBOK), I use 7 'knowledge domains' such as 'Service Customer Management' and 'Service Fulfillment Management', spanning the outside-in (customer centric) to Inside-Out (infrastructure centric) continuum.

Each knowledge domain has a distinct set of knowledge skills and abilities and position within the service provisioning model.

Each domain has six core 'Knowledge Areas' (akin to capabilities), representing must have capabilities.  This is close but not an exact fit to how some use 'dimension' as they do not span domains in my case.  They interact and interoperate with other elements of the USMBOK.

[Phil Scherry]

I know 4.0 has not been released in final version yet. 

1. Would you recommend customers stay with version 3.0 if they are not ready to track the SDLC area?
2. How would you map an OTS (Off the Shelf) application that doesn't receive any SDLC?

[Johannes]

Hi,

One place it says:

"Technical service is a service type that is published to service owners and typically underpins one or more business or application services"

Another place it says:

"Application services roll up to cmdb_ci_service_auto for common reporting and they underpin a business or technical service. "

May Technical Services and Application Services mutually underpin each other?

[CMDB Whisperer]

That's a great callout.  From my experience the term "underpin" is most often used in the context of SLAs.  Your SLAs (or service commitments) are often dependent upon SLAs of other services.  For example, you may have certain Availability targets or RTO/RPO commitments that you need to meet.  In order to meet them you need to know the dependencies you have on other services in order to provide your service, and the applicable service commitments for those services.  So in this case it is a service-to-service dependency that we are interested in.  When we look at CSDM, we have to ask ourselves, where do we define these different service-class CIs and where do we define their respective SLAs?  Because we are basically making the traditional concept of an "IT Service" follow a composition model, the service is ultimately composed of several components: the application service that represents the deployed infrastructure, the service offering that represents the management of that service, and the technical service that represents the outcome that is delivered to consumers. 

So while it is true to say that the technical service has a dependency on the application service that is used to provide its outcomes, and it is also true to say that an application service can have a dependency on the technical service, these dependencies are actually different types of dependencies and it is not necessarily a cyclical/mutual dependency.  Technical service A may have a dependency on Application Service X, which may have an underlying/underpinning dependency on technical service B, which may have another dependency on Application Service Y, and so on.  In my opinion, using the term "underpinning" should necessarily have a component of SLA or service commitment to it, and according to CSDM, that would be defined on the Service Offering, not on the Technical Service and not on the Application Service.

[dick1]

looking at the csdm 4 on the lifecycle and mapping it in the tool I run in to this consistency in models

the white paper gives the following flow (see attachement)

However when mapping this in servicenow to a model 

you can only select Design/Build --> Operational/available --> end of life/retired

What happend to the other statusses? eg a model can be pending retirement 
I'm trying to map our legacy states and they map more or less to the white paper but now not to the implemented variant.

[Adi Schmid]

We face the same question. Two weeks ago, @Marcel Leu  already opened a corresponding post.

[davidgustafsson]

Hi

I have an issue with what, to me, looks like an inconsistency in the CSDM model. It is about relationships from Service/Service Offering to Infrastructure CIs.

A platform (say Microsoft Servers) is a Technical service. It is provided to the rest if IT through several Service Offering (say Gold, silver bronze). That is, Application Services are using one or several of these Service Offerings and hence have a dependency to that/those Service Offerings that is represented by a CI Relationship. Also these Service Offerings are containing Infrastructure CIs (in this case Microsoft Servers) that dependency is represented by a CI Relationship. I guess that you should have it on the Service Offering and not the Service as each Service Offering may have a different set of CIs that it is containing.

But as the question then comes to Application Services that have a dependency to Application CIs it is not treated the same way in CSDM. Here the suggested dependency is created from the Service (not the Service Offering). In my head the principle are the same as a technical service just that it is about an application and not a non-Application infrastructure component.

Why does not the Application Service Offering have the relationship to underlying CIs (Applications) and why should it be the Application Service?

Either I miss something here or there is something that is not correct with this CSDM model.

[Andreas Balbach]

Why does not the Application Service Offering have the relationship to underlying CIs (Applications) and why should it be the Application Service?

Because the Application Service (prod(dev/test/train, whatever) is a logical representation of one of  its deployed sw installations. Like the name on the door of a building.

[CMDB Whisperer]

Basic idea is correct, but a couple of subtle details worth correcting for purposes of accuracy.  There is no "Application Service Offering", per se. There is an Application Service and a Service Offering. The Service Offering (or just Offering) describes how the application is being managed as a service, i.e. its service commitments (SLA, RPO, RTO, Availability, Schedule, etc.) whereas the Application Service is an instance of a Business Application which is used to provide that Offering.  The second point, is that it would be better to refer to the Application Service as a deployed instance of a business application rather than a "deployed software installation".  A software installation is a specific piece of software that is installed on a specific server, whereas a single Application Service actually can typically include multiple software installations across multiple servers, all of which are components of that single deployed instance.  

I like to think of it like this: the Technical Service describes the desirable outcome that is being consumed, and the service offering describes how we are providing that outcome to consumers as a managed service, and the application service encompasses a specific deployed business application that allows us to provide that service using our IT infrastructure.  In practice the can and often are thought of as the same entity, but CSDM separates these as separate components of the service that is consumed, and it is often not a one to one relationship because a technical service can consist of multiple offerings, and a single offering can even include multiple application services.

[davidgustafsson]

Thank you. I think that clears up things a bit more to me now. Just to test my understanding on you I´ll try to write an explanation in my own words.

If I understand you correctly then Application Service is not a service (even though defined as such in: What are services and service offerings?). This despite its name and despite it being held in a child table to cmdb_ci_service table. I also noticed that Dynamic CI groups are a child table to Application service table so they are clearly closely related.

With above in mind I take it that the Application service is to be viewed in the same way as a CI group rather than a service. Also that is why you should relate CIs directly towards an Application Service and not towards a Service Offering.

The question on why not relate Technical service Offerings directly towards a Business Service Offering I take it is because Technical Services are treated as an own kind of internal Service. That is even if the business Service uses the Technical Service it does so through an Application Service and a Business Service (Offering). 

Trying out some examples:

Business Service

• Name of service: Workspace
• Description of Service: This Service is providing a fully functioning workspace (limited to IT parts for ease of example) that includes Client computer, Email, etc.
• Type of Service: Business Service
• Business Service Offerings: Advanced and Normal (Advanced with a heavy duty computer)
• Depends on "Application Services":
  • Email Prod
  • Email Non-prod
  • HW-client distribution Applications Prod
  • HW-client distribution Applications Non-Prod
  • ...

Application Services

• Name: Email Prod
• Is contained by Technical Service Offering:
  • Server Hosting

• Name: HW-client distribution Applications Prod
• Is contained by Technical Service Offering:
  • Client Computers Advanced
  • Client Computers Normal

[CMDB Whisperer]

I can understand the temptation not to consider an Application Service as a Service, but in fact it is a service, just a different kind of a service.  A service is defined as the delivery of valuable outcomes to a consumer.  In that sense, the outcome provided is the access to a running business application, and the consumer is basically identical to (or a subset of) the consumers of the offering.  The application service is a service that provides the application.  It is the hybrid, or pivot point, that describes the actual usage of the application.  And in the platform it does behave as a service, in that it will be detected as one of the Impacted Services on a Change or Incident if the associated/affected CIs are part of that service.  

And yes, by its nature the Application Service does basically provide a "grouping" of CIs, i.e. it contains all of the CIs that have a dependency in the service map.  And thus Dynamic CI Group makes sense to extend the Application Service class, in that it provides the same function in the CSDM, i.e. to tie specific groupings of infrastructure to a context of how the infrastructure is managed as a service and consumed by consumers.  The primary difference is that the Dynamic CI Group is often categorically grouped based certain criteria and that it typically does NOT represent a deployed instance of a business application.

As for your specific examples one thing I notice is that you are splitting your service offerings based on the service commitments/agreements.  That's not wrong and it is a legitimate way of defining your offerings, but it is worth noting that it can conflict with other ways of defining your service portfolio.  It's certainly an area where more subjectivity can arise.  Beyond that I can only comment on the specific example of Email being used for Server Hosting.  That doesn't seem to be a logical dependency, so I'm not sure if that was just an error (we don't really use Email application to provide Server Hosting outcomes).  Second aspect of that is that if the application service is a true instance of a business application, it's probably going to be called something like Exchange Prod rather than Email Prod.  Typically I would expect the name and specificity of an Application Service to indicate both what Business Application it is an instance of, and what Environment type it is being used to service. 

Also, in my experience the use of Prod application services is very different from the use of non-Prod application services.  The Prod application services are often not part of the same technical or business service.  Typically the technical or business service are ONLY associated with the Production instance, because the non-Production instance doesn't actually provide those outcomes to consumers.  Rather, the non-Production instances are used for overall systems development and testing related technical services.  For example, we can have ServiceNow Prod used for Service Desk (technical service) with a service offering of Incident Management, but Incident Management won't have a dependency on our ServiceNow Dev/Test instances.  Rather, those non-prod instances could be components of a ServiceNow Platform Development offering which is one of the offerings of Enterprise /IT Systems Development.  But all of the ServiceNow instances would still be related to the main Business Application called "ServiceNow".

[Marc30]

Thank you, guys, for the fruitful discussion. Very insightful.

Talking Application Service, I tend to see it as the instantiation of a Business or Technical Service. One could also think of the concept of a Service System, such as e.g. IT4IT describes it. I.e. the system that is required to be kept up and running, in order to allow consumption of the Business|Technical Service and its Offerings.

Now, as I see it, Application Services can be used to describe instantiations of Data Center services. What I seem to still lack from CSDM 4.0 is the analog model for the instantiation of Client services. 

[Jan58]

I would consider "Infrastructure SDLC Components" as a kind of "configuration baseline" to be used/rolled out to new CIs. Whenever a new version of this configuration baseline is about to be developed, a new version or a new SDLC component would need to be defined.

[Mathew Hillyard]

I'd echo the comments above about wanting an update on progress with CSDM 4.0 moving from a Draft status. One of the sources of confusion for me is that with v4.0 there are two possible places to store a Business Service

• Business Service [cmdb_ci_service_business] table - now recommended for v4.0
• Business Service [cmdb_ci_service with a Service Classification of "Business Service"] table - existing (and presumably to be deprecated, used in v3)

However, links within Application Modules are inconsistent in their application. For example:

• CSDM > Business Services = Business Service [cmdb_ci_service with a Service Classification of "Business Service"]
• Service Portfolio Management > Business Services = Business Service [cmdb_ci_service_business]

For Technical Services, all links point to the newer Technical Service table [cmdb_ci_service_technical] rather than [cmdb_ci_service with a Service Classification of "Technical Service"].

Looking at a current Tokyo instance this hasn't changed. Any plans on the Roadmap to change this as for customers looking to implement CSDM now, I wouldn't recommend starting with v3.0 and putting all Business Service data in the original table - it would just mean extra migration work later. Some advice and roadmap will help customers just starting on the CSDM journey.

[Thomas Wright1]

Is there a reason that Technical Service Offering Managed by Group, Support Group, and Change group can only propagate to CIs via a dynamic CI group? This seems very limited.

What if you have support for some infrastructure defined at the Application Service level rather than class level? I feel this functionality would be much more useful if we could associate a Technical Service Offering to any type of Application Service and have the groups propagate rather than being limited to Dynamic CI Groups

@CMDB Whisperer 

[CMDB Whisperer]

I believe the logical use case for this is that if you are managing CIs that are not necessarily part of an top-down Application Service then you are managing CIs that are similar in nature/classification/criteria -- for example, all Production MSSQL Database Instances within a Business Unit, or all Windows Servers in USA -- then you probably have single sets of responsible teams for this.  However, in the case of an Application Service, your responsible teams aren't based on a single service.  We still want the Windows Server to go to the Windows team, and the Database instance to go to the DBA team, even though both of them are used as part of a single Application Service.

[Jan58]

@Thomas Wright1in the Application Service form, we are able to reference a Technical Service Offering and link it this way to either represent different instantiations of a service (e.g. several productive instances) and/or different service environments (DEV, Test, QA, PROD). So I think, there is no limitation to also make use of Application Services in the context of Technical Service Offerings in order to show, which components are meant to work together to offer a desired functionality.

[Paul Kilkelly]

@Jan58 when you say ‘reference’ do you mean a custom reference on the app service? As I understood it, the original question, was regarding use of CSDM Data Sync to push management data from a tSO to contained CIs without using dynamic CI groups. 

[Jan58]

@Paul Kilkellyone part of the question @Thomas Wright1 was asking was about "associate any type of Technical Service Offering to application services" and this was the part I focused on with my comment.

This is how it looks like in my Tokyo developer instance:
You need to open the application service form using the CSDM-View.

When you open the Application Service using CSDM view, there is a section called "Set Relationships". Within this section you have tabs to add relations to "Business Applications", "Technical Service Offerings", "Business Service Offering" and "Parent Application Service".

So using Application Services you are free to use whichever method you like to fill the ServiceMap -> manual, automatic service mapping, query based or tag based.

Example: Application Service linked to Technical Service Offering in CSDM view

Reference shown in Technical Service Offering default view:

[Rachel37]

Good afternoon Scott,

This is extremely helpful, thank you for sharing.  I noticed the version hasn't been updated since early 2022, is there a V3?

Thank you

[The SN Nerd]

Hey,
I have heard whispers of CSDM v5, but i still haven't seen a non-draft version of CSDM v4.

When will CSDM v4 be considered official?

Kind regards,

Paul

[CMDB Whisperer]

@The SN Nerd a few weeks ago @Mark Bodman indicated that there were no definitive plans for releasing a new version and that practically speaking you can consider the Draft V2 version as "official".

[Lisboa]

Diving into the white paper.  Lots of great content in here!

Minor observation on grammar - see a lot of "we have a processes that identifies..." in the Life Cycle section of the document.  As the document moves forward, might want to have those cleaned up.

Know it is a minor thing, but this error repeats multiple times and was a little jarring to read through.

#CSDM

[Lisboa]

Two practical thoughts about CSDM:

1. Would like to see how ServiceNow maps ServiceNow across the CSDM 4.0 landscape.  It would be the textbook example of applying the logic and schema described within this white paper.
2. Why wouldn't ServiceNow be included as the first and default entry for CSDM when consumers stand up a new instance - or a personal developer instance?  What better way to demonstrate the application of the CSDM philosophy that people could leverage as they try to crawl/walk/run/fly?

For companies that strive for CSDM maturity this is where ServiceNow could continue to be the leader and demonstrate its mastery of its platform.

[Jim41]

@Mark Bodman or any others with ideas.  We are getting pressure to add API's to the CMDB, has anyone added API's based on using the CSDM 4.0 V2 model?  If so, where did you put API's in the CMDB and how did you make that decision?   Any input is greatly appreciated from all!  Thank you

[Jan58]

@JimMwhen you are talking about an API service you operate and provide to others, I would propose to represented this a Service offering - either Technical Service Offering or Business Service Offering.

The API will not be accessible / usable as any other business application without an endpoint and components which handle the requests. These components may be load balancers with pools and hosts as well as software running on these hosts. So similarly to a usual business application, an API service could also be represented as an Application Service for different environments like DEV, TEST and PROD and these Application Services point to the components they actually depend on.

In case you are talking about APIs you consume from external service suppliers, I would also follow the same approach above, just leave the Application Services empty, maybe add the URL endpoints if possible to link incidents from Event Management and monitoring. (not sure if it is possible to include URLEndpoint-CIs in an Application Service map - there was a restriction in former releases as far as I remember)

[Jan58]

@Jim41I assume you are talking about something like REST APIs, accessible through http/https requests. I would see such API services always as a Service Offering - either operated or provided by your own organization or consumed from an external supplier. An service offering should be used whenever support groups, SLAs or prices differ. So such an offering record may point to the responsible groups and contacts as well as have SLA targets defined.

When we are talking about REST APIs, there needs to be a URL to be called in order to use it. This URL may be represented as a CI in the CMDB representing the central access point you depend on and which you monitor from consumer perspective.

If you operate the API service on your own, you will depend on different components like load balancers, databases, hosts and software services running on those hosts. This may be represented as Application Service with relevant components added to the Application Service map. Using the Application Services  allows you to represent different environments like DEV, TEST and PROD pointing to different sets of components.

[cyked]

The CSDM documentation specifies that in the build domain SDLC components encompass things like APIs and mircro services, the things your internal groups develop and manage and represent specific functionality or development efforts around your business applications. 

I view this as you may develop distinct services, something like a chunk of callable code on your website that calculates tax or shipping cost based off zip.  APIs describe the components and configurations of how two applications exchange data, but neither of these objects are the business application/instances themselves.  They can also, in the case of services, but singular but related to multiple application services that utilize them/where they are deployed.

[Carolyn Rast]

@scott_lemm I've seen a few references in the last couple weeks suggesting the CSDM 5.0 draft is in circulation - where can I find it? I HAVE to know -- did you relabel Application Service (System)?  

[scott_lemm]

@Carolyn Rast unfortunately, CSDM 5 is not in "circulation". The reference is coming from people that have been present for a roadmap presentation I or Mark have given. CSDM 5 is still being researched internally as we work through technical development and planned feedback. Circulation will not occur until 2024. 

And no, Application Service is not yet relabeled 😞

[CMDB Whisperer]

Although it is not yet in draft or circulation, it would be great to get some visibility into what the actual "Digital Product" concept might look like in practice, from a data modeling perspective.  I know that some configuration managers, practitioners, application and service owners, and professional consulting service providers have a lot riding on this and it should happen either seamlessly or not at all.  The very premise of CSDM was to lay out the differences between what is an application and what is a service.  They are very different things.  A service represents the value that gets delivered.  An application represents a computer program or programs put to a specific use.  A product represents output of a process (development process, service delivery process, manufacturing process, etc.).  And yes I agree that there is a lot of value in blending those together from a management and visibility perspective, and I like a lot of where DPM and SPM are headed along those lines.  However, from a CSDM perspective we're talking about data modeling, so what these terms mean and how they are defined and classified and related to one another and to other parts of the data model matters.  A lot.  The way it appears "on paper" in the CSDM 5.0 previews that have been provided, it seems suspiciously that perhaps the goal is to combine Applications and Services into a single class called Digital Product.  That would be a mistake in my opinion.  I would be fine with re-labeling classes to make them more aligned with industry standard terms, but as for how the platform and its customers operate, I see little to no benefit and lots of risk to radically changing the data model to intentionally blur or eradicate the lines between applications and services.  The very thought of it stresses me.  I'm hoping we can get some reassurance that this will not be the major data model refactoring effort that it seems to be positioned as in the glimpses that have been shown so far.

To be clear: this is the glimpse I am referring to, which came from a post from @Mark Bodman

[Robin Chytil]

Hi agree so much with Paul (CMDB Whisperer)!

First, I am 100% in favor of the renaming of "Application services" as "Systems" ("Application service" is adding confusion between a service and an application, which is very well explained in Paul's post). And it goes back to the good ol' way of calling an "set of things working together as parts of a mechanism" (Google).

Second, I like the term "Digital Product" for a group of service offerings, in different flavors (features, service level, location, etc.). The word "Product" definitely helps IT departments think in terms of value provided to the customer, with a cost (or price) attached to it, much better than "Service", which is way too vague and still not understood the same way by everyone.

But using Digital Product for a Business application is creating confusion compared to the "Digital product" proposed to the end-users.

And this is even worst for Technical services, which are probably the only "services" that everyone understand: database administration, platform support, service desk, azure management, desktop support, etc.

Therefore, I would prefer the following terms in the CSDM 5:

• Digital products (replacing Business services), provided through various Offerings
• Business applications (used to build Systems and provide specific Business capabilities)
• Systems (replacing Application services, i.e. instances of a Business application, accessing databases and running on infrastructure components)
• Technical services (management or support functions, or groups of components provided by IT and required to build or maintain systems)

Any feedback is very welcome.

Robin

[CMDB Whisperer]

Personally I would prefer keeping Services for Business/Technical Services, and I don't really see a problem with the terms.  They describe methods of delivering valuable outcomes to consumers, and that is both a good definition for the layperson and the IT professional.  We do work for people as a service that they don't have the tools, skills, time, or willingness to perform on their own.  That works to describe someone working in a food truck just as much as it describes someone provisioning and managing virtual servers.

If you look at TBM as a model, and start to pick on some of the Services/Solutions that it defines, you will see things like Workforce Collaboration and Employee Development.  These are not "Digital Products".  They are Services.  They are supported by Applications.  Some Services may be "Product" related, but others are not.  And trying to pretend that they are is going to influence how people define their Portfolios -- not necessarily in a good way, or in a way that allows for flexibility.

I agree that replacing Application Service with System is a good step.  (Personally I'd also replace the "Consumes" relationship it has with Business Application, which is very confusing). 

I would propose the following definitions:

Service - A valuable outcome that is delivered to consumers (either technical outcomes or business outcomes)

Offering - How the valuable outcomes are delivered to consumers using information technology and how the service is managed according to agreed service levels; multiple offerings can be defined based on the specific people, places, processes, and technology involved in the delivery of the service.

System - A set of things working together as parts of a mechanism, e.g. a logical grouping of similar things  that serve a common purpose (Dynamic CI Group) or a set of devices that function together as components of a business application deployment (Application Instance).  And yeah, if you rename it to System, you'll want to rename your Mapped Application Service as well, and I do think Application Instance would be a good choice, because that's what it is!

Application - One or more computer programs put to use for a specific purpose. 

Business Application - An application used to provide specific business capabilities or to solve certain business problems.

Product - The tangible output of a process (software development, manufacturing, business services, etc.) which either is used to enable service delivery or is the deliverable outcome itself.

Solution (or maybe Digital Product, although I prefer Solution) - A logical grouping of Products, Applications, and Services used as part of a common purpose or business goal.

[Mark Bodman]

The concept of Digital Product has been in development for more than 4 years.  One of the pivotal moments came from a meeting between David Thigpen and myself, as we sat in a room and envisioned what a merger of Business Application and Service would look like.  Caitlin Morse was in that room with us, and went off to create Digital Portfolio Management, a new product that reflect a large step in this direction that you can listen to in this video. 

Another consideration is our work has been the rise of DevOps practices, leading to a singular concept we can help us simplify tracking activities and deliverables across spanning Development and Service Management.  Having been involved in thousands of APM implementation since the early 2000's, I also recognized by this time that there was a fundamental flaw in not addressing service management concerns from the very beginning of the ideation process. 

Myself and many others worked together on this idea for approximately 2 years, culminating in publishing the Shift to Digital Product white paper, ratified and published by The Open Group, now available for download here.  It was decided by the broader standards community that the concepts captured in this paper were applicable to wider range of standard and guidance forums.

Subsequently, the IT4IT Standard was re-factored around this concept, released as a draft initially about 18 months ago, and released as 3.0 in December of 2022. Training and certification was finalized a few weeks ago, and the book publishing was completed, so the IT4IT standard can now be ordered from Amazon here or accessed online here. 

About 2 years ago, I discussed the mapping and potential impacts to CSDM in this video, and more recently in this video. @scott_lemm  and I have been presenting and discussing further refinement and thoughts on the future of CSDM at Knowledge this week to further establish how we will proceed.  

Please note that while these DRAFT revisions have been floating about for a while, exact details on how we will proceed have not been decided nor delivered yet.  We do appreciate the discussion thread on this forum, and would encourage folks to further explore the broader work being published, and looking at some of the products and features reflecting the evolution of this concept of Digital product and moving our thinking forward.

[CMDB Whisperer]

Thanks @Mark Bodman for the reply.  I've been following this closely, and I appreciate the intent behind this work and support the general approach.  I do hope there will be transparency around those technical details about how the actual data model will be taking shape as you get closer to decisions.  Since CSDM has grown to be an area with high value and visibility and priority to customers, the sooner we can prepare for any fundamental refactoring the better, especially for those of us in the Professional Services field, so we can continue to properly guide ServiceNow customers along their CSDM journey.  Looking forward to continuing to hear more about the establishment of the next iteration of CSDM!

Also, have a great time at Knowledge!  Sorry I won't be attending this year.

[muheer basha]

Thanks

[jnipala]

Hi Gurus

Has CSDM and CMDB model totally missed how to document Integrations between Applications?

I haven't seen any tables yet where to define integration related information eg. between different Business Application or Application Services (AS) etc. 

For example I have Application Service X Prod which communicates with Application Service Y Prod or Business Application X and Business Application Y which are somehow integrated together. These Business applications or AS can change information point-to-point, one-to multiple. or using integration platform, uni-directional or bi-directional, push-pull, asyn-sync, real time - Batched, protocols used for communication, format of data used etc.  

Documenting Integrations by using only relations do not have attributes mentioned above which would be very useful to have available in servicenow system directly from Ci and not only in knowledge articles or separate docs. 

Any comments or ideas about the topics, please ?  

[Jan58]

Hi @jnipala

the CMDB knows CIs of class "Endpoint". When you open the CI Class Manager and search the hierarchy for "Endpoint", you will find different types of end points, e.g. TCP Endpoint. I would use the Endpoint CI classes to represent interfaces provided by an application and either extend the existing CI classes to represent a missing endpoint type or enhance the attributes of an existing endpoint CI class. If you have an application providing a RestAPI interface, you could define a new CI class "URL Endpoint" as extension of the TCP Endpoint class and add attributes to define the type (e.g. XML, JSON, ...), the protocol (e.g. http/https) and a relative URL to eventually distinguish it from other endpoints offered by the same application.

I guess, there is always one application requesting the interface connection (consumer) and another one accepting the connection request (provider) - irrespective if the interface is uni- or bi-directional.
The Endpoint CI representing the "provider" may refer via dependency to the Application Service it is provided by. And the Application Service, which consumes the interface may point to the Endpoint via dependency.

[Dennis Magnuso1]

@jnipala Have you checked out Management of digital integrations under Application Portfolio Management as of Utah? 

[jesjuar]

Hello CSDM experts,

I'm seeking guidance on how to model a mobile app that falls under a different ownership compared to its platform. Let's take, for example, the ServiceNow Agent app. Its owner and support group differ from those of the ServiceNow Business Application and the various ServiceNow instances (Application Services).

Could it potentially be classified as a separate Business Application? And if so, could it be linked as a Business Application "app" to the ServiceNow "host" Business Application?

In general,  how should we model different user interfaces or devices that are part of the same application? E.g. for attaching them to incident, changes, etc.

Thanks for your insights!

[cyked]

Having different ownership/support of an application is likely good enough justification to register them as a separate business application, regardless of whether you utilize offerings or not (so you can avoid having a single business app/app service pointing to multiple offerings and related commitment/routing details).

Another use case would be the applications depend on a different set of infrastructure and software from each other.  I've seen this be the case in examples where a web app and the mobile version rely on completely different technology.

As for linking them, create your "platform" business application and set architecture type to "Platform Application".  Then, when registering business applications enabled on your platform, set the "Platform" attribute to the business app you specified was a platform app.  Ex. you have ServiceNow as a "platform application" and register unique business applications for incident, change, and problem. Each of these, set the "platform" attribute to ServiceNow.

[Johannes]

@jnipala 

We have been thinking about modeling our different applications APIs in the CMDB.

We would create them as "Application Services" and have

- one "Depends on/Used by" upstream relationship up to their respective parent "Application Services",

- one (or more) "Receives data from/Sends data to" upstream relationship(s) up to the "Application Services" using the APIs.

(I believe this is correct according to the relations described in CSDM v4.0.)

Seems like the "Digital integration" records mentioned by @Dennis Magnuso1 would be more of a meta-information regarding the integrations, kind of the same as how a Business Application contains the metadata regarding an application, whereas its child Application Services are the operational "instantiations" of the application.

When looking at "Digital integrations", I believe we should maybe create the records there first, and then (preferably automatically) create the "instantiations" (the API Application Services) based on those.

What do you think, @Dennis Magnuso1?

[jufru]

Do you have a final release for the document ?

[jnipala]

@Dennis Magnuso1 

Have you checked out Management of digital integrations under Application Portfolio Management as of Utah? 

Yes that is APM tables and contains more or less all needed attributes for integrations&interfaces but unfortunately it is not operative table so not able to use it eg. in Incidents which is the need now.

[SteveMacWWT]

@jnipala Take a look at @vNick's article on 'New Data Model in CMDB for APIs'.