Bertelsmann Software Migrated from Mainframe to Windows ...



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

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

| | | | |

| | | |[pic] |

|[pic][pic] | | | |

| | | | |

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

Runtime Micro 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.

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

windowsserver2003

-----------------------

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

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

| |Software and Services

■ Products

− Microsoft Windows Server 2003 Datacenter Edition |Hardware

■ Unisys ES7000

■ EMC Clariion CX 600 | |

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

[pic] [pic]

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

© 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 | | |

For More Information

For 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:

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

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

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

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

Günter Bodner, Chief Information Officer,

ICS Bertelsmann

| |

Figure 1: Bertelsmann tested 11 real-world scenarios.

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 | #$-.EWÙí& * 3 4 [?]

0

 

¢

[pic]

[?]

6

7

>

?

x

˜

©

±

²

´

¸

Õ

ò

+

.

y

™

ì

î

ï

ð

û

4

<

R

T

V

^

”–´¶üôìôüèüôüèüèüèäèÙèÎèäèäèÊüèÆèÙèüÂüèÂè»´»èÂèÂüèÆèÆ°üèƬèü¤üèÙèÎhñ1B* |phÿ™h´D¼hPã

h´D¼h´D¼

h´D¼h**MhÖ Å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 | |

[pic][pic][pic]

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 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 Officer, ICS Bertelsmann

| |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download