Negative Feedback Chain in Solution Definition and Execution
© Carlos Trigoso – 2008 – 2009
Executive Summary
This paper is based on many years of investigation working for major organizations. The paper summarizes the results of my investigation, revealing multiple inter-linked problems which determine a very low level of integration and lack of coherence in security project planning and investment decisions. The main aim of the paper is to highlight the complexity of the interrelations, calling for a systemic view of the situation.
Problem Statement
1. While working on many IT projects in the Information Security and Identity & Access Management space, I was able to determine the existence of a “negative feedback” chain in the processes of definition and execution of the IT solutions. This has particular relevance for Information Security and Identity & Access Management Space, but it is evident that the impact goes beyond this domain and affects numerous other areas.
2. The concept of a “negative feedback chain” or “negative causal chain” is generally associated with the disciplines of System Dynamics (Forrester, 1968), but it can be applied to any area of science. Its application to organizational studies can be found in Flood and Jackson (1991). The pertinence of this notion must be explained, especially because this perspective is not familiar to security professionals.
3. The justification, as “foreign” as it may seem, is actually quite simple. Identity & Access Management, of the various disciplines present in the IT Security arena (e.g. Cryptography, Networks, Operations, Applications, Continuity and I&AM) is the one that most affects organizational concerns and at the same time the one that is most affected by these.
4. It is fair to argue, for example, that although organizational features may affect the development and adoption of a Network Security strategy, the actual changes proposed by a coherent and advanced architecture in this realm do not affect an organization widely and may “remain in the background”.
5. Similar statements can be asserted for the other Security disciplines, but not for I&AM.
6. Identity & Access Management directly induces changes in the organizational structure, and also *requires* specific changes, without which the process cannot even start.
7. Identity & Access Management requires, for example, the notions of Role Owner and Identity Data Steward. Without these functions it is impossible to define, validate and re-certify a role model. It goes without saying that without a role model, none of the advantages of user management and provisioning can be materialized.
8. The Identity & Access Management process also induces changes, in that it creates new processes for authorization, maintenance and termination of user accounts. It does not matter really if these processes are automated, although obviously it is desirable to have such automation. What matters is that the processes are in place, and that these are mandatory, standardized and operational.
9. Identity & Access Management, on the other hand, imposes certain disciplines on IT project definition and execution, especially on the way user data is stored, updated and transported between systems. This is the key aspect that will allow us to introduce the rest of the argument here.
10. The first diagram presented below describes the mutual influence of different processes and aspects in the life of an IT solution. People familiar with project execution will recognize the terminology: funding model, organizational model, work queue, tactical solution, etc. [This is a high resolution image and can be enlarged for better viewing].
11. The arrows between the aspects represent “influence” or “action” of one aspect onto another. For example, looking at the diagram you will see (at the top-left corner) the negative influence of “no role owners” onto “no role-based-access control”. In some cases you will find that this sort of influence is trivial, in some other cases it is not. In any case, the point here is that the influence of one aspect over another is not the end of the story: for example, the absence of role-based access controls itself influences the aspect labeled “non-compliance”.
12. Looking at a different area of the diagram, towards the lower-left corner, you will see that three aspects consecutively influence the lack of a role model: “increased user management fragmentation”, “multiple directories” and “silo modality”. In fact, the very tendency towards point solutions lies behind the lack of a role model, although this is not the only factor at play here.
13. The value of the feedback chain analysis lies in the fact that is allows us to see “causes behind the causes”; the chain of events or determinations that in the end bring about a particular state. Going beyond the aspect labeled with “silo modality” you will see that the “lack of enterprise architecture” and the “funding model” can be listed as remote causes.
14. Near the middle of the diagram you will see aspects such as “tactical solutions”, “increase in number of tools”, “stressed resources” and others that should also be familiar to the security architecture practitioner.
15. The influences shown in the diagram are certainly not the only ones to pay attention to. Quite the opposite. An analysis exercise is always an abstraction process, and further consideration may lead us to add other causes and effects to the picture. In particular, we must note as a principle that no “cause” is by itself unidirectional of the “most fundamental” of the variety of inter-related factors.
16. For example, while it can be demonstrated that the persistence of “tactical solutions” causes or influences the “increase in number of tools”, it is also certain that the mere existence of a high number of tools *favors* tactical solutions.
17. An important idea is also that several aspects are negatively linked, thereby enhancing each other. This is the case of the aspects labeled as “increased work queues”, “stressed resources” and “organizational model”; but also of the cycle “increased work queues”, “project delay”, “funding model”, “old-ways mindset”, “tactical solutions”, “uncertainty”, “increased work queues”.
18. In general, these cycles aim to show that there are proximate and remote causes, and that the cycles reinforce themselves and become ingrained in the organization.
19. The second image (below) presents the countermeasures to the negative feedback chain. Because these countermeasures are actually Security Architecture artifacts, this is not the place to discuss why these are mentioned in this context. It will be sufficient to say that the key artifact or deliverable, the Domain Framework, is aimed at reducing the “uncertainty” aspect and therefore breaking several of the main self-reinforcing cycles in the structure described.
20. Other counter-measures are self-explanatory. It should be noted that the countermeasures labeled as “funding model change” and “organizational change” are not within the Domain Architecture deliverables but should be addressed as a common initiative across several domains and organizational units. Here is the second diagram:
21. So we can round up now by describing how the negative feedback cycles affect Solution Definition and Execution. While there are several aspects and negative feedback links which could be pointed to, the main causal chain in this case is as follows:
22. We can start in different places in the cycle, but it is certain that one key aspect is the “lack of enterprise architecture”. This in turn facilitates the persistence of a “silo modality” in solution design. The first is not the sole cause of the second, but we can easily see the direct relationship.
23. Further to this, the “silo modality” is conducive to the multiplication of directories in the IT estate, and this, in turn, causes the increase of fragmentation in user management. The “silo modality” in turn will determine an increase in the number of tools, and an increase in the integration needs.
24. Highlighted in orange is the Reference Directory Pattern (a virtual or meta-directory depending on the specific requirements of an organisation), a particular artifact that could be the key to initiate progress towards better identity management.
25. A purple dotted line leads back to “silo modality” because it is undeniable that the increase in re-engineering costs in and by itself determines the persistence of the silo modality. This is the only link drawn in a different color, just to highlight this particular fact, but in reality, this “back-link” is not different from all the other causal feedbacks.
26. In turn, the increase in the number of tools determines an increase in uncertainty at implementation level, as it is not easy to determine which tools should be used for which task, or even if the tool-set is right at all.
27. Uncertainty feeds into the increase of the work queues of the technical delivery, service delivery, support and project teams and this causes project delays. These links are not rare, but sometimes the participants are unaware of the fact of these feedback chains as a whole.
28. Finally (for the sake of this example) let’s point to the fact that delay in project delivery induces the maintenance of the existing funding model. This explains the continued “need” to fund projects on a first-come first-served basis or, more accurately, on the basis of competing and relatively isolated projects. As a consequence of this, the demands on the delivery of partial solutions are increased and this also causes the “lack of enterprise architecture”.
29. Overall, the negative feedback cycles appear as a “resistance to change”, not as a personal or conscious refusal to change, but as a systemic generalized low equilibrium point. In other words, this is almost the physical path of least effort, an established tendency to select, promote and fund those projects and solutions that are sub-optimal and actually block the development of an integrated IT service environment.
30. It should be noted that there is nothing exclusive or particular about the negative feedback chain described here. It is the case that *all* organizations, public or private, big or small, industrial or financial, in fact all human organizations have this sort of complex internal interactions. Some organizations succeed in mastering organizational change, some don’t. There is nothing “critical” about this at a low level. It is only when we consider what we could achieve if we could reach higher efficiency and effectiveness that we start to see the importance of organizational transformation.
31. For all of those interested in organizational change it is perhaps relevant to know that Identity & Access Management (among the Security disciplines) is the closest you can get, while still being a security specialist and even a very specialized one, to the essence of corporate advancement.
32. It could be said that this depiction of self-reinforcing cycles has little to do with the hard choices of IT project definition and delivery, and probably such an objection would be actually “reasonable”. The key point is, nevertheless, that the usual “hard choices” exist precisely because of systemic reasons and that they persist because the systemic causes keep them in place.
33. An analysis of systemic causality is foreign to project delivery insomuch as project delivery does not investigate the causes of its own limitations.
34. Technical people, more on the side of design, development, service delivery and service support, are sometimes agnostic regarding the organizational context, but the more knowledgeable know very well that no improvement of the “hard” systems or the “software” is possible when the organizational environment is not right.
35. If we had to describe in a few words how the negative feedback chain precludes an effective solution definition in the Identity & Access Management realm – independently of the technology chosen – we would say that it is not the technologies that conspire against effectiveness and efficiency, but the very way in which these technologies are chosen, put together and implemented.
Conclusion
A systemic approach to Information Security Investment decision-making requires analysis and control of the organizational changes that are necessary for a successful outcome. On the other hand, organizational resistance to change is the main obstacle to Identity & Access Management as a business process.
Considering the Negative Feedback Chain described, it is essential to promote change to explain and modify the mindset of the stakeholders and interested parties. Above all it is essential to reduce uncertainty regarding organizational transformation and to show the benefits of the I&AM process.
The Security Architecture artifacts depicted in the second diagram are part of the solution, as these address some of the critical nodes of the negative causal chain. These artifacts should be used as countermeasures and correctives to those aspects which renew and maintain the negative feedback chain.
The changes implied by Identity & Access Management affect each and every one of the employees, temporary workers, contractors and consultants in an organization. They also affect and extend to the customers and partners.
Getting the organizational changes right is the key to designing and implementing an Identity & Access Management process.
Identifying the negative influences between the different aspects of an organization is a key aspect of the success of this fundamental discipline.
Bibliography
Jay W. Forrester, Principles of Systems, MIT Press, 1968
Michael C. Jackson and Robert L. Flood, Creative Problem Solving, Wiley, 1991