Many times in conversation or debate it is useful to “step back” from the immediate matters at hand and look at the context. Having written that, I am even inclined to say that this is always the case, especially when addressing technology strategy. If we do so we will notice there are obvious problems with the way IT management is operated.
In the recent past, there was an important discussion about the fact that a large number of IT projects fail or are abandoned. My analysis of this debate and references to the sources can be found here: https://carlos-trigoso.com/fundamental-conceptions-of-information/when-is-a-system-secure-then/ .
People who wanted to deny that there was a problem tended to say that, after all, it is a good thing for management to cut short a project, and that the total number of “failed projects” didn’t have a negative meaning as for the quality and direction of the IT departments (and the IT industry as a whole). Granted that is is a function of management to reduce the negative impact of failed projects, this argument was never very convincing, given that the cause of the great majority of failures can be found at the beginning of the project, and consists of a mixture of lack of leadership, planning and accountability. It is my experience that Information Security programmes fail fundamentally because of lack of ownership and governance, which in turn determines the absence of a Security Architecture. It is rare to find a project broken merely because of “technical” reasons.
Here I want to suggest too that the studies mentioned above missed an additional category of project failure, one that I have been able to witness especially in the past 15 years or so. For reasons that it will be necessary to investigate, the type of failure that I want to introduce here is more visible in the area of Identity Management and Access Control. This is perhaps due to the fact that in this area the lack of business ownership and strategy has more negative consequences, while in other aspects of IT the damage caused is less evident.
While personal observation is not a statistical proof, I cannot but underline that in the recent past a large number of Identity Management projects fail, and that very significant proportion of failure appears as projects that are never completed, but also never cancelled, and become “part” of business as usual operations. The attentive Security specialist will be able to find this kind of failed projects just by looking around at the current state of the industry.
How does this happen? The peculiar nature of this kind of problem is determined by the almost complete disengagement of business team and leadership from the delivery of Identity Management services. This disengagement is at the root of a never-ending “delivery” phase, where the IT departments try to maintain the service in the absence of business input or direction. What originally may have been planned as an 8 or 18 months long project becomes embedded in the “standard” processes, albeit in incomplete form, and runs on for years.
These projects never end too, because they are upgraded on the fly, i.e. technologies are swapped for different ones, or patched and complemented as the process becomes stalled. The lack of directive and supervisory business involvement allows the IT departments to position Identity Management as just another “tool” in the arsenal of systems management, and the business teams (who did not formulate the original requirements) becomes unable to understand if the project is a failure or not.
In truth, the failure occurred right at the beginning in all cases, with the positioning of Identity Management as something which is done for the sake of IT efficiency and operational concerns. The IT department, in the drive to “simplify” their manual user access controls, normally adopts Identity management technologies in order to automate operations, but the previous lack of business process focused on user management and authorisation soon transform that drive into a very limited mechanism to register and delete users (but still without business backing and understanding).
Personal corroboration of these problems will be easy to find for the professional interested in these matters.
Now here is the point where I suggest that there is something more behind these problems, and where we need to “step back” and look “at the forest as a whole.” How is it –I would ask—that even in the extremely sensitive area of Identity management, the IT Departments are left to their own devices and are allowed to sink into an unbounded story of permanent technical updates and “tooling roadmaps” ?
First it is important to remark that in reality the entire IT context is marked by the acceptance that IT management is after all a perpetual “upgrade roadmap.” I don’t think that this can be disputed. Let’s say it it a different way: because of the peculiarities of the IT technology market, the IT space has become completely focused on technology upgrades and its entire planning and budgeting effort is optimised for this exercise.
In addition to that though, at least in my experience, it is becoming clearer that there is a hidden organisational impulse which does not come from the IT departments themselves but from the business which actually causes these departments to close in and become mired in the “upgrade roadmaps.”
Despite the fact that this unwinnable fight with legacy technologies, multi-year upgrade plans and failed projects that become “business as usual” I see the desire of the business teams to stay away from technology and to effectively delegate technology decisions to the IT executives. Everything happens as if the business teams and leaders do not want to have anything to do with technology and its real problems. This, and perhaps only this also explains the contradictory adoption of “Cloud-based” solutions, where we see clear business interest in avoiding the delays and issues arising from any technological transformation, but also the “resistance” of the IT departments which then bind and link the open ended Cloud technologies to their customary upgrade roadmaps. The result is a partial exploitation of the Cloud, and a continuation of the usual constraints in the IT department. Nobody wins and –as before—IT retains its “place” in the organisation.
What is this place? From the point of view of organisational theory we could say that the “function” of IT is not only to deliver IT services, but also to isolate and block these services and concerns away from the business teams. So it is a function with a dual character. Studying it for what it is we can avoid unwarranted optimism regarding IT transformation or “progress” in this area.
Is this a justification for the lack of change and improvement in the IT business or more particularly in the Security and Identity management? Not a all: quite the opposite, this is a call for IT and Security professionals to understand that there will be no change if we do not do things for the sake of excellence.