Build or Buy?
When an organisation needs a new software system, should it build the system (possibly using contractors/consultants) og buy the system (as in find a suitable COTS solution)? That's one of those questions being asked all the time, and it's one those questions that - in general - can only be answered with "it depends...". It's also a question I'm faced with from time to time in my work, and the first answer is always "it depends..".
I watched this talk by Neal Ford on emergent design recently and about 3/4 through the talk he adresses the build og buy question using this diagram:
The diagram says the new system should only be bought if it is not strategic (i.e. not part of what differentiates the organization), if there is a fully functional candidate COTS solution readily available, and that candidate is extensible (i.e. provides ways out, when the solution is too constraining). Especially the first clause I find interesting. Everything that is strategic, and thus everything that is part of what differentiates the organization should be purpose build in order get all the details exactly right, so as to support and further the differentiation.
So in a build situation, then what? Well, often one of the early things done is to choose a framework to build on.
What Should a Framework Implement?
In choosing a framework the first thing to consider IMO is what you actually want the framework to cover. If you've already decided not to buy a COTS solution, then there must be some part of the system you think should be purpose build. On the other hand you dont want to build everything from scratch (e.g. if you're building a web app for renting cars you dont want to start by building a web server). You want to concentrate your efforts on the really value adding parts of the system. Those parts are the bits that set this system aside from all others (in the car rental example that would be the parts for selecting cars, handling special offers, making reservation and so on). These are the differentiating parts. So you want a framework that implements all (or most of) the things that are not differentiating the system. But only if it is fully funcitonal and readily available, and only if it provides ways out.
So I end up with this diagram for deciding whether a given part of the system should be implmented by a framework or purpose build: