Monday, October 30, 2006

Musings on CODB and CA

A really interesting article is Mastering the three worlds of Technology by Andrew Mcafee as pointed out by Nicholas Carr.

Andrew categories IT into three types - functional, network and enterprise and discusses how each of could be managed. It's a good article, very insightful.

Of particular interest is the last bit.

"For a resource to have an impact on a company’s competitive position, it must be valuable, rare, inimitable, and nonsubstitutable. Oil wells and diamond mines meet the test; pencils and paper don’t. What about IT? At first glance, it would seem that all three IT categories fail to meet these criteria. Vendors offer a wide range of FIT, NIT, and EIT, so these technologies are not rare and seem to be highly imitable. However, people often forget that while the software itself might not be any of those things, a successfully implemented system isn’t easy to replicate"

The majority of I.T. systems do appear to be CODB and no matter how you categorize them, they would appear to fail to meet the criteria of valuable, rare, inimitable, and non-substitutable. However, this doesn't mean there aren't examples of novel and new processes which are differentiators with real return (CA).

Whether you agree with his ideas or categories, in my view Andrew does make one exceedingly good point.

The process of execution is separate from the purpose of the activity i.e I can just as easily wreck a viable CA through poor management as I can wreck a CODB.

Poor implementation of a CA doesn't mean it wasn't a potential CA and a single fantastic implementation of something which is CODB doesn't turn it into a CA.

Upgrading the power to a factory in such a way that you leave it without electricity for two months is costly, whilst getting the upgrade done in a day means we can start producing again. This upgrade is all about the cost of a CODB like activity and the cost of implementation is part of this.

Of course if being good at implementation of CODB projects is novel and rare in your industry - then that is a potential source of CA.

If everyone else's power upgrades knocks out their factories for two months, and I have the only team in the world that can seem to do it without such problems - I have a source of genuine if maybe temporary CA - that team.

It only remains an advantage whilst everyone else is constantly making a mess of the implementation, so when I have "power installation consultants" knocking on the door with examples of simple easy installation in a day as "Best Practice" and horrors of not doing "Best Practice" - then any source of advantage has long since gone.

Getting it right, when others do with a CODB like activity, is not a source of advantage or a benefit - it should be expected. In such a world, "cheap as chips" becomes the order of the day with CODB, and this is why commodity like operating environments and services are now becoming more relevant.

Times up on this merry go round. Salesforce, Amazon's EC2 and others have pointed the way. Of course this says nothing about how you deal with genuine CA-like I.T. projects (the rare examples) for which a VC like approach is more appropriate.

That's another topic though ...

2 comments:

Michael Schaffner said...

I agree with you that IT can either be a CA (Competitive Advantage) or a CODB (Cost of Doing Business). In fact it can evolve from a CODB to a CA and then back again.

While IT can most definitely be a CA on a temporary business it is difficult to sustain that state. It most cases it is only a matter of will and resources for the competition to catch up. When they do your CA becomes a CODB again. However, by being the first adopter you have hopefully established a place in the market that is hard to displace unless you mess it up.

The trick isn't to bemoan a shift from CA to CODB (or vice versa) but rather to understand it and use it to best advantage.

swardley said...

I completely agree with you.

I do use CA and CODB to highlight two polar points, however there is the whole transitional stage and related questions of how you deal with a project whose nature is changing from one to another.

The advantage of being a first adopter in something which creates measurable value can be eroded by holding onto proprietory technology for too long. There is a definite trick to managing this transition.

However this assumes the ability to distinguish between CA, CODB, to measure value and to identify when a transition is occuring - something which does not always seem to be well done.