In techno-centric environments it is not rare to find a strong emphasis on “people, process and technology”. These are three aspects consistently covered by presentations, papers, books, proposals and reference materials.
This kind of emphasis is shared by the major consulting firms and market research organisations like Gartner and Forrester. It is important to remark that this emphasis actually represents progress in relation to a period when IT disciplines generally ignored “people” and “processes” and when system analysis and design happened almost exclusively in the realms of technique.
So it is was and is good to see a well established focus on “people” and “process” outside of technologies.
In large organisations, deeply influenced by consulting services and market analysts, this “triad” of people, process and technology is also a given, something that managers will demand from their subordinates as if it were a sufficient condition of completeness and good practice.
So, complying with this, almost everybody in the industry works out carefully what the “people”, “process” and “technology” factors are in any situation. Neat diagrams show how the advisor/consultant is covering “all the bases”.
Is this satisfactory? Is it really “complete”?
My point of view about IT architecture and systems design is that we need to cover at least four aspects, and not only three. In previous posts I compared the Circle of Trust with the CIA triad. The four aspects of the Circle of Trust –Direction, Selection, Protection and Detection–, have been introduced in previous posts.
Here I want to point out to the fact that the “People, Process, Technology” triad maps to only three aspects of the Circle of Trust with some peculiar combinations:
The “People” concern – maps to the disciplines of Selection .
The “Process” concern maps to the disciplines of Detection.
The “Technology concern maps to the disciplines of Protection.
The concept of “People” is generally understood to cover the roles and entitlements required for the users of an information system; the concept of “Process” covers compliance with a permissions model; and the concept of “Technology” addresses the hardware and software that provide access control, data storage, connectivity and transaction capabilities.
This approach is incomplete as it does not encompass the disciplines of Direction, i.e. it does not cover organisational factors which can be described and addressed only in terms of purpose, strategy, intention, ownership, authority, structure or function.
This is particularly noticeable when we speak about Identity and Access Management. In this space, if we limit ourselves to analysing factors related to “people, process and technology”, we will be unable to explain what I&AM is about. We may still cover the aspects of “provisioning” people, “controlling access” to systems, and “ensuring compliance”, but we will be unable to address the fundamental issues around data ownership, business model and enterprise architecture.
That is the case of process-centric I&AM models. In these, every possible activity flow that can be associated with identity and Access Management is drawn in the form of a BPEL diagrams, perhaps with the help of some software tool capable of generating executable models. The problem is that BPM approaches are not able to represent the totality of the I&AM space. For example, all processes around role management and role-centric policies have at their core “functions”, “ownership” and “authority” factors which can’t be described as BPM flows or with the corresponding tools. Organisational functions like these are part of the effective –sometimes not manifest– Business Model of an organisation, and are the pre-condition for any organisational transformation as well as the cause of many failed I&AM programmes.
I am revising the layered approach I recently described in this blog (I&AM Programme Layers) to better reflect the organisational nature of some key aspects of I&AM. It will be good to separate all elements that can be grouped under the Direction disciplines.
Here is the a tentative diagram of how this will look. The reader will notice that I have changed the terminology to better reflect industry standard I&AM frameworks but key elements are similar to those in the layering published here:
https://carlos-trigoso.com/2010/08/20/iam-programme-layers/
It is evident that the four Layers are aligned to the four aspects of the Circle of Trust. Furthermore, the layers more clearly align now with a multi-tiered architecture. Please note that this is “work in progress”. Your advice and suggestions are welcome.