Now, a good friend of mine at a large national oil company (who prefers to remain anonymous) has borrowed Bush’s imagery, applied it to enterprises, and allowed me to pass it on to the attention of Information Management readers.
Who Belongs to the Corporate Axis of Evil?
The Corporate Axis of Evil conjured by my friend consists of IT, procurement and HR. For reasons we’ll examine in a moment, the rest of the enterprise shuns these three departments as much as humanly possible. It is only because the rest of the enterprise is compelled to interact with the Corporate Axis of Evil that there is any interaction at all.
The distaste is reflexive. A friend of mine who is an enterprise architect tells me her job is unfamiliar enough that other parts of the business are unsure of which department it is located in. She interacts well with the business - until the fact surfaces that she is part of IT and attitudes toward her become markedly more negative.
But behind the pejorative label, our fictional Corporate Axis of Evil is different than the former president’s vision. The global axis of evil, we are told, conspires in transgressions that include weapons smuggling, exchange of controlled technologies, financial shenanigans, counterfeiting and so on.
By contrast, the members of the Corporate Axis of Evil are polarizing enough that they even detest each other. The reality is also that procurement and HR have similar feelings toward IT - they try to avoid IT as much as possible. Though they use the same methods to earn their reputation, the Corporate Axis of Evil is much less collaborative than the “real” Axis of Evil that works together for their mutual protection and benefit.
What Does The Corporate Axis of Evil Deliver?
What could have earned the Corporate Axis of Evil this reputation? According to my friend, it is because the Corporate Axis of Evil delivers three main products: obfuscation, delays and bad excuses. Whether these are crutches of authority, a perpetuation of engrained bureaucratic work habits or just a big misunderstanding, these are the devices that create the distaste my friend describes so harshly.
Obfuscation comes naturally to IT because of the strange terminology it uses and because the language of IT changes rapidly. The terms used by IT are conveniently dropped into ordinary conversation where they have precise but arcane meaning to most listeners.
Consider the words “index,” “cluster,” and “partition.” Business users can easily be told that one of their cherished requirements is impossible because “partitioning does not support it” (or clustering, indexing or whatever). Can the users object to this? Of course not. Does a user really want to ask what a partition is compared to their comprehension of a room divider? He or she will look silly, and IT personnel might unload an extra torrent of buzzwords should they persist in their questioning.
Delays are achieved in many ways. A common tactic of IT, procurement and HR is to embed lots of rules that nobody else knows about. (This is a characteristic of all tyrannies - rules devised in secret, communicated as little as possible and comprehensible only to “competent” individuals.) When a project is delayed, the business users can be told something like “We have to wait for the next ARB.” If a business user is silly enough to ask, they will be told by their IT counterparts that an ARB is an architectural review board, and that everyone should know that, because some people in IT do. If the user asks why the project has to wait for such a meeting, they are told that the ARB only meets on the second Tuesday after a full moon, or requires Architect X to be present, who is right now on vacation cycling around Tierra del Fuego.
Bad excuses tend to be saved for the final stages of projects, where user expectations have to be addressed. These moments can be awkward for IT, but the discomfort is usually temporary. I have seen business users stoically accept the reality of what IT has delivered, as they listen to explanations of “rescoping,” “deferring functionality to later stages” or “redeployment of resources.” I have seen the IT staff sit just as stoically as user management heaps torrents of abuse on them. The scene is a common one and never appears to change much. Businesspeople know that IT staff are pretty much all the same, and replacing one with another may be gratifying, but will never fix the underlying endemic problems. And the IT staff? By appearances, they are quite happy to go from one failed project to the next.
I’ll concede this discussion in indelicate and some will insist that what is written here is exaggerated, unfair or extreme. But even if that is true, IT, HR and procurement live quite dangerously by not reflecting on the negative way in which they are viewed by the rest of the enterprise. In data management, this should be a clear signal to shed the IT stereotype as quickly as possible, disavow the Corporate Axis of Evil and look for ways to align itself with the rest of the enterprise.
Malcolm Chisholm, Ph.D. has over 25 years of experience in enterprise information management and data management and has worked in a wide range of sectors. He specializes in setting up and developing enterprise information management units, master data management, and business rules. His experience includes the financial, manufacturing, government, and pharmaceutical industries. He is the author of How to Build a Business Rules Engine and Managing Reference Data in Enterprise Databases and Definition in Information Management. He writes numerous articles and is a frequent presenter on these topics at industry events. Chisholm runs the websites http://www.bizrulesengine.com, http://www.refdataportal.com and http://www.data-definition.com. Chisholm is the winner of the 2011 DAMA International Achievement Award.