I am covering three key themes in these postings: Governance, Interoperability and Consolidation. In the previous article I described how a “way of working” based on autonomous programmes and platforms determines a peculiar governance culture which mixes financial and design (architecture) governance, so that, essentially, we have a “product/programme-centric” strategy and ultimately a lack of architecture governance. Large “central” IT-focused initiatives are favoured, and alignment with front-line and local requirements takes a back seat.
At first sight, one could say that this situation may be characterised by “excessive centralisation” of the digital initiatives, but there is both a lack of centralisation and too much of it. Paradoxically, there is no centralisation of Architecture Governance, which instead is directed by parallel programmes and platforms, while at the same time there is too much centralisation in the sense that local and regional requirements are not the starting point of the Architecture decisions.
This paradoxical context makes it so that colleagues find it difficult to see how at the same time more decentralized implementation but more centralised architectural guidance are needed.
With some reason, colleagues associate decentralized, local implementation with “duplication” and “multiplication” of cost, so the idea of focusing on front-line and local requirements is disallowed out of hand. But this just confirms the current delivery model, where effectively separate parallel teams deliver technology “for” the regions and the front line, each of them with its own complement of architecture, planning, strategy, and “ways of working”.
This situation is not sustainable and has led to serious problems of lack of interoperability and a serious need for consolidation of the central infrastructure. These two levels can and should coexist, if we separate Architecture decisions from Project/Programme delivery and abandon the model where Programmes and Platforms are autonomous and self-regulating in terms of Architecture.
Effectively, what I am proposing is more centralisation of the Enterprise Architecture decisions, but a simultaneous de-centralisation of the implementation of the digitalisation of the Health Services.
In the area of Identity Management we see this every day, at all levels of our work and in the user studies we have done in the past 5 years: our “central services” are a collection of 9+ different authentication and authorisation systems while at local level the NHS has hundreds of similar user access control services. Certainly, some technologies (brands) predominate, but even so the NHS can be rightly described as an archipelago of identity silos.
This, in turn, reflects and intensifies the lack of interoperability across patient data systems and other clinical applications and databases.
In parallel to this –but I will cover this in more detail in a separate post—it becomes clear how to think about consolidation: not in terms of how many Identity systems exist in the central services, but in terms of how many systems the USERS have to interact with.
We need to recognise that “infrastructure consolidation” does not mean primarily or only the reduction of the number of identity services as a goal in itself. The objective is not the centralisation of platforms per se, where one platform “wins” over all the others, but instead the enablement of the user by eliminating the “logon burden”. This can be achieved by fostering and enforcing the interoperability of the Identity Services.
There has been a lot of focus (several discovery projects and reports have been done) on the “Data Interoperability” side. This excellent work by several teams has had a lot of attention and several years have been dedicated to it, but as many times happens with standardisation work, the results have been slow in coming due to the innate tendency towards fragmentation of IT systems and the lack of Architecture Governance.
In addition to that, and without diminishing the value of Data Interoperability, I think that it has been developed in isolation, separate from other areas relevant to its task. Data Interoperability (for exchanges and integration across systems) was not positioned alongside Identity Data Interoperability.
In other words, there has been very limited attention to interoperability in terms of “access” to data, systems and applications. It has been difficult even to explain that “data sharing” implies and requires “data access” in the sense that data cannot have value if it is not used in the context of a complex and mobile work force.
This lack of focus on “Access Interoperability” arises within a perspective in which data itself has “value” and machine-to-machine exchanges are the primary object of attention. The multiple “API” centric projects also fall in that category insofar as they take for granted how data will be used!
Data sharing enables the front line if and only if there is no friction for data access. But, by not paying attention to User Access we have created more and more “systems” and “applications” each one installed in its own identity context.
In the NHSE Enterprise Architecture area we have been working on the “context – less” authentication pattern for this reason: the clinicians, staff and workers need to be liberated of “systems” in front of which they are just “users-of-the-system” instead of being concrete individuals with right and need to access multiple data sources without obstacles and artificial boundaries.
So, when if we think about “interoperability” we should mean this: putting the individual first, the citizen, the patient, the worker.
The IAM Community Forum and Lab, started in June 2024, based on the IAM Community of Practice (itself in operation since 2021), was precisely started to foster dialogue and innovation for Identity Interoperability. Last week we had excellent presentations from NHS suppliers who presented to us their vision for Identity Interoperability, responding to our strategy of “Context-Less Authentication”.
In the months to come we will continue working with technology partners to develop patterns for Identity-focused interoperability and hope for even greater participation of the industry in these events. (The image below shows a layered authentication service implementing concepts of consolidation and decentralisation)