Principles in Enterprise Architecture (1)

Information Technologies are fundamentally empirical, and Information Technology **Management** is even more so. In our professions it is challenging to speak of Principles, because of the ever-present drift towards immediate and reactive solutions. How many times have we heard a comparison of Enterprise Architecture with the “nice to have” or some remote “aspiration”? Sadly this is too frequent across all industries and sectors.

The truth is though that Enterprise Architecture does not have its “own” principles or special criteria which are then “applied” to the organisation. The principles of EA are in reality business, information and data management criteria that only condense institutional-level practices, and are not theoretical at all. Its goodness is self evident. Let’s take as an example the TOGAF 9.2 “Data Principles” which are presented in section 20.6.2, and read as follows:

Principle 10: Data is an Asset

Statement:

Data is an asset that has value to the enterprise and is managed accordingly.

Rationale:

Data is a valuable corporate resource; it has real, measurable value. In simple terms, the purpose of data is to aid decision-making. Accurate, timely data is critical to accurate, timely decisions. Most corporate assets are carefully managed, and data is no exception. Data is the foundation of our decision-making, so we must also carefully manage data to ensure that we know where it is, can rely upon its accuracy, and can obtain it when and where we need it.

I think it is evident this “general” TOGAF example does not represent a theoretical value or “aspiration” as it would be called in some IT teams, but instead a vital criterion of business management!

Probably many colleagues, especially Business, Data, Information or Security professionals will immediately agree that this is a valid principle, one that should be embedded in systems and services, in IT Architecture in general.

If that can be taken as something settled, let’s progress with the argument. Granted that Enterprise Architecture does not have principles of its own but instead these are ultimately essentials of Business practice, what can we say of the adoption of “Principle 10” in all areas of the IT infrastructure in our organisations?

Surely the colleagues here will have their own examples and experiences, so I will speak now about the area I care the most about: Identity and Access Management. And I started this note with Principle 10 –you may have guessed– not because it is readily adopted in I&AM or because it is even widely understood. No, quite the opposite!

So much so, that perhaps Identity and Access Management is a clear example where just establishing a “principle” as transparent as that of the TOGAF example, is nevertheless contentious, and even impossible in some IT environments. In my experience, Identity and Access Management is rarely addressed as a Data-centric discipline, so that –consequently- data management and quality criteria are seen as something extraneous and in some cases an “obstacle” in IT infrastructure and service management.

Or, putting it in a different way, more aligned with Principle 10: Identity Data, Role Data, User Attributes, User Credentials and similar data records of staff and workers primarily are NOT managed as a business asset, and are not owned, not governed, not standardised, not controlled as such.

Organisations –generally speaking and without pointing into any particular industry or sector– take Identity Data as granted, as a given aspect of IT infrastructure, and even as an “IT problem” where the business teams have little interest or accountability for.

As a consequence of that, Identity data (in all its forms) becomes “owned” , captured by diverse platforms, applications, databases and processes, to the point that, if there is one single major problem in these organisations is what we can call the “fragmentation of the identity sources” and, on top of that, the overwhelming, costly and unsafe multiplication of user credentials, controls, identifiers, passwords, etc.

I am not describing an esoteric aspect of Identity Management but one every professional is acquainted with, and it won’t be necessary to give more details about it. For sure, each industry will have a particular constellation of problems, ranging from problems of excessive permissions in critical infrastructure, to severe inconsistencies in user data dispersed across many data stores. In the NHS we have a similar problem too, which we call quite precisely the “logon burden” –a factor that makes the life of front-line staff and workers particularly hard, limiting their mobility and productivity as them move from one location to another or between tasks and systems.

The “logon burden” is so important that several of the I&AM objectives are focused on it. See for example a high level summary of our objectives (updated in April 2023), and notice the first five principles:

It is clear we are not speaking here about “theoretical” or “aspirational” notions of values, but of concrete operational requirements. Urgent, immediate requirements, as you may agree if you consider what front-line workers are doing each and every day!

So here we have a principle, a foundational criterion which has direct impact on work and productivity. And this leads me to a question: When we speak of Identity and Access Management, can we have also a principle, based on the TOGAF model, to achieve proper stewardship of Identity Data? For example the following Principle which actually was part of the NHSX Enterprise Architecture work completed in 2021 before the merger with NHS England:

Identity Data is an Asset

•Identity as an Asset: User data required to authenticate and authorise user access to resources is a fundamental organisational asset and should be managed for accuracy, quality and availability (as every other asset)

•Data Quality: Adopt Identity Data Control and Data Management to underpin Identity Services and Workflows: every project and solution design must align with Identity Data quality criteria

•Dependencies: Solution design must explicitly address Identity Data dependencies (inputs and outputs): IT Transformation requires Identity Management transformation

•Future proof designs: Behind every authentication and every authorisation of a user, there is a data reference (a claim, a credential, a group, an attribute, hence the scope of a solution is always the scope of its user data sources.

This principle has not been forgotten, but it also has not been embedded into our IT processes, with the obvious consequence that the “logon burden” is not only an issue, but a growing problem as the NHS –necessarily– adopts more technology for the improvement of our services. As it happens in many organisations, beneficial technology adoption is not accompanied by the streamlining of user management systems; a phenomenon all IT professionals know very well.

In my previous article, I offered to write about I&AM principles, so here we have a start, so to say: I propose to adopt as the first and foundational principle of I&AM that of taking Identity Data as a Business/Enterprise asset, and managing it as such. I am convinced that on that basis we can develop then a “data-centric” I&AM Capability Framework to establish other, derived principles, and define guidelines for programmes and projects. In the NHS but also in any other organisation. In my next article I will explore how to derive the I&AM Enterprise Model from the Data Principle.