One of things that Mads is at pains to point out in the construction of BlogEngine.NET is that it contains no 3rd party components (actually - he is being specific about assemblies as in fact BlogEngine does contain some JavaScript for a rich text box). There's some intelligent discussion in there about whether this is a good thing or a bad thing. Of course, this is an old hobby horse.

I think architects have a responsibility ensure that managers and developers can understand a strategy for the construction of a solution and why there may be different types of costs and decisions for a solution. Here I'd like to try and describe a general model that may work for you when considering these decisions. It's just an idea (although I have put it to practical use previously) and of course there are many levels of subtlety. Think strategy.

First of all, we need a model for evaluation of technology in terms. Let's try the following phases:

• Invention. This phase is when an idea is being invented, when there are few, or no precedents and limited standards, or limited implementation of standards.
• Innovation. This phase is when an idea becomes more accepted and there are several precedents and examples but the original idea is still being explored and developed.
• Commoditise. This phase is when the idea is well-established and solutions comprising the idea are readily available for implementation.
• Redundancy. This phase occurs when the idea is no longer a single concept, but is an expected component of a wider solution.



 

To illustrate the model let's consider blogging:

Blogging was invented a couple of years ago with a bunch of people effectively 'posting' HTML articles to a site with the appearance of a diary, or perhaps a wiki. As the idea took hold, standards were developed such as RSS, and nomenclature and de facto standards (feeds, Metaweblog API) began to appear enabling interoperability and continued innovation of the principles of blogging. Commoditisation occurred as services such as Wordpress and Blogger began to appear, and hints of redundancy are beginning to occur as services such as Facebook, and products such as MOSS roll the concept of blogging into larger concepts.

So then, let us consider two possible options for procurement of a needed component for a solution:

• Build. This method is the development method. Roll your own.
• Buy. This method is the find an open-source widget, or some other 3rd party component. (I use the term 'buy' but clearly you're not buying OSS).

Both of these options cost something:

• In the case of build, then the cost is the physical development effort, the ongoing support costs of the development and there is also a likely hidden cost in that any build is designed to achieve results quickly for a given purpose so rigidity may set in more quickly than a generic component.
• In the case of buy, then the cost is the licensing, the evaluation and learning, and ultimately the vendor lock-in (including OSS).

So, given the nature of technology development I'd assert that typically it would be RELATIVELY cheaper to 'build' VERSUS 'buy' in the Invention phase, and this trend reverses as we move towards Redundancy. Let me repeat, there's probably nothing cheap about inventing something, but it may be just as, or cheaper to do-it-yourself in the invention phase. There are many caveats in this: for instance, bought products may become more expensive as the core idea is extended well beyond required featureset, but our interest here is defining a generic strategy.

So, where's the balance, or the contention? Again, I'd assert that this occurs somewhere in the Innovation phase. At this point, established solutions are available, and the idea has been extended so featuresets are likely to cover the requirements so 'buying' is a valid option. But, as standards are not available, or implementation methods are being debated then it could be attractive to 'build' too.

How, then, to decide what to do? A matter of some debate of course, but based on the model, and the cost aspects we've defined, then some simple guidance could  be formed of the sort:

• On build:
  • Is the component covering a function that could be considered 'domain-specific'? In other words, are my analysts and developers likely to understand concepts and design a 'better' product than another development team.
  • How quickly is the technology likely to commoditise? If it's a niche requirement, then it may not.
  • Am I going to (genuinely) re-use the component on other projects?
• On buy:
  • Vendor assessment. Is this a 'live' technology? How active is the development community? The licensing and ongoing costs require assessment too.
  • Is the technology going to commoditise? If so, then the development community may die out as interest in innovation is lost.
  • How stable is the solution I'm integrating the component with? If it's very stable, I'd prefer a low-risk, commodity solution.

I've found this a useful definition of an overall strategy which can work effectively when explaining solution design to developers, or explaining costs to managers and of course removing the emotion from this decision making process.