The team I work on at Compassion created a document a few years back called Compassion’s Corporate Architecture Principles, or CAP. This document consists of a series of high-level principles meant to encourage IT development teams to consider the enterprise when they develop a solution to meet their given business need. Our team, the Architecture Office, or AO, reviews each project during elaboration (most of the time) and evaluates said project against these principles to determine if it passes muster. One of the most oft-discussed principles these days is “Prefer Packaged Solutions.” Here is the statement:

Compassion should “build” only those applications that cannot be purchased or that can be shown to offer critical capabilities that cannot be satisfied by a purchased application.

 

Even though these principles were adopted before I joined the AO, I like this one because it is intended to encourage Compassion IT and its development teams to pursue reuse at the highest levels possible (i.e. entire packages, services and modules rather than simply “code reuse”). If possible, teams are encouraged to buy an application (or set of applications) which meet the business need of their customer. This statement is clear and even includes the criteria in which building is acceptable (”critical capabilities which cannot be satisfied by a purchased application”). Rhetorically, we refer to this principle as the “Buy vs. Build Decision.”

Call me a biased architect with visions of Composite Applications running through his head, but I think that this principle is one of the most important we have. However, this principle is often minimized, misstated and mostly misunderstood, and I think that happens for  several reasons: first, there is no such thing as a pure “buy” solution; second, both IT and its customers don’t fully realize the implications of this principle; and third, most IT teams are faced with more than one Buy vs. Build Decision. I’ll elaborate on the first in this post and will cover the second and third in subsequent posts.

No Such Thing as a pure “Buy” Solution

When considering the “Buy vs. Build” principle, both managers and customers tend to get the idea that they are buying a met business need once the check is signed, when this is hardly ever the case. Instead, purchased solutions usually must be configured to meet the business need (skinning, adding modules, populating data, etc.), enhanced via custom code or other custom development, or both. I refer to this as the Purchase-Configure-Build (PCB) Continuum, which is pictured on the left. Most of the time, the closest you’ll get to a bought solution is one you purchase, then spend additional money configuring for the customer (This means that the purchase price is not the final price, by the way). The no-mans land is the 100% build, which is today’s age of frameworks like .NET and Java pretty much isn’t done by anyone’s definition. Between the two is a combination of purchasing, configuration and building that results in a met business need. Let’s look at an example in Microsoft Office SharePoint Server 2007 (MOSS) and Windows SharePoint Services 3.0 (WSS). WSS 3.0 is a site-provisioning engine which provides basic content and document management services to users via SharePoint sites. WSS is also a development platform upon which developers can configure and construct solutions using documents and lists, WebParts and Workflows that leverage Windows Workflow Foundation (WF). MOSS 2007 sits on top of WSS and provides a series of value-added extensions to WSS like site federation, search, Forms Services, out of the box Workflows, etc. The image below illustrates where each of these lands on the PCB Continuum. Obviously, WSS by itself can be leveraged and extended to meet  a business need, but doing so often requires plenty of configuration, development and administration. A tool like MOSS is designed to minimize the cost of those customizations by providing extra services which IT may leverage, thus it sits more on the buy side of the continuum. But it’s not all the way on the buy side, again because no bought solution can ever completely meet a customer’s business need.

Because a continuum exists between the purchase and construction of a given solution, it’s never so cut and dry that we can simply check a box and say that we’re buying this time, or not and say that the customer’s needs are too unique. The Buy vs. Build Decision is oftentimes a mix of what can be purchased for a customer (i.e. WSS for web-site hosting and basic collaboration) and what must be built in order to satisfy their business needs (i.e. Custom approval workflows) and it’s the job of the AO and the Governance process to ensure that an appropriate mix is pursued. We’ll see more on the complexity of that decision and its implications in the next two parts.