Why architecture became about people, not technology
When we started building the technology and architecture practice for CustomerFirst, we thought we had a reasonable idea of the role architecture would play.
Like many teams, we expected to spend our time understanding technology estates, mapping systems, identifying technical risks and leading organisations towards making good technology decisions.
What we did not expect was that the most valuable architectural conversations would have very little to do with technology at all. Instead, we've found ourselves talking about organisations, relationships and trust. We've spent time understanding how decisions are really made, where operational boundaries exist, and how information moves between teams. We’ve also explored why seemingly simple changes can become surprisingly difficult.
As we've worked with different organisations, we've realised these themes aren't unique to one partner. They've appeared repeatedly across services and departments, changing the way we're thinking about architecture.
Before committing to significant investment or large-scale transformation, we work with organisations to understand whether a different approach is actually viable. We test ideas, gather evidence and learn quickly before deciding what should happen next; we’ve previously written about our approach to exploration sprints. We're also learning what it takes for multidisciplinary teams to succeed in the NewCo model, and architecture needs to fit that environment.
As we've written before, NewCo is about creating bounded space for small, multidisciplinary teams to look at a service differently.
Many architectural approaches were developed for delivery programmes that already knew where they were heading. We're often working with organisations that are still defining the problem, or where the problem itself has evolved. They're exploring options rather than implementing predetermined answers, which has prompted us to rethink architecture's role in delivery.
If understanding the landscape takes months, teams lose the ability to learn quickly. If decisions have to pass through layers of governance, momentum fades and support for change becomes harder to build.
None of this invalidates traditional approaches to enterprise architecture. It simply reflects the context it was designed for. We're finding ourselves applying architecture differently.
What we mean by lightweight architecture
We've started referring to this as lightweight architecture. This is not because it reduces the rigour required to meet core principles of scalability, secure by design, interoperability or maintainability. It’s because it applies just enough architectural thinking to help teams make the next good decision. Rather than answering every question up front, it helps teams move forward with confidence while leaving room for new evidence to influence future decisions.
What we learned from two recent engagements
During a recent six-week discovery, we worked across an extremely fragmented and complex federated landscape.
At the outset we expected much of the work to be on technology and integration, to understand the systems, the dependencies and how everything connected.
We quickly discovered that understanding the technology was only one part of the challenge. The more important learning was understanding the landscape around it: who owned what, where decisions were made, how change happened and what would need to be true for services to evolve safely.
Users in this context do not experience those organisational boundaries; they experience a moment as part of their wider journey across that complex system.
That observation changed the conversations we were having. We spent less time discussing integration patterns and more time building a shared understanding of the problem, identifying operational dependencies and exploring how information could be shared responsibly. These conversations were every bit as architectural as discussing platforms or APIs.
One of the most valuable architectural decisions we made on another engagement was not deciding what to build. It was deciding not to build at all.
Instead of investing immediately in technology, we created a small experiment that generated evidence within days. The experiment was simple to implement, however went through a fast-tracked but fully signed-off governance process to get the experiment safely in front of users.
We worked with the Data Protection Officer as part of the delivery loop rather than as an approval gate. By giving them early access to the architectural decisions they were quickly able to assess risk and resolve privacy concerns that needed assurance before launch and within the scope of the experiment.
We used existing products that have been built and exist in the GDS products suite. We obtained approval to divert a small segment of user data that flowed into the service for a particular cohort of users. We used technical expertise from the partner organisation to route the cohort to the new service and worked with content designers so the new service could be found by that group during the experiment.
That evidence is now shaping future decisions in a way that simply would not have happened had we started with a detailed solution and spent weeks or even months working through governance processes designed for larger-scale change. We know governance systems exist to reduce risk in delivery. We are testing the application of appropriate governance at varying stages of our work, which is important, especially as we move towards higher fidelity, where more governance and assessment will always be necessary.
Reducing the cost of discovering the future
Experiencing high governance environments has reinforced something we'd started to suspect across several explorations: perhaps one of the most valuable things architecture can do is not describe the future but reduce the cost to the taxpayer of discovering the future. That idea continues to shape our thinking.
We're not presenting lightweight architecture as a finished methodology or a replacement for established architectural practices. But the faster organisations need to learn, the more architecture itself needs to become adaptive.
For us, that means architecture becoming another enabling function within the CustomerFirst model. It helps teams understand before they invest, helps partners work before they integrate, and helps organisations make confident decisions while uncertainty still exists.
Leave a comment