TESTING E-BUSINESS APPLICATIONS
WITHOUT BREAKING THE BANK

29 January 2002

by Ram Reddy

What exactly is an e-business application? Is it the Web front-end that allows customers and suppliers to access back-end corporate systems? What about the application server that connects the Web front-end to back-end systems? Are the wide area network and hardware components that link the front-end and back-end systems part of the e-business application? What about the processes (demons, if you are in an open systems environment) on the back-end systems that service requests from the e-business applications? The answer: all of the above. Additionally, an e-business application includes all hardware and software elements within a firm and its technology service providers (such as Web-hosting firms) that are required to support the front-end.

This definition of an e-business application makes testing exponentially more difficult. Creating a test environment that has all the components that make up the e-business application would not only be cost prohibitive, but practically infeasible. On the other hand, testing only the front-end of an e-business application is like testing the material needed to add another story to a building without checking the load-bearing capacity of the overall structure. Adding another story in this manner may seem like a good idea when the building is unoccupied, but it might collapse under full occupancy. Lucky for us, stringent building codes in the real, physical world prevent this situation from occurring. I advocate a similar real-world approach for e-business applications. Anything less would expose stovepipe corporate systems that do not work well with one another to a firm's suppliers and, more importantly, to its customers.

Brief History of Corporate IT Systems Evolution

A brief history of the evolution of corporate information systems is necessary to understand and deal with the challenges of development, testing, and production support of e-business applications. The typical Fortune 1000 firm has a collection of mainframe, midrange, and minicomputer/client-server systems. These would have been acquired to support the firm's growth and current market position. The first acquisition may have been billing and accounts receivable management systems. After a few successful quarters, the firm may have invested in order entry and manufacturing systems. Each successful year would see the firm automating some other segment of its operations to achieve economies of scale and operational efficiency. The focus was on a particular function, and there was no thought given to integrating the various functions or systems across the firm. On top of that, imagine that this firm had also acquired other firms with their own motley collections of information systems.

As a result, the typical corporation has stovepipe systems that can't interact with one another and islands of data that can't be integrated. A random survey of the typical Fortune 1000 firm may uncover at least two to five customer master files -- if you are lucky! The unlucky firm will have a proliferation of customer master files spread across different functional areas. Connecting these islands of data within a corporation has been one of the biggest challenges in the implementation of customer relationship management (CRM) systems. CRM systems seek to aggregate all customer touch points within a firm and present a single view of the firm to a customer. Quite often, customers are frustrated when dealing with a firm in this situation, as they get passed from one department to another for resolution of a customer service issue. "I'm sorry, you will have to call the warranty department before we can issue an RMA number" is a recurring theme.

The challenges of integrating these disparate IT systems and underlying processes are significant. E-business applications fall smack into the middle of this integration minefield. To be effective, an e-business application needs to interact with numerous back-end corporate and supplier systems. Design, development, implementation, and production support of e-business applications require a different mindset than the traditional system development lifecycle (SDLC) approach. However, best practices from the SDLC can be borrowed where appropriate. E-business application development and testing are iterative processes that take apart every component and examine the design and feasibility issues. But before I review the testing approach for e-business applications, a word of caution is in order.

Exposing Dirty Laundry

In general, IT shops have treated software development as an art rather than a science. After a brief interest in the Software Engineering Institute's Capability Maturity Model (CMM), most IT shops have reverted back to application development as usual. Unfortunately, if a firm's e-business applications fail, it can have disastrous consequences. As we move increasingly to inter-enterprise systems and the "virtual organization," the lack of rigor in design and development will focus attention on corporate IT development practices.

Successfully deployed and heavily used e-business systems will, on failure, affect multiple departments within a firm and get immediate attention from top management, customers, the news media, and, more importantly, analysts following the firm. IT personnel will be forced to fix systems with everyone looking over their shoulders; in some recent cases of high-profile e-business failures, the media gave daily updates. As business becomes ever more integrated and virtual, an e-business application failure will have the same attention-grabbing potential as a building collapse or a train wreck. Therefore it becomes critical that we design, test, and deploy e-business applications on solid foundations. When an e-business application fails, it should fail gracefully in a predictable manner. So how does one design, develop, and test e-business applications in this complex environment?

Copy the Physical World

The answers come from the real world -- specifically, the world of civil engineering. A building is constructed by assembling steel, brick, glass, and cement, among other construction materials. The building is designed to withstand extremes of nature -- earthquakes, lightning, severe wind, and so on. This is done without testing the finished building in an earthquake or lightning strike or severe wind conditions. Yet because of the design specifications, we expect the building to withstand all that nature can throw at it. How can the architect be so confident of the building's ability to perform according to specifications? Because the aesthetic/artistic element of building design is supported by a well-developed science of building technology. The art of architecture is built on solid scientific foundations and rigor.

In the same way, the art of application development needs a solid foundation. Keep in mind that the civil engineering field had hundreds of years to develop solid foundations, whereas software development practice is in its relative infancy. We can, however, copy the civil engineering elements of simulation and testing of individual components. We can collect performance data from extreme operational conditions to continually update knowledge about the performance of individual components of e-business applications.

-- Ram Reddy, Senior Consultant, Cutter Consortium