Ok, so enough of all of the talk about the nuances of this principle. I've added so much content to its explanation that if I were to append these last three posts to the original explanation, no one would ever read it. So as I wrap this series of posts up, I'm going to sign off with some guidance around these principles. Concrete statements that may help to avoid the three confusion points I covered when I introduced this series. So here they are, with links back to the original post.

Principle: Prefer Packaged Solutions

Guidance:

1. Pursue a mixture of purchase, configuration and construction for a given tool or solution 
2. Rely on configuration where possible and building where unique and critical
3. Buy/ reuse as much and many times as you can, then build the rest

Putting it another way, Leo De Sousa shares some principles of his own on this topic. He's much more succinct than I am and they are right on the money.

Do these sum it up? If not, feel free to comment and provide some of your own thoughts.

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

... software solutions today simply cost too much to build and maintain for the end customer, and we now live in a market where the supply of quality software cannot meet the demands. In order to achieve that, several key pragmatic things must happen, compromises if you like, to meet that demand. Primarily, most software requirements need to start being standardised, and custom software requirements become the exception to the rule - not the norm.

- Jezz Santos,  InfoQ Interview on Software Factories

At the end of my previous post, I stated that "Prefer Packaged Solutions," or the "Buy vs. Build Decision," is really about pinpointing a project's Purchase, Configure and Build mix on the PCB Continuum. In this post, I'll discuss those three aspects as they relate to satisfying customer requirements (via the Requirements Continuum) and what building upon each aspect means both to our projects and our customers. 

But before I do, an editorial note: I stated in my last post that this entry was going to be about how both IT and our customers don't fully understand the implications of this principle and I have since realized that that's not entirely true and comes off a bit negative to both parties. The real key here is not whether or not we or our customers understand hidden implications of this principle, but that as IT, we communicate with them about what it means to purchase, configure, then build to create a solution that meets their business needs. On with the show...

Customer Implications of a Buy vs. Build Evaluation

Chances are, you've heard about the 80-20 Rule (or Pareto Principle) enough times to be sick of it. And while I sympathize, it's overuse is, I believe, a function of its power and applicability to most systems. Broken down into abstract cause and effect, the 80-20 rule states that 80% of the effects in a given domain are a result of 20% of the causes. According to the Free On-Line Dictionary of Computing, the 80-20 Rule is the "... program-design version of the law of diminishing returns. The 80/20 rule says that roughly 80% of the problem can be solved with 20% of the effort that it would take to solve the whole problem" (see http://foldoc.org/?eighty-twenty+rule). Since "effort" also means "cost" in the case of software, I like to extend this rule to say that a customer can obtain 80% of their desired functionality at 20% of the total cost. The real rub though is:

• Where the 80% lies along the continuum (in Configuration or Build);
• and, if 80% isn't good enough, where to stop;

So, as we architect a solution for our customer, how do we move to the right spot on the continuum?

Buying a Packaged Solution

It all starts with purchasing something. That something may be large or small, expensive or free. It may be done more than once (as I'll cover in my next post), but you're always "buying something." The key, though, is buying the biggest thing you can without wasting the customer's money. For example, if the customer wants basic document library and list services in their app, you probably shouldn't buy Documentum. On the other end, you shouldn't custom build a package that provides these services if Windows SharePoint Services is sitting on your servers. A bit simplistic, but you get the point.

Once you've determined the correct solution to buy, you can determine its ability to meet customer requirements out-of-the-box (OOB). By that I mean: if you installed the application and made it available to the customer with no changes to the app whatsoever, what percentage of their requirements would be met? Often this is a small percentage and, in many cases, the things that are met are requirements IT usually adds on behalf of the customer, like role-based user administration, ability to recognize AD accounts, security trimming and the like. However, requirements like a consistent Look and Feel (UI) and a baseline database schema upon which the application is built also figure into the calculation as these are things that tend to take quite a while when building an application from scratch. Understanding exactly where the OOB solution results in met requirements is essential to knowing the final mix of configuration and building because it establishes the starting line on the Requirements Continuum, as in the illustration on the left. My placement is probably a bit high for most bought solutions, but the intent is to illustrate that there will always be a gap between the requirements met with the purchase, the those still remaining. I covered this in more detail in my last post.

Here's where facilitating customer understanding of this principle comes in. After determining where the purchase lies on the requirements continuum, we've reached an important communication touch-point with the customer. While it's probably not necessary in all cases to give the customer a complete breakdown of what needs are already met (though we may want or need to), the key here is simply letting the customer know that there will be extra cost involved in configuring or building on top of this solution. At that point, it's time to determine how much configuring and how much building (if any) needs to be done.

Configuring a Packaged Solution

Since there is no such thing as a bought solution, you'll always find yourself along this portion of the Requirements Continuum. Even packaged solutions targeted to meet a specific business need like CRM, ERP or ECM cannot align to a specific organization because each organization performs the processes that drive those applications in distinctive ways. In some cases, these distinctions are small, as in "we prefer to use the term 'prospect' instead of 'lead' in our CRM systems." Sometimes they are a bit broader, as in "The lead form should capture lead source and some freeform textbox for entry of interests." In other cases, the distinctions are large, as in "When a content producer publishes a document, it should be approved in sequence by 4 separate individuals." However, in flexible systems (which should be part of our evaluation), these three requirements can often be met by configuring the existing system to provide this functionality. A mentor of mine often referred this to as Declarative Programming, because implementation of the requirement manifests itself by telling the underlying system what to do and not how to do it. Here's an example: In Microsoft Dynamics CRM 3.0, the modifications to the UI for lead entry form mentioned in the second requirement would be implemented by declaratively adding these fields to the form through the tool itself, as opposed to imperatively adding this information directly in the ASPX form, then wiring it to the database.

This product-supported configuration, as illustrated in the updated Requirements Continuum on the left, is where the bought solution is extended, based on customer requirements, until the upper-limit is reached, whether that be 80% of the overall requirements or not. 

At this point, the second customer touch point comes into play. The requirements remaining after purchase and configuration then becomes a list of extra functionality that might be a bit more costly than what has been accomplished so far. However, if the customer needs that functionality and is willing to pay, it's time we do some building.

Building to Extend a Packaged Solution

If you've reached this point, your customer has expressed a desire to obtain functionality that is only available by extending the solution with custom-built code or extensions. Harkening back to the 80-20 Rule, it's important for the customer to understand that these requirements are typically more expensive to provide than those that were met through purchase and configuration. Thus, this is where the final 20% of desired functionality starts to make up 80% of the total cost of the solution.

That's not to say one should never build. In fact, it may often be necessary to build at least something for the customer that they can't get any other way, but which they need. This is why our the "Prefer Packaged Solutions" principle, states that is acceptable to build "critical capabilities which cannot be satisfied by a purchased application." (see Part I for the full text) Thus, here we should guide the customer to select that functionality which is considered "critical" to the solution being provided. Oftentimes, these things are not only critical, but also unique to the problem domain or organization, as illustrated in the complete requirements continuum depicted above.

The challenge here, of course, is helping the customer understand the fine line between "must have" or critical and "nice to have" requirements. It's often vital to have workflow that works, but it may not always be necessary to have fine-grained control over the placement of form fields. However, uniqueness means that anything is possible at times.

To this point, we've covered the true meaning of the "Buy vs. Build Decision" (via the PCB Continuum) and the customer implications of that decision (via the Requirements Continuum). In the third post on this topic, I'll discuss the reality of multiple "Buy vs. Build Decisions" in a given problem space.

The Great Buy Vs. Build Debate - Part I

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.