Problem
Once a CMDB has business applications and service instances in place (the Crawl phase), the next gap is usually the technical services that manage them day to day. Many “services” populated in customer instances are technical in nature but lack a formally modeled provider — meaning no clear owner, no defined support or approval group, and no consistent way to group the infrastructure they’re responsible for. Without this layer, incident and change impact analysis has nothing reliable to route against, and support-group metadata has to be maintained manually, CI by CI. The Walk blueprint addresses this by requiring a Technology Management Service Offering to carry ownership, support/managed-by groups, and a defined link to the CIs it manages, before any richer service or portfolio context is layered on top.
What the Blueprint Includes
The blueprint puts Technology Management Service Offering at the centre, ties it back to its parent Technology Management Service, and connects it to the people, groups, and CI groupings that make it operable and requestable. It captures what a technical service offering needs before Business Service and Service Portfolio maturity work begins.
- Technology Management Service Offering – Root entity. A stratification of a Technology Management Service into a specific offering, scoped to records with a Technical Service classification.
- Technology Management Service – The parent technical service that the offering refines; one service can have multiple offerings.
- User – Assigned as Owner of both the Technology Management Service and its Offering, so each layer has a clear accountable person.
- Group – Assigned as Support Group or Managed By Group on the Offering, both scoped to active groups only, so incident and change routing has a clear operational owner.
- Service Portfolio – Optional hierarchy the Technology Management Service can be placed under for portfolio-level reporting.
- Dynamic CI Group – One of two alternative ways to represent the configuration items the Offering manages; a query-based grouping of CIs by common criteria.
- Service Instance – The other alternative way to represent what the Offering manages; a discovered or mapped instance of a deployed service.
- Catalog Item – Makes the Offering available for subscribers to request.
- Catalog – The request catalog that the Catalog Item belongs to.
Considerations
This blueprint is intentionally scoped to the technical/provider side of the service model, distinct from the Business Service Offering model used for business-facing services. Use it to get the technology layer clean before adding business consumption or portfolio-wide reporting.
- Choose one path through the “Service Offering Alternative” link group. The blueprint contains an alternative-link group where the Offering “Contains” either a Dynamic CI Group or a Service Instance. Pick whichever matches how your CMDB is populated — query-based grouping when Service Mapping isn’t in place yet, or a discovered/mapped Service Instance when it is. Avoid relating the same CI, through a Dynamic CI Group, to more than one Technology Management Service Offering — doing so causes conflicting Support Group, Managed By, and Change Group data to overwrite itself on the related CIs.
- Keep ownership and groups active and populated. Owner on both the Service and the Offering, plus Support Group and Managed By Group on the Offering, are all scoped to active records — empty or inactive values are the most common cause of broken routing.
- This is a separate model from Business Service Offerings. The blueprint author’s notes are explicit that a parallel model exists for Business Service Offerings — don’t conflate the two when documenting your service catalog.
- Service Portfolio linkage is optional but recommended. Referencing a Service Portfolio hierarchy from the Technology Management Service is available and gives you a combined view of technical and business services once you’re ready for that reporting.
- Mind the naming history. Technology Management Service Offering was previously labeled Technical Service Offering (CSDM 4 and earlier), Dynamic CI Group is the current label for cmdb_ci_query_based_service, and Service Instance was previously Application Service — keep documentation and integrations aligned to the current names.
- Field Setup is available on request. The blueprint’s author notes call out reviewing Field Setup for details like pricing, vendor, and other stakeholders, and reviewing whether Approval and Change Groups should be added according to your agreed responsibility model — ask if you’d like the full Field Setup as a table.
- Stay in the Walk phase until it’s solid. Build this on top of a completed Crawl foundation (Business Application and Service Instance ownership already clean), and hold off on Business Service, Service Portfolio depth, or Fly-stage capability data until the technical service layer is reliable.
Benefits
When this blueprint is maintained well, technical services stop being anonymous entries in the CMDB and become services with a clear provider, a defined support model, and a consistent way to group what they manage.
- Clear accountability. A defined Owner, Support Group, and Managed By Group on every Offering make it obvious who provides and supports each technical service.
- Reliable incident and change routing. Active, populated groups give ITSM processes a dependable target for impact analysis and approvals.
- Less manual CI maintenance. Grouping managed CIs through a Dynamic CI Group or Service Instance lets support and ownership metadata propagate down instead of being maintained record by record.
- Catalog-ready self-service. Offerings linked to Catalog Items on a Catalog let subscribers discover and request technical services through the request catalog.
- A solid base for Run and Fly. With the technology layer’s ownership and CI groupings in place, the model can extend into Business Service, Service Portfolio, and later CSDM maturity stages without rework.
Related Information
Check other templates related to the Service Delivery.
How to Get This Blueprint?
If you’re already a Data Content Manager Customer, you can download the Blueprint from the Knowledge Base. You will need your login credentials to access the blueprint download page.
