# When a systems decision needs a shared business picture *A large UK retailer, a second attempt at unification, and what discovery helped make visible.* A large UK retailer had already run one technology-led unification effort that had not delivered the intended outcome. When I was brought in for the second attempt, the room was senior: CXOs, Directors, and Heads of business and applications. The question on the table sounded clear enough: which systems should be upgraded, which vendor direction should be backed, and how should the organisation set itself up for the next decade? The important work was to slow that question down. ## Different teams held different parts of the picture Many people could describe the symptoms from their own vantage point. What was missing was a shared picture of the problem. The familiar explanation was that the systems were old and needed replacing. That was part of the story, but not all of it. Older systems often sit on top of processes, ownership models and operating habits that have grown over many years. Until those are understood together, it is hard to know whether technology is the cause of the pain, the carrier of the pain, or simply the place where the pain becomes visible. The organisation had complaints, proposals and experience from the earlier attempt. What it needed was a clearer view connecting the business pain, process reality and technology estate. The question was not only what technology should change. It was what the organisation needed to understand before making that decision. ## The decision needed a broader frame The decision that mattered was not only a platform decision. It was whether the work should be treated as a technology upgrade, or as a broader business-and-technology change programme. That distinction matters because it changes sponsorship, sequencing, ownership, design authority, business change, data readiness, vendor accountability and the delivery model needed to carry the work. Without that broader frame, large programmes can move too quickly into solution selection. The plan can become precise before the shared picture is properly grounded. That is understandable: leaders need decisions, vendors need direction, and delivery teams need a plan. The value of architecture in that setting was not to slow the organisation down for its own sake. It was to make sure the decision was being made against the right picture. ## Discovery made the situation visible We did not start with an answer. We started with discovery, and it took the better part of ten months across three phases. I led the technology side — the retail systems, integration, platform and architecture judgement — alongside subcontracted business consultants who brought deep business-process expertise. The work was detailed and practical: how the systems really connected, how the processes actually ran, where the pain originated, which issues were technology issues, which were process issues, and which came from unclear ownership between the two. At the end of the first phase, I opened Excalidraw and drew the situation back to the room: not a polished target-state diagram or a vendor architecture picture, but the current situation as we had found it — dependencies, process breaks, system constraints, hand-offs and workarounds included. Then I began sketching possible routes forward. That was the moment the conversation changed. Not because of the drawing alone, but because enough work had been done for the drawing to mean something. It gave the room a common object to respond to, rather than separate accounts from different parts of the organisation. Architecture’s role there was practical. It made the situation visible enough for senior people to discuss the same problem at the same time. ## The programme changed shape Once the situation became visible, the programme changed shape. It was no longer simply a technology replacement conversation. It became a business-and-technology change programme: multi-year, multi-transition, and dependent on business, data, change, vendor and engineering teams moving together. I architected the roadmap and the transition states. The important work was not only defining a future state, but showing how the organisation could move through credible intermediate states without pretending every part of the business could change at once. That gave the organisation a clearer route into the next decade, at a scale it had not attempted before. Not all of the work continued into the next phase in the way originally intended. I was the Programme Architect leading design, and I was part of the leadership group accountable for the work. It remains work I would stand behind. The value was not that every ambition survived unchanged. The value was that the organisation had a clearer view of what kind of change it was really undertaking. ## What I learned A senior room can contain capable people, strong intent and real organisational pressure — and still not yet have a shared picture of the decision in front of it. That is not failure. It is normal in large change. Different teams see different parts of the system. Vendors respond to the questions they are asked. Technology teams focus on the estate they own. Business teams feel the operational pain. Executives need a route through the complexity. The role of architecture is to connect those views without pretending they are already aligned. I also learned again how much of that work is unglamorous. Ten months of discovery earned the thirty minutes of drawing. The drawing gets remembered. The ten months are what made it useful. ## What leaders should take away Large-scale change works as a partnership of three: - Business - Technology - Executive sponsorship Not one instead of another. Not one carried by the others. Not one expected to follow later. Lose the commitment of any one of the three, and the quality of the architecture will not save the programme. Three questions are worth asking before committing to a multi-year technology decision: 1. Can everyone in the room draw the current situation the same way? If not, people may be making one decision against several versions of reality. 2. Is this being framed as a technology problem because it is one, or because that is the easiest frame for the organisation to act on? That question is worth asking early. 3. Who has done enough work to challenge the first available version of the problem, and have they been given the room to do it? The retailer did not simply need a better system. It needed business, technology and executive leadership looking at the same picture.