CLEAR: why the order matters more than the steps

Most modernisation programmes do not fail because the people running them are careless. They fail because they start in the wrong place.

We named our method CLEAR because the five steps spell the outcome we are after: Clarify, Lighten, Establish, Accelerate, Realise. But the acronym is the least important thing about it. What matters is the sequence. Each step only works if the one before it has been done, and most of the damage we get called in to repair comes from programmes that skipped one or started at step three.

This is not a manual. Nobody runs CLEAR from a blog post, and we would not want them to try. What we can do here is explain why the order is what it is, and what goes wrong at each step when it is skipped. If you recognise your own estate in any of these, that recognition is the point.

Clarify

Every organisation has architecture diagrams. Some are hand drawn and years out of date. Many today are generated automatically from the cloud console, the service map or a discovery tool, and those are usually accurate. The problem is not that they are wrong. The problem is what they leave out.

A generated diagram shows every system and every connection with equal weight. It cannot tell you which flows the business would stop without, which ones have been dead for two years but still run, which integration was added on a Friday afternoon as a workaround and became permanent, or why two departments solved the same problem in different ways and never told each other. It shows structure. It does not show meaning, ownership, or intent, and it has no idea what the people who built it were thinking.

We have watched a programme select a target platform, secure the budget, and get six months into delivery before discovering that a workflow the finance function depended on ran through a system the map showed as a minor node. The map was correct. Nobody had asked what the node was for.

Clarify comes first because every later decision is only as good as the understanding it is made from. You cannot decide what to retire, what to keep, or what to build on until you know not just what is running, but what it is for and who would notice if it stopped. When Clarify is skipped, the programme is modernising a picture of the estate rather than the estate itself.

Lighten

The second step is the one most programmes skip entirely, because it feels like going backwards.

Once the real picture is on the table, the temptation is to move straight to designing the future. But most estates are carrying weight that will never pull its way: parallel systems doing the same job, integrations kept alive because nobody is sure what would break, licences renewed by habit. Build the target architecture on top of that and you have not modernised anything. You have added a new layer to an estate that was already too heavy.

We have seen this produce the strange result of an organisation finishing a well funded modernisation programme with more systems than it started with. Nothing was removed, because removal was never a step. The new platform landed, the old ones stayed, and the estate got harder to run than before.

Lighten has to come before Establish because target architecture designed for a bloated estate is bloated architecture. The cleaner the base, the simpler the target, and the less you have to migrate, integrate and explain later. Lightening first is also where the budget for the rest of the programme usually comes from.

Establish

This is the step where most modernisation programmes think they begin, and it is the step most organisations do worst, for one reason: they design the architecture but nobody owns it.

An owned architecture has a named person accountable for each layer, agreed standards for how systems talk to each other, and guardrails that give that person the authority to say no. An unowned architecture is a deck. It might be a very good deck. Boards approve them every quarter. But the moment a project team meets a deadline, an unowned architecture loses to the deadline, every time, because there is nobody in the room whose job it is to hold the line.

The programme with the forty slide target state and no route from current to target is the classic case. It was strategic, it was inclusive, and it gathered dust, because strategy without ownership has no way of surviving contact with delivery.

Establish sits third because it needs the first two steps to be honest. You can only tie an architecture to business goals when you know what the business actually runs on and have cleared out what it does not need. And it must sit before Accelerate because delivery without an owned architecture is how technical debt gets created at scale.

Accelerate

Accelerate is where the work becomes visible, and where the pressure to go big is strongest.

The big bang cutover is attractive because it looks decisive. A single go live date, a single migration, a single moment where the old world ends. In practice it forces the worst trade off in IT: either go live with known issues or admit the timeline was never real. We have seen leadership teams face that choice at the end of two year programmes, with no third option left.

Phased delivery is slower to describe and faster to succeed. Each phase has a defined scope, a measurable result, and a decision gate before the next one starts. If something is wrong, you find out at the end of phase two, not on cutover weekend. And because each phase is delivered alongside the internal team rather than around them, the organisation learns how its own new architecture works while it is being built.

Accelerate comes fourth because phasing only works against an owned architecture. Without Establish, each phase drifts. With it, each phase lands inside a structure that already knows where it belongs.

Realise

The last step is the one that separates a programme from a capability.

Most modernisation efforts end when the platform goes live. The consultants leave, the project closes, and within eighteen months the documentation is out of date, the decisions are unexplained, and two people hold the whole picture in their heads. When one of them resigns, the organisation is back where it started, with a newer estate.

Realise is about two things. The first is proof: metrics that show the board what changed, in terms they can repeat without a technical translator. The second is durability: the reasons behind every significant decision written down as they are made, so the architecture can be explained by anyone, not only by whoever was in the room. That is what makes the clarity belong to the organisation rather than walking out with a person.

We put Realise last because it is the step that makes the other four permanent. Skip it and you have paid for a modernisation. Do it and you have built a organisational capability.

Where CLEAR comes from

CLEAR is not a theory we designed and then went looking for clients to test it on. It codifies the way we have worked across national agencies, transport authorities, and global retail and industrial groups over more than a decade.

The clearest example is our work with Kronofogden, the Swedish Enforcement Authority. They came to us with ten years of department built systems, no shared reference architecture, and a drawer full of earlier attempts that had never been approved. The engagement produced a reference architecture, a working reference application, and a migration plan. The result was adopted across the organisation and is now mandatory for more than fifty applications, reviewed positively by a Gartner analyst, and built to hold for at least a decade.

Every step above happened there, in that order. Not because we forced a framework onto the situation, but because doing it in any other order had already been tried.

Diagnose your own programme

Here is a simple way to use this article. Take your current or most recent modernisation programme and ask which step it started on.

If it started with a platform decision, it started at Establish or Accelerate, and Clarify and Lighten were skipped. If it ended with more systems than it began with, Lighten was skipped. If the target architecture exists as a document but nobody can name who owns it, Establish was done as a deck rather than as a decision. If you cannot explain to your board what changed and why, Realise never happened.

None of these are unusual. They are the normal shape of modernisation in large organisations, and they are why we built the method around the order rather than the steps.

Where to start

If you want to know where your estate stands, the Architecture Signal assessment takes about ten minutes and gives you a scored picture of where the real risks sit. If the picture raises questions you would rather discuss, the next step is a free 30-minute Architecture Diagnostic. That is how every tDigital engagement starts.