Buy versus Build

I had a very interesting meeting with some customer architects recently, who are in the middle of evaluating packaged applications for running their core business. Essentially their requirement is to store/operate upon/retrieve realtime information about their assets and their clients, and some automated way of mapping the two. There are obviously a lot more business rules details that I am deliberately leaving out, but you get the idea.

They currently are running a monolithic application that pretty much serves up all their business needs. Unfortunately, this monolithic app is rather dated (green screen) and they've got the go-ahead to replace it with something more modern.

Should be exciting times right?

well, they've several options and challenges:

- upgrading the current software will cost far too much (eg. hundreds of millions of dollars), and the upgrade process will be long, and is seen as high risk.

- there is no other single app out there that will serve all their business needs, hence they need to look at acquiring more than 1 packaged application (possibly 3 or 4), and then build the integration and possibly additional custom bits to complete the picture. They recognise that the integration is not going to be trivial, but it may be their only option.

- their business is not unique in the market. However, upon visiting other similar organisations, they found that the market leader (and also pretty much the sole provider) for supplying this sort of software and service is having trouble delivering in another similar organisation - after 3 years of working at it. Hence the reluctance to approach this provider.

- The business has a good handle on their business processes, and the requirements from the end user and business perspective, however they do not have the developer resource to do the development completely in-house. It is also the governing authority's mandate that they should buy rather than build.

So, they're stuck.

I wish I have a better answer for them as an architect, it is unfortunately a problem that I see over and over again in various enterprise organisations, where due to various organisational, governance, HR issues, they cannot simply go ahead with the most optimal/technically sound approach to solving problems. And no single technology here will help them either, it is really a much wider enterprise IT strategy problem they're facing.

On the other hand, I'm thinking maybe it's time we as technical leads/architects challenge some of these 'assumptions' that our work environments impose on us... eg. do we must buy before build? why can we not invest in good design and development resources such that we take greater ownership in our own IT projects? is outsourcing IT really a cost effective way of doing things? Fundmentally, it's me that really care about my own system right? the outsourcer is simply doing whatever they are asked to do, and in order to guarantee quality service and anticipate unexpected contingencies, they will simply need to charge me an arm and a leg?