As we progress at NHS England towards the merger with DHSC, our new tasks and the continuation of long-sought improvements, we can see the need to clarify, to “right the wrongs” that have blocked for so long the digital agenda.
One of those blockers is the pervasive misunderstanding and confusion about the respective roles of Technical, Product and Enterprise Architectures. This, in relation to the “centralisation” or “decentralisation” of decision-making.
We have now an opportunity for change, and, perhaps even an imperative for it. For the structural transformations we seek are not compatible the old “ways of working.”
As the NHS increases its focus on the front line, on the Trust and ICS levels, as the ICBs start a much needed consolidation, and the NHS focuses more and more on supporting and enabling the localities and regions, the old roles of hyper-centralised but fragmentary services, programmes and “controlling” functions will lose relevance. Under the rules of enablement of health providers, the old thinking of “one size fits all” will make no sense anymore.
This, for sure, will have different degrees from area to area, from service to service, but we can already perceive how the conversations are changing.
In this context some legitimate questions arise: Would a decentralisation focused on local and sub-regional entities be contrary to the aspiration for a leaner, more efficient, investment-savvy infrastructure? Does decentralisation of implementation contradict the Enterprise Architecture mission regarding consolidation of the infrastructure?
From my perspective, both questions have a negative answer.
Here are several points to consider:
a) In reality, while the NHS “programmes” and “platforms” were and are centralised, the implementation of the digital agenda has been already and continues to be decentralised. The case is that any and all “programmes” are applied at the ground level, at the front line by local teams. Crucially, even the most “central” programmes, like the Federated Data Platform have to be delivered locally by the same teams who are implementing/adopting other parts of the digital agenda. Multiple programmes compete for the capacity of the local teams, who operate within local constraints of resources, skills, information, funding, geography, IT legacy, social factors, etc. Therefore, in this sense, decentralisation of implementation is not something that “may” happen or that could be avoided, but a natural characteristic of our organisation.
b) Also, in reality, the “ways of working” of the central bodies despite declared aspirations, has been “decentralised” too. In a peculiar way! It will suffice to recognise how each and every programme/platform in the NHS effectively operates in parallel to all the others. In my own area –for reference- we see some cases: the Corporate Okta platform, the Federated Data Platform, the ESR transformation, the CIS to CIS2 migration, the NHS Connect consolidation, the BSA authentication services, and like these many others. Yes, there are some points of interaction, for example CIS2 and NHS Connect do have a limited identity federation; the FDP does use Okta for developer access; but these are small integrations that do not change the nature of our Identity Services which are actually decentralised and fragmented across identity silos. In this sense, decentralisation is rooted in the peculiar way our Identity Services cater for specific software platforms and user types.
c) Decentralisation is also prevalent across “projects” and “project delivery”; because programmes, platforms, but also Regional, Trust and local delivery work is almost 100% decentralised as NHSE -despite project and budget controls, despite “technical” viability forums-, did not have and does not have a working IT enterprise architecture governance. This is behind the adoption of multiple Electronic Records, Identity, Joiners-Movers-Leavers, and other Systems which are not interoperable and are closed around vendor boundaries. The examples are numerous, both at central and regional/local levels.
Given the above, my point is that, in the context of a valid and much needed decentralisation of commissioning, technology adoption and a digital transformation which directly serves the Front Line, we should formalise and strengthen Enterprise Architecture across the board, for programmes, projects, products and platforms, . In other words, my point is that the objective of centralising, standardising, governing design decisions (Architecture) is not contradictory with keeping or even increasing local/regional and national delivery. Savings through the consolidation of IT capabilities should be seen through this lens.
Here I want to emphasise again the need to overcome outdated practices in technology strategy, especially the lack of separation of responsibilities between commissioning, planning, delivery and implementation. The confusion between Technical, Product, Solution and Enterprise; as not distinguishing these responsibilities can only harm the transformation of NHSE.
So, essentially, we can have decentralisation of delivery AND centralisation of architecture. And we can and must leave behind that sort of “central delivery” which in fact builds one point solution after another, one identity silo after another. A central delivery model which in many cases conflates areas which should have separate accountability.
And only when we finally become able to “centralise” Enterprise Architecture will we be able to address consolidation of platforms and make sure that we actually serve the front line and simplify or streamline the services that we provide from the centre.
Indeed, we will be able to prioritise services and save resources when we finally adopt a model where the organisation does not follow the technology, but the technology follows the organisation.
It will not be a surprise if I say that the Enterprise Architecture role is indispensable. On those lines, the “Let’s talk Architecture” initiative recently launched by our CTO Sonia Patel is a great framework for this effort.