We announced the architecture function this year and have been busy ever since with discovery work. (As well as the everyday work in transformation, performance platform, service standard, GOV.UK Verify, GOV.UK, and other digital services across government such as the MoJ of course.)
Who are we? The architecture function leads a cross-government community who are bringing about a sensible and coherent service architecture. With GDS leadership of the function, we ensure co-ordination with the controls and transformation functions, and are accountable to the Technology and Digital Leaders.
What are we doing? We are investigating the user and technology needs across departments and agencies. We're asking what services should there be, and what platforms they should rest on. Together we will build a clear and shared architecture, guidance and a supporting strategy. That way we make sure we are building the right services in the right context.
We need to learn from industry, and from our transformation work so far, to find and share common approaches to common problems. And we need to get the technology community working together towards a single open set of objectives.
The community will be accountable for the whole central government service architecture ‘ecosystem’. However it will start work primarily ‘within’ the services themselves. That way we can ensure we have the right skills in the right places.
Right services in the right context
We have discovered some things we can work on to improve how we deliver services in a joined up way. We have already started work in these areas:
Vision - Jointly define the architecture for departments to determine our main objectives.
Portfolio - Create an integrated view of architecture work across government. Content - Build a content platform and strategy for sharing code and advice, so we can build the service landscape together.
Quality - Improve our practice (especially security) to reassure stakeholders. Continue to ensure service managers and their teams keep their autonomy.
Common approaches to common problems
We've needed to do and build some things many times to find solutions. Sharing specialist technologies, tools and components will also help. We will investigate and capture good solutions and share them. The first candidates for these specialist projects are:
Hosting - Lots of services have made use of ‘cloud’ hosting - using computers and other services on the public internet. We want to do a lot more of that. We will use a consistent quality model to make sure we use the right hosting for the right service. Then we will ‘industrialise’ the hosting to make it easier to automate deployment and migrate services across hosting options. Lastly, we want to standardise some service platforms, to make services portable. This will avoid locking the service into any one provider.
Federation - We want services that are autonomous but linked through well-defined open data exchanges. How can we support transactions that cross services? How can we involve many citizens and civil servants in a trusted manner? We have GOV.UK Verify for citizens, but we also need better tools for managing access for civil servants and agents. We need a clear and open way to allow services to share data. We have already made some significant headway in developing identity management tools in MoJ and other departments.
Consistent case management - How can users track the progress of their applications? We want an open way of doing that. And how can government have predictability and efficiency across many services? We want to offer excellent business analytics to enable discovery of meaningful patterns in data, but without undue centralisation.
Right data tools for the right job - Government is making a lot of progress in using a range of distributed data and analytical solutions. We need to further codify how to ensure services ‘own’ and communicate their data, and provide the right kind of statistics to enable a more efficient government.
Other specialist areas we are thinking about:
Transaction monitors and threat (and other) analytics. To build security in through service / component interfaces and consider data aggregation patterns. Cross service information. Making sure data cross-referenced between services stays consistent.
Directory of products. Capturing the ‘long tail’ of services that look like simple application workflows.
Operations and help-desk integration. Lots of useful patterns around access to systems, logging, reporting to make services more reliable and easier to manage.
Common gateways. To ease the overhead of connecting between the internet and ‘government’ networks.
Common cross service transactions. Major life events such as moving house, job, partner, and how they impact services in a more consistent and open way.
Right skills in the right places
To build a scalable community we need to manage our work by themes, and consider shaping our recruitment and career development paths along these themes. We need people with these skill sets to work seamlessly with the other roles of the teams.
| Consulting | Specialist | Quality | ||
| Work with leaders to define the ‘service map’. and with service managers to deliver them. | Work with services to support and share efforts around common areas, such as hosting, technology choices. | Define best practice around the ‘pipelines’ which deliver changes into services, and associated assurances.Lead the testing community. | ||
| Portfolio | Content | Capability | ||
| Manage the architecture workload and prioritisation. | Operate and edit the shared content.Manage sharing services and tools. | Promote the community of practice for architecture. Manage recruitment. |
In summary, we’ve identified the following as the main challenges for the architecture function:
- create a ‘map’ of services, current and future, including composition and dependencies
- create a consistent language, with supporting patterns, examples and advice. Also identify common components and tools
- create a ‘roadmap’ of critical events, with a log of risks and issues
- provide material for clear goal setting and prioritisation, helping departmental service portfolio management
- above all, build up the technology capability of government by evolving the community of architecture practice
We are currently recruiting at GDS and across departments, so get in touch if you want to get involved.
We will keep you posted in these blogs.You can contact me at: kevin.humphries@digital.cabinet-office.gov.uk, or check out https://gds.blog.gov.uk/jobs/ and https://twitter.com/UKGovDigiJobs.
1 comment
Comment by Paul the TAX payer posted on
Surely you should start by looking at your business processes and requirements. Once you have determined them then you can work out if there is even a need for an IT system. From then on you can architect an IT system to address the specific business requirement.
In summary I dont think you should be starting with user and technology needs but should start by looking at what the actual business requirement is. You should also consider how much the cost of new system will be against how your doing it now. New shiny IT systems usually bring along new costs that often wipe out any benefit.