Buy vs Build

 Please note that the views expressed in this post, along with the rest of my blog, are my own and do not reflect the views of my employer.

 


Anna’s article on the issues being faced by the organisation she has been working with where the directive is to buy, not build, but where the buy decision is clearly not right.  There are a couple of principles that either organisations at a board level or IT Departments at an Enterprise Architecture level are applying that I fundamentally disagree with, and the principle of ‘Buy, not Build’ is one of the worst.


A solid architectural principle is to buy before reuse, and to reuse before build.  This principle enshrines the concept of reuse and avoids building code where a more cost effective option exists.  It is a core principle that I always use in architectural design.


There seems to be such a push towards the use of COTS products – not in a buy, reuse, build metaphor, but in a buy only metaphor, as Anna outlined in her article.  This is wrong on so many levels, and yet is being implemented in a number of major Australian firms at the moment, and I have no doubt is being replicated across the globe.



COTS products offer a quick path when, and only when, the following are true:


  • The product has a very close fit for your requirements; and
  • The product can easy be configured to meet the remaining requirements; or
  • Your processes can be easily configured to meet the product.

In some rare cases it may be possible to extend the COTS product through a separate, but linked, system.  Anything else, such as complex customisation of the COTS system to allow it to meet the requirements should not be undertaken as it will make future upgrades of the COTS product near to impossible.  This results in the worst of both worlds and is far worse than building the system in the first place.


The other option that I commonly hear today is that the organisation is so set on a COTS product that they decide to change their business to suit the product.  Now, I’m an Architect, not a COO, but I really struggle to see the sense in this.  It is simply unworkable on a number of levels:


  •  The cost of changing business processes is generally greater than the cost of developing software;
  • What may be an optimal business process for a COTS product may be common for an industry but is highly unlikely to suit the complexities of each organisation;
  • There is little or no room left to change business processes either because they may be sub-optimal or because the business or market conditions change.

So what is the alternative?  Well, buy-reuse, build is the alternative.


When I think of buy and reuse I think of components, not monolithic systems.  In some case a large system may be a good fit for common and simple processes, but a better option is to buy components and integrate them in an intelligent manner using an integration layer.  SAP and Oracle understand this architecture and are componentising their systems to an increasing degree in response.  This is not to say that I don’t advocate the implementation of a large COTS system, but only where the system is a good fit for the organisation.


Now, the other thing that most organisations, and even many Architects, fail to take into account, is that the cost of building software is dramatically falling – especially on the .NET platform.  Changes to the language, the IDE and advancements such as domain specific modelling languages and MDA are resulting in the need to build far less code (by around 50%) than even a couple of years ago.  The use of workflow tools in the architecture, such as Windows Workflow Foundation or BizTalk Server, can result in a system that is flexible to business change.


Given the rapidly degreasing cost of development, matched with the ability to closely meet requirements, I would suggest that a build option is well and truly worth considering, rather than blanket C-level decisions to implement COTS systems without at least assessing the options, relative advantages and costs.


In fact, given that I’ve been in the industry for quite a while now and have seen fads come and go I am sure that this leaning towards blanket COTS implementations is a fad and those organisations that go down the fad route wil be reversing the decisions at a far greater expense in the future.



See also:


The Microsoft Event of the Year

My wife and I were lucky enough to attend THE Microsoft Event of the Year on the weekend, and it wasn’t TechEd.  Yes, that’s right – it was the XBOX 360 Waterballoon Challenge.  We had an awsome time, and somehow managed to stay mysteriously dry, even though we were in the thick of it all, looking for trouble.  Odd.


Not sure that either of us managed to hit a single person from the other side (we were on the Green Team) and I’m pretty sure that every water balloon managed to get either (a) someone from our team or (b) someone that wasn’t even in the playing field, like those pikers that sat outside to watch rather than joining in.  If you look at the pics of the big XBOX 360 logo I’m sure you can see us – right on the top right hand point of the first X….


It was a blast.  Got our shiny new copies of PGR3 and Kameo.  Now all I need is a 360.

ASWEC 2006 – Yay, I got an award!

Well, ASWEC has just finished. This was the Australian Software Engineering Conference. You most likely won’t have heard of it as it is pretty small, but I thoroughly enjoyed it. It has papers from academia and from industry on software engineering and is vendor-independent. The quality of presentations was very impressive, and they were all engineering, rather than product focussed. I was lucky enough to receive an award for ‘Best Industry Experience Award’ – in other words, best presentation from the 14 presented by people from organisations as opposed to those from universities. The paper was “Large Scale Integration Design and Management”. Yay. I can recommend that anyone interested in architecture should attend the next one – after easter 2007.


 


Thanks to Anna too for her kind words…

So Why ‘Yes, But’?

Well, it came from a conversation at the MVP Summit in Redmond Sept 2005. The comment was made that more information is needed for Architects to show how technologies should and shouldn’t be used. This differs from the common marketing-focussed documentation that is generally available. The need is for this kind of ‘Yes, but’ documentation then, but this kind of information is best provided by MVP’s and other ‘external’ people. That therefore is one of the aims of the Blog – to provide the ‘Yes, but’ documentation.