|
E-COMMERCE AND CLIENT/SERVER RESTORATION With the growing popularity of the Internet and World Wide Web over the last few years, companies have been making significant investments to web-enable their legacy applications so they can be accessed directly by remote employees, business partners and even customers. In the process, they have made several discoveries that are of tremendous importance to traditional contingency planning methodology. Many existing client/server applications are not only difficult to port for web-based deployment, but are also almost non-recoverable in the event of an unplanned and potentially disastrous interruption. Without a full redundancy strategy of 1-for-1 replacement of hardware hosts and client/server software, recovery of the business functions supported by their legacy applications cannot be accomplished. Such strategies are extremely costly to develop and implement and may become a Herculean challenge for the contingency planner to maintain in a tested, up-to-date state. What is different about client/server application recovery? What can be done to keep plans for the recovery of these applications from bankrupting the business? What can be done to increase the options at the disposal of planners to address the unique requirements of contingency planning for client/server? These questions must be thoroughly addressed if contingency planners are to deliver the capabilities for which they were hired. THE PROBLEM Most of these applications have been rolled-out in an iterative manner, as projects with durations that can span as much as a decade for some enterprise resource planning (ERP) applications. In most cases, this means that personnel, application development tools, middleware and other development components have changed many times since the application was first created. In light of the above, contingency planners routinely confront the following obstacles to cost- and time-effective recovery planning for n-tier client/server applications: • Personnel and management changes over the term of application deployment may mean there are simply no "application experts" who can be leveraged to assist in identifying recovery options. • There may be significant design issues, such as hard-coded middleware identifiers (see below) for hardware and/or software components, which can effectively shrink the field of recovery options to only one: full redundancy of components at a hot site or alternate recovery facility. • Given the time and effort that has gone into deploying the system in the first place, there may be significant reluctance at both technical and business management levels to re-architect the system in such a way that recovery option-building is facilitated. In addition, many contingency planners lack even a rudimentary understanding of client/server technology. Without a basic knowledge of terminology, or an appreciation of client/server application design criteria and components, the thinking of contingency planners regarding recovery planning options will be limited. Also, the planner’s knowledge gap is likely to impair the ability of the planner to work effectively with application designers and managers when soliciting their assistance in contingency planning. Few application architects or systems designers possess the time, inclination or capability to deliver an introductory course in the many nuances of client/server application design. Against this backdrop, vendors of disaster backup services have been ready and willing to support the 1-for-1 replacement option for client/server applications. Many very complex mainframe applications often limit recovery options to the preparation of a nearly identical host platform at the commercial hot site. Similarly, the recovery of complex client/server applications may require a backup platform that mimics, down to the machine name and network address, every server host and client workstation that exists in the production environment. In this observation, vendors are not being deceptive. They are merely offering a solution that meets the customer’s perceived requirements. If the application is mission critical, they know the cost of such an expensive redundancy strategy will be paid. MEETING THE CHALLENGE 1. Gain education in client/server application architecture. The first point is critical. To understand how poor design choices can limit recovery options, planners must first understand the prevailing approaches to designing n-tier client/server systems. They must understand how client/server applications execute instructions and, especially, the role middleware plays in ensuring that client and inter-server requests reach their destinations across a network and are handled appropriately by executing systems. Moreover, planners must understand how middleware products are differentiated from each other. They need to know that certain middleware products identify system nodes by physical addressing or other "hard coded" naming conventions, while other products perform dynamic or on-the-fly resource identification. Systems using physical addressing are inherently more difficult to restore without full redundancy at the component and configuration level than those with dynamic resource identification. The former strategy, however, is growing in popularity—especially as major technology vendors have given their support to distributed common object model-based middleware strategies that deliver operational performance while virtually ignoring operational risk. Planners also need to know that many complex client/server systems implement many different types of middleware concurrently, often due to the iterative process used to roll out application functionality over time. In such cases, sorting out what components can be recovered on alternative platforms from those that cannot is a daunting task. Planners should be circumspect about accepting assurances from vendors of "packaged" client/server applications—those offering client/server applications in a shrink-wrapped box—that these products (e.g., enterprise resource planning (ERP), manufacturing resource planning (MRP), and customer relationship management (CRM) application suites) are more recoverable than apps developed in house. For a number of reasons, packaged apps often embody the worst of client/server design from a contingency planning point of view. One popular ERP package contains over two million decision points to implement and consists of hundreds of software "modules" held together by a kludge of different middleware products. In a disaster, recovering these packaged applications can be just as nightmarish and option-limiting as would be any "homegrown" application. Understanding what limits recovery options is important, but so is understanding what enhances client/server application continuity. Planners must also be aware of design options that enable high availability in n-tier client/server applications. Success stories involving companies that recovered from unplanned interruptions of their mission-critical client/server platforms almost always refer to key redundancies of networked resources that were built into the application when it was designed. This leads to the second point. Recovery options in client/server applications can be engineered into the application architecture. This usually only happens if the contingency planner (or someone else with the concern and authority to do so) instructs the architect to implement certain design elements. Thus, in addition to being knowledgeable about n-tier client/server technology, planners need to become actively involved in the application design process. In a word, they must become proactive. THE END OF TRADITIONAL CONTINGENCY PLANNING Doing so requires more than a "certification" or a "secretary-friendly" contingency planning tool. In the final analysis, to create planning options for n-tier client/server applications and to ensure the survivability of key business processes that the applications support, planners will need to "walk the walk" and "talk the talk" of the application designer. About the Author |