Business Intelligence Network - The Vision for BI and Beyond

ADVERTISEMENT

IT Culture and the EIM Paradigm Shift

Published: 2 April 2008

The false distinction of IT and "the business" as two separate worlds is impeding full realization of enterprise information management.

A few weeks ago, I was discussing the need for building processes to manage the operation of a master data management (MDM) hub. I made the mistake of calling them “business processes”. A colleague who was present looked at me as if I had just taken leave of my senses, and proceeded to carefully explain to me that we are IT and we do not have business processes – only “the business” has business processes. Realizing my mistake, I apologized and informed her that I had misspoken and had meant to say “data governance processes”. Everyone was happy.

This incident was a symptom of the way we in IT have trained ourselves to think. There is data and there is metadata. There are databases and there are repositories. There are applications, and there are repositories (again). There are business processes and there is data governance. All these false distinctions exist to support one overarching false distinction, which is that there is “the business” and there is “IT”. The absolute division between IT and “the business” is the current paradigm for IT. It is deeply held, but it will have to shift if enterprise information management (EIM) is to become a reality.

A Brief History of Time

How the IT versus “the business” paradigm came to be can be traced back to the original explosion of computer usage in commercial and public sector organizations. When computers became commercially available, they were mysterious large budget pieces of technology that required special support. Indeed, during the 1960s, the term software applied to programmers just as much as it meant operating systems and programming languages. The individuals who made the computers function in businesses needed specialized technical skills that were no part of anything found elsewhere in these businesses. Quite naturally, these individuals were closely aligned with the engineers who designed and built the computers.

This era ended when computers suddenly became much more widely available to businesses. At the same time, new programming languages and systems development methodologies became common. It was the heroic age of custom in-house application development. Every enterprise created its own operational silos. The staff that did this was usually young, had little experience working in non-IT areas, and was much more closely aligned with the IT industry than the organizations they worked for.

The youthful profile of this era has huge implications, since the programmers of yesteryear are the managers of today. They formed their working habits and outlook when they were scrambling to implement and support all manner of operational applications. Probe any of these managers and you will find that what they value most is the ability to develop solutions.

The PC Revolution

In the late 1980s, PCs suddenly became available. A huge wave of downsizing occurred as this technology reduced the need for secretaries, middle managers, and the like. PCs were also different in that there was no need to build custom applications for them. End users could simply buy packages. Package development had, of course, been part of the earlier eras dominated by mainframes. Now, it came on with a vengeance, such that building applications in-house came to be seen as unproductive. Package acquisition became the norm, not just for the desktop, but for departments, and eventually at the enterprise level. Creative talent began to evaporate from IT departments to be replaced by more administrative types who did not have such specialized technical skills. These individuals were more oriented toward selecting and configuring packages than developing applications.

Nevertheless, the new recruits to IT were still more oriented to the IT industry than to the organizations they worked for. Their world might now consist of categories of vendors rather than categories of application development tools and techniques, but whatever it was, it was certainly not “the business”.

The Current Reality

The historical outline just presented is only an outline that must be tempered by some realities. First, custom in-house development never disappeared entirely. It is especially necessary in the area of data integration, but it persists in other areas too. Second, there is some crossover between IT and the business, and indeed there always was. Familiarity with the business was always seen as a very positive factor, even for custom programming. It reduced the need for highly detailed specifications, and drove up the quality of what programmers produced. Third, “business users” have become a lot more familiar with IT over the decades, no doubt partly as a result of using PC’s and other personal technologies. This has made “business users” less in awe of IT, a trend that has grown since the bursting of the Internet bubble in 2000.

Yet, the fundamental paradigm that IT is essentially different from “the business” remains firmly embedded in the IT culture. This paradigm, and the history out of which it developed, have several consequences.

IT – The Only Business Area Without Systems

One consequence is that IT rarely has any information management infrastructure, in line with the well-known saying “the cobbler’s children go unshod”. This is, in turn, dependent on another view of IT, which is that it exists as a service to “the business”. Although never stated as such, it is as if IT thinks of itself as a giant union hall full of day laborers waiting to be hired by someone else – “the business,” of course. It would appear that this mentality became developed by working only on projects. An IT project begins, is staffed, runs its course, and ends. Everyone then moves on to some other project, and the cycle is repeated endlessly. What information management infrastructure would ever be required to support this business model?

This problem can also be approached from the perspective of metadata. When data professionals complain that “the business” does not understand and value metadata, do they not realize what they are saying? Metadata is the data that IT produces and consumes as it delivers its services. Indeed, the term “metadata” has had to be invented to maintain the distinction between “the business” (which produces and consumes data) and IT (which would never produce or consume data, by definition). If metadata is something that is required for IT to do its job, why would “the business” ever be interested in it, or why would a business sponsor ever be found for a metadata project?

Undoubtedly, many would object to this view. For instance, data definitions are very useful in the interpretation of reports, and so metadata should be something that “the business” cares about. Yet, this is a little like the human resources function saying that “the business” should be interested in standard performance evaluations. No doubt the business is interested in standard performance evaluations, but they expect the HR function to provide them. Similarly, it is the enterprise information management function’s responsibility to provide data definitions, since it is EIM’s responsibility to manage the enterprise data resource.

In other words, IT, in general, and EIM, in particular, should build or acquire applications to help them do their jobs. To the extent that this information management infrastructure is missing, neither IT nor EIM can be doing their jobs particularly well.

Paradigm Shift

The “IT versus the business” paradigm is deeply embedded because IT managers grew up in the heroic age of in-house custom application development, or the subsequent period of package acquisition and implementation. In either case, the whole experience of these individuals was based on IT being a separate world from “the business”. This paradigm is now preventing IT, in general, and EIM, in particular, from moving forward. The paradigm has always been responsible for frustration with IT by “the business”; but so much of “the business” today consists of processing information, that the paradigm is actually a drag on business growth.

The advantage of the paradigm for IT is that it provides clearly defined boundaries, within which IT can insulate itself from responsibilities to the enterprise as a whole. It can be reactive, and wait for “the business” to engage in certain preordained ways that probably never make sense to “the business”, and still pretend to be a service unit. The thought of proactively managing the enterprise information resource, if indeed this thought ever occurs, is probably frightening and alien to 50 years of accumulated experience.

This is not to say that trying to proactively manage the enterprise information resource is easy. It is a new idea to nearly everyone in nearly every enterprise, and there is no pattern such as exists for functions like human resources, finance, or facilities management. Yet, the paradigm must change because it is fundamentally flawed and has tremendous negative impact. Ultimately, it will change. The only question is how long it will take.

If you found this article helpful and would like to receive the latest insights each month from Mike Ferguson and other experts featured on the Business Intelligence Network, please subscribe to the UK Business Intelligence Network Newsletter.