Service Awareness

You cannot measure what you cannot see. Service Awareness makes the service chain visible — from the outcome the business cares about down to the infrastructure that carries it.

What it is

Service Awareness is Blu Wingu’s approach to enterprise service modelling, grounded in ServiceNow’s Common Service Data Model (CSDM v5) and oriented from outcomes downward rather than from infrastructure upward. The canonical service chain runs: Business Capability → Business Application → Business Service → Business Service Offering → Service Instance → Technology Management Service → Application and Infrastructure CIs. Each layer answers a different question: the business layer answers “what does this deliver?”; the service layer answers “how is it delivered?”; the technology layer answers “what runs it?”.

The orientation matters because most CSDM implementations start at the infrastructure layer and work upward, which means the chain often breaks before it reaches the business outcome — leaving Digital Portfolio Management (DPM) dashboards with no data, and incident management without traceability to business impact. Service Awareness builds the chain from the business outcome downward, so every layer is anchored to something the business can measure.

The methodology covers the four Service Instance subtypes — Application, Data, AI, and Connection — treating AI and Connection Service Instances as first-class operational entities rather than theoretical features. It models managed-service-provider boundaries, cross-application shared-service dependencies, and multi-regulator legal-entity separation, since these are the patterns that standard CSDM implementations miss at customer scale.

When you reach for it

Service Awareness applies whenever a CMDB, DPM, or ITOM investment is underperforming because the service chain is incomplete. It is the right methodology when DPM tabs return no data (the chain from portfolio through to infrastructure is broken), when incident management cannot trace a CI failure to a business service, when regulatory reporting requires evidence of service ownership across legal entities, or when an AI capability is being delivered but has no CSDM representation — making it invisible to cost allocation, SLA management, and audit.

It is also the entry methodology for any engagement involving DORA Article 28 (ICT third-party risk), where the chain from critical ICT function through to service provider must be continuous and auditable.

What you ship

• A validated CSDM service model — a Mermaid diagram and accompanying record-creation script covering the agreed scope (Crawl, Walk, Run, or Fly maturity level), with all structural validation rules and anti-pattern scans confirmed as passing before delivery.
• A gap analysis against CSDM v5 best practice — a structured register of missing layers, broken chains, and misclassified entities, prioritised by business-impact severity and mapped to specific CSDM v5 requirements.
• A DPM integration verification — confirmation that the three DPM query paths (Strategic Planning → sn_align_core_demand; Portfolio → Business Service; Cost → Service Instance) resolve correctly against the delivered model, so dashboards display live data from day one.

Linked methodologies

Service Awareness produces the service chain evidence that Outcome NAV prices against: a visible, verified service chain is the precondition for cost-per-capability analysis and SLA-linked performance fees.

Regulated Encoder depends on Service Awareness having established the Service Instance layer correctly — the encoder’s rules operate on Service Instance attribution and cannot function without a compliant CSDM chain beneath them.

The Karpathy-6 Adversarial Verification gate is applied to any service model produced as part of an engagement involving analytical output — ensuring the gap analysis and recommendations are faithfully grounded in source evidence rather than trained assumptions.

Start here

A service-awareness engagement typically begins with a scoped diagnostic — four to six hours of structured discovery against your existing CMDB, followed by a gap register and a prioritised build plan. Book a discovery conversation.