Customer Mainframe Migration Case Study
/ / Bertelsmann Software Migrated from Mainframe to Windows Supports 20 Million Customers
Overview
Country or Region:Germany
Industry:Media and Entertainment
Customer Profile
Gütersloh, Germany-based Bertelsmann AG is one of the world’s largest media companies. The company has 88,500 employees worldwide.
Business Situation
Bertelsmann had migrated from a mainframe application to the Microsoft® Windows Server™2003operating system to run many of its book clubs and wanted to know if the solution would scale up to support its largest club.
Solution
Bertelsmann turned to the Microsoft Technology Center, Micro Focus, and Unisys for benchmark testing of its Windows®-based solution on a 2.8 GHz, four-processor system.
Results
Supports 20 million customers
Supports 1,500 call center operators, 50 percent above goal
Enables 170,000 screen I/Os per hour, 200 percent above goal
Supports parallel batch and transaction processing with negligible performance effect / “We scaled up on Windows Server 2003, the Micro Focus Enterprise Server, and Unisys hardware, and ran a 20-million-customer business on a four-processor machine; we didn’t need the mainframe….”
Günter Bodner, Chief Information Officer, ICS Bertelsmann
In 2002, Bertelsmann AG achieved U.S.$1 million annual cost savings by moving the management of some of its book clubs off a mainframe and onto a Microsoft® Windows Server™2003–based solution. In 2005, when its largest club considered joining the move to the Windows®operating system, Bertelsmann needed to know that the Windows port of its mainframe software could handle 60,000 screen requests per hour by 1,000 call center operators—much more than the earlier migrated system was handling in production. A benchmark test simulating 20 million customers in real-world scenarios, conducted at the Microsoft Technology Center in Munich with the participation of Micro Focus and Unisys, supported 170,000 screen requests by 1,500 operators—far above the benchmark goals—plus another 51,000 orders and 130,000 payments in simultaneous batch processing. The system can easily scale to support additional needs.
Situation
Global media giant Bertelsmann AG is the leader in many of its markets: Europe’s largest television and radio broadcaster (RTL Group), Europe’s largest magazine publisher (Stern, Geo, Capital), and the world’s largest book publisher (Random House), as well as the BMG music division and BMG Music Publishing. Bertelsmann’s direct-to-customer businesses are bundled in DirectGroup, and include book and music clubs with more than 35 million members worldwide.
To run its club business and to share data among the various clubs, Bertelsmann created a COBOL-based mainframe application called International Cooperative Solutions (ICS) in 1984. The solution covered virtually every aspect of Bertelsmann’s club business, including customer marketing and management, inventory management, customer service center, point of sale, product marketing, distribution, invoicing, and data management.
The application served Bertelsmann well but was expensive to run and to upgrade. In 2002 and 2003, the company migrated off the UNISYS mainframe and onto the Microsoft® Windows Server™2003 operating system for its clubs in Switzerland (German- and French-speaking), Poland, Austria, and Canada, saving approximately U.S.$1 million per year. Windows Server 2003 is the foundation of Microsoft Windows Server System™ integrated server software.
The company’s French book club continued to operate on the mainframe until May 2005, when it migrated to an AIX-based system. The French club began to consider adopting the Windows®-based solution as well but was concerned about whether the solution could scale to meet its needs.
The Windows-based solution, running on Hewlett-Packard dual-processor computers, had been rated for 1.5 million customers, more than enough for the clubs that had adopted it, which served 300,000 to 900,000 customers each. But the French club served 4.5 million active customers and had a total of 10 million customers (active and inactive) on its subscriber lists. Bertelsmann needed confidence that the Windows-based solution could scale to support a total of 10 million customers.
In addition, customer-relations call centers for the clubs already migrated to Windows Server 2003 employed about 300 call-center operators each and were generating a maximum of 10,000 transactions or screen requests per hour (with each transaction or screen request representing an end-to-end servicing of the customer during a single interaction). The French club had 800 operators—almost triple the average of the other clubs—and processed 60,000 transactions per hour.
Could the Windows Server 2003 version of ICS scale up to support the French club’s additional customers, operators, and transactions load?
Solution
To find out, Bertelsmann decided to conduct a benchmark study.
Objectives
The objectives of the benchmark would be to successfully support:
1,000 simultaneous call center operators
60,000 screen requests per hour
10 million active/inactive and 20 million total customers (double the number of Bertelsmann’s largest club, to ensure room for growth)
High-volume batch processes (such as invoicing) in a reasonable time frame
High stability and reliability (the mainframe and smaller Windows solutions achieved 99.9 percent uptime in production)
Concurrent online transactions and batch processes
The benchmark was conducted over two weeks in late 2005 at the Microsoft Technology Center in Munich, Germany. In addition to Microsoft and Bertelsmann, the study included the participation of Micro Focus and Unisys. Micro Focus provided the runtime environment and simulated the production load. Unisys provided the hardware platform, an ES7000 computer server. Bertelsmann chose the ES7000 for its scalability and ability to be deployed readily in the company’s production environment if the test proved successful.
Test Scenarios
The benchmark covered 11 business scenarios simulating real business needs of the company, including what Bertelsmann described as complex business scenarios with enormous system impact.
“It’s important to remember that our overall objective wasn’t to get the best possible benchmarking results—we could have gotten that by selecting a lot of simple business scenarios—but, rather, to truly stress the system with complex, real-world scenarios with enormous system impact, to get an overall impression of how the system would respond,” said Günter Bodner, Chief Information Officer of ICS Bertelsmann.
The 11 scenarios simulated call-center functions including both updating of data and read-only accessing of data. They also included data intensive scans of information. The 11 scenarios are included in Figure 1, along with a rating of their impact on the system (where 1 indicates low impact and 3 indicates high impact).
Batch Processing
In addition to simulating a full range of call-center scenarios, the benchmark also simulated three common batch processes: daily processing, main selection, and end-of-period processing. These included two typical intensive business processes with a sequential-access method and a third process incorporating a very high number of business cases.
Daily Processing – The input for the daily mass-processing covers processing of orders, payments, returns, credits/debits, and tracking information in a 230 million-record table.
Main Selection – All customers stored in the database are scanned and checked to see if they have bought a product within predefined period. In cases in which the customer has not bought any product, the delivery of one or more products—depending on the customer’s stored profile—is released automatically.
End-of-Period Processing – All customers stored in the database are scanned and updates are performed on their records.
CICS-CallCenter Transactions
The 11 call center scenarios were tested in three ways in a Customer Information Control System (CICS) environment:
In an environment of 1,000 operators and 10 million customers (CICS-1)
In an environment of 1,500 operators and 20 million customers (CICS-2)
In an environment of 1,500 operators, 20 million customers, and simultaneous batch processing as just described (CICS-3)
System Configuration
Hardware:
Platform: Unisys ES7000
Processor: 16 x Intel Xeon MP 2.8 GHz, 2 MB L3-Cache, 24 GB RAM
Storage system: EMC Clariion CX 600
Logical Partition of the ES7000:
Partition 1: 4 CPUs, 12 GB RAM – used for the ICS application and database, Micro Focus environment, and monitoring tools.
Partition 2: 8 CPUs, 10 GB RAM – used for the MicroFocus Enterprise Link, which generated the simulated production loads on the first partition.
Software:
Operating System: Microsoft Windows Server 2003 Datacenter Edition with SP1
RuntimeMicro Focus Enterprise
Environment:Server with Mainframe Transaction Option 4.0
Micro Focus Application Server 4.0
Micro Focus Net Express 4.0 (compilation)
Benchmarking Tool: Micro Focus Enterprise Link 5.0
Database: IBM DB2 UDB Version 8.2
Application: ICS Version 1.5
Monitoring Tools:
Micro Focus Enterprise Link: End-to-End Response times, Transaction counters
Quest Central for DB2 Version 4.8.1: DB2-Performance Monitoring and Tuning
Microsoft Performance Monitor: CPU, Memory, Processes and Hard Disk Input/Output (I/O)
Results
The ICS solution benchmark outperformed the goals Bertelsmann set for it on all key measures. The benchmark test successfully simulated call-center operations with 1,500 operators implementing 170,000 screen requests per hour—50 percent more operators and nearly 200 percent more screen I/Os than the original goals.
The screen performance included 50,000 online orders processed per hour, or 13 orders per second. In addition to that transaction processing, the system was capable of simultaneous batch processing of another 51,000 orders and 130,000 payments. Combining the transaction and batch processing, the system achieved a total hourly rate of 100,000 orders, 130,000 payments, 64,000 customer requests, and 20,000 returns on a 20-million-customer model.
The addition of the batch processes in parallel to the transactions had only a “slight and negligible effect” on the performance of the call-center activities, says Bodner.
Average response time on this workload was 0.43 seconds with a 90th percentile of 1.54 seconds, making the scaled-up system as responsive as the smaller systems Bertelsmann already had in production. Reliability and stability were also unaffected by scaling up for the benchmark.
“We scaled up on Windows Server 2003, the Micro Focus Enterprise Server, and Unisys hardware, and ran a 20-million-customer business on a four-processor machine; we didn’t need the mainframe any more,” says Bodner. “I’ve been in this business for 30 years and this fascinates me. We balanced the workload among available resources without any problems. This was a reliable, stable, and well-performing environment, which gives us a lot of security in running ICS.”
Batch Processing Results
“The results of the batch benchmarking steps were absolutely satisfying,” says Bodner. “The test configurations were able to run large batch processes in a stable, reliable, and well-performing way. Moreover, mostly only two of the four available CPUs were used. This provides a lot of possibilities to optimize the duration times should this ever be needed.”
Results for the three batch processes described earlier was as follows:
Daily Processing – This process included high-impact interactions (orders, payments, returns, credits/debits, tracking information) with a 230 million-record table. The processing was achieved in 57 minutes for a total of 418,749 records updated. The CPU utilization was an average 11.6 percent for the four 2.8 GHz CPUs, with the workload balanced between only two CPUs. RAM use was also relatively low (0.58GB and 1.4GB for the two CPUs).
Main Selection Processing – This process selected all customers stored in the database and called a centralized service with every record; depending on the information within the customer record, approximately 14 tables were read and 6 were modified. This process was completed in 3 hours 25 minutes. That’s 48,780 customers processed per minute, or 813 customers per second. A total of 1,477,655 customers were selected and the corresponding product was delivered to each of them. This process also was achieved with low CPU use: 17.5 percent average CPU utilization over the four CPUs, with the majority of the process serviced by just two CPUs. RAM use was again relatively low and comparable to the daily processing test.
End-of-Period Processing – This process selected all customers in the database sequentially and called a centralized service with every record. Depending on information in the customer record, data fields were shifted and updated. The process was completed in 3 hours 5 minutes. 54,054 customers were processed per minute, or 901 customers per second. As with the previous batch processes, CPU use was low (24.4 percent), as was RAM use. However, unlike the other two batch processes, the end-of-period process did take advantage of the third CPU, to support more intensive DB2 activities in this process.
CallCenter Results
As mentioned above, the 11 scenarios were tested in three configurations, scaling from 1,000 operators and 10 million customers (CICS-1), to 1,500 operators and 20 million customers (CICS-2), and 1,500 operators and 20 million customers combined with simultaneous batch processing (CICS-3).Figure 4 shows the business impact of these tests.
Results for the three test configurations, including comparisons of the configurations and the consequent screen performance, CPU utilization, and response times, is shown in Figure 5:
The business activity achieved by each test configuration was as follows:
CICS-1:35,000 orders, 35,000 customer calls, and 10,000 other screen requests per hour
CICS-2: 50,000 orders, 51,000 customer calls, and 14,500 other screen requests per hour
CICS-3:101,000 orders, 51,000 customer calls, 14,000 other screen requests, and 130,000 customer payments booked per hour.
“Taking the system utilization into consideration, it’s obvious that the configuration used—Microsoft Windows, Micro Focus Enterprise Server, and Unisys hardware—is scaling up without problems and is balancing the workload among the available CPUs in a reliable and stable way,” says Bodner. “When you look at the average response times, 90th percentiles and slowest responses, it’s clear that most of the transactions were completed very quickly. Half a second response is real-time and means that the system is not holding up either operators or customers.”
For the CICS-1 scenario, most transactions were completed with an end-to-end response time of less than 0.3 seconds. An additional peak around 1.5 to 1.8 seconds was primarily the result of call-center scenario 1 (order process), which generates 37,000 orders per hour.
Because the number of members and products were limited in the simulation, the system sometimes ran into a database bottleneck, also reflected by the second peak. The order process scenario also included two screens (order process and return process), rather than just one.
Upper Limits
The benchmark testing detected an upper-limit to performance with the test configurations at about 2,000 operators producing 250,000 screen I/Os per hour, or 70 screen I/Os per operator per second.
Bertelsmann sees a variety of possibilities for scaling ICS beyond this level, including:
Scaling up Hardware – Using more CPUs or CPUs with higher capacity (the test configuration CPUs were 2.8 GHz) will increase processing speeds. For example, moving to 3.2 GHz CPUs will increase batch processing speeds by 15 to 20 percent.
Scaling out the Configuration – Putting the various tasks onto different servers (e.g., batch server, CICS-regions, etc.) will also improve performance.
Parallelize the Application – The application can be modified to run in parallel on separate CPUs for enhanced performance.
“The benchmark showed that we could more than meet the requirements of our largest book club today without the mainframe and that we could easily adjust the configuration to accommodate increasing needs as they occur,” says Bodner. “We are very happy.”
Windows Server 2003
The Microsoft Windows Server 2003 family helps organizations do more with less. Now you can: Run your IT infrastructure more efficiently; Build better applications faster; Deliver the best infrastructure for enhancing user productivity. And you can do all this faster, more securely, and at lower cost.
For more information about Windows Server 2003, please visit: