Chasing the mirage: the illusion of corporate IT standards
Corporate IT environments tend to evolve in a haphazard fashion, reflecting the competing demands made on them by the organisational functions they support. This state of affairs suggests that IT is doing what it should be doing: supporting the work of organisations. On the other hand, this can result in unwieldy environments that are difficult and expensive to maintain. Efforts to address this generally involve the imposition of standards relating to infrastructure, software and processes. Unfortunately, the results of such efforts are mixed: although the adoption of standards can reduce IT costs, it does not lead to as much standardization as one might expect. In this post I explore why this is so. To this end I first look at intrinsic properties or characteristics that standards are assumed to have and discuss why they don’t actually have them. After that I look at some other factors that are external to standards but can also work against them. My discussion is inspired by and partially based on a paper by Ole Hanseth and Kristin Braa entitled, Hunting for Treasure at the End of the Rainbow: Standardizing Corporate IT Infrastructure.
Assumed characteristics of standards and why they are false
Those who formulate corporate IT standards have in mind a set of specifications that have the following intrinsic characteristics:
- Universality – the specifications are applicable to all users and situations.
- Completeness – they include all details, leaving nothing to the discretion of implementers.
- Unambiguity – every specification has only one possible interpretation.
Unfortunately, none of these hold in the real world. Let’s take a brief look at each of them in turn.
To understand why the universality claimed by standards is false, it is useful to start by considering how a standard is created. Any new knowledge is necessarily local before it becomes a standard– that is, it is formed in a particular context and situation. For example, a particular IT help desk process depends, among other things, on the budget of the IT department and the skills of the helpdesk staff. Moreover, it also depends on external factors such as organizational culture, business expectations, vendor response times and other external interfaces.
Once a process is established, however, local context is deleted and the process is presented as being universal. The key point is that this is an abstraction – the process is presented in a way that presumes that the original context does not matter. However, when one wants to reproduce the process in another environment, one has to reconstruct the context. The problem is that this is not possible; one cannot reproduce the exact same context as the one in which the process was originally constructed. Consequently, the standard has to be tailored to suit the new situation and context. Often this tailoring can be quite drastic. Further, different units in within an organisation might need to tailor the process differently: the customisations that work for the US branch of an organisation may not work in its Australian subsidiary. So one often ends up with different organisational units implementing their own versions of the standard.
Related to the above point is the fact that standards are incomplete. We have seen that standards omit context. However, that is not all: standards documents are generally written at a high level that inevitably overlooks technical detail. As a consequence, those implementing standards have to fill in the gaps based on their knowledge of the technology This inevitably leads to a divergence between an espoused standard and its implementation.
Two people who read a set of high-level instructions will often come away with different interpretations of what exactly those instructions mean. Such differences can be overcome providing:
- Those involved are aware of the differences in interpretation, and
- They care enough to want to do something about it.
These points are moot Firstly, people tend to assume that their interpretation is the right one. Secondly, even if they are aware of ambiguities, they may choose not to seek clarification because of geographical, language and other barriers.
Some may argue that it is possible to work through some of the problems listed above. For example, it is possible – with some effort – to reduce incompleteness and ambiguity. Nevertheless, even if one does this (and the effort should not be underestimated!), there are other factors that can sabotage the implementation of standards. These include:
- Politics – It is a fact of life that organisations consist of stakeholder groups with different interests. Quite often these interests will conflict with each other. A good example is the outsourcing vs. in-house IT debate, in which management and staff usually have opposing views.
- Legacy – Those who want to implement standards have to overcome the resistance of legacy – the installed base that already exists within the organisation. Typically owners and users of legacy systems will oppose the imposition of the new standards, first overtly and if that does not work, then covertly. Moreover, legacy applications make demands of their own – infrastructure requirements, interfaces, support etc., each of which may not be compatible with the new standards.
- FUD factor – Finally, there is the whole issue of FUD (Fear, Uncertainty and Doubt) caused by the new standards. Many IT staff and other employees view standards negatively because they represent an unknown. Although much is said about the need to inform and educate people, most often this is done in a half-baked way that only serves to increase FUD.
Although the implementation of corporate IT standards can reduce an organisation’s application portfolio and the attendant costs, it does not reduce complexity as much as managers might hope. As discussed above, non-universality, incompleteness and ambiguity of standards will generally end up subverting standardization (see my post entitled The ERP paradox for an example of this at work). Moreover, even if an organisation addresses the inherent shortcomings of standards, the human factor remains: individuals who might lose out will resist change, and different groups will push to have their preferred platforms included in the standard.
In summary: a standardized IT environment will remain a mirage, tantalizingly in sight but always out of reach.