By Dan Oliver

When it comes to implementing a business solution, a common question routinely pops up: Should it be custom built or based upon commercial, off-the-shelf (COTS) products?

While it may seem simple, determining the right solutions approach is a complex process. Tech leaders first need to understand specific business processes and take into account strategic goals, external partners, and required systems support—all of which deserve thorough investigation. They also need to evaluate common business factors—such as project and business validation—before choosing the right solution approach.

The six-step process I outline in this article should help you make the right decision on that next project.

Step 1: Validate the need for technology
Many organizations often choose an enabling technology before identifying any legitimate business need. Sometimes this “cart before the horse” approach is due to rigid business processes, lack of technical knowledge, or pure product hype, which commands many a tech guru’s attention. Decision makers are very often awed by product suite success stories, dynamite product demonstrations, and industry analysts’ evaluation of technology—even when they haven’t formally identified a need for the technology.

To compete successfully, managers need to focus on validating that a business need exists prior to deciding upon the enabling technology and that the need can be readily associated with one of the organization’s strategic goals or objectives.

Last, but not least, tech leaders need to provide an estimated return on investment (ROI) or added value, along with how ROI will be measured. It is surprising how many programs are initiated without considering ROI or added business value up front. Many of these projects consume a lot of profit before leaders realize that either the solution will not add value to the organization or there is not a real business need.

Step 2: Identify core business requirements
In large organizations, pinpointing core business requirements is often easier said than done but is nonetheless critical before enabling a business solution. A core business requirement is one that must be supported by the solution to continue. If a requirement can be only partially met or not addressed by a solution, it is not a core requirement.

It takes effort to identify these requirements, and involving the right businesspeople determines the success of the process. It is extremely important to focus on identifying business requirements—not technology or design requirements. Remember: Business first, technology last.

Step 3: Identify architectural requirements
Most organizations are already using technology to enable their business processes. To reduce the cost of operation and maintenance of this technology, these organizations have established standards to which all solutions must adhere.

It is extremely important to identify any architectural requirements or standards that a solution must support before determining if a COTS or custom solution is the best choice.

Some factors that may restrict the solution choice are as follows:

  • Information security strategy
  • Existing or planned technology infrastructure
  • Existing systems with which the solution will be interfacing
  • Preferred architecture framework, such as J2EE or .NET
  • Existing corporate standards, such as Web servers or browsers
  • Operating systems in use by the organization and its business partners

Step 4: Examine existing solutions
At this point, a business need has been pinpointed, ROI has been estimated, and both core business and architectural restrictions have been identified. Leaders should now take a good look at existing systems.

It is not uncommon that different parts of an organization are not aware of what systems exist in other organizational components. Businesses will often implement solutions only to discover that another system within the organization could have supported the solution with little to no modification. Thus, before deciding on a solutions approach, you should determine if any existing system within the organization can be easily scaled or extended to meet your business need.

I should point out, however, that many heavily customized COTS systems often cannot be easily scaled or extended due to the following factors:

  • There is inadequate design documentation.
  • The vendor no longer supports the technology.
  • Resources with needed skill sets are no longer available.
  • Components within the modules are not cleanly encapsulated, creating dependencies between components that minimize the potential for reuse.
  • The custom code does not cleanly separate presentation and business logic, making it extremely difficult to scale the system to accommodate a larger populace or provide for operation in the event of a disaster.

Step 5: Do you have in-house skills to support a custom solution?
The major factor that significantly reduces the ROI of a custom solution (and in many cases, ultimately causes the endeavor to fail) is the lack of available personnel with proper skill sets. It takes many skills to design and deploy a business solution that is both scaleable and extensible. Unless one of your business areas is product development, there is an extremely high probability that your operations and maintenance technology resources do not include all of the skill sets necessary for a successful solution.

It is never profitable to let personnel gain these skills and experience by developing business-essential systems. Yet, more often than not, decision makers see the often significant, short-term cost differences between a custom vs. a COTS solution and decide to build their own to save money.

Leaders who decide to build their own solution often overlook the following expenses:

  • Replacing technology, extending functionality, or scaling of a poorly designed system (In many cases, systems need to be reengineered and sometimes completely rebuilt. If this results in the unavailability of a business-essential system, the loss of revenue can be substantial.)
  • Training or recruiting personnel with the necessary skills and experience to implement a solution
  • Needing to retain technology resources with the skill sets used in developing the custom solution

Step 6: Does a COTS solution fit your needs?
If your organization does not include a development group comprised of personnel experienced in designing systems to support enterprisewide business solutions, a COTS solution will probably provide the best long-term ROI.

Although the initial short-term cost of implementing COTS-based solutions is often significantly more than a custom solution, it has been my experience that a COTS solution will usually provide the best ROI over the long term. Most of the cost savings are derived from:

  • The product vendor being responsible for adapting the product to advances in technology.
  • The product vendor being responsible for isolating and correcting any design problems.
  • The product vendor providing data migration tools to move data from one release to the next when the product data architecture is modified.

You should consider a COTS solution if:

  • It is aligned with your organization’s business and technology strategy.
  • It can meet most of the core business requirements and a custom solution can accommodate unsupported core business requirements without modifying the product’s software modules.
  • It is anticipated that most of the COTS product functionality will be used in the next three to five years.
  • If IT resources with the proper skill sets are not available to the organization.

However, you may determine that a COTS solution is not the right choice for your organization if:

  • There is a lack of available COTS product support.
  • A significant portion of functionality provided by a COTS solution is not expected to be used within the next three to five years.
  • A significant portion of the core business requirements cannot be supported by a COTS solution.

COTS product core program modules need to be modified to accommodate unsupported core business requirements, introducing the risk that each product release or patch could impact the customization. Each release must be thoroughly tested by the organization to prevent changes from affecting the modified COTS module. It is not unusual for a vendor not to label a module as “changed” when its modification did not affect any of the other release modules. This is why vendors provide the disclaimer for their product performance when modified.

Don’t forget the first, vital step
I’m compelled to remind tech leaders that the first step to determining the right solutions approach—understanding internal business characteristics, such as culture, long-term strategic goals, and partners—is the most critical and can’t be skipped.

The long-term potential impact on your business warrants that you make the decision based on which approach will ultimately have the most positive effect on the entire enterprise. And remember: Business first, technology last.

Dan Oliver is a technical manager based out of the Washington, DC, office of Headstrong, a global consultancy. Oliver focuses on the challenges of deploying enterprise solutions involving multiple partners using a wide variety of disparate infrastructures and legacy systems.

Subscribe to the Daily Tech Insider Newsletter

Stay up to date on the latest in technology with Daily Tech Insider. We bring you news on industry-leading companies, products, and people, as well as highlighted articles, downloads, and top resources. You’ll receive primers on hot tech topics that will help you stay ahead of the game. Delivered Weekdays

Subscribe to the Daily Tech Insider Newsletter

Stay up to date on the latest in technology with Daily Tech Insider. We bring you news on industry-leading companies, products, and people, as well as highlighted articles, downloads, and top resources. You’ll receive primers on hot tech topics that will help you stay ahead of the game. Delivered Weekdays