Build vs. Buy becomes SaaS vs. PaaS

In the nascent years of Distributed Computing, a whole industry emerged; COTS. Off-the-shelf applications, or "commodity" programs became available. Due in large part to the ubiquitous nature of the x86 platform, sales of “shrink-wrapped” programs saw a volume large enough to support the creation of thousands of new businesses.

At the same time, the liberation of PCs by end-users created a whole class of what futurist Alvin Toffler called “prosumers.” Business professionals, armed with new software were suddenly producing and consuming their own applications. The promise of COBOL, which never REALLY trickled down to end-users was realized by spreadsheet macros and simple database programming languages like dBase II and its variations.

The upside was that suddenly, accountants, financial analysts and small business owners were no longer limited to the inflexible apps offered by Service Providers or “Data Processing.” Applications could get as granular as one’s imagination allowed. The downside was that business professionals, unaware of the reason for the existence of policies and procedures crafted highly complex undocumented monstrosities, whose underlying logic was understood only by themselves. A few horror stories about low-level staff leaving a company with now mission-critical apps unsupported and unmodifiable(without possibly calling in expensive consultants) led to a pendulum swing back toward putting application development and maintenance in the hands of trusted professionals.

Data Processing evolved into “Information Technology” dragging with it numerous “rogue” networks and homegrown apps to be “tamed” by the pocket-protector crowd.

Yes, responsibility for application development and maintenance returned to the glass house, but the genie was out of the bottle. Lines of business were no longer placated by cookie-cutter apps which did 70% of what they wanted. Departments DEMANDED that their applications met the specific needs of their business units. Sometimes they got their way. Other times, they didn’t.

In those days, the conundrum of “build vs. buy” pitted members of committees against one another, each side arguing over scarce resources (analysts, programmers, etc.)

Fundamentally, the question became one of how well an off-the-shelf package (or one that was SOMEWHAT customizable) would satisfy the needs of the organization.

A rule of thumb emerged, suggesting that applications which affect the CORE processes (those that differentiate the whole organization from competitors) would get preferential treatment, and those CONTEXT (non-mission-critical) needs would need to make do with a “best-fit” more economical solution. Geoffrey Moore is credited by most at the “Core vs. Context” guy. Reading his “Dealing with Darwin” will fill in the blanks if you are unfamiliar with the concept.

Of course, what is Core and what is Context can be argued indefinitely, but ultimately the “C” level folks decide what is best for the organization as a whole.

In a previous blog, “Déjà vu All over Again” I discussed how many of the fundamental issues facing IT in the past are resurrected when applied to Cloud Computing. The same issues which faced internal Data Centers making “build vs. buy” decisions are reflected in the SaaS vs. PaaS debates which replaced them.

At the end of the day, the only distinction is where the apps are running. The choice of a static (or marginally customizable) web-based application vs. a built-to-spec program running on a platform like Azure or Force.com creates the same types of debates.

I’m afraid I am not in a position to offer any advice on which approach is better. As in the past, this depends on what upper management regards as “Core.” For those end-users reading this, you might surmise from what model is chosen to support YOUR day-to-day activities, how your department is viewed from the top.