This was originally posted on the Government Technology blog.
With the number of visitors we have coming through GDS we’re often asked to present various areas of our work, particularly architecture. We’ve usually kept the presentation pretty informal. People mean so many different things by architecture that it’s important to take some time to understand our audience before we dive into explaining our approach.
Recently though, we’ve noticed some common patterns emerging and have begun pulling our thoughts together as an introductory slide deck.
We are sharing the thinking behind our slide deck here. In sharing this, we want to be very clear that this is a snapshot of a conversation starter. It’s very easy for a piece of work like this to switch from “useful starting point” to “expected, fixed approach” but used carefully it will make it easier for us to reduce the learning curve for new members of the team and present our approach.
The context
Last year Dave Rogers of the Ministry of Justice wrote a great blog post talking about their approach to technical architecture. For me the main insight in that post was captured in the comment:
The emergence of a mature infrastructure-as-a-service and platform-as-a-service marketplace has transformed compute, storage and networks into utilities. With this the costs associated with major architectural changes has dropped, in some cases, to near-zero.
Technical architects who are able to take advantage of these changes are now working with a single medium: code. The physical infrastructure, the manual processes and their constraints have largely gone.
The world in which we’re operating allows more and more elements of our systems to be defined in software, and our profession has developed practices that make that software easier and cheaper to change.
At the same time, not only are more and more of our activities digital, but users have come to expect that great services will be regularly improved. Responsive and regularly improved services engender trust, without which government services fail.
That’s not to say that all architecture is software and at GDS we have architects working on a variety of more “infrastructural” projects, working on Crown Hosting, Public Services Network, blueprints, such as secure email, for Common Technology Services, and so on. Over time, the interfaces between the hardware and software elements are becoming clearer and more standardised, with software defining more and more.
The approach
Within a more rapidly evolving environment, architecture has to be a team sport. That doesn’t just mean “architecture teams”, it means architects and architecture as part of a much broader team.
Teams build systems and services at pace using better tools than we’ve ever had before for. They test the behaviour and performance of our systems every step of the way and iterate as we learn more about our users, their needs, and the interactions between systems. We’ve recognised that to provide great services we need collaborative, diverse and multi-functional teams.
So too, the economics of how we approach common components has shifted. It is easier than ever for teams to build minimum viable components of their own and then swap them out as more mature alternatives emerge.
Common capabilities can still speed up delivery and improve services, but the best components emerge rather than being proscribed in abstract organisational designs.
The GDS architecture community always starts with the same Design Principles as all other disciplines working on delivering digital services, and draw on other great work like the Cloud Security Principles, Open Standards Principles and the Technology Code of Practice but we also have some working principles of our own:
Start small and self-contained
Focus on understanding the user needs your service needs to meet and how it will do that. Consider whether you can do this using existing tools to keep your technology simple.
The unit of delivery is the team
When we work in disciplinary silos we can easily reinforce our biases and we cause friction with complex hands-offs. Make space for the team to do the discovery and participate in it fully.
Work with the grain of the internet and the web
The web is the most successful technology platform we have, building from simple protocols to support incredible large-scale applications. It’s our starting point for the vast majority of what we do. That leads us to federated and distributed approaches, and to architectures that make use of resources across the network rather than tightly-integrated technology stacks.
Platforms, standards and re-use emerge
Design for concrete needs, not for abstract reuse, but look sideways to see opportunities.
No undifferentiated heavy lifting
Our effort should be put where we really add value. That’s why we have a Cloud First policy and focus on open source software.
Assume evolution
Software is never finished but different elements evolve at different paces. Allow for this in your planning and your management, providing clear interfaces between components and making sure each of them can be changed at the appropriate pace.
It’s not real until it has users
A project isn’t a success until its users think it is. The only good technology is the technology used by real users.
Government is rarely unusual
Very little of what we do operates at significant scale, and most of our challenges are common. That should inform how we work, and where we learn from, seeking out the best examples from across our profession.
Design for operability
Users need available and resilient services. This requires well maintained technology.
Common architectures and mandated components
There are areas where GDS is developing common architectures and has controls in place to ensure the use of common components and platforms.
In the slide deck we state:
There are reasons to mandate use of certain components, but they’re never about conformance to a technical roadmap.
GOV.UK Verify is a good example of this. Government services that need the levels of assurance GOV.UK Verify offers are expected to use GOV.UK Verify.
That’s not because of any technical purism saying we should only have one, but it’s about a collection of other factors. Such as GOV.UK Verify’s architecture using a federated identity model to help drive industry innovation (people can choose from a number of identity providers to handle their initial registration when they sign into government services) and avoid creating a central database of personal data within a single supplier or within government. GOV.UK Verify has also been rigorously tested with users.
As time goes on and more common components emerge, we will need to think broadly about the best ways to ensure we can take advantage of platform effects, by concentrating demand in a way that lets us better take advantage of changing technical and commercial options and making things simpler for users.
Where the technical considerations are dominant we need to ensure that we are always creating “services so good people prefer to use them even where alternatives are available (or could be made by the team)”.
We have shared our slide deck as an open google file. We do not recommend using it as a stand-alone presentation and it is purely intended to give an introduction to our thinking at this time. If you want to discuss the presentation contact the technical architecture team.
All our work is done out in the open so to keep up to date with our way of thinking check out: