---
type: index
title: STACKIT Architecture Framework
description: "Seven pillars for judging a workload on STACKIT: reliability, security, cost, operations, performance, sovereignty and sustainability."
status: draft
hero:
  tagline: Every workload is a set of compromises. The Architecture Framework names the qualities you are trading against each other, so that the trade is a decision rather than an accident.
  illustration:
    name: product
    position: right
sidebar:
  order: 0
  attrs:
    data-icon: dashboard
tableOfContents: false
hideLinkCard: true
prev: false
next: false
source_url: "https://framework.stackit.cloud/architecture/"
source_file: "docs/architecture/index.mdx"
---

Every workload is a set of compromises. You can make a system more reliable by spending more, more
secure by making it harder to operate, faster by making it more expensive. What separates a good
architecture from a bad one is rarely the individual choices. It is whether the compromises were
made deliberately, by someone who knew what they were giving up.

The framework exists to make those compromises visible. It gives you seven qualities to judge a workload
against, and questions precise enough that the answers tell you something you did not already
know.

## What is here

<ArchitectureFrameworkOverviewSvg
  style={{ width: "100%", maxWidth: "1740px", height: "auto", display: "block" }}
/>

Two sections, one spine. The pillars state what a good workload looks like; the industries read
that statement one at a time.

**[Pillars](/architecture/pillars/)** are the criteria: seven qualities, each with design principles, the
questions it asks, a page per question, and a page on what pursuing it costs the other six.

**[Industries](/architecture/industries/)** read the framework for one vertical at a time, the route map of
your industry: which regulation binds, which sovereignty tier is the default, and which statements
must hold.

This is a decision framework rather than a catalogue of designs. Blueprints,
infrastructure-as-code and hardened patterns are artefacts; what is written here is the basis on
which such an artefact can be called proven.

## Who this is for

Architects, platform engineers, and technical decision-makers designing or reviewing workloads on
STACKIT. It assumes you know your own domain and can read a service documentation page. It does
not assume you have used STACKIT before.

## How to use this

**Designing something new.** Read the [pillars](/architecture/pillars/) and their design principles first: the
principles are where the reasoning lives, and they are short. Then walk the questions while the
architecture is still cheap to change. You will not satisfy every best practice, and you are not
supposed to; the value is in knowing which ones you are consciously declining.

**Reviewing something that exists.** Take the questions to the workload as they stand. Every one
of them traces back to a numbered best practice, so a weak answer points directly at the page that
explains what to do about it. Expect the first pass to surface more than you can fix: rank by
consequence, not by count.

**Choosing or configuring a service.** The question pages carry an **On STACKIT** section each:
what the platform documents for the services involved, deep-linked to the documentation, which
remains the authority.

**Working in a regulated industry.** The [industry pages](/architecture/industries/) map what your vertical's
route demands: the regulation, the tier default, and the statements that must hold.

## What this framework is not

It is not a certification, and satisfying every best practice certifies nothing.

It is not a substitute for <LinkChip href="https://docs.stackit.cloud">`docs.stackit.cloud`</LinkChip>. Service
capabilities, limits, and configuration are documented there and change there; the framework links to that
documentation rather than restating it.

It is not a contractual commitment by STACKIT. For service levels and guarantees, see your
agreement.

It is not finished. Pages carry a `status` field, and what the platform does not document is named
as something to establish for your own workload rather than asserted.