Microsoft Windows Server 2003Customer Mainframe Migration Case Study

Bertelsmann Software Migrated from Mainframe to Windows Supports 20 Million Customers

OverviewCountry or Region: GermanyIndustry: Media and EntertainmentCustomer ProfileGütersloh, Germany-based Bertelsmann AG is one of the world’s largest media companies. The company has 88,500 employees worldwide.Business SituationBertelsmann had migrated from a mainframe application to the Microsoft® Windows Server™ 2003 operating system to run many of its book clubs and wanted to know if the solution would scale up to support its largest club.SolutionBertelsmann 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

“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 BertelsmannIn 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

SituationGlobal 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 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?

SolutionTo find out, Bertelsmann decided to conduct a benchmark study.

Objectives

“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

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

Scenario Name Business Content Impact

1 Call center: Ordering Ordering a product (including ATP-check, pricing, cross-/up-selling check, etc.) and returning the product within an additional follow-up transaction (necessary because of the benchmark scripting); creation of information for hardcopy invoice and FI/CO interface

3

2 Call center: question due to main selection

No member number available; customer search due to the given name; checking some member and commitment specific information (customer lifecycle)

3

3 Call center: question concerning products

Product search due to title (text search); common product information for call center (price conditions, etc.); availability check

2

4 Disposition/Forecasting department: Overview about a specific product

Product master data; warehouse information (sales and returns, etc.); delivery status (offer blocking, contingency information, reservations, etc.); upcoming supplier deliveries

1

5 Call center: Change of address

Immediate address change including keeping the old address in an address history

2

6 Call center: question due to a department reminder sent

No member number available; customer search due to the given name; checking quality of the member in general; customer account for checking the reason

3

7 Call center: question due to a purchase reminder sent

No member number available; customer search due to the given name; checking quality of the member in general; customer history for checking the reason

3

8 Call center: manually setting a fulfillment of commitment

Checking the overall quality of the customer (general info., lifecycle); updating the corresponding flag; resetting the flag in an additional follow-up transaction (necessary because of benchmark scripting)

2

9 Call center: manually blocking the main selection reminder process

Checking the overall quality of the customer (general info., lifecycle); updating the corresponding flag; resetting the flag in an additional follow-up transaction (necessary because of benchmark scripting)

2

10 Management: overview about pending orders

Real-time scanning of pending orders within the whole system; statistic 3

11 Disposition department: updating product master data

Updating some information regarding the product master data 2

Figure 1: Bertelsmann tested 11 real-world scenarios.

ability to be deployed readily in the company’s production environment if the test proved successful.

Test ScenariosThe 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 ProcessingIn 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-Call Center TransactionsThe 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)

“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.”Günter Bodner, Chief Information

System ConfigurationHardware: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

Runtime Micro Focus Enterprise

Environment: Server with Mainframe Transaction Option 4.0Micro Focus Application Server 4.0Micro 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)

ResultsThe 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.

Figure 2: In the Windows Server 2003 benchmarks, both the number of operators supported and the number of screens per hour soared above both previous production levels and the test goals.

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:

Figure 3: Total customers supported, average responsiveness, and availability all scored at or better than the benchmark goals.

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.

Call Center ResultsAs 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

Database Benchmark Benchmark Benchmark

Activities CICS-1 CICS-2 CICS-3

Scenario SQL Read

Accesses

SQL Update

Accesses

Operators Business Impact per hour

Operators Business Impact per hour

Operators Business Impact per hour

1 44 10 400 ~ 35,000 orders 600 ~ 50,000 orders 600 ~ 50,000 orders

2

2,050 0 100

~ 8,000 customer calls in Call center (incl. searching member number)

150

~ 11,000 customer calls in Call center (incl. searching member number)

150

~ 11,000 customer calls in Call center (incl. searching member number)

3 40 0 100 ~ 8,000 customer 150 ~ 11,000 customer 150 ~ 11,000 customer

calls in Call center Calls in Call center Calls in Call center

4 30 0 50 ~ 4,000 requests for product info (sales, returns, forecasting)

75 ~ 6,000 requests for product info (sales, returns, forecasting)

75 ~ 6,000 requests for product info (sales, returns, forecasting)

5 20 2 50 ~ 3,000 changes of address

75 ~ 5,000 changes of address

75 ~ 5,000 changes of address

6 2,050 0 50

~ 4,000 customer calls in Call center (incl. searching member number)

75

~ 6,000 customer calls in Call center (incl. searching member number)

75

~ 6,000 customer calls in Call center (incl. searching member number)

7 2,050 0 50

~ 4,000 customer calls in Call center (incl. searching member number)

75

~ 6,000 customer calls in Call center (incl. searching member number)

75

~ 6,000 customer calls in Call center (incl. searching member number)

8 25 1 50 ~ 4,000 customer calls in Call center 75 ~ 6,000 customer

calls in Call center 75 ~ 6,000 customer calls in Call center

9 25 1 50 ~ 4,000 customer calls in Call center 75 ~ 6,000 customer

calls in Call center 75 ~ 6,000 customer calls in Call center

10 6 0 50 ~ 2,500 reports about pending products

75 ~ 3,500 reports about pending products

75 ~ 3,500 reports about pending products

11 15 1 50 ~ 3,500 product updates

75 ~ 5,000 product updates

75 ~ 5,000 product updates

Batch 15 10 - --- - --- 51,731 orders

Batch 3 5 - --- - --- 129,748 payments

Batch 12 10 - --- - --- 19,693 returns

Batch 3 5 - --- 1,965 credits/debits

Batch 3 4 - --- - --- 215,612 track. info

Total 1,000 1,500 1,500

Figure 4: Results for three test configurations of the 11 scenarios. For example, in Scenario 1, the database was accessed and read 44 times, and accessed and updated another 10 times. The number of operators—400 in the first benchmark, 600 in each of the others—shows how many operators simultaneously triggered the number of orders shown (35,000 and 50,000, respectively).

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 LimitsThe 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.”

CICS 1 CICS 2 CICS 3

Number of Operators 1,000 1,500 1,500

Batch in parallel No No Yes

Number of customers 10 million 20 million 20 million

Screen I/Os per Hour 126,773 176,608 170,619

% CPU-Utilization Total/CPU-0/-1/-2/-3 31/32/30/23/40 37/32/30/49/38 68/66/66/73/69

Resp. Time – Average 0.67 sec 0.35 sec 0.43 sec

Resp. Time – 90th-percentile 1.72 1.52 1.55

Resp. Time – Slowest 2.83 4.55 5.7

Number of SEPs 25 30 30

Figure 5: Performance of the three configurations on key business metrics.

Windows Server 2003The 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:www.microsoft.com/windowsserver2003

For More InformationFor more information about Microsoft products and services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada Information Centre at (877) 568-2495. Customers who are deaf or hard-of-hearing can reach Microsoft text telephone (TTY/TDD) services at (800) 892-5234 in the United States or (905) 568-9641 in Canada. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information using the World Wide Web, go to: www.microsoft.com

For more information about Micro Focus products and services, call (877) 772- 4450 or visit the Web site at: www.microfocus.com

For more information about Unisys products and services, call +49 6196 99 1405 or visit the Web site at: www.unisys.com

For more information about Bertelsmann AG products and services, call +0049 5241 80 0 or visit the Web site at: www.bertelsmann.com

© 2006 Microsoft Corporation. All rights reserved. This case study is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Windows, the Windows logo, Windows Server, and Windows Server System are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are property of their respective owners. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Document published April 2006

Software and Services Products

− Microsoft Windows Server 2003 Datacenter Edition

Hardware Unisys ES7000 EMC Clariion CX 600