Build a service-oriented configuration baseline

Configuration Management explains how services are delivered. Begin with a manageable, maintained scope rather than an indiscriminate inventory of everything that could be discovered.

Before you start

Confirm the optional module is activated, CSM Full is selected and the right people have read/edit permissions. Agree service, application and technical stewards, environment naming and a review process. CSM is the shared information model; Configuration Management supplies its configuration and delivery detail.

Steps

1. Select one important Service and a usable Offering with an accountable owner, assigned team, support schedule and priority targets.
2. Register the Business Application identity where applicable. Create its actual production Service Instance before adding other environments.
3. Register the operational CIs needed to explain delivery: runtime, database, compute, network, storage or middleware as appropriate.
4. Classify each CI and maintain environment, state, criticality and support context.
5. Associate the Offering and Instance with a delivery, support or management role. These are separate many-to-many associations, with activity/validity context where available.
6. Add directed CI relationships with explicit impact modes. Review hosting, fallback and shared dependencies with technical owners.
7. Test a representative Incident and planned Change. Check routing, predicted impact, environment and maintenance constraints.
8. Record findings and assign ongoing stewardship. Expand to PREPROD, TEST, DR or further Services when the initial map is useful and maintainable.

Example: customer-facing Portal

Digital Customer Services is the Service; Portal PROD Support is the Offering; Customer Portal is the Business Application; Customer Portal PROD is the Instance. Supporting CIs can include app server, VM, host, production database, network device and storage. Review each connection's actual failure meaning, rather than setting every edge hard.

Example: container deployment

Keep the production container cluster separate from the deployed application Instance and its external database/middleware/network dependencies. Avoid registering every transient container unless its identity and operational maintenance justify it.

Example: network and shared platforms

Keep a deployed network capability distinct from its routers/appliances. Model alternate WAN paths according to their real redundancy. A middleware or database resource shared by several applications should normally retain one truthful identity with explicit consumer relationships, rather than duplicate records per Service.

Expected result

The pilot can demonstrate who supports the service, what is deployed and which failure/change paths matter, with known gaps assigned to owners.

Important behaviour

Enabling CSM Full or entering mapping metadata does not discover infrastructure, validate dependencies or certify completeness. The whitepaper's Establish, Connect, Govern, and Measure and improve stages are adoption guidance, not automated feature gates.

Related guides