To build or not to build? Or buy or switch to SaaS…Almost Shakespearean question about IT applications

Time passes by but one of the oldest dilemma in IT keeps getting more complicated as new options emerge. Should you license a commercial enterprise application that looks like to meet 75 % of your needs? Or would it be better to build your own application that suits you as much as possible?

Through years of trials, errors and analysis a consensus conclusion has been crystallized out: “Buy when you need to automate commodity business processes; build when you’re dealing with the core processes that differentiate your company.” But have reality ever been so orderly? Afraid no. In fact companies face a lot messier and more interesting choices.

Build-versus-buy decision factors are as follows: cost, time to market, politics, architecture, skill sets, and strategic value. Commercial software may boast shorter time to market and lower maintenance costs than big in-house development projects. Complicated homegrown systems may handle difficult and specific tasks. The third character on the stage is SaaS, their offerings may also fit the strategic plans of an enterprise. So, what’s better?

“As vendors saturate the market from general-purpose CRM to the narrowest vertical solution, the economic pressure to buy and consolidate (or subscribe and let a SaaS provider deploy and maintain) continues to mount.” When time-to-market and money are top priorities IT execs evaluate commercial software first. No doubt the more standardized you are and the more you buy off-the-shelf, the more cost effective it will be for both implementation and ongoing maintenance.” Here it’s extremely critical to thoroughly understand total costs during the software lifecycle, typically 7-8 years, due to the fact that 70 % of software costs occur after implementation. Very often an in-depth lifecycle analysis that realistically estimates ongoing maintenance by in-house developers tips the balance in favor of buying.

On the other hand, executives from MCI, for instance, say: “Where we tend to invest is where we can get incremental revenue … or competitive advantage.” Many modern enterprises have recast their in-house development efforts within an SOA, enabling them to reuse rather than build from scratch. “Part of the decision is to look at your legacy applications and analyze what legacy you have that still has business value.”
Also the build decision has to be taken when the solution should be of such strategic and specific area to the business that commercial apps never enter into the discussion. In this case it’s better to follow agile development methodologies that allow you keeping cost down.

Now it is definitely to the point to talk about open source that enables a hybrid approach combining purchased and custom-built components. It’s sort of “getting the best of both worlds [of buying and building]”, as they say at Visa.

Still as far as open source is concerned there is the thing you should keep in mind. Although open source implementations invite all sorts of customization, ERP wars of the ‘90s have taught a clear lesson: When it comes to commercial software, avoid hacking the system when possible. The advice from MCI execs says to rather adapt your business processes in the not-unique areas (e.g. sales, financials, etc) to off-the-shelf software.

As an alternative to customization you may also turn to aftermarket products, like plug-ins, for instance. Try to avoid touching the main package and it will keep your maintenance costs down.

If to speak about SaaS, such kind of vendors typically lets customers pick and pay for functionality in modular fashion, versus licensing packaged software functionality. Additionally, SaaS incurs no hardware or software capital investment and so drives maintenance costs lower.

Lately market situation has also pushed some commercial software vendors, such as Oracle, SAP, and Siebel, to stick to the approach makes the buy decision more viable. This is possible due to using SOA, because in SOA business processes are broken down into coarse-grained application components, which begin to be standardized, commoditized and offered individually.

Personally I believe in IT world the majority of companies, especially large ones, use a wild mix of all these approaches and the line between build and buy is blurring more and more with the course of time. And what is your experience? What factors and conditions determine your choice in favor of this or that approach? I am very interested in hearing your point of view on the topic.
Thank you in advance,