The place for Central Infrastructure

A while ago I was playing around with a picture that would represent the right place for central infrastructure in government. It morphed into several related pictures that overlay. Once I had the pictures, I saw that there were some big challenges to face if CI was going to have a “place”, let alone the “right place”. I’m not sure that anyone has really solved those challenges, least of all in a way that makes sense in all situations.

The challenges that stem, for me, from these pictures are:

How to rapidly adopt new, innovative technologies that address current or near-term business issues, without disrupting the reliability and performance of what is already have in place

– How to take new technology and make it stable enough for widespread deployment through big departments, whilst keeping fresh enough for the more fleet of foot government entities

– How to remain speed-competitive at the low end, stable in the mid-range and scale-sufficient at the high end … using the same set of platforms

– How to be price competitive throughout the maturity/adoption curve – at low and high volumes

– How to anticipate longer term “might needsâ€�, balance shorter term “must-doâ€� and create architectures that are modular enough to adapt and evolve to meet all of these needs

Trying to be “all things to all people” in every space is never going to work – but each “person” wants “many things” and if you try and serve all the people, then all the things is the result. So picking the things you’re going to do and the people you’re going to do them for seems to be the essence of the game. It means that “one thing” isn’t going to happen for “all people”, but that one thing could happen for many of them; likewise, some people will have a few things.

In another paper, much earlier in the life of CI, I summed up the three issues as:

– Control. Departments are used to working in isolation to deliver systems that meet their specific needs. This results in a large range of inconsistent and often contrary requirements meaning that little sharing (of technology, lessons learnt or business best practice) takes place between departments, each department takes as long as any other to deliver a project and costs increase directly in proportion to the number of departments. With central infrastructure, a core set of requirements is agreed up front and then implemented for all departments – subsequent implementations take less time, lessons are learnt with each new department and shared across the others and costs reduce as more departments sign-up. There is a tendency to see technology as a differentiator between departments but, in reality, it is the business process applied to the technology that really makes something happen.

– Integration. Central infrastructure requires departments to do work to connect to it or to otherwise take advantage of it. This work may be outside of their current plans and may involve implementing new standards and processes, sometimes with vendors outside of their existing relationship. Such infrastructure allows third party portals and applications to provide government services more readily. With centrally-published standards, suppliers can develop programmes to connect faster and competition is introduced sooner.

– Joining up. By definition, central infrastructure involves a range of stakeholders deciding on overall system scope and timing of delivery. Functions are introduced ahead of the needs of most, but may fall behind the needs of the most advanced department. Conversely, the bulk of departments will get more than they might otherwise be able to afford or have the capability and capacity to deliver – the change in practice here is an “all for one and one for allâ€� stance versus “I must win so that the others loseâ€�. This requires a complex juggling of stakeholder requirements, timetables and priorities. The consequence of not joining up is, however, dramatically inconsistent experiences for the customer as they traverse government.

I noted that these three issues are the very reasons that CI makes sense – and, in the light of the PM’s speech, this week, I’m very encouraged that we can make good progress against all of them.

Leave a Reply