Architecture & Design

Domain-driven decomposition, C4 modelling, API-first architecture, and the "buy common, build unique" principle.

Overview

Architecture is the highest-leverage activity in any programme. Getting the decomposition right removes more downstream risk than any other investment. At the Department of Home Affairs, we reduced 700 ESB integrations to 16 RESTful resources across 5 domains in 6 months with a team of 3. At ABF, our cargo systems strategy secured executive approval and capital funding. These results come from the same approach: understand the business domain deeply, decompose by business function, and design modular architectures that let small teams deliver independently.

How We Deliver

System Decomposition

We follow domain-driven design principles, informed by deep engagement with business subject matter experts.

  1. Understand the business domain. Before any technology decisions, we invest in understanding core business functions and the natural boundaries between them. This requires working with the most experienced subject matter experts, not just technologists.
  2. Identify bounded contexts. We map the business into bounded contexts with their own internal complexity but minimal coupling to other contexts. These become the natural boundaries for services and teams.
  3. Define interfaces. Between bounded contexts, we define lightweight interfaces — typically RESTful APIs and domain events. These are the only coupling points, designed to remain stable as internals evolve.
  4. Align teams to domains. Each bounded context is owned by a small, multidisciplinary team with end-to-end responsibility. This is the inverse Conway manoeuvre: designing the architecture to drive the team structure.

We apply the ADDA programme decomposition approach to break large monolithic programmes into loosely coupled workstreams. This eliminates the two most common failure patterns: too many dependencies between product teams, and too many blockers from platform and support teams.

C4 Architecture Documentation

We use the C4 model to communicate architecture at the right level for each audience:

  • Level 1 — System Context. The system in its environment: users, external systems, boundaries. For executive stakeholders.
  • Level 2 — Container. High-level technology building blocks: applications, APIs, databases, message queues. For technical leadership.
  • Level 3 — Component. Internal structure of each container: modules, services, responsibilities. For development teams.
  • Level 4 — Code. Class and interface design, used only where complexity warrants it.

Buy Common, Build Unique

Government front-office services are shaped by unique legislation, policy, and operational context. Commercial off-the-shelf products rarely fit without expensive customisation that creates vendor lock-in.

For front-office services, we compose solutions from proven open-source libraries and frameworks, adding custom business logic. This delivers better fit than COTS, lower cost than bespoke, and no vendor lock-in. All services expose well-documented RESTful APIs conforming to OpenAPI specifications.

For back-office functions (finance, payroll, HR, records management), we buy. Mature commercial products serve these well. We design clean integration boundaries via APIs so these products can be swapped without affecting front-office services.

Principles

  • Decomposition is the critical success factor. The wrong decomposition — by technology layer or organisational silo — creates crippling dependencies between teams. The right decomposition — by business domain — creates maximally independent workstreams.
  • Architecture as a service, not a bottleneck. We define the boundaries, interfaces, and standards, then empower teams to make their own design decisions within those boundaries. Excessive upfront detailed design is a handbrake on delivery.
  • Ethical separation of strategy and delivery. When we provide architecture strategy services, we voluntarily decline to bid on the resulting implementation work. Our recommendations serve the client’s interests, not our pipeline.

Policy Alignment

  • Australian Government Architecture Framework (AGA) — reuse, interoperability, and technology neutrality.
  • ADDA Program Decomposition — domain-driven decomposition into minimally dependent workstreams.
  • Digital Service Standard (DSS v2.0) — iterative, user-centred design aligned with DSS stage gates.

Evidence

  • Case Study: Home Affairs Integration Strategy — 700 ESB integrations reduced to 16 RESTful resources across 35 domains; team of 3; 6 months.
  • Case Study: ABF Trade Modernisation — Modular future-state architecture with SAFe-aligned costing; secured capital funding.
  • Case Study: ABF Trade Modernisation — Enterprise strategy applying DDD, value metrics, and generative AI; secured capital funding.
  • Case Study: Geoscape Geospatial API — Developer-friendly REST APIs; more traffic in 2 months than the legacy product had in 18.
  • Case Study: Records Management as a Service — Microservices architecture; 500M records with sub-second search at whole-of-government scale.
  • Staff: Steven Capell — SFIA Level 6 enterprise and solution architecture; 30+ years.
  • Staff: Chris Gough — SFIA Level 5 solution architecture; 20+ years.

Tools & Technologies

  • Architecture Modelling: C4 model (Structurizr, draw.io), ArchiMate
  • API Design: OpenAPI / Swagger, RESTful design patterns, API Gateway (AWS, Azure)
  • Domain Modelling: Event storming, bounded context mapping, aggregate design
  • Infrastructure as Code: Pulumi, Terraform, AWS CloudFormation
See all capabilities