I’ve been at GDS for the last 5 years and I’ve spent most of this time as a technical architect. I’d like to share how we’re tackling some of the biggest technical architecture challenges at the centre of government.
If you’re interested in applying for a role as a technical architect in government, please see the Civil Service Jobs page.
Our role as technical architects
I like the definition of a technical architect’s role, as given by David Blair in his DWP blog post. The job of a technical architect is to bring together the demands of the organisation and IT teams and find a technical solution that satisfies various stakeholder requirements.
When finding a solution, a technical architect needs to consider a number of different aspects, including the:
- existing environment and context in which they’re working
- changing technology
- skills they have available to them
- innovation they see ahead
It’s these various aspects that make the role of the technical architect so interesting, especially in a government context when the variables change from project to project.
Overcoming challenge 1: Managing the existing environment
Part of the challenge of the government context is the existence of many legacy systems that store data in silos.
In many cases, we are building new greenfield systems that still have to interact with the legacy databases in order to connect with the data. There are a number of ways to build these connections, but a challenge facing government technical architects is to find the best way.
You can build APIs around the legacy system using the command query responsibility pattern, or an ETL style data migration, or through applying the Strangler Pattern. There are all kinds of other options but sometimes it’s hard to find out what is most appropriate for the situation.
We’ve worked with departments to help them understand what patterns work for their context, make sure they understand good practice and their staff are fully involved in the product building process. This is because every department is different, with different skills and different missions and so we recognise that there is no single correct solution.
This is why we recruit architects who understand that there are multiple ways to solve any given problem, and that pragmatism and an understanding of the context matters as much, if not more, than knowing and applying the correct pattern.
Overcoming challenge 2: Adapting to changing technology
It’s often easier to trial new technology than it is to shift our working culture to ensure that technology becomes an ingrained standard.
For instance, we’ve previously blogged about being cloud first and aspiring to be cloud native, but we need to think about how this can be articulated for all departments to fully understand what actions they need to take.
We want to help departments easily take advantage of software-as-a-service solutions when operating a service, but we need to think deeper, such as how this area affects all stages of development. For example, from prototyping to development pipelines to quality control.
Taking advantage of cloud native is more complex than it sounds partly because good practice, like microservices, immutable servers and infrastructure as code, is only just emerging. In some newer areas, for example Function as a Service (FaaS), there are very interesting technologies like AWS Lambda (in use by NCSC and DVSA) and Microsoft Azure Functions but these come with complex questions. Technical architects need to be able to answer such questions, for example, how you differentiate between environments, such as test from production, or how changes get promoted through them.
Overcoming challenge 3: Balancing skills and innovation
We aim to use the latest tools and services on the market, but as an architect, we need to make sure teams at GDS and within departments are capable of building, maintaining and operating the services using these tools. As Dan McKinley said, it’s often appropriate to choose ‘boring technology’ because it’s reliable and robust.
Dan's post makes it clear that we should concentrate our innovative efforts in specific areas for each project or system. This helps us to explore the appropriate technology or business innovations while reducing the risk of building a whole system on a new and untested technology.
We need to strike a balance between skills and innovation. Focussing too much on innovation leads to team chaos and unmaintainable software and focussing too much on skills leads to archaic systems that never change. Government technology events like StackTech3 are ways for us to exchange ideas on this balance. DWP may do some innovative research into artificial intelligence assisted casework, whereas Home Office may do research into biometric identification, and we can swap the outcomes and learn from each other. Every department does not have to innovate in every area equally.
Overcoming challenge 4: Embracing the full benefits of agile working
Working in agile teams allows us to find flexible solutions to challenges, taking into account all the aspects I’ve mentioned above, rather than come up with ivory tower architecture plans that are either so complex as to be unworkable, or don’t cover the most difficult problems.
Technical architecture in agile teams requires thinking beyond technical systems. We expect our architects to understand the various ways agile teams can work together. They are expected to understand and know the difference between Scrum and Kanban, Systems Development Life Cycle and Scaled Agile Framework. Architecture is often about dealing with multiple teams, handling the requirements, scheduling the work and ensuring people can get on and deliver the thing.
While we have delivery managers who have expertise in a variety of agile methodologies and when they are appropriate to use, the technical architect is often involved tweaking or adjusting the methodology to work for development teams.
Overcoming challenge 5: Working with data
At an architectural level, digital data presents numerous challenges for departments across government. They must fully understand data protection laws and put in place policies to make sure they are:
- storing data in appropriate and consistent formats
- using appropriate databases
- optimising query performance
- ready to comply with the General Data Protection Regulation (GDPR)
- avoiding duplication of data
Services that require data to be shared between departments add complexity not just from a technical point of view of data transfer. This data sharing needs legal frameworks and clear policies so it is clear how to make changes to data and who is responsible for it.
Finally, architects also need to think about how to effectively analyse data from services. This is key to making data driven decisions to improve services as required by the Digital Service Standard. Producing Management Information (MI) data, showing how systems work and what data is collected where, is one way to do this.
We’d be interested in your thoughts on these challenges. Are they attractive to you? Come and work in government as a technical architect and see if you can solve them. Technical architect roles from all government departments are available here. You can find out more about our recruitment process in this blog post.
