When we build digital services like booking a prison visit online we usually start small and then test and refine as we go along. This 'iterative' approach, based on GDS design principles, has major implications for the role of the technical architect.
In government, technical architects often bear a closer resemblance to architects of buildings and bridges, whose role focuses more on detailed up-front design.
By contrast, technical architects in MOJ Digital help deliver the simplest viable architecture to users, and then continuously adapt this as the service evolves. In this approach it's better to be able to respond to change than to plan everything out in advance.
Architecture: a broken metaphor
An architect can be viewed as a visionary designer, working on a grand project like the construction of a large building. They are expected to understand the constraints they are working within: time, cost, and the physical limits of materials. With the help of others, they come up with a single coherent project plan, which has to be complete before construction can begin.
This architect metaphor is increasingly problematic for software development. 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. The increasingly widespread adoption of DevOps practices has also created a wealth of tools to automate the management of cloud-based systems.
Building with code
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.
With the right engineering practices, code, and the systems it describes, can become a malleable material with a low cost of change. This is where the metaphor breaks down: buildings and bridges cannot be changed quickly and cheaply once they have been built.
An adaptive role
Making sure that change isn't expensive is vital for digital services because they have to change and adapt. Research can give us new insights into user needs, analytics can provide us with data to counter our assumptions, and legislation can profoundly alter the legal framework for a service.
In this new environment, a technical architect must be reactive. They must change a system incrementally to meet the changing demands. Architectural design is still important, but the design takes place in smaller increments, with the future mapped out in more abstract terms.
What this means for technical architects
This means that our technical architects will always be involved while the design of a service is changing - and not just at the early stages of the project.
They will be just as much a member of the delivery team as a user researcher, interaction designer or developer. Developers will always understand more about the detail of a system, but a technical architect will often have a better understanding of the context for the system.
As architects won't be under pressure to design something which exhaustively meets a large set of user needs, they can focus on a minimal viable product, and on subsequent incremental changes.
Platforms and consistency: the technical architect community
Does this mean that 'everything flows and nothing stays still'? Will there be room for platforms to emerge? And will there be any consistency? Without a rigorously-planned approach to architecture, will we just end up with lots of discrete silos?
We believe that platforms and consistency should emerge from a strong community of technical architects who are focused on delivery. We have 8 technical architects in MOJ Digital, who are in turn part of a government-wide community of technical architects (and closely-related roles).
Between us we need to continuously identify commonalities, to find ways of delivering effective platforms, libraries, data standards or patterns. However, we need to be careful not to create abstractions which are either too generalised or too specialised. For example, should there be a single payments platform? Or several for different types of payment? Choosing the wrong abstraction can easily occur if they are created with too much distance from the original user needs.
Find out more about joining the team
We are currently looking for technical architects to join our team at MOJ Digital to create important services for citizens. We are looking for people who are keen to influence how digital services are delivered, both in the justice system and across government.
You can apply online or email contact-us@digital.justice.gov.uk or recruitment@digital.justice.gov.uk if you need more information about the role.
A lot is going on in the team at the moment, so make sure you follow us on Twitter @MOJDigital so you don't miss out.
Leave a comment