Reuse, Buy, or Build: Components and Services

Simon Thurman
Microsoft Corp.

Phil Rowland
Capgemini UK P.L.C.

June 2009

Summary: The purpose of this article is to highlight and discuss the considerations that are required to make the appropriate choice among reusing, buying, or building components and services.

Contents

Introduction
Definitions
Assessment Structure
Evaluation Framework
Forces
Balancing Act
Services
Conclusion

Introduction

Let us begin with a simple statement: All things being equal, the choice should be to reuse, buy, and then build components and services in order to deliver the required solution to the business. But not all things are equal, and that is the purpose of this article: to highlight and discuss the considerations that are required to make the appropriate choice.

Of course, this is something that all architects have been doing forever—albeit, probably with a view on fine-grained software components. What we want to do is clarify that choice for solution components and test whether it is applicable to the world of services.

In order to explore this subject in more detail, we have identified three areas that we think are worthy of discussion: an Evaluation Framework, Forces, and a Balancing Act. Because it is something with which we are all familiar, we will look at these in the context of components first. Then, we will move on to test whether the same thinking can be applied to services.

At the outset, we will make the assertion that ultimately it is a business decision—not one of technology.

Definitions

Here are the Oxford English Dictionary definitions of “reuse,” “buy,” and “build”:

Reuse—“The action of using something again.” In architectural terms, reuse can mean different things to different architects.

For example, it could mean reusing an entire existing IT solution by creating another instance of it to satisfy some other business requirements. Alternatively, it could mean that a number of solutions use the same functionality that is contained within another solution to satisfy parts or all of their requirements.

Buy—“Obtain in exchange for payment.” In architectural terms, the buying of packages has been commonplace for many years. For the purposes of this article, buyrefers to the procurement of a software component or service.

Build—“Construct by putting parts or materials together.” For the purposes of this article,build within the architecture community could be misleading to some. Therefore, build in this article relates to the development of a bespoke solution by using software-development tools and methodologies.

Assessment Structure

We think that the considerations and decision to reuse, buy, or build fall into the following categories: strategic, operational, business, and technical (see Figure 1).

Figure 1. Consideration categories (Click on the picture for a larger image)

Strategic considerations, which deal with the long-term vision and direction of an organization. How things should be without the external influence of other factors. These include:

• Market share and differentiation.
• Growth.
• Strategic change management.
• Managed portfolio.

Of course, there are other factors that determine the path that a decision can take. These fall into the operational category and include:

• Governance.
• Change management.
• Skills.
• Support and maintenance.

Alongside the strategic and operational considerations, there are those that fall into the business and technical categories. The business considerations are the ones that support the short- to medium-term objectives of the business. These include:

• Delivery and running costs.
• Contract management.
• Depreciating of assets.
• Internal or external provision.

Most organizations have a technical strategy—one that states what technologies can be used and for what purposes. Considerations in this category include:

• Technology choice.
• Interoperability/Integration.
• Repository of assets.

While it is important to understand the higher-level considerations that affect the direction in which the business goes, it is probably more valuable for our purposes to explore a little deeper and identify the lower-level considerations. In order to do so, we have created an Evaluation Framework.

Evaluation Framework

The Assessment Structure offers a classification for the types of considerations within the context of the business. Now, we want to move on and examine the elementary considerations:

The Evaluation Framework identifies seven attributes that influence the sourcing decision. These are delivery time, complexity, cost, maturity, requirements compromise/match, maintenance, and support. Our hope is that the choice of words provides sufficient explanation of what we mean; therefore, we will not discuss further.

However, we do believe that it is valuable to discuss the entries in the considerations column. The idea here is to identify the high-order factors that should be considered when making the decision. It is also worth noting that the specific consideration might not be unique to the category with which it is aligned. So, for example, we recognize that governance is also a consideration when buying or developing an asset, but we believe that it is of higher-order importance when thinking about reuse.

In the reuse category, governance, consolidation, and culture are the identified priority considerations. Governance covers such areas as ownership of a specific business capability and data within the business. The owner can be thought of as the custodian of the asset who handles such things as change requests to both functionality and data. Identifying the owner should not be underestimated; this might prove to be a very difficult and challenging task and fraught with politics. The policy that describes the motivation and execution of the reuse strategy would also come under governance.

Consolidation describes the desire to minimize the number of assets that deliver similar functionality. This might be to achieve a variety of outcomes that range from reduction of overall cost to delivering data sources that present a single version of the truth. In order to be executed successfully, consolidation has strong links with governance.

Finally, there has to be the correct culture within the organization to achieve success when looking to reuse assets. This might result in the ability to compromise in order to meet the greater needs of the business, instead of completely fulfilling the needs of a specific project.

In the reuse category, it is also worth stating that some development effort might be required in order to achieve reuse of an asset; that is, it is not simply a matter of reusing an asset and, therefore, completely ignoring the other categories.

Integration and customization are the high-order considerations within the buy category. Integration is probably self-explanatory, when selecting a component to reuse it has to integrate with what is already in place and what is planned for the future. Particular attention should be paid to how interoperable the asset is.

It is worth remembering that interoperability makes integration easier. Of course, integration is not only a technical consideration; it refers also to other areas, such as people, processes, and tools.

Beware of customization. A high degree of customization can eliminate some of the benefits that are allocated to the buy category and can introduce new disadvantages.

Again, as with the reuse category, it is highly likely that some development effort will be required when buying an asset. The amount might well depend on how interoperable the asset is.

Finally, the build category has skill and core as its two high-order considerations. Skill refers to the expertise that is required to develop an asset. This might be a simple binary decision: Do you have the skill or not? Of course, the answer to this question might not necessarily eliminate development as an option; there are alternative approaches, such as off-shoring. However, that is probably a different discussion. So, for the purposes of this subject, the decision might be somewhat easier if there is no skill.

If the business capability that is to be implemented is core to the business—that is, a differentiator—it is highly likely that the build category is the favored or only approach. It is worth noting that core does not automatically mean business-critical or vice versa. A capability could be considered business-critical, but not core to the business; a human-resources function might well illustrate this point.

We did consider including a fourth category, which was a hybrid of two or more of the categories. This is something that happens quite regularly within specific industries. For example, it is quite common in the oil and gas industry for two or more competing companies to develop something together and then reuse it among them. There is probably a lot to learn from these sorts of activities, although it falls out of the scope of this paper for us to discuss here.

In all of these cases, it is important to recognize the impact that these considerations will have on the ultimate decision, and that classifying them in this way provides a mechanism to ensure that an objective approach is applied to the selection process and that opportunities are not hidden from view.

Forces

Of course, there are other forces that influence decisions. We refer to these as the pushing and pulling forces, but some might consider them to be drivers (see Figure 2). These forces pull and/or push solution decisions in particular directions; while some might see it as less than ideal, this is unavoidable.

Figure 2. Pushing/pulling forces, or drivers (Click on the picture for a larger image)

Each set of drivers can be considered unique to an organization; typical example drivers are as follows:

• Cost—The drive to remain cost-neutral or, more likely, more profitable—for example, affordability, return on investment (payback), and finally the cost implications of not doing it.
• Quality—The drive to achieve an outcome that meets or exceeds the quality expectations of a customer—for example, 99.999 percent availability.
• Time—The drive to be first to market to help differentiate from competitors.
• Sustainability—The drive to reduce energy consumption and improve the carbon footprint of an organization.

The intention of these and any other Forces that an organization identifies is to ensure that they are Simple (that is, make sense to an organization), Measurable (that is, an organization can recognize when it has been met), Achievable and Realistic (that is, it is within an organization’s gift to make it happen), and, finally, Timely (that is, it can be delivered within an agreed timescale). A good rule of thumb is to ensure that each chosen Force is SMART.

Balancing Act

Ultimately, any solution decision that is made by an architect is often a balancing act (see Figure 3) among the seven attributes, the high-order considerations, and the forces.

Figure 3. Depiction of balancing act (Click on the picture for a larger image)

It will come as no surprise that we do not believe that there is a silver bullet whereby an architect can feed in all of these inputs, turn the handle, and out pops the answer; neither do we believe that any of these three has a higher priority than another.

So, where does all of this leave us? As with any decision-making process, we believe that it is important to ensure that solution decisions are transparent and clearly communicable and understood by those who need to know and must buy into them. Our approach has led us to the conclusion that use of the Evaluation Framework,

in conjunction with an appreciation of the organization’s Forces, provides a simple evaluation tool for architects to use to provide a balanced proposal.

In no way is this approach considered to be a substitute for the necessary rigor that is required for architecting solutions and does not detract from the need for a richer, deeper understanding of architecture and use of methodologies that exist and that architects use today and will use in the future.

For example, measurement of each SMART Force can be of particular importance and relevance in the evaluation of solution options. A Spider Diagram, such as the one that is shown in the following figure, can help communicate the relevant fit that a solution has to an identified set of business drivers.

In the first example (Figure 4), the Spider Diagram would help an organization in which quality is important—perhaps an engineering company—identify that a solution component is not of the quality that it can accept and, therefore, cannot be used.

Figure 4. Forces diagram—solution option 1 (Click on the picture for a larger image)

In the second example (Figure 5), the same engineering organization can be reassured that the solution component is of high-enough quality for its intended use and it would be prepared to accept it. The production of Spider Diagrams such as these for each solution option can help visually highlight which one provides the best fit.

Figure 5. Forces diagram—solution option 2 (Click on the picture for a larger image)

Services

Ever since there has been an architect role, architects have been answering the questions that we have posed here. In recent years, we believe that the question has been more relevant to software components, and not services, which has been the basis of our paper so far. However, the emergence of services and such things as cloud computing has and will continue to make the reuse, buy, or build dilemma more relevant than ever before.

Arguably, the starting point with services is somewhat different from that of components—specifically, in the reuse category. If a company already uses a service, the chances of it reusing that service somewhere else is incredibly high. Take, for example, any common data set that numerous solutions use—perhaps a credit- checking facility in the banking industry or a list of dealerships in the automotive industry. Design and implementation of these as services means that they can be reused by other systems within an organization. It is also not inconceivable to suggest that it might also emerge as a new product in an organization’s product portfolio for other organizations to buy—for example, an address-lookup service for resolution of postal addresses. This opens up a further discussion (for another day) on a possible additional dimension to the Evaluation Framework that addresses the external and internal consumption or provision of services.

All of this raises the question: Should the capability be delivered as a software component or service? All things being equal, if the motivation is to reuse, the answer might be quite simple—although this, of course, can be influenced by a number of factors. While the decision of component or service is an interesting and important one, what we are concerned with here is whether to build your own service or buy one. Also, can the experience and rules that we have used in the past be applied?

Conclusion

In this article, we have discussed three main areas: Evaluation Framework, Forces, and Balance. Looking at buy or build, let us address each area in turn and its applicability to services:

Let us begin with the Evaluation Framework. It would seem that the seven attributes apply to services in the same way that they do to components; the considerations, however, might not.

For buy, integration and customization were the identified high-order considerations. This remains the case for integration; however, customization should not be a priority concern. If it has to be considered, perhaps there is an issue with the choice of service; for example, the compromise on requirements is too much to be acceptable.

The situation is different for the build category. The high-priority considerations here were skill and core. Both of these remain important factors for services. As with components, the ability is required to build a service; and, if that service is core to the business, it is highly likely that the build option is the preferred one.

Services probably warrant an additional dimension to the Evaluation Framework in order to apply further considerations.

Service-level agreements are always a hot topic with the subject of services. Does the service provide the required availability, reliability, and scalability that the business demands? If we consider the previous credit-checking example, if this service is part of a wider business process (which is likely to be the case) and the end-to-end process must complete in a fixed time, service issues such as reliability are a vital consideration.

We have noticed also that companies that already partner with other organizations in the course of their business are comfortable with a services model. They can clearly see the advantages, understand the approach and risks, and have a willingness and culture to succeed. One example of such a business is the airline industry. Today, that industry works with numerous partners in order to deliver the end-to- end service to their customers—for example, check-in at the start, the flight itself, and finally baggage reclaim at their destination.

Reflecting upon what we have discussed, we believe that both the Forces and Balancing Act are as useful when considering services as they are for components. Architects, then, should be confident in taking their knowledge of and past experiences in designing software components forward into the design of solutions that encompass services.

About the Authors

Simon Thurman, (simont@microsoft.com) Architect Evangelist—Microsoft, is an Architect in the Developer Group. Over the past 20 years, he has architected and developed software on mainframes, client-server architectures, and the Internet. Such memorable software includes ensuring that you have the correct address, routing algorithms, and streamlining the house-moving process. Today, he helps customers do innovative things with new technology to deliver business value. The rest of his time is spent with his wife and daughters, and mountain-biking.

Phil Rowland (philip.rowland@capgemini.com) is an Enterprise Architect at Capgemini UK plc. For the past 20 years, he has successfully undertaken a number of roles, including presales, technical strategy, technical consultancy, business analysis, solution design, software development, and implementation management. Phil’s breadth of knowledge and experience has enabled him to design a number of highly available, scalable, and robust solutions to clients in the public and private sectors, as well as providing advice and consultancy for Enterprise and Solution Architecture.