In the book IT Risk by Westerman & Hunter, the authors define a framework for mitigating risk in a company related to IT. It revolves around four areas: availability, access, accuracy, and agility. Agility relates to the ability of IT assets to change fast enough to allow companies to take advantage of trends in the marketplace. If the IT department needs a year to make changes to the systems in order to support a new product or service that the company wants rushed to market, we aren’t talking an agile application.

A good example of this is an enterprise resource planning (ERP) application that still requires interfaces to legacy systems it was intended to replace. The more interconnections you build, the more complicated the system will be and the harder it will be to change. Rettig, quoting a research study of over 400 companies performed by MIT researchers, “In many companies, it takes the IT department one to two years to implement a new strategic initiative – hardly the agility companies are striving for … Legacy systems cobbled together to respond to each new business initiative create rigidity and excessive costs. Every change becomes a risky, expensive venture.” (p. 21). Not a prescription for mitigating agility risk in a company.

A number of ERP implementations did not go well, or the company is finding out that managing this behemoth of an application environment is impossible, and they are looking for the next big thing that will give their company a competitive edge in order to survive in the marketplace. And along comes Service Oriented Architecture (SOA). But make sure you know how the company is going to implement SOA. As Rettig says, “…to the extent that these service-oriented architectures use subsets of code from within ERP and other enterprise systems, they do not escape the mire of complexity built over the past 15 years…” (p. 26).

So the sales executive from XYZ Software convinces the CEO and CFO that the best approach is to leverage the company’s investment in their ERP application by adding on a service-oriented architecture on top of it which will let company respond to the pace of business more quickly. But wait, you just added a layer on a layer on a layer. How good can that be? “SOA’s become additional layers of code superimposed on the existing layers. That means it is possible that a process will fail at some point due to some fault in the layers below, and in order to understand and fix the problem, software engineers will need to deal with the layers of enterprise applications below the modular business processes” (Rettig, p. 26). That’s definitely not agile software!

Maybe it’s time we as IT managers need to sit back and rethink the whole process; how we organize data, how we access that data, how we write the applications, etc. Are we stuck in the rut we’ve dug, and don’t realize how bad the situation really is that we’ve made? As Rettig says, “… IT departments tend not to be innovative leaders within organizations, but rather conservative forces, viewed by business executives as cost sinks and liabilities” (p. 21). Ouch! “A recent study by Forrester Research…found that only 28% of CEO’s thought their CIO’s were proactive or creative in terms of business process improvement” (Rettig, p. 27).

Rather than thinking “outside the box,” maybe it’s time to get out of the box, throw it in the trash compactor, and start looking at our processes, applications, data, and other assets from totally different perspectives. If we don’t, we might find that our jobs have been outsourced to someone who will.

— Rettig, C. (2007, Fall). The Trouble with Enterprise Software. MIT Sloan Management Review.

— Westerman, G. & Hunter, R. (2007). IT Risk. Boston, MA: Harvard Business School Press.