Continuing with the analysis, I ask myself – Where did we fail?
While recognising a wealth of experience and know-how in the NHS England teams, immense commitment and value that should not be lost in the transition, we should still be able to avoid mere continuity.
Leaders in our organisation have been clear, especially during the last few weeks, that any conceivable future has to make room for transformation. But how do we combine the efficiency and effectiveness drive with changes in our planning and delivery?
Aside of the need to abandon a default “product-based architecture,” there are other critical areas to consider, where changes are possible in the new period even within the increased focus on savings. These are: Governance, Interoperability and Consolidation.
I will address these aspects one by one in what follows and in other posts.
When “governance” is mentioned, some colleagues respond with reservations. The most frequent objection being that governance bodies (“boards”) slow down transformation. A valid observation: in many areas “gateways” make technology management quite slow. My response to this is that we had (and have) the wrong type of governance. We have control mechanisms which make no distinction between “approval” of investments and approvals of design (architecture).
That conflation of processes is what makes them “difficult”. So, in the new period we need to separate funding approvals (which should be even more selective and strong than before) from technology achitecture approvals. Just by making that distinction we will see that an increment of strict spend controls does not lead to “slow” approvals or technology projects.
Now, why did we have that problematic combination? My contention is that this lack of differentiation arose from the way NHSE defined and launched programmes and projects, in particular from the way Programmes, Platforms and Projects operate as self-contained entities with ability to define their own objectives, their own cost structure, security policies, their architecture, their technology choices, their resourcing and their delivery schedules!
In the context of that high level of autonomy of the delivery units, our governance evolved as a mixture of financial and technology strategy control. In other words, the complex governance so many colleagues dread is the organic counterpart of the “autonomy” of Programmes, Platforms and Projects. So, it is not that we have too little of too much “governance” but that we have a peculiar mechanism which does not comply with a Separation of Duties and Controls.
Now that we move towards Citizen, Patient and Community-centric services, now that we need to achieve efficiency and effectiveness in Health Services delivery, we need a different Governance Model where most transformation will happen locally and regionally and the focus on massive Programmes will change. Those large central services should move to a BAU and maintenance/continuity of service and should not define our IT governance. Central platforms should then focus on supporting the local and regional entities, commiting to their requirements –the actual requirements of the front line teams–, instead of prioritizing their particular technology silos.
In that context, we will also see where Architecture governance fits: also moving away from the “center” towards the production and dissemination of principles, patterns, guidelines, and mid- to long-term strategy primarily for Trusts, ICSs, ICBs and Regions. Change will happen mostly there, and we (Enterprise Architecture team) are commited to this.
We all know that dispersed, fragmented technology adoption is not optimal. Therefore, the increased decentralisation of Health Services opens up an even greater role for Architecture Governance. Indeed, part of the “failure” of NHSE has been caused by that fragmentation. The lack of interoperability and standards in Electronic Health Records and Identity Management systems are examples of that. This points back to the need for a unifying, guiding force which enforces compatibility, standards, interoperability and repeatable solution patterns. I think the role of Enterprise Architecture could not be clearer.
So there we have another distinction to make: While Financial Control is absolutely essential and should be enforced in the new period, Architecture Governance –if its place is recognised– will be an ideal companion of the first, each in its own sphere.