Justifying the Migration

Before authorizing the project, the customer undertook a due diligence phase to ensure that the company's business goals could be achieved by moving their platforms from HP/UX to the Solaris OS. The engagement and justification tasks required for this migration project were undertaken collaboratively by the customer and Sun. This joint process enabled the discovery of the customer's key requirements and current state, as documented in the following sections.

Business Background

In this case study, the organization's business strategies involved excellence around process, people, and business tools. The applications the organization used enabled it to run business operations and measure their efficiency and profitability.

The primary reasons for pursuing a migration effort involved meeting the system-capacity forecasts for new business and legacy replacement. The organization was moving customer data files from a legacy mainframe to its client-server environment, which created a demand for an additional disk. The IT department forecasted that they would run out of disk and CPU capacity, and hence the server environment needed to be upgraded. The Sun solution was selected for a number of reasons, including the requirement of the two systems and their associated storage for minimal floor space and the availability of vertical scalability strategies.

The organization expected Sun to migrate the applications and data from the incumbent HP systems to the new Sun servers. The transition needed to be seamless, with minimal impact on business operations, application development schedules, and the legacy migration schedule.

Enabling the legacy migrations became a key design constraint; the customer did not want to pay for a second migration infrastructure, and the benefits case required the retirement of the HP systems. The organization had already developed software and processes to move data from its mainframe to the client-server architecture, and they required the move from HP to the Solaris OS be undertaken as a deployment. The company had deployed the enhanced ledger package to meet the CEO's vision of employing good people, creating and enabling industry-leading processes, and supplying clients with the best technology. The COTS package had created an integrated risks, claims, and ledger solution and was in the process of taking on the current customer base a month at a time from disparate legacy mainframe systems. The target system had to be configured to act as the target for the legacy migration software. In addition, it had to seamlessly support a migration of the underwriting, claims administration, and finance department staff. (The insurance example presented earlier in this book illustrates how an insurance company can buy time for migrations by leveraging natural business-processing cycles.) The migration from the legacy mainframes utilized the annual cycle of insurance underwriting , but the migration from HP to the Solaris OS was unable to take advantage of this cycle; it was necessary to switch off the HP system as soon as possible.

Technology Background

In this case study, the goal was to replace a number of HP/UX server systems with a lesser number of Solaris Operating Systems. The key services hosted by the HP systems were database services, print management services, and job management services. These services served the risk management, claims administration and reserving systems, and the accounting and ledger systems. In addition, the systems also acted as hosts for the database client programs that undertook journaling services and end- user reports . In accounting systems, much of the referential integrity between ledgers occurs overnight (or on another periodic basis).

The other driver for the migration effort that was contrary to "work load consolidation" in the source estate design was the need to support different management environments, including development, training, quality assurance, production, and management information instances of the organization's software solution.

The COTS package the customer used was GEAC's SmartStream, which was written as a two-task client-server package developed using Powersoft's PowerBuilder and Sybase Software's SQL Server. At the time of the case study, Sybase had completed its takeover of Powersoft and was the product author and vendor of PowerBuilder. GEAC SmartStream's natural architecture consisted of Wintel PC's hosting the client application and UNIX servers hosting the database.

At the customer organization, a PC file-sharing LAN was implemented. File servers were used to locate the client binaries, and user PCs acquired client runtime images with Microsoft's LAN networking protocols. The Sybase SQL servers were deployed on HP/UX servers that also acted as job hosts for the accounting overnight-batch programs. (These were GEAC-provided binaries.) One of the management environments, known as the Quality Assurance (QA) environment, acted as the interface between the legacy systems and the current system. Files with the next renewals were loaded into the QA environment database, transformed with Sybase-stored procedures, and then copied across to the production environment for renewal notice production. The customer also had a development environment for the bespoke risks and claims system, a training environment for training new and existing staff in new functionality, a production environment, and an MIS environment that held an image of the production database as at the close of the previous month. This last environment was used to run reports by the finance department and corporate management. These reports were of data warehousing or online analytical processing (OLAP) profiles, with large reads and small outputs. A separate instance was configured to reduce database contention between these users and business processing case workers. The following figure illustrates the client's application components model.

Figure 11-1. Target Deployment Platform

The company ported its database and some of the application infrastructure to the Solaris OS as part of this process, to ensure a degree of confidence that a platform migration was possible within reasonable budgets and that the proposed Sun platform would meet business growth and performance expectations.