Let’s not invent that round thing again

I realised while I was out tonight that I was rambling in my earlier post, commenting on Joel’s very valid comments about when you’d buy and when you’d build. What I wanted to say and now that I’ve had a bit of time to think it through is:

– If you’re in a business where you can steal a march on competitors through a bit of sharp innovation in technology, you’d bespoke your code. Good examples in the UK would be Easyjet or Firstdirect; in the USA, I doubt that there was a platform to do what Amazon did before they built it. If you were in a bank selling investment products and you came up with some clever derivative, or a range of such products you’d probably have to build a system to support them. I know banks that ran their warrants businesses (close to the “options” business that the US banks run) on Excel spreadsheets with lots of custom macros because there were no other systems. Again, clear that this is “build” space.

– If you’re a follower, or you’re not in a position where customers come to you because of technological innovations – perhaps where customers have to come to you or where that area is invisible to customers, why on earth would you want to build something that someone else has already taken care of. I’d be thinking here about HR systems, payments handling systems, forms processing, data capture, even your corporate web hosting system. And that’s where Joel’s point about “core competence” is strongest. This is all “buy” territory.

– Now, where I think it gets more interesting is the decision on whether you “buy and leave” or “buy and fiddle”. Too many organisations are in the latter camp – taking a supposedly off the shelf package and fiddling with it endlessly to make it confirm to the business process rather than wondering about why the business process is the way it is and perhaps changing it to match the software. The “buy and fiddle” option allows many to claim that they are using off the shelf items when, in reality, they are saddling themselves with longterm problems – maintenance costs, issues when the new version comes out, incompatible standards and lockin to a product. That’s just plain ugly territory.

I hope that’s a bit clearer.

Leave a Reply