Enterprise Architecture and TOGAF Consulting

Architecture that is written by someone who has to build it

Enterprise architecture has a reputation problem in Australia, and it is largely deserved. Too much of it is produced by consultancies that deliver a model, a roadmap and an invoice, then leave before anything is built. The delivery team inherits diagrams that describe a system nobody has costed, and spends the first three months quietly rewriting them.

The translation loss between the people who design and the people who implement is where most architecture budgets actually go.

I do both halves. I am a TOGAF Practitioner, certified by The Open Group in 2025, and I have been writing production code since 1993 without stopping. That combination is the whole point of the offering: the architecture comes from someone who knows what each decision costs to implement, because implementing it is the next thing on the list.

What the work covers

Enterprise and solution architecture engagements generally sit in one of four areas.

Target state and roadmap

Where the organisation is, where it needs to be, and a sequence of changes that each deliver something on their own. TOGAF's ADM provides the structure — architecture vision, business, data, application and technology architecture, opportunities and solutions, migration planning — but the structure is a means, not the deliverable. A roadmap whose first useful outcome is eighteen months away is not a roadmap, it is a wish.

Integration and interface architecture

The part that determines whether the rest of it is achievable. Most organisations underestimate this by a wide margin, because the systems that need to be integrated are old, poorly documented, and owned by people who have moved on. Real integration architecture means going and looking at the interfaces rather than assuming they exist.

Cloud and platform architecture

Designs on AWS, Azure and GCP that survive an audit as well as a load test. Serverless where it genuinely fits, containers and Kubernetes where it does not, infrastructure as code either way. I hold the AWS Certified Solutions Architect certification and have delivered production workloads on Lambda, Fargate, EKS, CloudFormation, CDK and Terraform.

Identity and access architecture

Federated identity, SAML, OIDC and IAM design. This is specialised work and it fails in ways that are difficult to observe from the outside, which is why it repays being done by someone who has debugged it in production rather than diagrammed it.

Where TOGAF helps, and where it gets in the way

TOGAF is a useful discipline and a poor religion. Its real value is that it forces the questions that otherwise get skipped: who owns this capability, what business outcome does this system serve, what happens to the data, what is the governance around change. Organisations that answer those questions make better decisions regardless of what notation they use.

Where it goes wrong is when the framework becomes the work. An architecture practice that produces a complete set of TOGAF artefacts and no shipped system has failed, however conformant the artefacts are. The right amount of formality depends on the size of the organisation and the risk in the change, and part of my job is to say when the answer is "less than you think".

In practice I use the ADM as a checklist for completeness and produce the subset of artefacts that someone will actually read and use. For a mid-sized organisation that is usually a target state model, an integration view, a set of architecture decision records with the reasoning intact, and a sequenced roadmap. For a government agency subject to formal architecture governance it is more, and I will produce what the governance body requires.

Evidence from delivery

The architecture I write is informed by having had to live with architecture I wrote earlier.

At eHealth Queensland the central architectural decision on a referral management system was to make clinical criteria metadata rather than code — held as XML and JSON in SQL Server and rendered into clinician-facing forms at runtime — because clinical criteria change constantly and no release cycle can keep pace. That decision is why the system is still in service across Queensland Health. It also created integration work across both REST and SOAP boundaries, with RabbitMQ handling referral submission, which was the genuinely hard part and was visible in the design from the start.

At Magentus, three years of healthcare interoperability work produced HL7-compliant FHIR APIs that were adopted across multiple client teams. An API that other teams adopt voluntarily is a reasonable test of whether the architecture was any good.

At the University of Queensland I delivered SAML-based federated authentication into a C#/.NET application and into production. Because SAML fails silently and obscurely, the work included building a mock identity provider to debug traffic before anything reached the real one, alongside dependency conflict resolution through Fusion Logs and assembly binding configuration. That is the kind of detail that never appears in an architecture document written by someone who will not be implementing it.

The broader track record runs through Queensland Health clinical systems, Medicare claims processing, banking, the ATO, and industrial platforms on AWS.

How engagements are structured

Two shapes work well.

The first is a defined architecture piece: a target state, an integration assessment, a cloud design, or a review of an architecture someone else has produced before you commit to it. Fixed scope, quoted up front, typically three to six weeks.

The second is a contract engagement where you have a team and a roadmap and need a senior architect who can also build, without a ramp-up period. Typically three to six months at a day rate, on site in Brisbane or remote anywhere in Australia, direct or through your preferred agency.

In both cases you are dealing with the person doing the work. I carry my own company, professional indemnity and public liability cover.

Related reading:

• AI-powered enterprise architecture, from TOGAF to implementation
• choosing between AWS and Azure for AI workloads
• RAG patterns for enterprise AI
• managing risk in AI-driven systems