In my job I often receive project proposals. These will usually say “we want to buy/develop in-house <x software> and get the IT dept to develop/install and support it for us.” Sometimes this is ok. Sometimes my IT colleagues will even accept that this is a good idea, but they are hard pressed so I have adopted the following heuristic approach and would be interested to see what others make of it. It’s a strawman.
So with the disclaimer under my belt: I always try to consider things in the following order of (decreasing) preference:
Option 1: Re-use something we already have
This works for a few potential projects. If the required functionality is already in an existing pience of software we have, why reinvent the wheel. Cheap, quick, and painless (assuming the fit is good for business requirements).
Option 2: Use a shared service from another related organisation
Again, this can work for a few more projects as there are (in my industry anyway) lots of very similar organisations working under similar constraints and trying to solve the same problem. Slightly more expensive (fees + network bandwidth), slightly slower to implement (politics, data sharing agreements, integration), but quality can be good and best practice can be shared. Also, it looks good.
Option 3: Software as a Service (“Public Cloud”) or Off the shelf remotely hosted software
Before you start flaming me, I know these are technically two very different things. But from my point of view they are equivalent. We need to do due diligence on whoever we are buying it from, there are security and governance concerns, there are performance and integration issues. But this can be good quality, quick, and relatively cheap. The G-cloud initiative should make this kind of thing easier, quicker and cheaper in the public sector.
Option 4: Off the Shelf, locally hosted
For many requirements this is still the default option. Always worth having a go to convert it to 2) or 3). Support arrangements can be a bind but we can normally deal with it. This option will always require some kind of interface with the people managing the desktop environment. This can slow things down but they are a happy bunch. I miss them (see options 1-3). We still need to do integration but because its inside the firewall its less stressful (SOA gurus might want to look away now and instead consider this rather cute video of a dog).
Option 5: Internally developed
ok, so we got to bite the bullet and develop something in-house. That means long timescales, resource conflicts, delays, long-term maintenance overhead, even using modern techniques. Most organisations the size of mine or smaller aren’t going to want to maintain an expensive pool of internal resource. There’s a slight edge to getting the solution hosted externally as it’s (slightly) less infrastructure to worry about and there are tools to help, although I’m not an expert on them – my colleague Stian Sigvartsen is better placed to advise on that.
And that’s all. I’m interested in refining, or even throwing out, this model out in favour of something better, if such a thing exists. For now this is just a common sense way of evaluating projects.
The longer-term question of what our target architecture should look like will have to wait for another day.