Methods

Methods define how we translate technology strategies into practice. They are the ground rules for collaboration between engineering, business, and operations. A consistent set of methods reduces cognitive load in teams and ensures reproducible quality.

This section covers proven frameworks such as the C4 Model for architecture documentation, Site Reliability Engineering (SRE) for stable operations, and agile scaling methods for growing organisations.

---

Table of Contents

• Agile Scaling and Descaling: Agile scaling restores team momentum through simpler structures, stream-aligned ownership and end-to-end responsibility for products or features.
• Bounded Context: Clear domain boundaries create maintainable models, shared understanding between teams and a solid basis for microservice architectures.
• C4 Model and Docs-as-Code: Current architecture diagrams earn trust when C4 Model structure and Docs-as-Code keep services, dependencies and changes aligned with code.
• Compliance as Code: Continuous Compliance as Code keeps regulatory controls machine-readable, testable and integrated into delivery pipelines and audit trails.
• DDD (Domain-Driven Design): Domain-Driven Design creates clear Bounded Contexts where terms have one meaning and microservice architecture gets a reliable domain basis.
• FinOps and Cloud Economics: FinOps makes cloud economics transparent through tagging, right-sizing and operating practices that keep infrastructure spending accountable.
• GitOps and Reconciliation: GitOps keeps infrastructure consistent through pull requests, declarative configuration, reviewable changes and fast disaster recovery.
• Golden Path: Golden Paths speed up delivery with supported development routes while preserving team autonomy for justified deviations.
• InnerSource and Code Openness: InnerSource opens codebases across the organisation for pull-request fixes, smoother delivery flow and broader knowledge sharing.
• ITIL vs. SRE: SRE makes ITIL service management executable with software engineering, automated operations and reliability control through error budgets.
• Requirements and Functional Specifications: Clear requirements come before implementation: Lastenheft defines the buyer view, Pflichtenheft the supplier solution and delivery scope.
• Nearshoring and Vendor Integration: Vendor integration improves delivery quality when service providers use the same GitOps, CI/CD and documentation practices as internal teams.
• Blameless Post-Mortems: Blameless post-mortems turn incidents into timelines, systemic analysis and concrete action items for stronger operational resilience.
• RASCI Matrix: RASCI matrices create ownership clarity by assigning clear responsibility, accountability, support, consultation and information roles.
• Refactoring: Regular refactoring keeps code easier to extend, defects easier to control and technical debt visible while behaviour remains stable.
• RFCs and ADRs: RFCs and ADRs make architecture decisions reviewable, searchable and open to expert feedback across teams and time zones.
• Strangler Fig Pattern: The Strangler Fig Pattern replaces legacy systems incrementally, letting new capabilities grow around existing production systems.
• 20% Tech Debt Rule: The 20% Tech Debt Rule keeps delivery speed sustainable by reserving capacity for refactoring, updates and architecture improvements.