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:
7 comments
Comment by Tariq Rashid posted on
The Abuse of Reuse:
https://medium.com/@postenterprise/the-abuse-of-reuse-96b2e0af01a7
or "Platforms Emerge"
Comment by Peter Swift posted on
This is contradictory.
You say don't go against the grain of the internet. You say don't differentiate common heavy lifting.
Yet you still have a PSN.
What is the case for the PSN?
What are the use cases where the internet won't do? It's not security, nor availability. It's just more expensive with less competition.
Comment by Mark Smith posted on
Peter,
Thanks for your feedback, and I’m sorry if you feel that what James is saying is contradictory. While more and more of what we do is digital and delivered through software it’s still vital that we ensure the security of government data. Today there are many government services that primarily use the Internet, but there are some where the PSN is currently the right choice because of their particular networking requirements.
As an established, highly-used high performance network, the PSN allows everybody who regularly uses public sector data to communicate appropriately and PSN compliance ensures that the connected organisations are secure. It also gives us a common, safe platform to extend the reach of this data to a broader community that will help connect those people who can really make a difference at the frontline. As we’ve outlined in my previous blog posts (https://governmenttechnology.blog.gov.uk/2016/03/21/save-999-and-get-more-choice-improving-psn/) we’ll continue to work to make the PSN simpler, better and reduce the cost as technology and policy evolves.
Mark Smith
Head of PSN
Comment by Michael H Bracken (not that Mike Bracken) posted on
Mark .. you haven't explained at all why PSN is required for "high use" or "security".
All of those requirements can be had from the existing more open and more competitive market. And used by many very serious customers (banks, telcos, etc).
Your failure only adds to the growing agreement that PSN is an old programme that should have been killed off years ago.
Everyone I ask .. from GDS to CESG .. has failed to a clear solid case for PSN.
I reread your reply several times to be sure ... But sadly it is content free.
Comment by Mark Smith posted on
Hi Michael,
Thank you for your comment.
I didn’t mention “high use” or “security” as the PSN isn’t required for those things, although it does offer them. I should also clarify that the PSN isn’t a programme: it’s an operational network service, so it makes sense to maximise the return on public investment through reuse.
As I’ve mentioned, technology has moved on since the PSN was originally conceived. It remains the right choice for many because of their particular needs, but this will change over time. Everything you mention is correct which is why we’ve developed different ways for people to connect with government. The changes we've made to policy and the creation of common technical guidance will enable organisations to choose the best options for them.
Comment by Tariq Rashid posted on
Hi Mark thanks forr reply.
I've designed and delivered solitions in gov requiring both security, volume and availability... And all without PSN ..
This gives me access to a better more competitive market and avoids significant overheads and constraints .. we can move with agility, changes services, avoid imposing PSN on new users, ... etc etc.. all of which is exactly in line with GDS design philosophy, and good design besides that.
I have to say, more and more people are admitting there is no reason for PSN that we know of.
Is there one? Im genuinely open to being enlightened .. maybe do a blog post responding to challenges? Open and transparent working and all that...
Comment by Mark Smith posted on
Hi Tariq,
Thanks for your comment.
Technology has moved on a long way since the PSN was originally conceived. The PSN is just one of many ways to connect with government today and remains the right choice for many because of their particular needs. This will change over time but for now, the PSN is an operational network service that’s the result of public sector investment, so it makes sense that the return on investment is maximised through reuse. Keep watching our blog: there’s lots of good news - including PSN updates - coming up.