--- type: pillars-index title: The seven pillars description: Seven qualities a workload is judged against on STACKIT, what each of them asks, how the questions are numbered, and what the sovereignty pillar covers. status: draft sidebar: order: 0 label: Overview tableOfContents: false hideLinkCard: true source_url: "https://framework.stackit.cloud/architecture/pillars/" source_file: "docs/architecture/pillars/index.mdx" --- A workload is never optimal in every direction at once. Making it more reliable costs money. Making it more secure costs operational convenience. Making it faster usually costs both. The pillars name the qualities you are trading against each other, so that the trade is a decision rather than an accident. | Pillar | Code | The question it answers | |---|---|---| | [Operational Excellence](/architecture/pillars/operational-excellence/) | `OPS` | Can a team run it without heroics? | | [Security](/architecture/pillars/security/) | `SEC` | Can it withstand a deliberate attack? | | [Reliability](/architecture/pillars/reliability/) | `REL` | Does it keep working when something breaks? | | [Performance Efficiency](/architecture/pillars/performance-efficiency/) | `PERF` | Does it meet demand without waste? | | [Cost Optimization](/architecture/pillars/cost-optimization/) | `COST` | Is the money buying business value? | | [Sustainability](/architecture/pillars/sustainability/) | `SUS` | Is the resource consumption justified? | | [Sovereignty & Compliance](/architecture/pillars/sovereignty/) | `SOV` | Do you control your data, and can you prove it? | Each pillar page states what the pillar covers, what it deliberately does not, and the questions it asks, each with a summary. Beside it sit design principles (the reasoning), a page for each question (the detail), and a tradeoffs page (what pursuing this pillar costs the others). Read the principles first if you are designing something, since that is where the reasoning lives and they are short. Go straight to the questions if you are reviewing something that exists. ## What the sovereignty pillar covers Sovereignty is usually treated as a contractual matter, settled once in a procurement conversation and then assumed. On a sovereign cloud it is not. Where data resides, who can technically decrypt it, whether your logs leave the jurisdiction along with your data, whether you could migrate away if you had to: each of those is an architectural choice with real alternatives, and each is what an auditor and a customer questionnaire ask to see evidenced. It does not decide *whether* your workload needs sovereignty, or how much. That is settled earlier, in the Advisory Framework, which classifies workloads into three sovereignty tiers. This pillar takes the tier as given and answers the next question: how you implement it, and how you would prove you did. ## A note on the identifiers Questions are written [`REL 1`](/architecture/pillars/reliability/rel-01-reliability-targets/), [`SEC 7`](/architecture/pillars/security/sec-07-encryption/), [`SOV 4`](/architecture/pillars/sovereignty/sov-04-key-ownership/). Where best practices are added beneath a question, they extend the identifier: [`REL 1.3`](/architecture/pillars/reliability/rel-01-reliability-targets/#rel-13-check-every-target-against-the-published-availability-of-the-services-it-depends-on). A compact form without the space, [`REL01`](/architecture/pillars/reliability/rel-01-reliability-targets/), means the same thing, and is what appears in URLs and file names. An identifier is permanent once published. A question that stops applying is retired rather than renumbered, and its number is not reused, so that a review recorded two years ago still means what it said. Numbers do not indicate priority. They follow the order in which decisions are usually made, and new questions are appended rather than inserted, so even that ordering loosens over time.