Glossary

Terms as this framework uses them. Where a word is used loosely in the industry, this page states which meaning it carries here.

Framework terms

Pillar: one of the seven lenses this framework applies to a workload. A pillar is a perspective, not a partition: the same design decision is legitimately discussed under several pillars, from different angles.

Design principle: the reasoning behind a pillar. Principles are not checkable and never appear in an assessment; they exist so that you can judge when a best practice does not apply to your situation.

Question, the unit a pillar is organized into, and one page: “How do you back up data, and how do you know you can restore it?” Written REL 8. A question is not answered yes or no. It is answered by the best practices you have established under it.

Best practice, a numbered, checkable instruction beneath a question, identified REL 8.1. This is the unit an assessment answers. Anything an assessor could not confirm or refute with evidence appears in the design principles instead.

Risk if not established: what kind of damage skipping a best practice produces. High is a discrete failure that arrives at once, an incident, a breach, an unrecoverable loss, a finding an auditor writes down. Medium is damage that accumulates: cost, manual work, drift, a decision nobody can reconstruct. Low is a missed improvement. It says what is at stake, not how much of it you should accept, which is your organisation’s decision.

Tradeoff: what pursuing one best practice costs the other pillars. Every best practice states its own, including the ones that genuinely cost nothing, so that a cost you decide to pay is one you saw first.

Workload, a collection of components that together deliver a business capability, deployed and operated as a unit. The unit this framework assesses. A workload is usually smaller than “the platform” and larger than “a service”.

Flow, a path through the workload that delivers something a user or business process cares about, such as “complete a checkout”. Flows are ranked by business impact, and most reliability, performance, and cost decisions follow that ranking rather than treating all components equally.

Industry page: how the framework applies to one vertical: the regulatory map, the sovereignty tier default, the pillar weighting, and the statement core an assessment must account for. It adds no best practices of its own; every demand in it points at a statement that already exists.

Reliability

SLO (Service Level Objective): the reliability target you commit to internally, expressed against a measurable indicator. Distinct from an SLA, which is contractual, and from an SLI, which is the raw measurement.

RTO (Recovery Time Objective): how long a flow may remain unavailable after a failure before the business consequence becomes unacceptable.

RPO (Recovery Point Objective): how much recent data the business can afford to lose. RTO and RPO are business inputs, not technical outputs; they are decided before the architecture, not derived from it.

Blast radius: the extent of what stops working when one component fails. Segmentation and redundancy are both attempts to bound it.

Graceful degradation: continuing to serve reduced function when a dependency fails, rather than failing entirely.

Health model, the mapping from raw signals to a per-flow verdict on whether the workload is healthy. Without one, monitoring produces alerts but not answers.

Security

Assume breach, designing on the premise that an attacker is already inside the boundary, so that internal traffic and internal identities are verified rather than trusted by location.

Least privilege: granting exactly the permissions a principal needs, for as long as it needs them, and no longer.

Principal, any identity that can act: a human user, a service account, a workload identity.

Data classification: the assignment of data to sensitivity categories. Here, classification is upstream of nearly everything: it drives encryption, key ownership, placement, retention, and access control. See [SEC 3](/architecture/pillars/security/sec-03-data-classification/) and [SOV 1](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/).

Sovereignty & Compliance

Digital sovereignty, retaining effective control over your data, your ability to operate, and your ability to leave. This framework treats it as three separable properties: data sovereignty (where data resides and who can reach it), operational sovereignty (who can affect your ability to run), and software sovereignty (whether you are locked to one provider’s interfaces).

Data residency: the jurisdiction in which data physically resides. Necessary but not sufficient for sovereignty: data can reside in Germany while remaining technically accessible from elsewhere.

Operator access: the technical ability of provider personnel to access customer data. Reduced by customer-held keys and by confidential computing, which protects data while it is being processed rather than only at rest and in transit.

Reversibility, the ability to move a workload off the platform within an acceptable time and cost. Untested reversibility is an assumption, in the same way an untested backup is.

Subprocessor: a third party processing data on behalf of the provider. Relevant to sovereignty because a compliant provider with a non-compliant subprocessor is not a compliant chain.

Shared responsibility: the split between what the provider secures and what you secure. Most compliance failures happen on the customer side of a boundary the customer did not know was there.

BSI C5, the German Federal Office for Information Security’s cloud computing compliance criteria catalogue. Type 2 additionally attests that controls were effective over a period of operation, rather than merely present at a point in time.

Cost and sustainability

Cost attribution, the ability to say which team, product, or business unit caused a given cost. Requires the resource hierarchy and labelling to reflect ownership.

Right-sizing: matching provisioned capacity to measured demand. A continuous activity; requirements drift and yesterday’s correct size becomes today’s waste.

Utilization density: how much useful work runs per unit of provisioned capacity. The primary lever in the Sustainability pillar, and usually in Cost Optimization too.

Demand shaping, moving, batching, or deferring work that does not need to happen immediately, so that peak capacity requirements fall.

STACKIT platform terms

Definitive descriptions live in the STACKIT documentation ; these are short orientations for readers new to the platform.

Region: an independent geographic deployment. STACKIT operates eu01 (Germany) and eu02 (Austria).

Availability zone (AZ): a physically separate facility within a region with independent power, cooling, and network. Each STACKIT region provides at least three.

Project: the container that holds resources and to which access and billing attach. The unit most segmentation and cost-attribution decisions are built on.

Resource Manager: the service that organizes projects within an organization, and the place where the hierarchy backing segmentation and cost attribution is defined.

Service account: a non-human identity used by workloads and automation.

SKE: STACKIT Kubernetes Engine, the managed Kubernetes service. The abbreviation is STACKIT’s own and appears throughout its documentation, so this framework uses both forms.