August 2nd, 2004, 10:30 am
Marine is right, to the extent that buy vs build is a function of your size and requirement complexity, so there is usually not the same optimum for everyone.If you need a lot of functionality, then you will end up writing a lot of the system anyway. Thus the first question may be how easy the system is to customise, coupled with whether you are tied to the vendor for these changes.At some level, you have to stop, and buy black boxes. This may be a trade reconcilliation module, regulatory reporting, bond pricing, or low level memory allocation. The trick to to know where to stop, and be wise enough to know that you will want to change more than you think at first.As a very broad rule of thumb, niche software is priced as a function of what it would cost to write the damn thing from scratch. What you are buying is not a big saving in cost, but (usually) a dramatic decrease in risk. Bought in components have a fixed price and time, ones you build yourself do not.You need to do some rough bounds on what the system can do. Some systems by their nature cannot give competitve edge. Others only get noticed when they go wrong. You need to identify a few paths and model what happens at (say) 1%, 10% and 100% differences to default behaviour.Thus a pricing system that runs 1% faster may be worth a million bucks more, or nothing more. What is 99% availability worth vs 99.9% ?What is the mean time to repair vs failure time ? Excel apps crash with depressing frequency, but they are usually easy to fix. OK for many pricing models, but you don't want your settlements to go into a loop of sending money to people. (saw it happen once).If you replace 75% of someone's job, can you sack them ? If you can't move the other 25% to another person, you have a bored member of staff, and an IT bill both to build and run the thing. Easy for this to end up costing more.If you can't pose and answer these questions for your system then you are nowhere near being able to make a proper decision anyway.A big problem is personnel risk.I did a piece of really, really horrible code a few years back. Got into all sorts of places. Really ghastly it was. The comment in the code is "you won't understand this, ring Dominic on XXXXXXXXX". Alas, BT have changed my telephone number This sounds like a risk of building it yourself. In this case not so, I did it for a software house who sold it to a much larger firm who then sold it all over the place. All the major (and minor) vendors do this.