Is Part 1 really free?
Yes. PBW makes Part 1 available as a free entry point so teams can review the control-plane doctrine, vocabulary, and lifecycle framing before deciding whether the full playbook belongs in their process.
Before you evaluate platforms, before you run a vendor demo, before you scope a project — understand what an OMS implementation actually is. Not a software installation. A data-centric, cloud/hybrid, resilience-conscious operating transformation. Part I (Chapters 1–5) of the 25-chapter OMS Implementation Playbook lays the conceptual foundation that every other chapter builds on.
The OMS is not a workflow tool. It is the control plane through which investment intent is translated into controlled market activity — the layer that holds the relationship between what your portfolio managers decide to do and what actually happens in the market. If you get that layer wrong, nothing else works correctly. If you get it right, the rest of the implementation becomes tractable.
Part I establishes the conceptual architecture that the rest of the Playbook builds on. Before you can make good decisions about OMS configuration, integration architecture, compliance rule implementation, or cutover sequencing, you need a clear mental model of what the OMS actually is and where it sits in your operating structure.
The chapter covers three interconnected themes:
Buy-side firms operate under a specific pressure: scale, T+1 settlement, data fragmentation, and wealth complexity all create operational load that the OMS either absorbs or propagates. The control-plane doctrine says that the OMS should be the authoritative layer — the system that defines what is possible, what is restricted, and what has already been executed. Everything downstream of the OMS should be derivable from it, not reconciled against it.
Every OMS implementation eventually surfaces boundary questions: Where does the OMS end and the PMS begin? Which system holds the IBOR? What is the golden source for a given instrument attribute? These questions get answered in the vendor demo if you haven't answered them yourself first. The consequence of an underspecified boundary is control debt — the accumulated gap between what your systems should be doing and what they're actually doing. Control debt compounds over time and is expensive to retire.
Part I maps the full investment lifecycle as a swimlane: idea → research → model → order proposal → approval → compliance → execution → allocation → settlement → reconciliation → reporting. The swimlane isn't a process diagram — it's a boundary definition tool. For each transition in the lifecycle, the section identifies where the OMS holds authority, where it defers, and where it shares responsibility with adjacent systems. This maps directly to the integration architecture decisions in Chapters 4–5.
The Playbook introduces the PBW 21-tenet standard: data-centric, platform-aware, operating-model-led, resilience-conscious, evidence-driven, artifact-first, wealth-aware, value-measured, cloud/hybrid-aware, API-and-event-governed, and six additional tenets that govern the full implementation methodology. Misuse of core terms — treating EMS and OMS as interchangeable, for example — is a reliable indicator that a boundary problem exists in the implementation plan.
Continue reading: Enter your email to unlock the full chapter — including the 5 decision gates, 8 failure patterns, and the practitioner artifacts (boundary map, control-plane diagram, lifecycle swimlane, and controlled vocabulary glossary).
Download Part 1 (Ch 1–5) for free →Enter your email to download Part I of the OMS Implementation Playbook — Chapters 1–5 — immediately.
Yes. PBW makes Part 1 available as a free entry point so teams can review the control-plane doctrine, vocabulary, and lifecycle framing before deciding whether the full playbook belongs in their process.
It covers Chapters 1-5 of the broader OMS Implementation Playbook, including the control-plane doctrine, platform taxonomy, boundary discipline, lifecycle traceability, implementation economics, and recurring failure patterns.
Yes. Part 1 is especially useful when the platform decision is still open because it helps leadership teams define the operating questions that should exist before feature comparisons or vendor demos take over the conversation.
You can keep Part 1 as a standalone reference, continue into Part 2, or move directly to the full playbook if you need the rest of the lifecycle and the supporting practitioner materials.