Best Practice for Representing Application Modules in CSDM

[EssnZilla]

In our CMDB (aligned with CSDM v4), we currently have Business Applications and Business Services defined — for example, Outlook as the Business Application and Email as the Business Service.

Similarly, other applications are classified this way. However, when it comes to application modules, some are microservice-based while others are logical components of the main application.

For instance, our Passenger Booking Application includes a Billing Module (a separate microservice) and a Fare Module (an inbuilt feature within the main app).

I’d like to classify incidents by module when issues are reported and also route change approvals to the respective approvers based on these modules. Currently, our CMDB only defines Business Applications and Services — so we lack lower-level granularity.

👉 Question:
Which CSDM domain (Design, Consume, Capability, or Build) should these application modules reside in?
Are there any existing tables or CI classes recommended for representing these modules?

One option I’m considering is using the cmdb_ci_appl_component table to record logical modules as components, or alternatively, defining them as child Business Applications.

Has anyone faced a similar challenge? How are you modeling and managing application modules in your CSDM-aligned CMDB?

[Phil Scherry]

I would put them as Technical Service Offerings in the Technical Service domain:

• Technical service offering table [service_offering]

Technical services

Technical services are associated with service owners and are typically layered under one or more business or application services. A technical service may have one or more technical service offerings.

Technical service users can view and manage the technologies that you provide to the business. Event Management enables you to monitor service performance. You can also use Event Management to identify health issues for related infrastructure CIs and application services.

Technical services can be managed as part of the Service Portfolio in the Sell/Consume domain (that is, a Service Portfolio hierarchy can be referenced from a Technical Service). This allows for a more complete hierarchy and management of both Technical Services and Business Services within the Service Portfolio Management workspace and related workspaces. You can make better decisions when you know how spend on technical services can improve performance and reliability of your business services.

Note: Business services and technical services connect to the spm_service_portfolio through the spm_taxonomy_node. See Service Portfolio Management taxonomy.

Technical service offerings

Technology consumers can request technical service offerings (SO) through the request catalog. Catalogs are described in detail in Service Catalog. The consumer can typically select the following features and options:

• Level of performance
• Location or geography
• Environment
• Pricing
• Availability
• Capability
• Support group (for incident)
• Technical approval group (for change)
• Packaging options (commitments)

Technical service offerings typically have the following components: One or more service commitments

A service commitment defines the service delivery obligations agreed to between the consumer and the provider. Service commitments uniquely define the level of service in terms of availability, criticality, scope, pricing, and other factors. For example, an organization may offer two levels of support for an application service:

• Support for a production-level offering: Provides a high level of availability and criticality for production instances. Includes a 24/7, 5-minute response time guarantee (24 hours per day seven days per week).
• Support for a non-production-level offering: Limited availability and criticality for non-production instances. Includes a 60-minute response time guarantee between 8:00 a.m. and 5:00 p.m., Monday through Friday.

A service offering subscription that records which users have access to an offering

Technical service offerings that are mapped to the [service_offering] table are classified as “technical service" and are derived from the service. The technical service offering is based on how the parent serves a specific technical need. Every operational technical service should have at least one technical service offering.

Each CI associated through a Dynamic CI Group can be related to only one Technical Service or Technical Service Offering. Conflicts can result when one service includes multiple offerings with different SLAs, OLAs, Support Groups, and commitments.

[EssnZilla]

Thank you for taking the time to explain; it’s detailed and informative.

I am already using the child classes (of the service class), like business services, application services and technical services to represent business app/services, application entry points and underlying web services.

Technical services represent shared IT capabilities, such as the underlying IT / technology services that enable the application.

By modules what I am referring to is the subunits or features within the application. Going by the previous example, in the booking application, fare module in a built-in feature it's part of the same source code, likewise we have scheduling module, availability module, communication module etc, all are logical modules (or features) within the same application. 

The performance, availability, and approvals all are tracked through the main business service and the business application CIs. The module is an additional bifurcation under the business application CI. For trend analysis.

Question is where to place them; under which table/class. 

Not technical services because these aren't technology enablers

Not application service, because this is not a runtime, deployment or an entry point to the service.

I am thinking it should be the cmdb_ci_appl_component table or the cmdb_ci_business_app (bis app) table where the modules will be created as child CI's for a specific Business application.

[changeman]

Based on our interpretation of CSDM 4 as well as other ServiceNow documentation (if you don't have it already, I highly recommend a PowerPoint slide deck titled CSDM Data Model Examples, which contains lots of actual model examples as well as comparisons to other architecture standards), we have modeled our modules at two levels:

1. For platforms (large systems), we use Business Application/Application Service pairings to denote what we refer to as independent modules that only require the platform itself to run and can often be purchased independently (e.g. ServiceNow SPM, ITOM, etc.). Such Business Applications have their Architecture Type set to Platform Application, which then enables the reference to the Platform Host (which is Architecture Type set on the core Business App). Platform Application Services depend on the Platform Host Application Service.
2. For dependent modules, that is those that support the whole system or platform and wouldn't be purchased completely on their own, we use the Application CI class (cmdb_ci_appl), which is defined as "any deployed program or module that is designed to provide specific functionality on specific compute infrastructure. An application defines behavior and has specific functionality associated with it. Applications are typically discoverable instances and tend to provide a specific set of functionalities for one or more services." Examples include interface brokers/gateways, reporting tools, access/user security management tools, etc. For us, the MID Server is an Application that the ServiceNow Platform Host Application Service as well as the ITOM Platform Application Service depend on. The Application CI class is two levels down from Business App: Business App consumes Application Service, which depends on Application. While this CI Class may have been meant for discoverable processes (running software or process), we aren't using it in this fashion: most of our Applications are manually created and we feel they still meet the CSDM definition of being specific functionality.

I can't speak to the suitability of cmdb_ci_appl_component to model modules since we don't have this table in our instance (Yokohama) and I don't see it in the CMDB table descriptions on the Documentation website.

[Barry Kant · Accepted solution]

This is one way to do it:

 Have indeed a 2-layer business application:
 - Platform/Host
 - Application/Module

You would do this when:
 - your build/models/deployments/funding is/can be different/separate.

Each of those records will have Application Services below per deployment:
The Business Application for the Incident application component will have an Application Service per deployment with a depends on relation to the platform deployment Application Service.

BR,

Barry