Unclear Relationships Between Service Offering and the Services It Contains

CD4WG
Tera Contributor

Situation:

  • Reviewing and cleaning up a technical service offering that's being phased out.
  • The company has restructure one team into multiple teams, each with separate service offerings.
  • I'm mapping all application services associated with the original service offering to make sure that they are re-mapped appropriately.
  • In some cases, stakeholders are confused as to why either a technical or application service was mapped to the original service offering, since they don't answer tickets related to these services.

Solution:

  • If the relationship (contains) always indicates incident support, then I can ignore remapping items the new teams don't handle. However, I need to rule out the possibility that the mapping might represent some other, less obvious connection.

Question:

  • Does "contained" always imply support for incident resolution?
  • Could "contained" indicate other types of relationships?
  • Example: A service offering for software deployment distributes different software programs—would the corresponding application services still be mapped to this offering even if the team doesn’t handle tickets?
1 ACCEPTED SOLUTION

CFrandsen
Tera Guru

Short answer: No,
"Contained by" does not inherently or always imply incident support responsibility.


Longer answer:
The Contains :: Contained by relationship in ServiceNow CMDB is a logical decomposition or composition relationship. In the context of Service Offerings (especially with Application Services and Technical Services), "Contained by" simply means:

This service offering includes, depends on, or provides this service as part of its bundle of functionality to consumers.

It does not imply that the team managing the Service Offering is automatically responsible for incident resolution for all contained services.

Responsibility for incident support is typically governed by:

  • Assignment groups
  • Catalog fulfillment groups
  • CI support groups (on the CI records themselves)
  • Operational Level Agreements (OLAs) or underpinning contracts

In practice:
Many organizations mistakenly overload Contains to imply support ownership because it’s convenient, but it is not semantically accurate per CSDM.

Service Offering → Application Service mapping is often used to express scope of delivered capability, not necessarily support accountability.

Was the mapping originally created to reflect Deployment, Licensing, or Access?

  • Yes:
      → Keep the mapping.

  • No:
      → Proceed to next question.

Was the mapping created to reflect Incident Support ownership?

  • Yes:
      → Does the Service Offering still deliver any value tied to this Application Service?
       - Yes:
        → Remap or review the mapping.
       - No:
        → Remove the mapping.

  • No:
      → Proceed to next question.

Is there any remaining business capability or functional relationship between Service Offering and Application Service?

  • Yes:
      → Review manually.

  • No:
      → Remove the mapping.


That would be my take on it ðŸ¤“



ï’¡ If this pointed you in the right direction, hit Helpful to spread the good vibes.
✅ If it cracked the case for you, mark it Correct so the next person doesn’t have to reinvent the wheel.

View solution in original post

1 REPLY 1

CFrandsen
Tera Guru

Short answer: No,
"Contained by" does not inherently or always imply incident support responsibility.


Longer answer:
The Contains :: Contained by relationship in ServiceNow CMDB is a logical decomposition or composition relationship. In the context of Service Offerings (especially with Application Services and Technical Services), "Contained by" simply means:

This service offering includes, depends on, or provides this service as part of its bundle of functionality to consumers.

It does not imply that the team managing the Service Offering is automatically responsible for incident resolution for all contained services.

Responsibility for incident support is typically governed by:

  • Assignment groups
  • Catalog fulfillment groups
  • CI support groups (on the CI records themselves)
  • Operational Level Agreements (OLAs) or underpinning contracts

In practice:
Many organizations mistakenly overload Contains to imply support ownership because it’s convenient, but it is not semantically accurate per CSDM.

Service Offering → Application Service mapping is often used to express scope of delivered capability, not necessarily support accountability.

Was the mapping originally created to reflect Deployment, Licensing, or Access?

  • Yes:
      → Keep the mapping.

  • No:
      → Proceed to next question.

Was the mapping created to reflect Incident Support ownership?

  • Yes:
      → Does the Service Offering still deliver any value tied to this Application Service?
       - Yes:
        → Remap or review the mapping.
       - No:
        → Remove the mapping.

  • No:
      → Proceed to next question.

Is there any remaining business capability or functional relationship between Service Offering and Application Service?

  • Yes:
      → Review manually.

  • No:
      → Remove the mapping.


That would be my take on it ðŸ¤“



ï’¡ If this pointed you in the right direction, hit Helpful to spread the good vibes.
✅ If it cracked the case for you, mark it Correct so the next person doesn’t have to reinvent the wheel.