There have been a spat of IT articles in HBR in the past couple of years, showing that IT has finally made it from the weirdo to the standard practice status. “Getting IT Right” seems to follow from “The REAL New Economy” and “IT Doesn’t Matter”. Charlie S. Feld and Donna B. Stoddard make an argument for “three interdependent, interrelated, and universally applicable principles for executing IT effectively”. These are:
- A long-term plan for renewing IT, that is linked to the corporate strategy
- Simplified and unifying corporate technology platform
- Highly functional and performance-oriented IT organization
Pretty simple to say but difficult for IT managers to implement. Although IT is ostensibly based on scientific and engineering principles, we resist any form of unified technology that we don’t invent ourselves and any, I mean any
Rebuilding the systems from scratch would have been extremely costly — plus the company had an airline to run. Instead, Delta built a new set of software, or middleware, that connected a common infrastructure with every application. The middleware within the Delta Nervous System sat on top of the old transaction systems and carried critical operational data from one application to the other.
This middleware sits between the existing applications and a new, common database system. The middleware acts as a common translator for the applications: they send requests for data, just as they always have, but instead of hitting their own database layer, the Delta Nervous System middleware intercepts the request, converts it to the language of the common database and passes it on. When the DNS middleware gets a reply back from the database, it converts that into the language of the application and sends it on.
The beauty of this solution is obvious to everyone but engineers and developers. (I have a suspicion that most engineers and developers are true adherents to what James C. Scott calls “High Modernism”, that fascism of ideological purity best represented by Le Corbusier and Lenin.) The middleware allows you to simply turn on different systems to use the new database backend one at a time, reducing threats of downtime. It also lets you keep the application the same. Replacing the backend database is a major undertaking, to be sure, but it pales in comparison to having a to train the staff on a new application.
The middleware solved the immediate problem — data was stored in a common format and forced common definitions to be used, whether teams wanted to or not — without requiring a complete rewrite. Turning on a new system could be done simply by just switching over to the new front-end application. If the switch-over didn’t go well, you could switch back to using the old system. Both hit against the same data backend so it wouldn’t matter.
Most developers and engineers want to replace anything that they didn’t create. A friend of mine who owns a boutique law firm in Chicago complains about this on a regular basis. Even for his small firm, the IT consultants always want to rip out the way that they previous guy (it’s always a guy) did it. “Not Invented Here” is a serious problem with IT departments.
I’m a bit leery, though, of their point about having a single platform. While you do want to reduce the amount of complexity in a system, by doing so you increase your risk of total system failure. With all the data being stored in a single repository, a compromise of security in one application would have devastating effects across all applications. Data could be poisoned in one place and it would be replicated across the entire enterprise. This is one of the reasons that you do not want the government databases all talking to each other. If there is a problem with one of the databases, you can currently seek information in another database and challenge the wrong information with the government’s own data. If they all corresponded properly, poisoning one record is all that it would take to destroy your life.
Works Cited
Feld, Charlie S. and Stoddard, Donna B. “Getting IT Right“. Harvard Business Review. Feb 2004:72-79
Image Credit: Devizesbowmen (shooting a recurve bow at archery target). © Jethrothompson (CC BY-SA 3.0). Via Wikimedia Commons.
