To remain competitive in todays rapidly changing business climate, the agile enterprise must be able to introduce new applications to automate manual processes quickly and effectively. But making a build or buy decision is often as time-consuming as the process of getting the new application up and running. Business Process Management is an alternative that can be leveraged to develop applications faster and cheaper than traditional methods. Knowledge Center contributor Jo Hoppe discusses what you should consider when faced with a build, buy or BPM decision for your organization..jpg)
Traditionally, when looking to introduce a new business application into an existing business environment, an IT manager would first draft high-level business requirements for the application and then conduct a build-versus-buy analysis. A time-consuming process, this analysis entails researching available third-party solutions, evaluating the packages using a highly quantitative selection criteria matrix and conducting a gap analysis to determine whether the available solutions cost-effectively address the high-level business requirements, while meeting architectural standards.
Normally, if a package meets better than 80 percent of the functionality, if it is compatible with architectural standards and the cost of adding the essential missing functional components does not exceed the cost of building the same application, a buy decision is made.
The decision to buy: Is it really right for you?
Buy decisions are attractive because they allow you to leverage the vendors considerable development investment and domain expertise. Buy decisions are also associated with accelerated implementation cycles, since you are starting with a working solution.
But its important to keep in mind that, depending on the underlying technology of the solution, packaged solutions may be difficult to modify. If the vendor provides mechanisms for extending their application, you must be careful to ensure that your changes will remain intact once the vendor upgrades the package. Some additional factors to consider before proceeding with a buy decision include the following:
1. How often will the business processes addressed by this application change?
2. How easy is it to change the application? (Speak with a technical contact from the vendor to understand what mechanisms are in place to extend or change existing functionality.)
3. What types of skills will be necessary to change the system as needed to ensure competitive advantage?
4. Does the vendor provide a well-documented API for integration with third-party systems?
5. How easy is it to train business and IT users on the system, thus reducing reliance on the vendor for ongoing support?
6. Is the package overkill for your business problem? Will the superfluous functionality negatively impact the user experience, impeding adoption and making support and upgrades difficult?
7. Are adaptors required to interface the application with third-party systems? If so, what is the cost of the adaptors you will require?
The decision to build: Will you really get what you want?
If a third-party solution is neither available nor cost-effective, a build approach is usually prescribed. In this scenario, the business works with IT to build a custom application. A build strategy provides the company with ultimate flexibility, since the application will be finely tailored to meet the unique needs of the business, rather than a generic solution designed to meet the diverse needs of many clients.
The disadvantage is that custom-built applications require much more time to design, build and test, since the application will need to be built from scratch. As such, build decisions often result in a longer time required to derive business benefits.
Build applications also tend to be designed to address a specific functional need, and they are rarely designed with the goal of integrating with existing enterprise applications. Depending on the design and underlying technology of the build solution, this may introduce downstream integration problems, leading to information silos.
The BPM decision: Identifying good candidate projects
With the advent of BPM (Business Process Management), business and IT users are afforded another alternative to the build vs. buy option. In the new model, the proposed solution is further evaluated to determine whether a BPM solution is appropriate. If the proposed application is either process-intensive (that is, it involves automating and routing complex business processes), or if it involves complex decisioning or business rules, BPM may be the best approach for quickly and effectively implementing a solution. In general, BPM solutions work best when one of the following three situations applies to you:
1. The applications underlying business processes or rules are likely to change frequently to meet business needs.
2. The application will be required to access data from other internal systems or from the backend systems of supply chain or trading partners.
3. The business rules and/or processes that need to be built are also required in other areas of the business. That is, the components of this application are likely candidates for reuse.
If, however, the application is static or primarily focused on transaction processing, and it involves few, if any, business rules or process flows, a more conventional approach should be considered.
Today, IT managers are faced with numerous decisions when adding new applications to their infrastructure. Having a strategy in place that helps them implement solutions quickly and cost-effectively is key to maintaining a competitive edge.
Should you build, buy or BPM?
The table below summarizes the basic considerations when making a build, buy or BPM decision:
Jo Hoppe is CIO at Pegasystems. She is responsible for designing and building a comprehensive portfolio of enterprise solutions that exploit the intrinsic business advantages of Pegasystems' rules-based BPM technology. Hoppe has held a wide range of positions in Fortune 500 companies. Her business background is international in scope and has included assignments in information-technology, software-product development, marketing, P&L management, and operations.
Prior to joining Pegasystems, Hoppe was an executive at CMGI, a $1.2B global Internet holding company, where she held the dual role of EVP/CIO of CMGI and CTO of uBID, CMGI's $750M online auction and eCommerce business. She also managed a host of other operational responsibilities in this position, including asset management and warehousing, corporate travel, Amex administration, and group purchasing.
Before her CMGI assignment, Hoppe held CIO positions at Addison Wesley Longman and Houghton Mifflin Co. Prior to that, she was VP and General Manager with Atex Media Solutions, where she also gained 12 years of software-development experience. She can be reached at Jo.hoppe@pega.com.
Enterprise Applications 
