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: