Being a GDS technical architect - Looking back over my first eight months

Becoming a “consulting” architect


In the spring of 2015, after years working in technology, most recently in the fast-paced mobile sector, I joined the Government Digital Service as a technical architect and I blogged about it at the time.

After some months shadowing an experienced architect, I gradually branched out on my own, and have now become established as a “consulting” architect - one who spends most of their time out in the field working closely with departments and agencies.

Why I'm here

I’m here to make sure government stories are a success, using my years of experience within the technology sector. As a consulting architect, I’m to bridge the gap between GDS and other departments and agencies, helping communicate best practices.

It’s my job to help define and design government systems and processes to meet user needs, and this involves making sure all stakeholders are on the same page. I also explain cross government architecture patterns and our Government as a Platform (GaaP) offerings.

Digging in

I often get asked to review spend requests by digging into the technical details to advise those who authorise the spend about how the tech side complies with our standards and guidelines and general architecture practice.

This involves going out and talking to the teams working on these projects to get a better understanding from the ground up and to be able to provide a good overview back into GDS and others that may be interested in central government. Occasionally I also dig into a critical project to help the team by providing a more detached assessment of risks and progress.

Setting standards

I’m here to help teams work within certain government standards such as the Digital by Default Standard. For instance, when I can, I am available to help service teams digest and understand the written guidance GDS provides. This helps them to pass the alpha, beta, and live assessments. I also advise them on discovery and technical options, and bring valuable feedback to inform how we develop those standards.

Many departments and agencies are already doing an impressive job of transforming their technical architecture to meet government-wide standards but it is often helpful to get extra advice from architects like me who can bring a fresh pair of eyes to problems.

Sharing the driving seat

One of my assignments has been across the driving spectrum, working both with DVSA ( Driver and Vehicle Standards Agency ), and DVLA (Driver and Vehicle Licensing Agency ). So I travel to Bristol, Nottingham and Swansea a fair amount.

With DVSA, I have been working with the team on the new MOT system which successfully moved 22,700 garages over to a new online method for recording and managing MOT results. Already, many millions of tests have been undertaken using the new system.

The web-based service has been created to enable garages more flexibility, without the need for specialist IT equipment, and enables garages to record test results using mobile devices such as tablets and laptops. It will also allow DVSA to much more easily improve the service over time as they learn more about their users and provides a foundation to respond to changing technology use in the industry.

With DVLA, I have been working with a number of teams on various services and technical issues. Part of my job there is to look specifically at how driving services can be transformed by the arrival of Government as a Platform. For example, the whole experience of buying and selling a car involves many transactions with government, a process that can almost certainly be streamlined. Recently, a team of people from DVLA, DVSA, and GDS created a map of how driving services work and these activities may help progress that process.

Having people in a position to work across organisations like this allows us to spot opportunities and help teams work together in ways that drive greater efficiency and cost savings across government. And that in turn lets us provide a better experience for the citizen - the main reason I do what I do.

It's all about user needs

The focus GDS puts on user needs resonates with my own approach to improving systems. I’ve always taken a user-centric approach to their design and delivery.

I continue to work with other departments such as HMRC and DWP both in the field and in London where I am involved in Digital by Default assessments for larger services.

What is a “Consulting” Technical Architect

When it comes to a consulting technical architect’s other must-have traits, I’d say you need:

-    a good understanding of technical architectures and how different systems glue together

-    flexibility and the ability to understand differing technologies

-    empathy to understand what different stakeholders are dealing with

-    the ability to easily adapt to different projects, eg, you may be talking about electronic   licensing one minute, and then to an MOT garage owner about how a system works the next

-    diplomacy and the confidence to challenge deep seated ideas

-    a whole lot of diligence and endurance

Above all you need a desire for change. Government technology has had a poor reputation for being slow, inefficient, and full of mammoth IT projects. The Government Digital Service has spent the last few years working with departments to change this, and since joining, I’ve got a first hand taste of how challenging this shift really is.

Vacancies at GDS

At GDS, we are recruiting for a wide range of roles and if you are interested in becoming a technical architect at GDS, have a look at our current job vacancies:

Stay tuned for more from us on being a technical architect at GDS.

You can follow John on Twitter, sign up now for email updates from this blog or subscribe to the feed.

If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.

Leave a comment

We only ask for your email address so we know you're a real person