My previous blog post on the benefits of commercial enterprise systems, which was a response to an article by Cynthia Rettig, generated some interesting comments, both on my blog and elsewhere. The ones that caught my eye argued that companies were digging themselves into a deep, dark, hole of complexity by deploying these technologies:
"Rettig is looking forward and McAfee is taking the historical perspective. In summary, information technology has been good for business to date, but we’re at an impasse where, as the saying goes, past performance is not necessarily indicative of future success." – comment on my blog from Philip Sheldrake
"Also, I think Rettig’s larger point… is that ERP systems… may hinder companies from capitalizing on potentially more flexible and simpler systems going forward." – comment on my blog from Nick Carr
"McAfee’s critique, however, doesn’t address Rettig’s larger point, which concerns the effect of ERP’s complexity on companies’ choices going forward." – from Rough Type, Carr’s blog
When it comes to enterprise IT architectures, everyone agrees that complexity kills. It adds to expense, decreases reliability, and makes system accidents more likely. Everyone also agrees that modern commercial enterprise systems (like those sold by SAP and Oracle) are unbelievably complex pieces of software. So it’s a short and easy logical leap to conclude that companies that buy enterprise IT are killing themselves, or at least mortgaging their futures in a demonstrably counterproductive way.
The flaw in this logic is that it ignores the differences between system (or design) complexity and module complexity. A company’s IT infrastructure is a system made up of many interdependent modules, or discrete applications. These modules interact with each other in many, many ways, but they also do some purely internal work. An SAP ERP application (module A), for example, might receive an order from a Web front end (module B). This order triggers a number of purely internal events within ERP — decrementing inventory balances, preparing billing paperwork, printing out a pick list in the warehouse, etc. The order also yields a commission payment for a sales rep. Data about this payment is sent to a CRM application (module C), which salespeople check obsessively from their Blackberries.
The key distinction here is that it’s SAP’s responsibility to configure, test, and maintain all the logic and data flows that are purely internal to ERP, while it’s the CIO’s responsibility to do the same for all the activities that flow between systems. And of all the complaints I’ve heard about commercial enterprise applications over the years, I’ve rarely heard that their internal logic was messed up — that they kept losing orders, double-paying sales reps, and so on. And when I have heard such complaints during an implementation project, it’s almost always turned out that an interface with another system was to blame. Enterprise systems can be terribly difficult to configure, but if and when they are properly configured their internal logic generally works. CIOs who want to minimize complexity can "set ’em and forget ’em." A complexity theorist would lump all that internal logic together as a ‘hidden module‘ and ignore it, concentrating instead on all the interfaces between modules.
The counterintuitive result is that adding a wildly elaborate and complicated module can significantly decrease system complexity, if it replaces a number of older modules whose interactions required babysitting. If the PC I wrote this on had a motherboard I’d built myself from scratch, I’d have to spend a lot of time troubleshooting it, and making sure that every new peripheral I added didn’t destabilize the whole machine. I’d be smart to just replace the whole thing with a ready-made and pre-tested motherboard. If I tried to build a motorcycle engine from scratch and put it in my bike I’m sure I’d spend no time riding and all my time fixing. Even though my Ducati’s desmodromic engine is complicated even in comparison to its peers, it gives me no headaches and I never think about it (except to feel cool ’cause my bike has a desmodromic engine). Some very talented people in Bologna dealt with its complexity, so I don’t have to.
Companies that go through the hard work of deploying enterprise IT and shutting off some of their pre-existing legacy systems are reducing their complexity, not increasing it. They might be mortgaging their future in other ways with this IT architecture choice (although I doubt it, which is a topic for another blog post) but they’re not setting themselves up to be overwhelmed by complexity somewhere down the road. Instead, they’re reducing the number of modules in their system.