The rate at which .Net advances and improves is fantastic. Everything from LINQ to ASP.Net MVC via F# and parallel programming advances. The roadmap for on-premise and cloud computing shows that the future will be far from dull. Alongside the platform, the core Microsoft server products, such as Windows and SQL Server, are also advancing very favourably. Beyond Microsoft we are also getting ever more fabulous tools and frameworks ranging from ReSharper, Inversion of Control and Aspect Oriented Frameworks to Mocking and Test Frameworks. Around all of this, maturity is growing in Test Driven Development, Continuous Integration, Domain Driven Design and a whole range of Agile delivery methods. There is a growing reality of custom building solutions with repeatable success, considerable flexibility and quality that exactly meet the needs. Good times indeed.
What's my point? With such continuous and powerful advances being made I think it is time to re-evaluate many of the Build vs Buy decisions made a few years ago and maybe reset some of our defaults. Now I am not saying that something so radical has happened that the pendulum has decisively swung towards Build. However, I do think it has moved in this direction and I am expecting this to bring pressure on Product vendors to respond. That goes for Microsoft too who are ironically instrumental in handing the builders this power. You may argue that this power is also available to the product vendors, but too often I don't see that materialising. Maybe this is just the lag between harnessing the power and shipping products. That's me being generous.
No longer can products rely on (or even hide behind) arguments such as vendor support, upgrades and a resource pool of trained professionals. More than ever the products are lagging much further behind the technology curve, don't deliver exactly what you want and often represent significant compromise. Where the product contributes to the market differentiation of your business proposition it has to be super compelling and leading edge.
For example, some of these may resonate:
- How long do you have to wait for a product to take advantage of SQL Server 2008 - not just "supported on" or "compatible with", but actually exploit it?
- How long before the product adopts an architecture that better reflects how you want to deploy it in a Virtualised data centre - and changes its licensing to make sense?
- How long before it recognises that at scale might mean a large cluster of commodity hardware - e.g. a web farm of 50 pizza boxes each with their own local web and instance of a federated and co-operating database?
- How long before the product caters for and exploits the emerging and different Cloud computing platforms?
- How long before it truly exploits multi-core developments and has parallelism built right into its fabric as opposed to just using ubiquitous multiple cores as a means to extract more licensing?
- How long before the product is architected and licensed to match your increasing need to deploy for high levels of availability and business continuity? This is a regular expectation not an extraordinary demand.
In summary: Development platforms, methodologies and tooling is aggressively getting better and looks set to continue. This is certainly shifting the balance of power in the Build vs Buy argument towards Build. This should put pressure on product vendors to demonstrate clear advantages ("value-add") and more aggressive roadmaps; they have no excuse not to because they should be harnessing the same power! The Build vs Buy balance of power should remain mostly in equilibrium except during periods of arbitrage during the time lag when advances in the core technologies are harnessed by vendors. The ideal is to spot arbitrage and exploit it, or mitigate it. Right now, builders have the opportunity to make market share whilst vendors have the opportunity to leap frog competitors whilst ensuring they invest so as not to lose market share to builders!
N.B. Taking true advantage of these advances puts more emphasis on smart, skilled and experienced people.
I know. I ramble.