NHSE CTO #Sonia Patel is leading a large initiative across the NHS and its ecosystem under the banner of #let’s talk architecture . This effort promotes the development of communication channels and effective collaboration across all levels of our stakeholders, service and technical teams, obviously including our Enterprise and Solution Architecture teams.
To contribute to that work, I published recently an article describing the Axiomatic Design Process as applied to a complex organisation like the NHS.
As we frequently observe in conversations and debates about Architecture and its role in our organisations, it is not always clear what our work consists of. When we say –for example– that Enterprise Architecture “translates Functional Requirements into Design Parameters,” there is still room for clarification and detail, as it is not always transparent what is meant by such “translation.”
Experienced practitioners have many methods and there are good models to follow, among others the TOGAF process-orientated methodology. Depending on the organisation we operate in, these methods will be more or less understood and effective across the business, architecture, delivery and technical teams, but there are always gaps and divergent interpretations of what is “required” and what is intended with a proposed architecture.
This is due to the multiple “perspectives” (“world-views”) that coexist in any organisation, and which are organic and necessary aspects of the same. The perspectives of the business, architecture, delivery and technical teams are complementary and mutually dependent, even if in the daily operations we seem to speak different languages or have incompatible objectives.
To facilitate the “translation” of Functional Requirements into Design Parameters, then, a method must be precise, and serve communication and joint design processes. Generic descriptions, however aligned with TOGAF or other nomenclatures, will not be enough especially if we have to interact with several diverse and decentralised teams.
In such conditions, the more formal the argument is, the clearer the assumptions will be, the better the objectives will be documented, and the more positive the results we achieve. That was the main motivation in introducing “Axiomatic Design” for Enterprise Architecture.
The key benefit of this method is that of focusing the fundamental requirements “translation” criteria. Instead of more or less generic preferences or approximate benefits, the AP methodology requires adherence to two “axioms” or principles: a) the Axiom of Independence, and b) the Axiom of Information.
We will understand this better if we just see those “axioms” not as a mathematical device, but a principles to be followed during requirement analysis and prioritisation. We will then see that the method eliminates uncertainty, guesswork and subjective preferences at each step of the architecture and solution design process.
I won’t repeat here the formal methodology already described in Axiomatic Design Process for Enterprise Architecture, but will remind the reader that, in essence, the translation of Functional Requirements (FR) into Design Parameters (DP) ideally requires that each DP corresponds to a single FR, meaning that each Functional Requirement is satisfied by a single Design Parameter. The result is called an “uncoupled” solution. Less ideal is a solution where one or more FRs may be addressed by multiple DPs: a “decoupled” solution. And in all cases the method strongly leads us away from “coupled solutions,” those where multiple FRs are simultaneously addressed by multiple DPs.
The Information Axiom, which is the second one in N.P. Suh’s methodology (see: Nam P. Suh, Design and operation of large systems, Journal of Manufacturing Systems, Volume 14, Issue 3,1995), can also be described as an “information minimisation” principle, i.e. reduction of complexity and “information variables” in the design. This second principle needs little explanation: it is evident that the best solution will be always the one that is less complex and has less “information content” (in the sense of “information entropy”). So, let us focus on the first principle for the rest of this article: the “Axiom” of Independence.”
As mentioned earlier, the Axiom of Independence calls for a transparent alignment between Functional Requirements and Design Parameters; “transparent” in the sense that the alignment is methodical and not arbitrary or subjective.
The actual meaning of the principle will be even clear if we look into a practical case, for example a standards step in an architect’s work, where she or he starts with a “requirements catalogue” provided by the business teams. Such catalogues condense the desired characteristics of a solution. Let’s consider an example in the space of Identity Management, where we generally get a combination of “functional,” security, performance and useability requirements.
A list like the one below is quite frequent in our area:
- The end user should be able to present to work at any time of the day and should be able to authenticate using a national authenticator
- User sessions should be managed with policy and risk rules for systems access
- The Identity service should integrate with the existing provisioning systems, enabling access to local applications
- The solution should be able to integrate with approved Identity Verification providers
- The solution should enable access both to clinical and non clinical applications as well as to buildings
- The solution should be compatible with mobile devices and wireless network connectivity
- The solution should allow emergency access and “break-glass” procedures, including password reset
- . . .
What do we usually do with these fairly common requirements? Practitioners will proceed to map requirements to known models or technologies. A process of classification and aggregation of requirements takes place, as the architecture team gradually maps those requirements to a potential solution. Some requirements are aggregated, others are split or detailed. For example, requirement 5 may be split into two or more Design Parameters, one for each of the relevant applications. And requirements 1 and 2 may be aggregated, so that a single authentication service is positioned to address those two points.
The usual practice — the conventional approach– will continue the analysis of the requirements moving away from the original list towards a more granular but also more structured one, and moving towards a potential configuration, including a product or a tool, which covers all or most of the Business requirements.
Here is where the Axiomatic Design method is far clearer and effective than the usual process, because it helps us to clearly state –at each step– how we select the Design Parameters, not by “experience” or “belief” only, but by selective mapping of the requirements to individual Design decisions!
Here is how the analysis will proceed if we operate under the Independence Axiom explicitly and progress the analysis without presuppositions:
Each FR must de analysed in itself without presuppositions as to the solution, and even without a presumption that all or most of the requirements will necessarily have a technology-based solution. For example, while points 1 and 2 seem to point in the direction of a single technology which would allow access at any time of the day on the bases of some policy rules, actually both requirements depend on user registration and management processes which are not technically driven and in fact precede any technical solution.
For point 1, the ability to authenticate a user at any time of the day, while apparently pointing to a technical functionality, in reality depends on the status of the users (the job-roles or business roles) under which they can have access at any time of the day. And, for point 2, the fact that there should be rules governing such access, effectively means that it is not enough for the user to be in a role, but that access requests have to be verified on a case by case basis (which in turn means that the rules must be codified beforehand and enforceable at the application layer). In both cases, neither the roles nor the rules can be provided by any tools, and must be developed by the organisation. Then, if we apply the Independence Axiom we will be forced to decouple the FRs from the DPs: For each of the pre-requisite business processes (roles, rules, registration) we need separate DPs and these requirements should not be mapped to a single one.
It is clear that the Axiomatic Design method leads to a “late,” well-documented choice of technology: It shows that in many cases the Functional Requirements are far more complex and distinct that those that the business team have perceived on the surface. Too frequently, while proceeding with a rushed mapping of requirements to design parameters, we introduce tools or technologies which either are not sufficiently powerful for the underlying business problem, or else impose a process model which does not fit to the business practices.
In other words, a thorough analysis of the requirements under the Axiom of Independence, allows us to discriminate what appears as an access control requirement, e.g. “integration with provisioning system,” as effectively implying changes or improvements in the user management processes themselves and not only the “mapping” of processes to a particular technology. Similarly, where the business team ask for “integration with approved Identity Verification providers” we will find the need for policies and standards changes before the integration takes place.
In the whole, the Axiomatic Design approach leads us to see the Identity and Access Management space (and the task of the Architect) in a wider, layered system. I usually depict that with a four-layer model shown here:
This model is not arbitrary, that means it is not a simple classification of processes or functions. In fact, the layers are organised in a systematic way, from top to bottom, so that the Functional Requirements and Design Parameters of the lower levels inform and are translated upwards. This can be expressed too if we visualise an “identity data flow” from Layer A, to the layers above, in sequence. There is also a dependency from left to right in the diagram, for example, in Layer A, “Data Governance” must be addressed after “Data Ownership” as the second is a precondition of the first.
Looking at those diagrams may also clarify how a conventional analysis of I&AM requirements fails, as we usually focus only on the top-most layer of the I&AM space, and neglect the underlying preconditions and capabilities. Too many Identity solutions address only the Authentication, Authorisation, Credentials and Federation capabilities, and miss those non-technical, mostly data-centric and process-centric aspects of the problems. A thorough application of the Axiomatic Approach, leading to a “decoupled” design, is the way to avoid these pitfalls!
When we conventionally analyse requirements, despite our best efforts, if we do not link the “surface,” the more or less “evident” requirements in Layer D, we will miss the necessary transformations in terms of data ownership and governance, data management, role management and provisioning, our solutions will be limited to tweaks of the “services”. And that limitation of the analysis will in turn limit the solution: Our technical choices and implementations may “work” or may be “valid” but they will not resolve the underlying data-related problems every identity issue consists of.
Layer A, the Identity Data Layer, represents the Business Requirements level, while Layers B and C are equivalent to the second and third layers in the Axiomatic Design process. In turn, the Identity Data Services Layer is equivalent to the technical level.
At each level, the requirements of the previous layer are translated: the Data Management Layer (which defined the data standards and data flows) translates the business needs into a “data logic” and data quality criteria. The Data Workflows Layer translates the data logic and quality FRs into processes and human-driven processes (e.g. user onboarding and provisioning), and the Data Services layer translates the FRs of the user management processes into Identity Services which face the users and their managers.
The consistency and appropriateness of these translations are vital for a successful organisation-wide Identity Management Architecture, both as descriptive (the “as is”) and as normative guidelines. In the descriptive phase, the model leads to a “bottom-up” requirements analysis, without undue or preconceived adoption of technology solutions, addressing the underlying organisational issues, and selecting technologies that resolve each of the FRs instead of aggregating all of them into a coupled design. And, in the normative aspect, the model indicates the potential gaps in a system landscape and the priorities in the technology roadmap: A solution is good if and only if it progresses the Identity Data Flow and if it corresponds to the requirements of the layers below its own.
This article is already long and possibly difficult to read for colleagues who are not familiar with the complexities of Data or Identity Management, but this will not be the last time I will address this, and any remarks or questions are welcome.
At the very least, all of this may help to establish a common language, one of the first steps in Architecture Design collaboration. An indispensable step, indeed, if we are going to succeed.
You must be logged in to post a comment.