Architecture & Design

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

Overview

Decomposition is where programmes are won or lost. Get it right and most of the downstream risk simply does not arise.

Two examples of what that is worth. At Home Affairs, three people over six months took 700 ESB integrations down to 16 RESTful resources across 5 domains. At ABF, a cargo systems strategy won executive approval and capital funding.

Same method both times. Learn the business properly, cut along business function rather than technology layer, and design so that small teams can get on with it without waiting for each other.

How We Deliver

System Decomposition

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

Understanding the business comes before any technology decision. That means time with the people who have done the work longest, not only with technologists, because the natural seams in a business are rarely where an org chart puts them.

Those seams become bounded contexts: each dense inside, barely coupled to the others. They are what services and teams should be built around.

Between contexts we keep the interfaces light, usually RESTful APIs and domain events. They are the only places things touch, so they are designed to hold still while everything behind them changes.

Then teams get aligned to contexts, each one small, multidisciplinary and responsible end to end. That is the inverse Conway manoeuvre: pick the architecture you want and let it shape the org chart, rather than the other way around.

For large programmes we use the ADDA decomposition approach to split them into loosely coupled workstreams, which heads off the two failures that recur: product teams waiting on each other, and everyone waiting on a platform team.

C4 Architecture Documentation

The C4 model lets the same architecture be shown at four depths, so each audience gets the one they can act on.

System context is the outermost: the system, its users, the things it talks to, and where its edges are. That is the view an executive needs and the only one they usually need.

Container level shows the technology building blocks, applications, APIs, databases, queues, which is what technical leadership makes decisions against. Component level opens each container up into modules and responsibilities, for the people building it.

Code level, classes and interfaces, we draw only where something is genuinely complicated enough to warrant it. Most of the time it is a diagram that goes stale faster than it is read.

Buy Common, Build Unique

Front-office government services are shaped by a particular Act, a particular policy and a particular way of operating. A commercial product almost never fits one without customisation expensive enough to lock you to the vendor who did it.

So for the front office we assemble from proven open-source libraries and frameworks and write the business logic ourselves. Better fit than off the shelf, cheaper than bespoke from scratch, and nobody owns you afterwards. Everything exposes documented RESTful APIs against OpenAPI.

Back office is the opposite call. Finance, payroll, HR, records management: thousands of organisations need the same thing, so a mature product exists and you should buy it. What matters there is the integration boundary, kept clean enough through APIs that the product can be replaced without the front office noticing.

Principles

• Decomposition is the critical success factor. Cut by technology layer or by org silo and teams end up unable to move without each other. Cut by business domain and they can.
• Architecture as a service, not a bottleneck. We set the boundaries, the interfaces and the standards, then teams decide the rest for themselves. Detailed design done too early is a handbrake.
• Ethical separation of strategy and delivery. Where we provide architecture strategy, we decline to bid on the implementation that follows. The advice should serve the client rather than our pipeline, and the only way to prove that is to give up the work.

Policy Alignment

The Australian Government Architecture Framework asks for reuse, interoperability and technology neutrality, which is what the buy-common-build-unique split is for.

Decomposition follows the ADDA approach, cutting programmes into workstreams that depend on each other as little as possible. Delivery runs iteratively and user-first against the Digital Service Standard’s stage gates.

Evidence

The Home Affairs integration strategy is the clearest single result: 700 ESB integrations down to 16 RESTful resources across 35 domains, by three people in six months.

ABF trade modernisation produced a modular future-state architecture with SAFe-aligned costing, applying domain-driven design and value metrics, and it secured capital funding. The Geoscape geospatial API carried more traffic in two months than the product it replaced had in eighteen. Records Management as a Service proved a microservices architecture against 500 million records with sub-second search.

Steven Capell works at SFIA Level 6 in enterprise and solution architecture, over 30 years. Chris Gough at Level 5, over 20.

Modelling is C4 in Structurizr or draw.io, with ArchiMate where a client expects it. APIs are designed against OpenAPI and run through AWS or Azure gateways. Domain work uses event storming, bounded context mapping and aggregate design, and infrastructure is defined in Pulumi, Terraform or CloudFormation.