Last year GDS did a lot of discovery work. As well as ongoing work evaluating what was next for many of the things we were already doing, we built teams exploring possibilities for new platforms, and we worked with colleagues across government looking at topics like Licensing, Funding, and Justice. We learned a huge amount about all of those topics and some really exciting new initiatives are now underway.
We also learned about building teams for this kind of work and within the community of architects have been reflecting a little on that. The unit of delivery is the team, but it can often be difficult to work out what skills are needed in a team at various points in a project’s life. Having just wrapped up a set of discovery projects we realised that the role of an architect in discovery is often unclear and it’d be good to unpack it a bit just as John has been doing for the consulting role.
This post covers some of the things that we’ve come away with - we’ve not got all of this right in the past, but we hope that by reflecting on this journey we’ll be able to form better teams, assign people more clearly and generally do discovery better in future.
The term “architect” is difficult to define. We generally use it to mean an experienced technologist with recent hands-on delivery experience, who has a good ability to understand organisational and technical context, to consult with a wide range of people, and to use all of that to inform what technology (and related processes) is needed to support future services. When building a team you should be thinking more about the capabilities (skills, background knowledge, etc) you need than about the job titles.
The goals of discovery
The service manual defines discovery as:
A short phase, in which you start researching the needs of your service’s users, find out what you should be measuring, and explore technological or policy-related constraints.
That means that the primary focus should be on user research, not technical design, but that you should be gathering all the information you need to make sure you know what you need to learn and test in an alpha, and can make sure that any proposals resulting from the discovery are informed by a solid understanding of the surrounding technology landscape and how it’s changing. That means knowing what data held elsewhere you’re likely to depend on, which systems will be expecting data from you, what interfaces with other systems you’ll need to test, and so on.
The needs - broadly
Many of our services aren’t independent units and we’ve not always been good at mapping out the dependencies between them. It may be that when we are redesigning a service it will look like a particular component such as a case management system is no longer necessary, but it’s easy to miss details such as other services or systems that expect to get updates from that component or call on it for some data that they need.
That is to say, we use one system to meet quite different user needs, and even where those needs are out of scope for your service you should understand those needs and dependencies so you can help the organisation make informed decisions.
The "legacy"
In common with any organisation that’s been around for a while, we also have a lot of older technology powering our services and holding our data which is often difficult to map out, connect with and test. It’s important to understand enough of those systems and what other services they relate to in order to determine what your options are.
Could you replace those other systems cleanly? Would a one-off copy of the data from the old system to a new one do the job? Will you need to maintain data in the old system, and if so are there real-time APIs that will let you do that, or will there need to be batch (or manual) reconciliation?
It’s also important to remember that often the challenge with accessing and understanding those systems isn’t technical, but contractual and that your team will need access to the right commercial and legal expertise to handle that.
The organisation
You should understand any common technology decisions the organisation has already made (e.g. preferred databases or programming languages) so you can take an informed position on how that will work for your service, can push back if there are significant advantages to taking a different approach, and know who to talk to in order to make sure you can take advantage of common platforms as you get a better understanding of what your service needs to do.
Discovery should also be telling you about other capabilities that are likely to be needed, including the delivery team who will work on the alpha.
When working on discovery for another organisation it will often be necessary for the architect to gauge the skills of the team currently available. As you understand the technology context you will need to get a sense of whether the skills that exist in the organisation are the ones needed for alpha (and to an extent beyond) in order to advise on training and recruitment that might be needed.
The opportunities
As the user needs lay out the opportunity and the legacy tech context gives some sense of constraints, we can begin to explore what technology we might need. The tools we have to work with, and those our users have access to, are developing quickly and the whole team will be looking to understand what that means in this context.
Most of the exploration of particular solutions should be left for the alpha phase, but early prototyping is a very good thing and it’s often a good idea to begin exploring what you’re learning during discovery with throwaway code and experimentation with new tools.
Beyond that, it’s important to have capability within the team who can explore whether changes in technology are changing the constraints - do new approaches and new standards remove constraints or open up new ways of thinking about the problem. Our former colleague Richard Pope has been writing quite a bit about that, based in part on what he learned working on government projects. As with the rest of this work, that needn’t be someone with a formal ‘architect’ title but should be someone with the insight and experience to assess new tools and tech.
Balance and experience
In some cases mapping out all of that could be a lifetime’s work, the architect will need to bring judgement and experience to bear in working out how much detail to go into, with a focus on being able to understand and articulate the complexity of the work involved and where likely challenges are that should be explored during alpha.
Just as developers revisiting code should seek to leave the code better than they found it, an architect in discovery should try to make sure that everything is easier to understand for future teams, whether a team doing something based on that discovery or anyone else revisiting the same organisation, systems or services.
Doing it all again
The discovery work we did through 2015 was enormously valuable, for informing what we should do and also what we shouldn’t. Having experienced technologists on the teams helped make sure our recommendations were rooted in deep technical understanding, and gave an early sense of what technology solutions would and wouldn’t help.
Having reflected on it, when we do this again we’ll be working harder to agree some of this context up front, to make sure we’re making the best use of everyone on the team and help shape how we share what we’ve learned back with the rest of the community. We’ll use what we’ve learned to shape pre-discovery activities that make it clear what sort of skills we we need on the team.
You can follow James 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.
