Item Description: A discussion of competitive advantage via IT

Review Synopsis: A discussion of competitive advantage via IT

There has been a great deal of controversy surrounding this book, and the article it derives from, and I think the controversy has its origins mostly in a misunderstanding. Some IT people seem to have reacted to the (admittedly somewhat confrontational) title, without reading the book.

Mr Carr is writing for a business audience, and as such approaches the subject using the standards of business writing. As a result, his definitions are sometimes not entirely clear, and his conclusions are pretty much entirely drawn from analogy*. The first two thirds of the book are devoted to setting out and exploring the notion that IT as a whole is an 'infrastructure' technology, and both software and hardware are increasingly commoditised (I'll return to the commodity point). Carr is meaning 'infrastructure' in the same sense as the electrical distribution network, or the railway network (analogies he draws on very heavily). He goes on to point out that during the 'build out' (i.e. original development and construction) of previous 'infrastructure' technologies, companies were able to derive significant competitive advantages from good use of the new infrastructure. However, now that the infrastructures are mature and complete, they are commoditised and 'best practice' in making use of them is commonplace throughout business. Since 'best practice' is practiced by all, there is no competitive advantage to be gained.

I read this as something of an oversimplification, and also a failing on the part of the analogy. For the majority of businesses (leaving aside the infrastructure businesses such as the rail companies), there is no competitive advantage to be gained from intelligent use of the electrical infrastructure. In Carrs phrase, 'vice presidents of electricity quietly disappeared from the corporate hierarchy'. Well, perhaps under that name. A company heavily reliant on the large scale, cost effective use of electricity, or transport of large volumes of materials may well have a 'facilities director' or 'logistics director' whose responsibility is to make good use of these infrastructure components, and ensure that internal interfaces to the public infrastructure are maintained at optimum. Similarly, a company who used rail transport extensively within their own physical bounds may do the same (I'm thinking of e.g. mineral mines, where a complex internal rail network can exist).

Even with those considerations, I don't think the analogy holds up all that well. Information pervades all organisations, and every bit of improvement in information flow will gain a little bit of efficiency for your organisation. There is always a cost/benefit trade off to be made, but generally the better your organisation handles its information flow, the better it will do. The same cannot be said about transport unless transport is core to your business. The key difference is that information is core to everyones business. Comparing the electrical distribution network, information flow and structure is many orders of magnitude more complex - that analogy doesn't hold at all. I get the feeling that Carr has seen a topological analogy between the public electrical infrastructure and the internet, and just stretched it a little too far.

Carr also explores the notion that IT hardware and software are increasingly commoditised, and that argument seems to hold up pretty well. Hardware is easily and cheaply bought in undifferentiated bulk, giant server farms are often these days built using generic Linux PCs rather than high performance, high cost servers (Amazon and Google being good examples). Commodity (shrink wrap) software is increasingly outsourced and bulk written cheaply. My feeling is that the argument is pretty much won as far as hardware goes - it doesn't really matter who your PCs come from (apart from price and quality concerns), they aren't really much different. Commodity software (shrink wrap) is increasingly written in 'code factories' these days, at low cost. Network infrastructure is largely 'plug it in' now - outsourcing of network infrastructure can make a lot of sense, provided its managed intelligently. However, this argument misses out one all important component - configuration. This lack is never really addressed, although it is alluded to near the end of the book.

In the last chapter, Carr explores what he considers to be 'good practice' in IT for the future. "Follow, don't lead" - don't be the first to implement a cutting edge new technology; "Spend less" - slow your investment cycle, most of your desktop users don't need the latest kit; "Innovate when risks are low" - you can lead the pack when you're in a strong or no lose position; "Focus more on vulnerabilities than opportunities" - you might paraphrase this as "more testing, less spec creep". Customisation of the IT infrastructure for your organisation is the place of the people on site (Carr does stress that it is important to get good IT people to run your IT infrastructure - he considers wholesale outsourcing to be a mistake: "Today, there is probably no better way to reduce IT risk than to attract and retain the best IT talent"). In this context, relatively small quantities of 'glue software' linking generic applications via standards based interfaces are effectively configuration, and by extension Carrs argument calls for these to be written and maintained in house. That could be something of a pointer for us. Dynamic languages generally and Perl specifically are ideally placed to do exactly this kind of work

Ultimately Carrs message is that IT (in the sense that he is using the phrase) will not give your business a competitive advantage. However, it is vitally important in interpreting that message to understand who his target audience is. He is addressing the kind of PHB who truly believes that a roll out of the latest version of office software ahead of the competition will give the company an edge. Really, he's just warning against the kind of hyperbolic neophiliac nonsense that gave rise to the dotcom bubble.

What Carr is saying is that just 'IT' won't give a business an advantage, but well designed processes, incorporated into well designed information systems will. That, as with many things in this book, is something many of us would agree with. Sadly its an argument that has been missed or ignored by many business managers during the rush to outsource, but the more adaptable ones can understand it.

After approaching this book with a good deal of suspicion, I ended up finding it extremely thought provoking, and agreeing with many of his conclusions. There are over-simplifications, but it is aimed at a non technical audience. Ultimately many of his arguments are what we would like to say ourselves, couched in terms that the PHB can understand and accept, by someone the PHB might actually listen to.

*'Academic' business writing has little time for concepts like 'evidence', 'methodology' etc. Like pre-Enlightenment 'natural philosophy' or medieval Christian apologetics, the whole field seems to be mainly based on inductive logic and rhetoric. This is quite deliberate, as it is considered more efficient that way. In a bizarre and scary realisation of Dilbert, it is OK to do things wrong as long as you're really really fast. Personally I find this somewhere between distressing and laughable. Reading the Harvard Business Review, a part of me is sniggering: 'awww, how sweet, they think they're doing research'. Then I remember the influence this pseudo-science has on our societies and the whole thing becomes much less cute.