Beta This is new guidance. Complete our quick 5-question survey to help us improve it.
Choosing technology: an introduction
Choosing technology is often the most significant area of investment you’ll make when developing or maintaining your service.
Your choice of technologies has a huge impact on the quality of your service and your team’s ability to operate and iterate it.
Meeting the Digital Service Standard
Following the Technology Code of Practice
You must follow the Technology Code of Practice when choosing technology.
What to consider when choosing technology
When choosing technology, the most important thing is to make choices that allow you to:
- change your mind at a later stage
- adapt your technology as your understanding of how to meet user needs changes
You and your team should also try to:
- keep up to date with the latest technology developments so you can choose the best tools for your service
- minimise the total cost of ownership, including reducing the chance of getting locked in to long contracts for specific tools and providers
- use standard government technology components that are common across all services - read the Government as a Platform guide to learn more about this
- use software that other departments have built, and make it easy to use software that you build - read the Application programming interfaces (APIs) guide to find out more
- make sure you always have full control of any data you store
How to make decisions about technology
Every service is different, and many of the decisions you make about technology will be unique to your service.
Follow these steps to help you make good decisions for your service’s technology:
- understand the landscape
- explore the opportunities
- start with prototypes
- make and maintain a map
- allow for evolution
Understand the landscape
No service exists in a vacuum. You need to understand the technology context you’re working in.
You should consider:
- existing technology systems and data sources that your service may need to work with, whether they’re changing, and how, for example, your department might be replacing certain legacy systems
- the reasons why previous technology decisions were made - for example some departments have preferred programming languages or databases
- where to look for available tools - even if you don’t yet know what you need it’s worth knowing where to look for existing components
Learn more about the role of a technical architect in discovery.
Explore the opportunities
You should have people in your team who have the knowledge to explore whether changes in technology are changing the constraints.
For example, you can investigate:
- new cloud technologies - see if they allow you to find simpler ways to make your service robust
- new web browser capabilities - see if they mean you can make it easier for users to interact with your service
You need to check if new techniques and standards remove constraints or open up new ways of thinking about the problem.
Use this knowledge to inform conversations about how to design your service and help you test whether your approach is sufficiently adaptable.
If a new technique isn’t ready for you to use but would let you meet user needs better in future, consider how you can make it easier to integrate at a later stage.
Learn more by reading:
- Changing changes of circumstances: a blog by an ex-GOV.UK product manager
- Learning through prototyping: a Department for Work and Pensions (DWP) blog about their Universal Credit service
Start with prototypes
Start testing what it’ll take to meet your users’ needs as soon as you can.
During the discovery and alpha phases you should use prototypes to:
- help you test your emerging understanding of user needs
- explore assumptions about technologies that could improve your service and check if the technologies are ready to use
- make sure that interfaces with other systems work as you expect and that the process and all technical constraints are clear
- develop a map of what the primary components of your service are likely to be
It can be tempting to break services into separate components very early on, but it’s very easy to get the boundaries between those components wrong.
Use your prototyping to get an early understanding of components, but always be prepared to re-evaluate decisions as you go along.
Make and maintain a map
Once you understand the landscape, the opportunities and what you need to do, you should start mapping out the components.
You can use techniques like Wardley mapping to learn what you’ll need to build and what you can buy or get for free.
Your map will:
- help you to understand your architecture, particularly the parts of your system you can consider mature enough to treat as stable, and those which will change frequently
- allow you to minimise the number of long-term decisions you’ll have to make
Even if you don’t have a great understanding of the components of your architecture, it’s good to sketch out what you know as this will help you prioritise more exploration.
You should keep updating your map and using it as part of your planning and prioritisation.
Allow for evolution
As your service develops, you’ll get a better understanding of:
- your users and their needs
- the systems you need to integrate with
- the best way to structure any software you’re building
Give your team space to make changes and talk to them regularly to decide the right time to make structural improvements.
You should use open standards to manage the interfaces between parts of your system, if they’re available. Using open standards makes it easier to make changes later.
- Published by:
- Technology community (technical architecture)
- Last update:
Guidance first published