Finding the decisions that decide the outcome

Every transformation has a handful of decisions that decide the outcome. Which platform stays and which one goes. Who owns the integration layer. Whether the AI initiative builds on the current estate or waits until the estate can carry it. Where the next two years of budget actually goes.

Most leadership teams know these decisions exist. Very few can name them. They sit underneath forty slides, three vendor roadmaps and a transformation office that reports on progress every month. The programme moves. The decisions do not get made. They get postponed, inherited, or made by default when a contract renews.

That is the situation Architecture Signal was built for. Not a lack of information. Too much of it, and no way to tell which part is the signal.

Why more information makes it worse

The instinct when a programme feels unclear is to gather more information. Another assessment, another current state review, another round of workshops with the business units. Each one produces a document. None of them produces a decision.

We have sat in rooms where the CIO had a vendor roadmap, a cloud migration plan, an integration strategy, a data platform proposal and an AI readiness report, all current, all professionally made, and all written as if the others did not exist. Every document was right on its own terms. Together they described five different futures. Nobody had been asked to choose.

That is the noise. It is not bad work. It is good work with no shared frame around it, so the leadership team cannot see which decisions matter and which ones are already being made for them.

The cost shows up in two places. The first is time. A decision nobody owns gets revisited in every steering meeting, and the programme runs at the speed of the slowest unresolved question. The second is risk. When a decision is made by default, by a renewal date or a vendor's convenience, the person accountable for the outcome carries it without ever having chosen it.

About Architecture Signal

Architecture Signal is an executive accelerator: a minimum of one year, longer when the estate is large, opening with an intensive Discover phase. It looks at the whole estate, not one platform or one project, and it has one job: find the architectural decisions that will determine whether the transformation succeeds or fails, and get the leadership team aligned on them.

It is deliberately not a documentation exercise. You will not receive a new set of diagrams to file next to the old ones. You will receive a clear picture of where the real risks sit, which decisions are open, which ones are already closing by default, and what order they need to be taken in.

It draws on established enterprise architecture practice, TOGAF among it, on systems thinking, and on the experience of leading architecture work inside national agencies, transport authorities, global retail and industrial groups. The method matters, but the point is not the method. The point is that at the end, the people who carry the risk can explain their own estate and defend their own decisions.

That is what we mean by Architecture Without Heroes. The clarity has to belong to the organisation, not to the consultant who produced it.

The Architecture Signal framework

Four moves that take a leadership team from operational noise to executive momentum. As with everything we do, the order is the point. Each move builds on the one before it.

Discover comes first because every judgement that follows is only as good as the picture it produces. Align comes third because you cannot align people around decisions that have not been named, and you cannot name them without a true picture of the estate. Accelerate is the move most engagements try to start with. It is the one that has to come last.

If you recognise the shape, it is the first half of CLEAR, run as an accelerator. Architecture Signal does the clarifying and the deciding. The building comes after, and it comes with an owned architecture instead of an inherited one.

What you leave with

The thing that matters most is the Architecture Decision Register. It is a short list of the decisions that decide your outcome, who owns each one, what depends on it, and what happens if it is left to default. A board can read it. A new CIO can inherit it. That is the test we hold the whole engagement to.

Around the register sit the supporting pieces: a short executive report that explains the findings, a roadmap that sets direction, and a briefing with the leadership team so the decisions are understood, not just documented. The full list is on the accelerator page.

What you do not leave with is a target architecture designed in detail, or a system-by-system migration plan. Architecture Signal stops at diagnosis, risk exposure and direction. Designing and delivering the architecture is a different piece of work, and doing it before the decisions are made is how estates end up with one more layer nobody asked for. That is work we do as well, as a separate engagement, once the decisions are made and the architecture is owned.

Who it is for

Architecture Signal is for the person whose name is on the outcome: the CIO, CTO or Chief Architect, the transformation director, the leadership team that has to approve the next investment, and the scale-up founder whose estate has outgrown the people who built it.

It is most useful when both the stakes and the complexity are high: an AI initiative landing on a legacy estate, a platform strategy with vendors pulling in different directions, a consolidation after a merger, or a programme that has been running for two years and still cannot be explained in one picture.

It is not for an organisation that wants a second opinion on a decision it has already made. If the estate is simple and the decisions are obvious, you do not need us. If the problem is a single product idea rather than the whole estate, a Design Sprint is the better tool.

Where this comes from

The pattern behind Architecture Signal was set at Kronofogden, the Swedish Enforcement Authority. The organisation had a decade of department-led digitalisation and a drawer of reference architectures that had never been approved. What unlocked it was not a better document. It was mapping the estate as it actually ran, naming the decisions the previous attempts had avoided, and getting them approved in the architecture council before anything was built. The reference architecture that followed was made mandatory for every web-based application, more than 50 of them, reviewed by Gartner, and designed to hold for at least a decade.

Two things happened at Kronofogden, and it is worth keeping them apart. The first was strategic: mapping the estate, naming the decisions, getting them approved. The second was implementation, done by Kronofogden's own teams, system by system, over the years that followed. Architecture Signal is the first part, packaged as an accelerator with a fixed scope and a fixed price. The second part belongs to your organisation, and how long it takes depends on the size of the estate. A national agency and a global retailer with factories, shops, warehouses and a delivery fleet will not be on the same timeline. What they have in common is that the implementation only goes well if the decisions were made first.

Where to start

If you want a first read on your own situation, take the Architecture Signal Assessment. Ten minutes, a handful of questions, and a scored picture of where your estate stands and where the real risks sit. If the picture raises questions you would rather discuss, the next step is a free 30-minute Architecture Diagnostic: bring the decisions you are facing and get a straight read on which ones are worth surfacing and where to act.