So far, I have discussed how the “Buy vs. Build” principle is designed to encourage teams to choose solutions based on their Purchase, Configure and Build mix, and to help the customer understand how our purchase decisions affect what requirements can be met and how. In this next section, I’ll discuss how the “Buy vs. Build” decision is a continual and iterative assessment as opposed to a one-time effort.

More than one Buy Vs. Build Decision Exists

Often the “Prefer Packaged Solutions” principle is assumed to mean that one should be on the lookout for a single software package that provides a close fit to our customer need. We then find the best thing, buy it and we’re on our way. But in reality, most IT projects, at least at Compassion, are a bit more complex than that. The problem may walk like CRM, and it may talk like CRM, but oh, they need Digital Asset Management as well. On the other hand, buying a full-stack package might be overkill when the customer just wants to track conversions from the web. Buying a single packaged solution often just doesn’t cut it (no matter what the ECM vendors tell you about their shiny hammer). As a result, I believe that the principle is best applied when we buy as much as we can (but not too much), and build the rest. Let’s consider two scenarios…

Horizontal and Vertical Purchases  

Sometimes, teams find themselves in a situation where the best purchased fit for their business need includes laying a piece of infrastructure which has yet to be purchased. If that happens (and when it rains it tends to pour), said team now has the pleasure of laying some infrastructure. I’ve heard this referred to “taxing the project teams” and I will say that it’s a known pain point that we’re trying to fix. Let’s hope we do so before someone breaks out the tea. However, even if said infrastructure were already in place, a project team “buys into it” when they choose to invest their vertical and their goodwill into that platform. Thus, a purchase decision is still being made, even when the purchase is in the form of reuse (which is the best buy decision of all). 

Were we to follow the “letter of the law,” we could say that we’ve purchased something for our project and go on about our business. But this leaves out the vertical business need… your real purpose for being a project  in the first place. If we simply check the box that says we’ve bought something and move on, we miss out on an opportunity to explore reusable and packaged options for the vertical (From ISV plug-ins on a platform like MOSS to domain-specific guidance and recipes built on top of a Software Factory). Granted, verticals tend to be domain-specific and a bit harder to pin on a tool, but as I said in my last two posts, I believe that we have an obligation to asses our purchase and configure option against the customer’s requirements (along with them) to determine if we really can find a fit on their vertical. I think that software is moving more and more up the vertical in any case and am finding that we have more and more reasonable purchase options at our disposal.

Assembling a Package

The other scenario, which happens less likely now but will become more prevalent over time, is when requirements dictate a solution that can’t be met with a single purchase, but for which several partial solutions are available (all over the PCB Continuum). It’s in these cases where maximizing what you can build has the most power. Here’s an example: we are currently working on an effort to provide an “Offline” capability for a select number of business critical applications so that they can perform critical work when they lose connectivity to the WAN. This solution has some typical requirements, like local storage and synchronization, but it also has some requirements around remote workflow and collaboration which complicate the issue a bit. I have spent some time this week assessing a series of tools which could help meet these needs and have found, as expected, that there is not a vendor out there selling “Compassion’s Offline Framework 1.0.” Instead, I think that the solution chosen will end up being a mix of a few packages, some configuration and some construction by a development team (the sync engine seems a likely candidate).  To help illustrate this to the team involved in gathering requirements, I created the chart to the left (you can click it to enlarge) which illustrates each of the 15 options on the draft list (within their area of primary functionality) and placed them on the graph in such a way to illustrate how much of a “buy” we are getting and how much that option meets our requirements. The point I hope to illustrate to those involved is that there is no single package for this problem, but that we don’t need to build something from scratch either. As a happy medium, I believe that we can compose a solution from some key complementary technologies on this graph. We would start by going off on a spike or two and really vetting some of these out, of course, but I think that we can come up with a framework that can be leveraged by all of our current and future applications needing an offline capability.

In both scenarios, the common thread is that preferring packaged solutions means we prefer to buy as much as we can, then we build the rest. And the common thread through all three of these posts is that “Preferring Packaged Solutions” means that as stewards of the mission of Compassion International, we have a responsibility to use our resources (money, people, talent, etc) wisely. This doesn’t mean we don’t build, it just means we target building to those areas that are unique and important to our customers. We have very talented developers, so we have the resources to build. The problem is, they’re overloaded and they end up being supplemented with contractors who often get to do the “fun stuff” that they ought to be doing. If we apply this principle well (and I think we do oftentimes), those guys and gals will get to build where it counts and really make a difference in the solutions we deliver to our customers.

One more brief post to recap and sum up, and then on to other vistas… 

The Great Buy Vs. Build Debate - Part I

The Great Buy Vs. Build Debate - Part II