Skip to content

Reference Architecture Maturity Model

Jump to bottom
Adri edited this page Aug 1, 2024 · 3 revisions

There are three levels of maturity for Reference Architectures exist:

  1. No Reference Architecture
  2. Clone and Forget
  3. Reference Architecture as Product
  1. No Reference Architecture

At this level of maturity, the platform is architected enough to build and run applications, but no Reference Architecture exists. This level is significant since the ability to build and run applications is a prerequisite for creating Reference Architectures. The platform should have the following capabilities:

  • Onboarding Teams and Applications: A method for onboarding teams and applications with minimal additional processes (preferably one form to submit).
  • CI Pipeline Creation: A tool for creating and running CI pipelines, empowering developers to write and run their own.
  • Application Deployment (CD): Ideally, a GitOps-based approach that allows developers to create their own manifests with the platform consuming and reconciling them.
  • Provisioning Credentials: A way to provision credentials for integrations like version control systems, image registries, static code analysis tools, vulnerability scanning tools, databases, messaging, caches, and remote service invocations.

At this level, every development team must figure out how to write the pipeline and deployment manifests, leading to duplication of efforts and inconsistencies. However, this helps establish patterns for later use.

  1. Clone and Forget

At this level, templates exist for all Reference Architecture artifacts, such as repository templates, pipeline templates, and templated manifests. Developers clone and run these templates with specific parameters during onboarding to obtain ready-to-use artifacts. From then on, the development team owns these artifacts, leading to a bifurcation between the evolution of the Reference Architecture templates and the specific instance. As divergence increases, it becomes harder to integrate updates from the Reference Architecture templates, often requiring manual merges. Early adopters experience the most significant drifts.

  1. Reference Architecture as Product

At this maturity level, Reference Architectures are treated as products with releases, new features, and bug fixes. Backward-incompatible releases may occur, requiring specific files within the code repository. Developer teams using a particular Reference Architecture can adopt new releases when feasible. Dedicated Platform teams maintain Reference Architectures, create documentation, release notes, and assist developer teams in adoption. Establishing feedback loops with the developer community is crucial for evolving Reference Architectures based on ongoing requirements.

Clone this wiki locally