Haven+ Architecture Principles
Purpose and Application
These architecture principles provide the framework for solutions implemented on or with Haven+. They are intended for use in a Project Start Architecture (PSA) and support design decisions, architectural assessment, and decision-making.
Deviations are permitted where there is a demonstrable functional, technical, or business need. A deviation must be explicitly documented as an architecture decision and include at least the rationale, affected principle, alternatives considered, risks and consequences, mitigating measures, and accountable risk owner. Deviations with a High or Very High impact require explicit architecture and risk acceptance.
Note: These nine principles are a PSA-oriented formalisation of Haven+ architectural objectives and technical patterns. They should not be interpreted as an official list of nine principles published by Haven+.
AP-01 — Cloud and Vendor Agnostic
Principle
The solution is designed so that it does not become unnecessarily dependent on a specific cloud, infrastructure, or software vendor. Kubernetes and open standards are used as the abstraction layer wherever possible.
Rationale
Haven+ is aimed at portability and reducing vendor dependency. By avoiding direct coupling between applications or platform services and provider-specific cloud functionality, workloads can remain deployable across different Haven+-compatible environments.
This also supports a viable exit strategy and prevents future choices from being disproportionately constrained by previous vendor decisions.
Implementation
- Kubernetes is used as the abstraction layer for the underlying infrastructure wherever possible.
- Provider-specific services are used only where they provide demonstrable functional, technical, security, operational, or cost benefits.
- Open standards and portable components are preferred.
- Vendor-specific APIs and dependencies are explicitly documented.
- Applications make as little direct use as possible of underlying cloud-provider APIs.
- Exit and migration options are considered as part of product and service selection.
- Data must, wherever reasonably possible, be exportable using open or widely supported formats.
Impact of Deviation — High
A deviation may result in vendor lock-in, higher migration and exit costs, and reduced freedom of choice in future procurements or infrastructure-provider changes. A workload may no longer be portable to another Haven+ environment without substantial modification.
Dependency on provider-specific technology may also introduce additional skills, operational, and continuity risks.
Deviation Permitted If
A specific service provides demonstrable functional, financial, security, or operational value and the resulting vendor dependency is consciously accepted. The deviation must document at least the lock-in implications, exit strategy, migration impact, and mitigating measures.
AP-02 — Kubernetes Is the Platform Contract
Principle
Kubernetes is the primary technical abstraction layer and platform contract between applications and platform services on the one hand, and the underlying infrastructure on the other.
Rationale
Using Kubernetes as the common interface decouples applications as much as possible from the technical implementation of the underlying infrastructure. This creates a uniform model for deployment, configuration, security, scalability, and operations.
Implementation
- Workloads are delivered as containers where appropriate.
- Deployment takes place through Kubernetes resources and associated APIs.
- Kubernetes-native standards and interfaces are preferred over provider-specific alternatives.
- Applications make no unnecessary assumptions about individual nodes or the underlying infrastructure.
- Generic infrastructure functionality is preferably exposed through platform interfaces.
- Platform services must be consumable by workloads through clearly defined interfaces.
- Alternative runtime or infrastructure models must be explicitly justified.
Impact of Deviation — High
A workload outside the Kubernetes platform may require separate deployment, security, monitoring, patching, and operational processes. This introduces additional operational overhead, skills requirements, and potentially a second infrastructure stack.
Portability is also reduced, and the solution may be less able to benefit from the generic capabilities provided by Haven+.
Deviation Permitted If
The workload is technically unsuitable for Kubernetes or has demonstrable functional or non-functional requirements that cannot responsibly be met within Haven+. Alternative operational and security measures must then be explicitly documented.
AP-03 — Everything as Code and Declarative Management
Principle
Infrastructure, platform, configuration, and policy definitions are managed declaratively and as code wherever possible. Git is the authoritative source for changes managed through IaC or GitOps.
Where a DTAP — Development, Test, Acceptance, and Production — or similar pipeline is used a consistent and controlled promotion flow is applied wherever possible. This promotion flow applies to all releasable artefacts, including container images, Helm charts, Kubernetes manifests, configuration bundles, and other versioned software and platform artefacts.
The guiding rule is:
Build/package once, promote the same artefact through the pipeline, configure per environment.
Rationale
Declarative management makes environments reproducible, reduces human error, and prevents configuration drift. The desired state can be reviewed, tested, deployed automatically, and reconstructed when necessary. A consistent promotion flow also ensures that the artefact tested and accepted in an earlier environment is the same artefact ultimately used in production.
This does not apply only to application images. A Helm chart, package, or other deployment artefact can also change between environments when it is rebuilt, regenerated, or repackaged for each environment. In such cases, it can no longer be demonstrated with sufficient certainty that production is running exactly what was previously tested.
A distinction is therefore made between:
- Artefact: an immutable, versioned output that is promoted through the a pipeline.
- Environment-specific configuration: configuration that is intentionally allowed to differ between environments and is managed separately, declaratively, and under version control.
Implementation
- Git is the source of truth for the desired state.
- Changes follow a controlled Git-based process.
- Changes are traceable to commits and preferably merge or pull requests.
- GitOps tooling reconciles the desired state with the actual state.
- Direct manual changes to environments are avoided.
- Kubernetes manifests, Helm, and Kustomize are used where appropriate.
- Infrastructure and platform configuration is stored under version control.
- Rollback is performed, wherever possible, through Git and/or a previously validated artefact version.
- Where a DTAP pipeline is used, a fixed and transparent promotion flow is applied from Development → Test → Acceptance → Production.
- The promotion flow applies, wherever possible, to every type of releasable artefact.
- Container images are built once and subsequently promoted unchanged.
- Helm charts are packaged and published once and subsequently promoted through the environments using the same chart version.
- Other packages, manifests, and generated artefacts follow the same principle wherever possible.
- Artefacts are immutable and have a unique, traceable version, digest, or identifier.
- An artefact is preferably not rebuilt, regenerated, or repackaged for a subsequent environment.
- Environment-specific configuration is kept outside the immutable artefact and managed declaratively.
- For each environment, it must be possible to determine which versions of which artefacts are currently deployed.
- Promotion may include automated quality gates and/or explicit approval.
- Skipping stages in the regular promotion flow is treated as a controlled exception.
- Policies are defined as code wherever possible.
- Manual configuration through administrative interfaces is minimised.
- Environment-specific differences are explicitly defined as configuration.
- Configuration is tested and reviewed where possible before deployment.
- An environment should, as far as possible, be reconstructable from the recorded declarative configuration.
Impact of Deviation — High
The absence of Git as the source of truth can result in configuration drift, reduced reproducibility, and insufficient auditability.
If artefacts are rebuilt, regenerated, or repackaged for each environment, it may no longer be possible to establish with certainty that the production artefact is identical to the artefact previously tested and accepted.
This may lead to:
- differences between DTAP environments;
- reduced reliability of acceptance testing;
- non-reproducible deployments;
- configuration drift;
- uncontrolled or untraceable changes;
- software supply-chain risks;
- more complex rollback;
- reduced release auditability.
Manually configured components are harder to reproduce, control, and recover. Disaster recovery may therefore take longer, and differences between OTAP environments may arise unnoticed.
Operational overhead also increases, together with dependency on individual administrators and undocumented knowledge.
Deviation Permitted If
An artefact cannot technically be promoted unchanged between environments, or an alternative approach is demonstrably necessary. The selected approach must then provide an equivalent level of integrity, traceability, reproducibility, and control. Required manual configuration must then be documented, performed in a controlled manner, and automated where possible.
Operational emergencies may require direct intervention or an alternative promotion route. The change and deviation must subsequently be incorporated into Git and the regular operational and promotion flow as soon as possible.
AP-04 — Platform Services Are Modular, Reusable, and Replaceable
Principle
Generic functionality is provided as a shared platform capability. Applications consume these capabilities through standardised interfaces and are not unnecessarily coupled to a specific product implementation.
Rationale
Haven+ is a composition of platform capabilities rather than a monolithic product. A modular architecture prevents duplication, promotes standardisation, and allows components to be replaced, maintained, or upgraded independently.
Architecturally, a distinction is made between the required capability and the product that implements that capability at a particular point in time.
Implementation
- Central platform services are reused where they meet the requirements.
- Applications do not implement their own equivalent of an available platform capability without a justified need.
- Open interfaces, protocols, and standards are preferred.
- The capability and its product implementation are architecturally distinguished.
- Coupling to product-specific functionality is minimised.
- Platform components have their own lifecycle wherever possible.
- Replacement of a component should not unnecessarily require changes to all consuming workloads.
Example
The architectural requirement may be identity and access management. Keycloak may implement this capability, but applications should preferably integrate through standards such as OIDC rather than through unnecessary Keycloak-specific behaviour.
Impact of Deviation — Medium/High
Applications may develop separate solutions for capabilities such as identity, secrets, ingress, or observability. This results in functional duplication, additional operational overhead, inconsistent security levels, and higher lifecycle costs.
Strong coupling to a specific product implementation also makes future replacement or upgrades more complex and expensive.
Deviation Permitted If
The available platform capability demonstrably fails to meet the functional or non-functional requirements of the application. The alternative solution and its consequences for operations, security, and lifecycle management must be explicitly documented.
AP-05 — Open Source, Open Governance, and European Digital Autonomy
Principle
For Haven+ and the platform services built on it, open-source software with transparent and independent governance is selected wherever possible.
Preference is given to projects governed or stewarded by the Linux Foundation, the Cloud Native Computing Foundation (CNCF), or a comparable independent open-source foundation. Mature European open-source products, are also preferred where they are functionally, technically, and operationally suitable.
Rationale
Source-code availability alone is not sufficient to prevent vendor dependency. In practice, an open-source product may still be strongly dependent on a single commercial vendor, owner, or very small group of maintainers.
Independent and transparent governance reduces this risk and supports continuity, transferability, community development, and the ability for multiple market parties to provide expertise and support.
European open-source solutions receive particular consideration because of their potential contribution to:
- European digital autonomy;
- technological independence;
- data sovereignty;
- availability of European knowledge and expertise;
- reduced strategic dependency on non-European vendors.
Implementation
- Software is preferably available under a recognised open-source licence.
- Suitable projects within CNCF, the Linux Foundation, or a comparable independent open-source foundation are the first preference.
- For CNCF projects, project maturity, governance, and status are considered where relevant.
- European open-source products are preferred alternatives where they are demonstrably mature, secure, actively maintained, and operationally suitable.
- Product selection is based not only on functionality, but also on licence, governance, community, maintainability, security process, and continuity.
- Projects effectively controlled by a single commercial vendor are explicitly assessed for vendor-lock-in risk.
- Dependency on a single maintainer or a very small development community is explicitly assessed as a continuity risk.
- Open standards and interoperability remain fundamental requirements; being open source is not sufficient in itself.
- Where commercial support is required, support from multiple independent providers is preferred.
- Product selection considers whether sufficient knowledge and expertise is available, or can reasonably be developed, within the European market.
Impact of Deviation — High
A deviation may lead to greater strategic dependency on a single commercial vendor or technology provider. Possible consequences include:
- higher exit and migration costs;
- reduced influence over future product development;
- risk of future licence or business-model changes;
- reduced ability to have another party maintain or develop the solution;
- dependency on non-transparent roadmaps or decision-making;
- reduced European digital autonomy;
- potential concerns relating to data sovereignty and extraterritorial dependencies.
For open-source projects with a very small community, maintainer and continuity risks may also arise.
Deviation Permitted If
A solution outside the preferred categories is demonstrably necessary or substantially more suitable because of functional, technical, security, continuity, operational, or cost requirements, and no suitable Linux Foundation/CNCF or European open-source alternative is available.
A deviation must document at least:
- the open-source alternatives considered;
- rationale for the product choice;
- licence and governance risks;
- vendor dependency;
- consequences for digital autonomy and data sovereignty;
- exit and migration options;
- availability of alternative vendors or support providers;
- mitigating measures.
AP-06 — Security by Default
Principle
Security measures are provided and technically enforced centrally and consistently by Haven+ wherever possible. Applications and platform components follow the principle of least privilege.
Rationale
Security is more effective and manageable when generic controls are available by default and do not need to be designed, implemented, and maintained separately for every application.
Central services promote a consistent security baseline and make security policies easier to demonstrate and audit.
Implementation
- Central identity services and open standards such as OIDC are used where appropriate.
- Secrets are not stored in application code, container images, or unsecured configuration.
- Secrets are managed through designated platform services.
- TLS and certificate management are centrally and automatically managed wherever possible.
- Policies are automatically enforced where possible.
- Service accounts and workloads receive only the minimum permissions required.
- Security configuration is managed as code wherever possible.
- Security controls are enabled by default wherever possible rather than being optional.
- Deviating security configurations are explicitly justified and assessed.
Impact of Deviation — Very High
Deviations may result in inconsistent security, unauthorised access, inadequate secrets management, or insufficient evidence that security controls are operating effectively.
This may affect compliance with applicable laws, regulations, and security frameworks, as well as the ability to operate the solution securely. Security deviations may also affect resources beyond an individual workload when shared platform resources are involved.
Deviation Permitted If
Only after an explicit security risk assessment and formal risk acceptance by the accountable risk owner. Compensating controls must be implemented and documented wherever possible.
AP-07 — Observability by Default
Principle
Every production workload is observable through central facilities for logging, metrics, and, where relevant, distributed tracing.
Rationale
A distributed Kubernetes platform can only be operated reliably when behaviour, availability, performance, and failures are sufficiently visible. Central observability supports operations, incident analysis, capacity management, security analysis, and demonstrable achievement of service levels.
Implementation
- Applications produce useful and preferably structured logs.
- Relevant technical and functional metrics are exposed.
- Critical conditions generate appropriate alerts.
- Distributed tracing is used where required for end-to-end observability and diagnostics.
- Central dashboards support operations and incident analysis.
- Correlation between logs, metrics, and traces is supported wherever possible.
- Monitoring and alerting are part of the Definition of Done for production use.
- Applications do not build a separate observability stack without a justified need when central services are available.
- Retention and access to observability data are configured appropriately.
Impact of Deviation — High
Incidents may be detected later and become more difficult to diagnose, increasing Mean Time To Repair (MTTR). Problems across service chains become harder to locate, and SLA/SLO compliance becomes more difficult to demonstrate.
Security incident analysis, capacity management, and proactive detection may also be impaired.
Deviation Permitted If
The workload demonstrably does not require operational observability or uses an equivalent centrally accessible facility. The alternative must provide sufficient support for operations, incident analysis, and relevant audit or compliance requirements.
AP-08 — Separation of Responsibilities
Principle
Infrastructure, Haven+ platform services, and application workloads have explicitly separated responsibilities, ownership, and lifecycles.
Rationale
A clear division of responsibilities prevents ambiguity regarding operations, security, incident handling, lifecycle management, and changes. This supports Haven+ as a shared platform on which multiple workloads and teams can operate in a controlled manner.
Implementation
- Platform and application configuration are logically separated.
- Ownership of repositories, namespaces, secrets, policies, and other resources is explicitly defined.
- Application teams consume the provided platform interfaces.
- Administrative permissions follow the responsibility model and the principle of least privilege.
- Platform and application components can be changed and upgraded independently wherever possible.
- Responsibilities for incidents, vulnerabilities, patches, backups, and recovery are explicitly assigned.
- A distinction is made between the responsibilities of the infrastructure provider, Haven+ platform operations, and application teams.
- Shared responsibilities are explicitly documented to prevent gaps and overlap.
Impact of Deviation — High
Unclear ownership may lead to operational and security issues, delays during incidents, and uncontrolled changes.
Excessive permissions for application teams may affect the stability or security of other workloads. Conversely, excessive dependency on platform operations may create delays and ambiguity regarding application responsibilities.
Deviation Permitted If
Responsibilities cannot be fully separated through technical controls and can instead be adequately managed through explicit organisational controls, authorisations, and operational agreements. Residual risks and the accountable owner must be documented.
Summary
| ID | Architecture Principle | Impact of Deviation | Primary Risk |
|---|---|---|---|
| AP-01 | Cloud and vendor agnostic | High | Vendor lock-in / portability |
| AP-02 | Kubernetes as the platform contract | High | Divergent infrastructure / operations |
| AP-03 | Everything as Code and declarative management | High | Reproducibility / operations / configuration drift / release integrity / auditability |
| AP-04 | Modular, reusable, and replaceable platform services | Medium/High | Duplication / tight coupling |
| AP-05 | Open source, open governance, and European digital autonomy | High | Strategic dependency / autonomy |
| AP-06 | Security by default | Very High | Security / compliance |
| AP-07 | Observability by default | High | Operability / incident response |
| AP-08 | Separation of responsibilities | High | Ownership / security / operations |
Generic Deviation Process
Deviations from the architecture principles above are permitted where there is a demonstrable functional, technical, or business need.
Every deviation must be explicitly documented as an architecture decision and must include at least:
- the affected architecture principle;
- the reason and necessity for the deviation;
- the alternatives considered;
- the selected solution and rationale;
- risks and consequences;
- impact on portability, security, operations, continuity, and digital autonomy where relevant;
- mitigating or compensating measures;
- the accountable risk owner;
- how the deviation will be monitored;
- if temporary, the intended end date or reassessment date.
Deviations with a High or Very High impact require explicit architecture and risk acceptance before the solution is taken into production.