What is a Statement of Architecture Work (SoAW)?

A Statement of Architecture Work is a TOGAF deliverable that frames an architecture engagement before any design starts. It records the scope, the stakeholders, their concerns, the as-is description, the assumptions, the constraints, and what the engagement will produce. Treated seriously, it is a transparency contract between the architect and everyone the work will affect.

How does a SoAW reduce political friction on transformation projects?

The SoAW lists every stakeholder by name and writes down their genuine concern in their own words. Once a concern is on a shared document that everyone signs, it stops being a private agenda and becomes an item on the work plan. Nobody can claim later that they were ignored, and nobody can wage a backchannel campaign about a concern that the document already commits to addressing.

Why does the as-is section of a SoAW matter so much?

The as-is description forces the team to look closely at what is actually running today, not what the documentation says is running. That depth of inspection routinely uncovers single points of failure, undocumented dependencies, end-of-life hardware, and tribal knowledge held by one person. Discovering these before the transformation begins is far cheaper than discovering them mid-rollout.

Which stakeholders should appear in a SoAW?

Anyone whose work, budget, accountability, or systems will be touched by the engagement. That usually means the business owners of affected processes, the IT operators of affected platforms, the security and risk functions, the finance partner who funds the change, and the local site managers whose continuity depends on the systems involved. The test is simple: if their concern could derail the project, they belong on the list.

Is a SoAW only relevant if you follow TOGAF?

No. TOGAF formalises the deliverable, but the underlying discipline is independent of the framework. Any non-trivial transformation benefits from writing down the scope, the stakeholders, their concerns, and an honest as-is before starting. The format can be a template, a wiki page, or a single document. What matters is that everyone affected signs the same version.

The SoAW: Where Transformation Gets Honest

This is a short story about an SAP rollout, a sales office in Beijing, and a 25-year-old server.

It is also the story that changed how I think about the Statement of Architecture Work, the smallest and least glamorous artefact in the TOGAF toolkit, and the one I now treat as the most important deliverable in any transformation. That is why I chose to bake this document into Turbo EA itself.

Enterprise Architecture, at least the way I practice it, is not about collecting diagrams and running around with capability maps. It is about setting the architectural intent of major transformations, with an effective methodology grounded in a holistic approach. It works because it elevates the discussion from the target solution to the actual business architecture discussion.

A sales office in Beijing

A few years ago I was kicking off an SAP rollout across a mid-size industrial group that had recently integrated a smaller company through acquisition. One of the newly absorbed entities ran a sales office in Beijing, and the request that landed on the programme came from the Beijing team itself. Their ERP vendor had pulled out of China, their support contract was gone, the system was effectively orphaned. They wanted to be migrated to SAP, urgently, ahead of the rest of the integration plan. On the surface it was a clear-cut business continuity emergency that called for an accelerated rollout.

The SoAW required an as-is description, so the local IT lead flew to the site and looked at the machines.

What he found was worse than the no-support story. The ERP was running on a 25-year-old monolithic server. Isolated, off any modern management plane, with no failover. Spare parts could only be sourced on eBay. None of this was in the CMDB. None of it was on any risk register. It existed entirely at one office, on the other side of the world from headquarters.

But the visit also surfaced something the original brief had ruled out: a much smaller intervention was possible. The continuity problem did not require an emergency SAP rollout. It required virtualising that one machine.

A small fix that changed the project

We paused the SAP design discussions for a few weeks, virtualised the legacy server onto modern infrastructure, and put a proper backup and runbook around it. Business continuity went from one eBay listing away from disaster to a routine VM with snapshots, at a fraction of a single week of what the emergency rollout would have cost.

The Beijing team’s concern was real, and it was answered. Because it was answered without committing to an accelerated SAP rollout, the rest of the engagement could now be looked at properly.

That is when the regional finance team came forward.

Their concerns were nothing like Beijing’s. They were not about continuity at all. They were about the business shape of the integration: how the newly acquired entity would actually be folded into group processes, controls, and reporting. Real, specific, and disconnected from the trigger that had launched the conversation. The SoAW gave each of those concerns a line on the page next to the relevant stakeholder name.

What the project actually was

Once every concern was on the list and the as-is was honest, the shape of the engagement was unrecognisable from the original brief.

The continuity emergency had dissolved into a small infrastructure task, already done. The hard work was business architecture: aligning processes, capabilities, and the operating model of the acquired entity with the group. That is what got delivered. A deliberate business architecture engagement, with a small side infrastructure project. Not an emergency SAP rollout.

The trigger had been real. The project that the trigger called for was the wrong project. The SoAW is what let us see that in time.

What the SoAW actually did

None of this was a TOGAF trick. It was the SoAW doing its real job.

The first job is forcing an honest description of what is actually running today. Most projects skip this. They paste the architecture diagram from the last steering deck, declare it accurate, and move on. The diagram describes the system as the documentation says it works, not the system as it actually works. The gap between the two is where bad surprises live, and that gap is exactly what the Beijing site visit closed.

The second job is forcing a list of stakeholders and what each of them is genuinely worried about. The Beijing team had a valid continuity concern, and they had proposed the wrong solution to it. The regional finance team had a different set of concerns entirely. Without a structured place to put each of those concerns, the programme would have launched as the emergency the Beijing team asked for, the finance concerns would have surfaced mid-rollout after commitments were made on the wrong scope, and the 25-year-old server would have been discovered only when something broke.

The SoAW asks two uncomfortable questions: who is affected, and what is actually running today? Answered properly, they kill the backchannel conversations, expose the real scope of the work, and put the real risks on the table before a single design choice is made.

The list that kills politics

Generalise that second job, and you get the part of the SoAW most teams underestimate.

You list the stakeholders. Not the steering committee. Not the names that look good on a slide. Every person whose work, budget, accountability, or systems will be touched by the engagement.

Then, next to each name, you write their concern. In their own words. Without sanitising.

The product owner who is worried the project will swallow the next quarter’s roadmap. The CFO who wants the migration cost broken out from the run cost. The security lead who has seen three programmes ship with the same identity workaround and refuses to be the fourth. The local site manager whose team depends on a machine nobody at headquarters has ever seen.

None of those concerns are noise. They are the project, expressed honestly.

Something quiet happens when you put that list on a shared document and ask everyone on it to sign. Concerns stop being private agendas. They become work items. Nobody can claim afterwards that they were ignored, because the page in front of them has their name and their words on it. Nobody can run a backchannel campaign about a risk that the document already commits to addressing.

This is not a soft outcome. It is the difference between a transformation that spends its first six months relitigating trust and one that spends its first six months delivering.

The SoAW as a transparency contract

That is what the SoAW really is. Not a deliverable for the architect’s archive. Not a sign-off ritual. A transparency contract with four columns.

Here is the work we are committing to. Here are the people it will affect. Here is what each of them is genuinely worried about. Here is what we will do about it.

Sign that together, and the architecture work has a foundation. Skip it, and every later disagreement turns into a debate about whose concern was raised when, and whose interpretation was on the slide deck nobody actually read.

The TOGAF format is one way to structure the contract. A wiki page can do it. A single shared document can do it. The framework is not the discipline. The discipline is the honesty.

Closing thought

When every concern is listed by name, politics has nowhere to hide. When the as-is is described honestly, surprises do not ambush you halfway through the build. The SoAW is the smallest, cheapest, least glamorous artefact in the TOGAF toolkit, and it is the one that decides whether the next twelve months go well.

Write it properly. Have the awkward conversations early. Then build.