> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/programme.md). # Programme and sequencing The decisions about order rather than architecture — why identity lifecycle is established before single sign-on, what belongs in a first phase and what should be deferred, and how the platform's evid ## What this is, and when you need it Every other part of this guide answers *what to build*. Part 8 answers **in what order, and what that order costs when it is ignored**. Three decisions live here: whether identity lifecycle precedes single sign-on, what the first phase of a rollout contains, and how the platform's capabilities relate to an organization's own compliance obligations. None of the three is an OpenIAM configuration decision, and all three are decided by people who will never open the Webconsole — a programme director, a sponsor, a head of compliance. That is why they are in an architecture guide rather than an implementation plan: they are architectural in effect, they are made early, and getting them wrong is not recoverable by configuration. You need this part when a plan is being drafted, when a sponsor is pushing for a visible win in the first quarter, or when someone has written "the platform is compliant with" in a document that is about to go to a regulator. ## The decisions in this part | The question in front of you | Page | What it turns on | | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Do we do single sign-on first, because it is visible and users will notice? | [Sequence: lifecycle before SSO](/solution-architecture/programme/sequence.md) | Whether the identity is already known in both OpenIAM and the target application — because if it is not, single sign-on cannot work at all | | What goes in phase one, and what can wait without leaving the phase incoherent? | [Phasing a rollout](/solution-architecture/programme/phasing-a-rollout.md) | Which populations and applications make the identity data true, and which merely make the programme look busy | | What can we say the platform does for our regulatory obligations, and what remains ours? | [Operating in a regulated environment](/solution-architecture/programme/regulated-environments.md) | The line between a technology that supports controls and produces evidence, and an organization that validates its own configured process | ## The position this part exists to defend > **Identity lifecycle and governance are established before single sign-on.** A person must be known in OpenIAM and known in the target application before single sign-on to that application can work at all. Lifecycle is the foundation; single sign-on is what stands on it. This is the single most repeated recommendation in the material this guide is built from, and it is repeated because it is the one most often argued with. Single sign-on is visible, popular and easy to demonstrate; lifecycle is invisible until it is missing. A programme that inverts the order produces a federation that appears to work, cannot be evidenced, and leaves a population of accounts nobody can attach to a person. The second position in this part is quieter and just as important. **The technology supports controls and produces evidence; the organization validates the configured process under its own quality framework.** That sentence is carefully bounded in both directions, and [Operating in a regulated environment](/solution-architecture/programme/regulated-environments.md) explains why it should be neither weakened nor strengthened when it is repeated to a sponsor. ## How this part relates to the rest of the guide Part 8 does not introduce new decisions about the product. It sequences the ones already made: Part 2's identity foundation, Part 3's authentication and access design, Part 4's governance programme, Part 5's coexistence rules and Part 7's deployment shape. Read those first; this part is about the order they are delivered in and the claims that may be made about the result. Where a second governance platform is in play, the sequencing question is sharper rather than different — Part 5, *Planning a wave migration* is the same decision applied to an estate being dismantled rather than built, and the two plans should be one document. ## Related * [Sequence: lifecycle before SSO](/solution-architecture/programme/sequence.md) — the strongest position in this guide, with its reasoning and its exceptions. * [Phasing a rollout](/solution-architecture/programme/phasing-a-rollout.md) — what a first phase contains, and what to defer without regret. * [Operating in a regulated environment](/solution-architecture/programme/regulated-environments.md) — the boundary of what the product can be said to deliver. * Part 5, *Planning a wave migration* — sequencing when an incumbent platform has to be retired as well. *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/solution-architecture/programme.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.