Configuration Management: The Enabling Layer of ASPICE

Everyone treats configuration management as plumbing — a box you tick, a tool the CM manager owns. That's backwards. Get this one right and every other process becomes provable. Get it wrong and no amount of process ceremony saves you.

ASPICE lists SUP.8 Configuration Management among the supporting processes, which makes it look optional or peripheral. In reality it is load-bearing. Every requirement, every architecture element, every test case, every review record, every change — all of it is a configuration item with an identity, a version, a place in a baseline, and links to other items. That web is your ASPICE evidence. SUP.8 is the process that keeps the web coherent.

Strip ASPICE down and underneath every process is one data model: items (requirements, architecture, design, tests, change requests, problems, reviews), their versions, the baselines that freeze a consistent set at a point in time, and the bidirectional links between them (SYS.2 → SWE.1 → SWE.3 → SWE.4 → SWE.6). Capability Level 2 is, in large part, the demand that this data model is managed — controlled, versioned, consistent — rather than reconstructed before an audit.

This is the point almost everyone misses. The maturity of any process area is bounded by the maturity of the CM data model beneath it. Your SWE.1 requirements can be beautiful, but if their versions and links aren't controlled, SWE.1 isn't CL2. Your tests can be thorough, but if they don't trace to a baselined requirement, SWE.6 isn't CL2. Configuration management is the basis that only allows mature processes across every other group. It is the secret enabling layer.

Here's the structural problem. Requirements live in DOORS or Polarion. Architecture lives in Enterprise Architect. Tasks and changes live in Jira. Reviews and plans live in Confluence. Each tool holds a slice of the data model, with its own item identities and its own idea of a link. There is no single data model — there are five, stitched together by hand and by export. The moment a requirement changes, the hand-maintained links across those tools decay. You don't have a configuration-management data model; you have five of them pretending to be one. (See best ASPICE tools.)

The fix is architectural, not procedural. You need a headless ALM — an API-first, tool-agnostic application-lifecycle-management layer that holds the configuration-management data model as the single source of truth for every work product and every link, and exposes it as a service. Your existing tools become views and editors on top of that model, not five competing copies of it. And because it's API-first, it's readable and writable by agents as well as humans — which is the precondition for automating any of it.

A data model on its own is inert. On top of the headless ALM you need a platform that defines and coordinates the work: who does what — a human or an agent — for each change; how a change flows from requirement impact through architecture, design and test; and a trace of every action written back against the one data model. That's how a change becomes planned, assigned, executed and evidenced continuously — instead of archaeologically reconstructed before an assessment. Wire it into CI and compliance stops being a project. (See Agile ASPICE and automating ASPICE with AI agents.)

Recall the original sin of ASPICE: there is no official blueprint anywhere. The standard grades you against a checklist and refuses to tell you how to build the thing. So we wrote one. The Blueprint is our take at the missing blueprint — a free, open template QMS for ASPICE: every VDA-scope process area, its outcomes and work products, mapped to concrete artifacts in your tools, all grounded in this one configuration-management data model. Take it and implement it yourself, at no cost.

Or have us implement it for you. We bring the agentic solutions — Vera generates the work products and traceability as a byproduct of your build, each with a confidence score and audit trail — running on a partner headless ALM that holds the configuration-management data model. The Blueprint tells you what good looks like; our agents plus a headless ALM make it exist. That's the offer: no hallucination, no AI slop, evidence you can take into an assessment.