... 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