The Implementation Function
Where a published catalog becomes running workflows, and the corrected model of the chain.
The implementation function receives a published catalog and produces running workflows. It is the last design-time function in the chain, and the only one whose size is decided elsewhere: how much work arrives here is a property of what the previous two functions produced. Where both did their job, most launches pass through without a line of new orchestration logic. Where they did not, every launch is a project.
The flow, and where it stops
From Published Catalog to Live Journeys
Use the catalog as input
Catalog governance handoffTake the published, versioned specification set as the build input — not a requirements document derived from it, and not the concept the portfolio function approved.
Select the workflow path from the catalog
Orchestration / BPMN engineDetermine which existing orchestration path the decomposition selects at runtime. Designing 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 channel systems against the published specifications, and build any adapter the fulfilment path needs and does not have.
Test and deploy
Release managementRehearse order-to-activate end to end in a lower environment against the published catalog, verify rating and pricing, regression-test the installed base, then release.
The end of step 4 is the line Section 1.4 draws between design-time and runtime, seen from the design-time side. Everything before it is a definition applying to every future order; everything after it is an instance, correctable in flight — which is why a defect on this side reaches every customer who orders afterwards.
The model, corrected
Section 2.1 drew the version most organisations work from. It is right about the three functions and incomplete in four specific ways, each of which has now been paid for somewhere in this module. The corrected version is the same picture with four differences. What they are is drawn; why each one matters is not.
The commercial layer. The commercial model is always built. A catalog scope that omits it does not avoid the work; it moves the work somewhere that cannot decompose to a CFS, which is what Section 2.3 traced.
Workflow design as the exception. Work drawn as a standing step is read as work that should happen every time, and that reading normalises a workflow per product — the sprawl of Section 2.3 expressed in orchestration rather than specifications, and harder to see, because near-duplicate processes are no more countable 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 here with no time left — exactly how the manual task above gets built.
The closed cycle. None of Section 2.2's four intake sources is assurance, so without this path operational reality reaches the portfolio at best as an internal idea raised by whoever noticed. Closing the loop also makes Section 2.1's point concrete: a model ending at deployment is a model of a programme, and C2M is a standing capability.
Section 2.4 Key Takeaways
- The implementation function turns a published catalog into live automated journeys; and that output sits exactly on the boundary where design-time ends and Lead-to-Cash begins
- The corrected model restores the commercial layer, demotes workflow design to an exception, returns feasibility to prioritisation before a date is committed, and closes the loop from T2R