Home
 > Research and Reports > TEC Blog > Buy, Build, or Somewhere Between

Buy, Build, or Somewhere Between

Written By: Sean Wheller
Published On: July 7 2004

Introduction

Organizations considering the implementation of a resource management system are often faced with the decision of purchasing a packaged solution or building their own custom application.

Both choices have their pros and cons. A decision that favors either route depends on a number of factors whose influence on the decision process varies between organizations. As a result, there is no golden rule that can help organizations choose one route over the other. Whatever the route, organizations generally inherit all that is good and bad about that option and are subsequently excluded from the good and bad of the alternative. Furthermore, once embarking on a route it is difficult and expensive to change course.

This article discusses the decision factors weighed by customers in the build versus buy debate and explores a new option, one that lies somewhere between build or buy and offers the best of both choices.

This article has been sponsored by SYSPRO

Background

Prior to the advent of packaged software, organizations wishing to implement software solutions had no choice but to build a custom application that met their needs. This situation changed in the nineteen eighties as software developers realized the commercial opportunity in developing applications that addressed the common processes and needs of many organizations. Since then, the software industry has seen the continuous return of the build versus buy debate and vendors in both camps periodically switch sides, depending on which option enjoys the strongest support and has the greatest potential to drive increased revenues at the time.

During the nineteen nineties, accelerated technology advancement in market niches increased the number of business applications and core building blocks available in the market. While this resulted in greater choice for customers, it also lead to greater confusion and complexity.

Still, these options did little to squelch the build versus buy debate. Now, instead of buying the technology stack and applications of a single vendor, customers were deciding on a level of vendor-centricity and augmenting this with other best-of-breed packaged solutions. If anything, this only increased the number of arguments instead of improving the customers' ability to take advantage of the benefits of both camps.

For sake of brevity, this article refrains from delving too deeply into the differences between these options. Fully explaining both sides of every option and comparing them against one another will take too long and in all likelihood will just fuel an ongoing argument. Instead, we will focus only on the basic options which all other options fall under to a lesser or greater degree: build or buy—packaged solutions versus custom applications. This article will illustrate the benefits and abilities of new emerging technologies that offer a more "middle of the road" approach that should benefit all.

Buy (Packaged Solution)

The advantage of the buy strategy is that, in theory, a package will enable the organization to go live with broad functionality in a short period. This is primarily because the vendor has already developed the functionality and because it is easier to plan an implementation timetable.

Post-implementation factors also have to be taken into consideration. When purchasing a package solution and outsourcing the implementation, the customer is, in effect, shifting several aspects of risk. Generally the subject of risk is associated only with the implementation. Yet, in the long run, taking a longer view, customers are also exempting themselves from the task of maintenance, effectively placing the responsibility and cost for keeping abreast of technological advancement and market trends on the vendor. Though leaving the vendor responsible for technological advancement can be a risk in itself, the buyer's risk is far reduced.

These factors, combined with the fact that the majority of resources engaged for implementation are outsourced, makes packaged solutions easier to budget for and appear cheaper on paper. The level of control, accountability and reduced risk makes for an attractive proposition when compared with custom development. Generally, it is difficult if not near impossible to enjoy all of these benefits when it comes to building custom applications, in-house or outsourced.

However, for all these positives, packaged solutions also have their drawbacks.

The most well known of these is that packaged solutions are never exactly tailored to meet all customer needs. Additionally, customers almost always end up purchasing and paying for more functionality than they actually need. As a result they often complain that their total cost of ownership (TCO) is higher than expected for the smaller portion of functionality they actually use.

For the most part these complaints are valid and expected. Packaged solutions, by definition, strive to be a "one-size-fits-all" or an "off-the-peg" solution. They are, therefore, designed to fit the broadest set of requirements and are void of industry or sector specific functionality. Obtaining these enhancements often drives up cost significantly, resulting in a cost to functionality ratio that is difficult to justify. However, in some instances where vendors recognize that an enhancement will have broad appeal in their customer base, they will include the feature or functionality in the implementation at a much-reduced cost. This is, however, rare. Customers with shallow pockets soon learn that they are at the mercy of the vendor when it comes to specialist requests.

It is then that customers wish they had taken the build route. They start to source alternative packaged solutions or reconsider the build option with the intention of integrating the new solution to their existing system. Integration is, however, not always possible and often carries a heavy price tag especially when proprietary technologies, such as electronic data interchange (EDI), are involved. Integration also has the nasty side effect of increasing the costs of future upgrades, since changes in any part of a system may cause the integration layer to no longer operate as initially designed. A simple addition or modification to a field may cause exceptions and even result in data corruption. The total cost of ownership is, therefore, forced higher, flexibility is reduced and often it may have been a cheaper long-term decision to have the main vendor develop the special requirements from the onset.

Understandably, this situation is undesirable from the customers' perspective and often leads to tensions in the relationship or worse, a general disillusionment with ERP as a whole.

The customer expects to purchase a packaged solution free from the constraints of the vendor and retain the ability to develop deep industry or sector specific functionality that will improve their overall level of execution to better customer relations, increase productivity and profitability—all the items for which they bought ERP in the first place.

Build (Custom Application)

In the face of advanced packaged solutions, support for building custom applications has waned but did not die a silent death, and it is, therefore, still possible to find organizations that prefer to build their applications. When asked why they prefer this route, the answer most commonly given is, "When we surveyed the market, we did not find a packaged solution that met all of our business requirements or could integrate to the existing systems."

The key advantage of the build option is that organizations can create applications that match 100 percent of the nuances particular to their business. Most custom applications are also more closely aligned with user requirements, and therefore increase usability, reduce training, and generally promote the user experience and level of satisfaction with the system.

The additional advantage is that organizations only develop the functionality they require and are, therefore, not paying for features or enhancements for which they do not have a use. This comes with the added benefit of not having to pay ongoing annual license fees (ALF).

Object-orientated development techniques that enable a building block approach to creating applications have significantly reduced development time-scales. These factors, combined with cost-effective, off-shore coding shops, have in many cases taken the shine off packaged solutions. The result being that the build option is once again enjoying a rise in popularity.

Now, for the bad news. As mentioned in the previous section, it is difficult to accurately place a timeline on custom development initiatives. Estimation of project duration and costs is, therefore, often speculative. Functionality must be built from scratch, and project scope and process modeling need to be completed and understood before development begins. Getting either of these wrong may result in significant overruns to timelines and budgets.

Organizations on the build route also assume the risks of implementation, maintenance, and have the responsibility for keeping abreast of technological advancement and market trends. Failing to do the latter may often result in the custom system being rendered inept from technical and business perspectives. When this happens, the result is often a scrapping of millions of dollars in labor in favor of a packaged solution that can be quickly implemented in order to avoid market fallout.

So the argument for and against either option is "six of one, half a dozen of the other". Both routes offer great benefits, but without any ability to reduce or eliminate their negative qualities.

What customers need is the ability to leverage the pros of both build and buy options while being able to avoid the negative qualities. They need something in between.

Somewhere In Between

Does such a place really exist?

Yes, new technologies have emerged that are widely considered to be sufficiently mature as technology platforms that can be used for development and solving business problems. These technologies include

  • Extensible mark-up language (XML)

  • Managed code realized in Sun J2EE and Microsoft .NET

  • Component architectures

Leading vendors of packaged solutions have already incorporated these key technologies into their product offerings, resulting in what can be described as a system and platform providing the best of both the build or buy strategies. Ironically, the drive behind providing customers with this choice has not been due to the problems described in previous sections. Instead, the driver has come from the customers' demand for collaborative commerce (c-commerce).

C-commerce involves collaborative, electronically-enabled, business integration among an organization's internal personnel, business partners, and customers throughout a trading community. The trading community could be an industry, industry segment, supply chain, or supply event segment.

C-commerce is made possible by means of ERP II, which is the next iteration in the evolution of resource-planning systems. ERP II adapts ERP functionality, technology, and architecture to enable the deployment and interoperation of enterprise applications both internal and external to the virtual boundaries of the enterprise network.

The demand for "something in between" combined with the new environmental requirements and demands of c-commerce has had the following effect on vendors. It has made them aware that it is impossible for any single ERP vendor to develop packaged solutions that cater to the thousands of imaginable business applications that will deliver deep industry specific functionality in all vertical industries while continuing to assimilate applications and functionality in the core applications.

However, in order for vendors to qualify for entry to the ERP II arena, they are required to provide customers with a way to create what many call "next generation" applications. These factors demand change to the functionality, architecture, and data of resource planning systems to accommodate the characteristics of "next generation" applications that will

  • Make extensive use of existing enterprise applications and business logic as a business process infrastructure.

  • Make significant use of freely available, open, and standards based integration and connectivity resources.

  • Have a small technological footprint relative to the core technology stack or core applications.

Resource planning systems that enable ERP II deployment capabilities are finally helping customers to realize the "somewhere in between." They give customers the basic functionality for which ERP is known, while enabling an extension or expansion in functionality from this position. Furthermore, they give the enterprise the agility and flexibility to develop (build) or choose other best-of-breed vendors (buy), and so craft a system that can be easily adapted to business requirements and next generation applications.

Conclusion

ERP II helps customers drive business change and innovation while reducing IT costs and complexities.

Going forward, companies that incorporate an ERP II strategy will be better positioned to focus on their vertical strategies through increased, deep, industry specific functionality or any unique functionality to the organization. As momentum grows, traditional core functionality will increasingly be viewed as a commodity.

Next generation applications will undoubtedly become nothing less than the future of enterprise software. As we move into this era, we will be increasingly forced to rethink some of our conventional wisdoms and traditional approaches to application development. From the limited scope of this article, perhaps the most important of these is the "80/20 principle".

This principle advocates that nearly 80 percent of any custom development effort is focused on overcoming problems related to core technologies, data access, security, query, and user interface. The remaining 20 percent is spent on actually developing the business end of the solution. These new technologies and ERP II compliant systems reverse this principle so that 80 percent of the development time can be focused on developing the business solution.

The result should be custom business solutions built on the business logic inherent to packaged solutions that more accurately meet both the business and user requirements.

This article has been sponsored by SYSPRO

About the Author

Sean Wheller is an author, management consultant and the president of enbaya, a consulting firm that assists hi-tech businesses as they chart a course and get underway with new initiatives-products, markets, partnerships, and entire businesses. Wheller is the author of the book "SYSPRO e.net solutions - The Definitive Guide" which is available from SYSPRO. Over the past fifteen years, he has been a consultant to leading European, American, Middle Eastern, and African based information services and software firms. Prior to founding enbaya, Sean held the position of CEO at MediaOneIT. Currently, his clients include Lucent, Avaya, Nortel, IBM, Comverse, SYSPRO, and numerous early stage technology firms.

He can be reached at sean@enbaya.co.za

 
comments powered by Disqus
Popular Searches

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.