The Implementation Function
Last updated 12 Oct 2026
At a glance
The implementation function turns a published catalog into live automated journeys: configuring, integrating, testing and deploying the systems that execute against the specifications. Its output sits on the line where design-time ends and Lead-to-Cash begins, and its size is decided by how well the two functions before it did their job.
The picture
How it works
Implementation is the last design-time function and the only one whose workload is decided elsewhere. Where portfolio and catalog governance did their job, most launches pass through without a line of new orchestration logic. Where they did not, every launch is a project.
From published catalog to live journeys
Use the catalog as input
Catalog governance handoffBuild from the published, versioned specification set, not a requirements document derived from it, and not the approved concept.
Select the workflow path from the catalog
Orchestration / BPMN engineDetermine which existing orchestration path the decomposition selects at runtime. A new workflow belongs here only when no existing path can carry the product.
Configure and integrate
IT delivery, integration, OSS engineeringConfigure order capture, decomposition, rating and channels against the published specifications, and build any adapter the fulfilment path lacks.
Test and deploy
Release managementRehearse order-to-activate end to end in a lower environment, verify rating and pricing, regression-test the installed base, then release.
The end of step 4 is the design-time/runtime line of Section 1.4, seen from the design-time side. Before it, everything is a definition applying to every future order; after it, an instance correctable in flight. That is why a defect on this side reaches every customer who orders afterwards.
The model, corrected
The model in Section 2.1 is right about the three functions and incomplete in four specific ways.
The commercial layer. The commercial model is always built. A catalog scope that omits it moves the work somewhere that cannot decompose to a CFS, as Section 2.3 traced.
Workflow design as the exception. Drawn as a standing step, it is read as work that should happen every time, which normalises a workflow per product. That is catalog sprawl expressed in orchestration rather than specifications, and harder to see, because near-duplicate processes are no easier to count than near-duplicate specifications.
The feasibility return. This is the missing control from Section 2.2. Without it, effort is estimated without feasibility, the date is committed, and the absent activation path is discovered in implementation with no time left. That is how a manual fulfilment task gets built and then never removed.
The closed cycle. None of the portfolio function’s four intake sources is assurance, so without a path back from Trouble-to-Resolve, operational reality reaches the portfolio at best as an internal idea raised by whoever noticed. A model ending at deployment is a model of a programme; C2M is a standing capability.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Published specification set (build input) | Product, service and resource catalogs (catalog governance) | — | Implementation | Implementation reads it; it does not redefine it |
| Workflow (BPMN) definitions | Orchestration engine, under the implementation team’s source control | — | Catalog governance | Should be selected by the decomposition; product logic held here is a definition living in code |
| System configuration and adapters | Each configured system (COM, SOM, ROM, billing, channels) and the integration codebase | — | Release management | — |
| Test evidence and release record | Test management and release tooling | — | Catalog governance, operations | Typically separate from the catalog; linking it to the catalog version tested is a deliberate choice |
| Live journey defects and fallout | Assurance / Trouble-to-Resolve | — | Product portfolio | Reaches the portfolio only if the T2R loop is closed |
In practice
Implementation is where gaps upstream become code. A thin decomposition becomes a gateway in a BPMN process; a missing activation path becomes a manual task. Each works, and each is invisible to anyone reading the catalog. Once a second product copies that workflow, the product definition effectively lives in orchestration code, and changing it is a release rather than a catalog version.
Testing is the step most often compressed when the date was committed before feasibility was confirmed. Rehearsing against synthetic orders proves the new journey; it says little about the installed base, which is where regressions from reused specifications and workflows appear. Section 8.11 covers how workflows are built and selected.
The trade-off
What it solves
A repeatable route from a published catalog to live, tested journeys, at the point where Lead-to-Cash can begin.
What it does not solve
- It cannot correct a missing or mis-modelled definition; it can only build around it.
- It does not confirm feasibility; by the time implementation finds a missing activation path, the date is usually committed.
What it adds
- Workflows, adapters and configuration that must be kept consistent with every catalog version they serve.
- An installed base that every release has to be regression-tested against.
Architecture decision
When does a new product get a new workflow?
Reuse an existing orchestration path selected by the decomposition
Choose when The catalog decomposes the product to specifications an existing path already handles, perhaps with new characteristics
Design a new workflow
Choose when No existing path can carry the product, for example a new network domain or a new fulfilment partner
Breaks if New workflow design becomes the default step for every launch: product logic migrates from the catalog into orchestration code, near-duplicate processes multiply, and nobody can count or change them as a model.
Takeaways
Key Takeaways
- Implementation turns a published catalog into live journeys, on the line where design-time ends and Lead-to-Cash begins.
- Its workload is decided upstream: whatever the catalog does not express, implementation builds as code.
- A new workflow is the exception, needed only when no existing path can carry the product.
- The corrected model restores the commercial layer, returns feasibility to prioritisation and closes the loop from T2R.
Check yourself
Every product launch at an operator includes a new BPMN workflow. What does that suggest about the catalog?Show answerHide
That the decomposition is not selecting existing paths, so product logic is being built into orchestration per product. This is sprawl in workflows rather than specifications, and is harder to see.
Implementation discovers there is no automated activation path two weeks before launch. Which control was missing?Show answerHide
The feasibility return to prioritisation. The date was committed on an effort estimate, and the gap was found when there was no time left except to build a manual task.
Put this to work