STACKIT Architecture Framework

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

Swipe sideways to see the whole diagram

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

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 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 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 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 docs.stackit.cloud . 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.