The CreatorCon Call for Content is officially open! Get started here.

Best Practice for Representing Application Modules in CSDM

EssnZilla
Tera Contributor

6 hours ago

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?

0 Helpfuls
  • 123 Views
1 REPLY 1

Phil Scherry
Tera Guru

3 hours ago

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.

0 Helpfuls