> 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/frame.md). # Frame What OpenIAM is made of, why it is made of several parts, and which deployment shape fits the estate you are designing for. ## What this is, and when you need it Part 1 answers the two questions that come before every other decision in this guide: **what is OpenIAM actually made of**, and **what shape does it take when it is deployed**. Neither is a configuration question. Both are asked by the people who approve the design — an enterprise architecture board that wants to know what happens when a component stops, a CIO who has been handed a component list by an analyst, an infrastructure owner who has to size the estate before a budget cycle closes. Read this part once, in order, before you go to the decision in front of you. The component question is asked far more often than it is answered well. OpenIAM runs as a set of services over a set of shared infrastructure components rather than as one process against one database, and that shape has consequences worth understanding before you commit to it — some of them good, one of them a genuine operational cost. *The OpenIAM architecture* states the component list precisely, says what each component holds and serves, and — the part that usually decides the argument — sets out what degrades and what stops when each one is unavailable. The shape question follows from it. Once you know which components exist, the deployment decision is how many machines they run on, which of them you hand to a cloud platform service, and where the connectors sit. *Deployment shapes at a glance* orients you across the three families and names the thresholds that move a design from one to the next; Part 7 holds the topology catalogue, the sizing material and the per-platform detail. ## The decisions in this part | Decision | Where it is made | What it turns on | | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Whether the component set is acceptable to your operations function, and which parts of it you will run yourself | *The OpenIAM architecture* | Whether your team already runs a message broker, a cache and a search tier, and whether a managed equivalent is available on your platform | | Which components you hand to a cloud platform service | *The OpenIAM architecture*, then Part 7 | What your cloud platform offers a Terraform module for — the answer differs by platform, and one common assumption is wrong | | How many nodes, and whether the infrastructure tier is separated from the service tier | *Deployment shapes at a glance*, then Part 7 | Availability target, population size, and whether a maintenance window is acceptable | | Where connector processes run | Part 6 | Whether any managed system needs a Windows Server host, and whether targets are on-premise | | What a backup has to cover, and what can simply be rebuilt | *The OpenIAM architecture* | Which components hold a system of record and which hold derived data | The last row is the one most often got wrong, and it is the reason the architecture page is the first page of the guide rather than an appendix at the back. ## Related * [The OpenIAM architecture](/solution-architecture/frame/architecture.md) — the component list, the dependency chain, and the failure-mode table. * [Deployment shapes at a glance](/solution-architecture/frame/deployment-shapes.md) — the three families and the thresholds between them. * *The OpenIAM object model* in the Administration Guide — what the platform manages, as opposed to what it is built from. *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/frame.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.