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.
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
- make effective security risk management decisions
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 where possible
- 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
- be aware of any relevant cyber security obligations
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 any 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
- potential security threats and how to mitigate them
Learn more about the role of a technical architect in discovery and how to include security within your business case.
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 to see if they allow you to find simpler ways to make your service robust
- new web browser capabilities to 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 the future, consider how you can make it easier to integrate at a later stage.
Learn more by reading:
- Learning through prototyping: a Department for Work and Pensions (DWP) blog about their Universal Credit service
- Managing third-party product security risks: part of the cross-government Secure by Design approach
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 secure and ready to use
- establish the type of data you’ll be collecting and what compliance requirements there are for managing it
- 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 the likely primary components of your service
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 that are 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
- give you an idea of where security vulnerabilities may exist
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
- the nature of security threats you may be facing
Give your team space to make changes and talk to them regularly to decide the right time to make structural improvements.
If they’re available you should use open standards to manage the interfaces between parts of your system. Using open standards makes it easier to make changes later.
- Last update:
-
Integrated elements on working out security risk appetite, managing third-party product security risks and understanding cyber security obligations.
-
Guidance first published