This week we are announcing the creation of a technical architecture function for government to sit within the Office of the Chief Technology Officer. Here, Kevin Humphries, the acting Chief Technical Architect for HM Government, explains what that means and tells us more.
A technical architect does for computer-based systems what a civil architect does for buildings. They draw up blueprints, make sure the structure meets user needs, oversee delivery, and are concerned with the qualities of the operational service.
The new architecture function for government will establish the high level design of government technology, based on modern, user focused services. We need to build services in a way that means they can be continually upgraded, changed and reintegrated to keep up with user needs.
That means moving away from big custom-made infrastructure and from outsourcing to large IT providers. We will build the architecture service by service, working from the start with multidisciplinary technical and digital teams within departments.
This is a new approach to architecture across government and will ensure that departments have the modern technical architecture they need to deliver great digital services.
Working iteratively
Our way of working will be iterative, with a focus on proof through doing and constant testing. If we want to define a way of storing distributed data safely, for example, we will build an initial version of a proposed data network and then prove how it works quickly and cheaply. This gives us an approach we know works which we can then share across services. We can continually improve new versions each time we reuse it, from project to project, service to service.
Community of architects
We need to encourage this new approach to architecture right across government service delivery. One of the ways we will do this is by building and maintaining an active community of architecture practice. This will include architects, of course, but also quality assurance practitioners. Everyone in the team should be able to contribute to the architecture of their service.
Scale
There are 24 ministerial departments, each with a huge number of services to support. As we go from 25 exemplars to supporting 700+ government transactions, we will need approaches to architecture that bring out common patterns, components and services.
While reinventing the wheel is sometimes a good thing - in software the wheel can always be invented better - we don't want every project reinventing the same wheels. Certain features like packaging, testing, deploying and operating software into cloud environments are things we want to be able to standardise into a small number of approaches.
So our architects will need to take a firm grip on the higher level structure and technology choices for projects and services. We need to form a clear view of what each service is for, how they interoperate and what work should be done. Knowledge and best practice need to be shared.
Accountability
We believe that user focused and cloud hosted services will be better, more cost effective and more flexible than the older horizontally-integrated ones. But we also need to have a coherent plan and architecture for what we are building, to ensure that:
-
the right services are built
-
there is reuse and savings wherever possible
-
services are of the right quality and are built at the right price
-
citizens own their data, are aware of what data is used and it is shared at each stage
We will hold ourselves accountable through a clear decision-making process. We will publish the architecture decisions and progress on projects and services along the way.
Next Steps
Our plan is to establish the needs that an architecture service must support in more detail during a discovery phase. We will then operate an alpha service in a few departments and a number of larger projects. This will take most of the remainder of this year.
After that we will extend the architecture service to most of government.
If you have questions or comments, please drop Kevin a line: kevin.humphries@digital.cabinet-office.gov.uk
Follow Kevin on Twitter
6 comments
Comment by Tom Padgham posted on
Great news and well done on your new role Kevin.
It will be interesting to see how 'architecture for support' will figure in this new function. By this I mean that operational support of services is often an afterthought (although the continuous delivery principles that GDS use on the exemplar projects helps avoid that to a certain extent) and I think there is an opportunity for people to consider what it will be like to support a service as early as the first architecture work on a project.
An example of this might be a data integrity issue which is discovered in service: how easily does the technology used allow the support team to identify and fix the issue.
Comment by Kevin Humphries posted on
We will indeed include 'architecture for support', in two key ways:
Firstly, as a key part of our continuous delivery discipline. And
secondly, by maintaining product knowledge in the development team
throughout the operational life of the service.
We always advocate a bias for action, so we want to get a real working
service in place as soon as possible. But each service must be built
within its very own delivery 'pipeline' to allow safe continuous
updates to the service. The pipeline is defined by the operational
practice, quality controls, tooling and change management required to
change the service during its life.
As you suggest, each service needs to include the elements that make
the service supportable - problem and issue management, metrics and
monitoring, and I have already mentioned change management. Lessons
learned in operations are fed back into the quality controls that are
applied on each release.
We also want to maintain a single team that both develops and operates
the service. The trick there is to harness that knowledge and the
'debugging' techniques, and instil that into production operations
setup. This would help with the data integrity example you mention as
the team understand the data within the system. This is the opposite
approach to trying to build a hopefully complete service, and then
handing it over to a separate operations organisation.
We will evolve our practice and advice around building the pipelines,
analysing and proving service qualities, and managing the support
aspects services - feel free to lend a hand 😉
Comment by James Barratt posted on
Kevin - what have you set out to achieve in specifically, to what benefit, and by when?
Please don't give an evasive vague response like some of the other queries on the gov.uk blog have (eg PSN question by Louise Bennett)
Comment by Kevin Humphries posted on
Hi James. We have set out to achieve a coherent architecture for government. We will deliver this by building a community of architecture practitioners, with a clear decision-making process, and through a shared and managed set of resources. Specifically, that means we deliver the digital services that are right for the business of government. Through a shared understanding, we minimise repetition and improve quality. We make clear wherever possible the data we need from users, and share it effectively. We minimise cost by iterating and delivering against need. We empower teams closest to each service to speed up decision making.
It will take a long time to get right. To reiterate what I said in the blog post, we are starting discovery (https://www.gov.uk/service-manual/phases/discovery.html) now, and will alpha in some departments over the course of about a year.
Comment by Oswald posted on
Does the architectural remit go down to a common repository for genuine shared code? An example I can think of is GDS-wide css style sheets to make things like forms have a common look and feel. There's probably much repetition across projects.
Comment by Kevin Humphries posted on
Hi Oswald. Yes we will firmly encourage sharing of code (and documents, and tests) across government, and the idea is to get as much in the public domain as we safely can. See http://alphagov.github.io/