The pipeline is our change control
Meridian Health has 14 product teams deploying around 30 times a day through a shared CI/CD pipeline. The change manager discovers the pipeline creates no change records; the teams argue the pipeline is the control, because it runs automated tests and supports rollback. Separately, operations raises roughly 200 'changes' a month that turn out to be password resets, disk expansions and certificate requests. Last month a pipeline deployment altered a shared patient-lookup API contract in a way that broke three downstream services. Each team had tested its own service; nobody had checked the consumers, and the first anyone knew was a clinical support call.
1. Separate what belongs to change enablement, deployment management and service request management here, and identify the actual control that was missing.
Read the worked answer
Deployment management moves artefacts into an environment. It is a means of implementing a change - a very good one here, with automated tests and rollback. It is not a substitute for deciding whether the change should happen and what it affects.
Change enablement asks: what could this affect, who needs to know, and who needs to agree before it goes? The pipeline answered none of those questions. It was working exactly as designed, which is precisely why it missed cross-service breakage - it tests the service, not the relationships between services.
Service request management owns the 200 monthly items. Password resets, disk expansions and certificate requests are pre-defined, low-risk, user-initiated requests. Filing them as changes inflates the change population, distorts every change metric, and buries the real changes in noise.
The missing control is not a ticket. It is impact assessment against shared configuration items, and a coordination point between teams that share them. The API contract was a shared CI with three consumers; nobody owned the decision to change it, and there was no mechanism that would have surfaced the consumers even if someone had asked.
2. How would you integrate change enablement with the pipeline without turning it back into a manual CAB gate? State what is automated, what is human, and at which moment.
Read the worked answer
Automated, at every deployment:
- Registration - a change record created from the deployment event itself, linked to commit, test evidence and the configuration items touched. No human writes a ticket.
- Risk classification - derived from configuration management data: does the diff touch a CI with relationships to other services? Is it reversible? Which environment? What is the blast radius?
- Auto-approval - isolated, reversible, low-risk deployments proceed with no gate. This should be the large majority of the 30 a day.
Human, and only where classification says so:
- Changes to shared or published interfaces, shared infrastructure, security configuration or irreversible data movement require explicit acknowledgement before the pipeline releases to production. For the API contract, that means the owning teams of dependent CIs must confirm - and the request arrives with the dependency list already populated, so the decision takes minutes rather than a meeting.
- Expedited and emergency paths run asynchronously with a response SLA.
The principle: controls scale by being automated and risk-proportionate. A CAB reviewing 30 deployments a day is not a control, it is a rubber stamp that produces records nobody reads. The gate belongs where the risk is, and the risk here was a shared contract, not the deployment itself.
3. Which other practices must be involved to stop the API contract failure recurring, and what specifically does each contribute?
Read the worked answer
The failure cannot be fixed inside change enablement, because the information needed to prevent it lives elsewhere.
- Service configuration management - the CI relationship data that makes 'three downstream consumers' detectable at all. Without it, risk classification is guesswork. This is the highest-priority dependency.
- Service request management - to take the 200 monthly items out of the change population and manage them as requests, restoring a meaningful change data set.
- Release management - to coordinate multiple related changes into production together, which is where cross-team sequencing belongs.
- Problem management - known errors and workarounds feeding back into playbooks and the standard change catalogue, so recurring fixes become pre-authorized rather than repeated emergencies.
- Architecture or technical governance - the durable fix is API contract versioning and a deprecation standard. More approvals would not have prevented this; versioning would have.
- Relationship management / supplier management - where API consumers sit outside the immediate organisation and need to be engaged in the assessment.
Change enablement's role is to be the point where these inputs converge into a decision. It cannot be the point where they are generated.