Common Services Data Model

Making an Enterprise Legible to Itself

The Problem Nobody Could Name

At Western Governors University, Brian Jolley’s problem management team sat at the nexus of the entire IT operation. They needed to know who owned what system, coordinate with security for access control, interface with HR, the Service Desk, engineering, infrastructure, DBAs, and the change advisory board. They had to know what features were coming so the Service Desk could prepare, and what systems were expected to have downtime so nobody accidentally woke up a director during planned maintenance.

They touched every department. And no department had the same vocabulary.

Procurement needed to know about vendor contracts and license counts. Finance needed to pay bills. Security needed to know which vendors had access to what. Legal couldn’t let personally identifiable information into test environments — which meant coordinating synthetic data across three or four dozen systems whose test data was constantly out of sync. And across all of this, the most basic questions had no consistent answers: What is a product? What is a service? What is a system? What is a team? These terms were used interchangeably and differently by every department. Without shared definitions, every cross-departmental conversation was a translation exercise — and translation errors produced real operational failures.

The Framework

As major ServiceNow customers, WGU had been working with ServiceNow’s team to maximize use of the platform. ServiceNow introduced the concept of a Common Services Data Model (CSDM) — a framework for organizing the relationships between business services, technical services, systems, applications, teams, and projects.

Brian Jolley, Director of Service Management at Western Governors University, recognized the value immediately. The CSDM provided the organizing principles his team needed: a shared vocabulary, clear ownership lanes, and a model for how the different parts of the enterprise relate to each other.

The Work

The initiative started on whiteboards. When the whiteboards couldn’t contain the scope, the work moved to Lucidchart. Brian Jolley and his team mapped out how priorities should flow from executive leadership through product development, software engineering, implementation and support, and finally to a plan for software end-of-life. They separated concepts the organization had been conflating:

The Initiative Success Strategy

Beyond the CSDM itself, Brian Jolley developed an Initiative Success Strategy — a governance framework requiring formal criteria before any initiative could proceed. Required elements: acceptance criteria, process diagrams, cost/benefit analysis, success metrics, a problem statement, executive sponsorship, procurement and security and architecture approval, enterprise experience alignment, a feasibility assessment, a support plan, and an end-of-life plan.

The gate-check process was designed to prevent half-baked initiatives from consuming resources and creating technical debt. It also established delivery priorities: system integrity and stability first, then service restoration, then defect resolution, then enhancements, and finally new capabilities.

How Far It Got

The CSDM itself was implemented nearly in full within ServiceNow. Business services, system portfolios, ownership lanes, health metrics, and configuration management were operational.

The Initiative Success Strategy — the governance layer coordinating demand across departments — was not fully implemented. This is where Brian Jolley hit the ceiling of director-level authority. Departments could not be compelled to subordinate their own priorities to a shared model from within. Each was in a tug-of-war over how the business worked, based on its own priorities. The Initiative Success Strategy required executive authority to enforce — authority that a director does not have.

This is the insight that crystallized Jolley’s understanding of organizational fracturing: it is fundamentally an executive problem. Departments can’t solve it because they are participants in the fracture. Only someone with cross-departmental authority — a C-suite executive or a strategic consultant empowered by one — can align the pieces.

Ahead of ServiceNow

Brian Jolley’s team didn’t just implement ServiceNow’s framework — they operated ahead of it. They noticed shortcomings in the CSDM and developed workarounds. They anticipated where ServiceNow’s model was heading — sometimes correctly predicting features before they were announced. Through a direct feedback loop with their ServiceNow representative, WGU met regularly with ServiceNow’s product team to share work and make recommendations.

ServiceNow adopted terms and ideas that Brian Jolley’s team brought to the table. WGU was not just a customer implementing a vendor’s framework. They were genuine industry thought leaders whose work influenced the framework itself. Brian Jolley was invited to present WGU’s CSDM work to other ServiceNow academic clients.

Connected Work

The CSDM is the most architecturally ambitious of Brian Jolley’s WGU initiatives because it doesn’t fix a single process — it reframes how an entire organization understands itself. Every other case study connects back to it: Scorecards needed the CSDM to know which team owned which system; the DCR needed it to route root cause findings to the right owners; Outage Response needed it to know who to escalate to; the SMS Rollout needed it to map communication channels across departments; QA Transformation needed it to trace accountability from product definition through testing to deployment.