Methodologies and Technologies for Rapid Enterprise Architecture Delivery


| Home | Courses | Certification | Projects | Papers | Contact Us |



TEN Archive

Contact Us



A Visible Solution Paper

How Do You Evaluate Packaged Software?

Printable PDF Version

 Copyright 1997, Visible Systems Corporation


Commercial Off the Shelf Software

Commercial Off The Shelf Interview

In this interview, Visible’s Alan Perkins, vice president of Consulting Services, discusses the important issue of determining whether off-the-shelf software will truly meet a company’s business needs. Alan, who has over thirty years of information technology experience, has been consulting with companies on business process reengineering and establishing corporate data architectures for the past ten years.


Q. What are problems that companies face in purchasing off-the-shelf software for business applications, such as SAP , PeopleSoft, and MRP?

I have heard horror stories about companies spending hundreds of thousands of dollars – sometimes even millions of dollars – on consulting services to implement these already over-priced, integrated business application packages. In many cases it has taken years to get to a point where the applications are useful. Some companies just give up after months or years of effort because they realize the package will never meet their needs. I believe there are two main reasons why companies have little success with these applications:

  1. Many executives do not practice strategic management and therefore are hoping an off-the-shelf business application will magically make up for their lack of focus. Essentially, they abdicate their management role to the programmers who developed the application suite. This usually results in wholesale change of their business practices to make the best use of "one-size-fits-all" software, rather than modifying the software to reflect their own best practices. Even those executives who know the company’s mission, goals, strategies, objectives and performance measures haven't documented them to a degree that allows them to be translated into business software requirements.
  2. Most companies search for applications before they have paid sufficient attention to improving their internal processes and practices. Good software that automates bad business practices is not a good system.


Q. What are common mistakes companies make in evaluating software packages?

It's surprising what otherwise competent managers will do when selecting software. They will select based solely on price, or physical platform, or development language, or database management systems, or size of the manufacturer, or persuasiveness of the sales pitch, but rarely do they look at anything but the most general business and data requirements. For example, if they need accounting data, they'll make sure the application suite includes an accounting package, but they won't look any deeper to see if it will handle their chart of accounts and their accounting practices.


Q. Which techniques are most effective in evaluating software and ensuring that they meet the business and data requirements of the organization?

There is only one effective technique for such evaluations. It is not complicated, but it requires a thorough knowledge of the company, its strategic and performance plans, its data and information requirements, and its practices and processes. These elements, which make up the company business model, must be documented in such a way that they can be communicated and validated internally. The business model must also be documented so that it can be modified easily and quickly when change happens –and it will happen. In addition, the company's strategic business model should be capable of being translated readily into software requirements and evaluation criteria. Only when armed with this information can a company successfully identify, evaluate, and implement commercial software.

This assumes that the company's business practices and processes have been evaluated and engineered to most effectively meet company goals and objectives. A company should never attempt to buy or build systems to support processes that need improvement. Nor should they blindly adopt external "best" processes and practices without ensuring that they are truly best for the company.


Q. What technique/method would you recommend for evaluating software packages?

After determining the business data and information requirements that the package will need to support, companies should identify potential packages and vendors. Then the company's information system needs and evaluation criteria should be communicated to all potential vendors with an invitation to propose solutions.

The first round of evaluation will involve reviewing all proposals and rejecting those that do not meet minimum requirements. The vendors that survive the first round should be invited to make a formal presentation and demonstrate their product. If one or more of the vendors can demonstrate that their products exactly meet the company needs, then selection can be determined based on price and service. If no vendor meets all the requirements, then the gap between the vendor proposals and the company requirements must be analyzed. This may require asking the vendor and other firms to project the cost and effort required for closing the gap.


Q. How is data/process/object modeling used in evaluating software packages?

Models are used to represent actual things. They can represent things that exist or designs of things to be created (or purchased). Data models represent the company's operational data, strategic information, and business rules. Process models represent what the company does, and often how things are done. Object models represent reusable application components that are a combination of data and the processes used to create, read, update, and delete the data.


Q. What are the advantages of using modeling for such an application?

Models facilitate communication within a company and with potential vendors. A single, conceptual (logical) model can represent the overall business model of the entire company. The company can use this enterprise architecture model as the source for every application and database design (physical) model. Most CASE tools and other state-of-the-art application development tools can create executable application components directly from physical models.

The company can also use the logical model as the benchmark against which to evaluate commercial applications. If a vendor has used a structured, model-based approach to developing its application components, then those models can be compared readily with the company model.


Q. What are the benefits of using data modeling for packaged software evaluation?

The most stable portion of an enterprise architecture is its data model. How a particular data element is processed is less important in selecting packaged software than the existence of the data element. In fact, a company can effectively evaluate commercial software using just functional requirements and a data model.


Q. Do you foresee changes in the way software package vendors work with their customers?

I think vendors will be more and more likely to make their own models available to potential customers for comparisons and evaluation. I hope vendors will encourage customers to take a strategically-driven, information-centric, customer-focused, model-based approach to application development and implementation. I expect vendors will partner more with customers in order to provide solutions that meet the customers exact needs.


More Information

For more information regarding this Visible Solution, please contact:

North America

Visible Systems Corporation
201 Spring Street Lexington MA 02421 USA
Phone: +1-781-778-0200 Fax  +1-781-778-0208

Web Site:


Clive Finkelstein, Managing Director
Information Engineering Services Pty Ltd
PO Box 246, Hillarys Perth WA 6923 Australia
Phone: +61-8-9402-8300 Fax: +61-8-9402-8322

Web Site:


| Home | Courses | Certification | Projects | Papers | TEN Archive | Contact Us | [Search |

(c) Copyright 1995-2015 Clive Finkelstein. All Rights Reserved.