we know

they know

SAP MASS Billing Solution for tElECoMMuniCAtionS

2

IBM and SAP investigate the new challenges brought on by business process evolution in the telecommunications indus-

try and demonstrate the viability of a new cross-industry high-volume Consume-to-Cash architecture and solution for

meeting these challenges.

A business model for the future

The emergence of new ecosystems of Internet-based communication service providers, along with new technology and regulatory

drivers are providing a catalyst for unprecedented change in the traditional telecommunications industry.

New business models will be needed to keep abreast of this volatile industry; business models which will allow providers to combine

strategic assets and customer relationships with market innovations. Greater speed, flexibility and a willingness to collaborate with

other contributors in the value chain are critical – both for creating new revenue opportunities as well as reducing risk and operating

expense – if providers are to maintain their industry leadership. These are the findings of a recent survey of today’s

telecommunications industry leaders.

A solutions architecture meets exceptional demand

The incremental charging model, used to support these new flexible business processes, leads to an explosion in billing transaction

volumes. Transactions generated from multiple sources (such as phones, the Internet, road toll and parking garages, shops and

public transport pass cards) can include payment requirements to multiple providers. This can also result in a omplex payment

scenario composed of numerous steps. For example, in the telecommunications scenario, the revenue collected may generate

payments to various parties such as content owners, wholesalers and interconnect partners.

The transition to IP-based networks and convergence in its different forms (fixed-mobile, pre-/post-pay, to name only a few examples)

creates an increasing need for flexibility and performance in the systems handling the associated incremental charging events, or

Event Detail Records (EDRs) and in handling the complex convergent invoicing.

SAP Convergent Invoicing is designed to meet the requirements of these new business processes. This solution allows for bundling

of services and devices which are becoming key to the telecom industry evolution –thus increasing revenue and customer retention

by offering new services and products (see Fig. 1)

Evolution brings new challenges

Service Provider

ANYWHERE ANY DEVICE

ANY CONTENT

Connectivity CommunityContent

PULLSUPPLYEnterprisePublic Sector

PersonalHome / SoHoSMEs

Airlines, Merchants

Info Providers

Cinema, Theater...

Music

Game Video

M-commerce

Small Payments

Micro-payments

Bonus Points

Stocks

Ticket Services

Loyalty Prog

Merchants

MerchantsSponsoring

Advertisment

SaaS

SW Vendor

Mobile Phones

Smartphones

Laptops

Desktops

ProvidersMerchants

ApplicationDevelopersContent

Figure 1

3

In this document we take a look at the solution design, the supporting infrastructure used to master the most demanding scenarios

being faced by the industry today and present results of a recent solution scalability and performance proof of concept.

Architecture of the SAP solution

SAP’s solution for mass billing addresses industry implementations as diverse as voice telephony, music downloads, road and

congestion charging, public transport, and postal services. One common denominator found in these industries is the sheer volume

of billing transactions which result from the business model: small incremental charging events generated by a huge customer base

(see Fig. 2).

A cross-industry mass billing solution

Contract AccountsReceivable and Payable

Debit Credit

Contract Account

10.000.000Customers

Vendors and3rd party

Customer Invoicing

Vendor Invoicing

Customer Payments

BW

Upd

ate

CO

Upd

ate

GL

Upd

ate

EDR

EDR

EDR

Debit Credit

GL Account

Smart Cards

TechnicalSystems

Millions ofEDRs per day

Mobile

Music Downloads

Road Tolls

Figure 2

Handling these mass volumes requires the creation of a highly scalable billing and invoicing solution, efficiently integrated into a high-

performance infrastructure. This is a significant IT challenge – and IBM and SAP provide the solution.

4

The incremental charging events (Event Detail Records, EDRs) are transferred to the SAP ERP platform using an API (application

programming interface) provided by SAP. Here, they are stored, aggregated with the next bill cycle, and then invoiced.

This architecture offers great adaptability and flexibility, and is able to adjust to the specific implementation requirements. It allows for

an easy addition of new services and their related EDR types, is absolutely independent of the external technology used to collect the

EDR, and can be easily extended. Several systems can feed into a single convergent invoicing system – for example, orders from

sales and distribution systems, from various billing systems, and from sources outside the Telco operator. The solution is able to

perform consolidated invoicing for any number of services from different providers and send a single invoice to each account holder.

This can greatly simplify process management and reduce costs, while providing a solution that is able to scale up rapidly and cost-

effectively.

Designed for now – architected for the future

The system provides a powerful backbone that helps to keep the business compliant with present regulatory requirements, and can

be easily adapted to accommodate the future requirements. The solution allows interoperability with other service partners. It offers

integration with SAP CRM (Customer Relationship Management) and Business Intelligence, delivering a real value-add.

Handling massive volumes

SAP Convergent Invoicing uses the same platform and technical concepts (eg. parallelization, etc.) as the widely adopted

SAP RM-CA solution for contracts accounts receivable and payable handling of SAP ERP 6.0.

To better understand some of the design features enabling both business flexibility and system performance, we look at the example

of a mobile service provider. Each subscription contract and its associated SIM card are assigned to one billing account. One or

multiple billing accounts can be assigned to a contract account, and the contract account is linked to the individual or company that

owns the mobile device. The contract account is the level at which invoicing and A/R treatment (payment, dunning, etc.) takes place

As part of the Invoice Pre-Processing component of the solution, the Event Detail Records (records pertaining to the incremental

charging event – for example a mobile call) pass through the Event Detail Handling engine for inbound processing and aggregation

This engine must be able to store, handle and process the millions of records received by the upstream rating and charging systems

on a daily basis (see Fig. 3).

SAP ERP Consume-to-Cash

InboundEDR

Invoice Pre-Processing

Invoice Creation

PrintOut

1 2 3 4

BillingAccount

ContractAccount

FI-CADocument

EDRBilling

DocumentInvoicingDocument

EDR

EDR

Figure 3

5

To meet the volumes of data predicted for this business model, the total solution has to scale. Scalability is the sum of the application

designs and the infrastructure’s ability to meet the applications’ needs. This is not limited to the raw processing power of a single CPU,

but refers to the overall solution harmony, application to infrastructure.

At the request of the SAP Service Industries sector, SAP and IBM conducted a proof of concept (PoC) to test the performance and

scalability of SAP Convergent Invoicing to ensure that the volumes being targeted could indeed be managed.

The PoC was a collaborative project, completed within the scope of the IBM and SAP Alliance Co-Innovation Initiative for Industry

Solutions. Such projects can pave the way for a new SAP product rollout, or verify a first-of-a-kind high-end implementation using

scalable IBM infrastructure.

Proving the solution fits the real-life requirements

The PoC targets are taken from the combined “real-world requirements” coming from multiple active engagements, rather than

simulated load, or specific and unique customer requirements. These PoCs implement current best practices and recommendations

for the application and infrastructure; verifying their validity. These PoCs follow a step-wise scalability design to understand the

effects and requirements of increasing load. This approach enables a single PoC to provide realistic baseline input for many different

customer situations, creating reusable collateral around a new SAP product or “first-of-a-kind” design, which can help first customers

in dealing with their sizing and implementation challenges. These proof points reduce risk for customer implementations by ensuring

the stability, scalability and performance of the application design, and providing “end to end best practice” recommendations for the

overall solution implementation.

iBM and SAP collaborate to meet new industry requirements

integrated solution – the architecture

EDR

EDR

EDR

Debit Credit

Customer Invoicing

Customer Payments

Network Mediation RatingInvoice Pre-Processing

InvoiceCreation

Accounts Receivable

Contract Account

Figure 4

6

Architecture – SAP Convergent invoicing

The insights gained by the PoC regarding achievements and resource requirements of SAP Convergent Invoicing apply to the volume

of incremental charging events (EDRs) to be handled, and the size of the customer base (billing and contract accounts), and not to a

specific industry use case. It is therefore possible to apply the PoC results to various industry use cases according to volume and

data model requirements (see Fig. 5).

SAP CRM

SAP NetWeaver

SAP CRM Sales & Customer Care

EDR

Portal Business Warehouse

EDR

SAP ERPSAP ERP Consume-to-Cash SAP ERP

Enterprise Services

BusinessAgreement

Activation

Rated EDRs

UsageUnrated

EDRs

GeneralLedger

SubledgerPostings GL

Postings

AggregatedEDRs

A/R &Collections

InvoiceCreation

Invoice Pre-Processing

Billing /ContractAccounts

Rating Engine

EDR Rating

Order & ContractManagement

FinancialCustomer Care &

Dispute Management

NetworkProvisioning

SAP BPM(Business Process Mgmt.)

Mediation

Mediation

Network

DataCollection

Multi-ChannelSales

Figure 5

7

To ensure high-end throughput, the PoC focused on the new business processes that handle the mass volumes for billing and

convergent invoicing. The data-flow into the system needed to be able to handle extremely high volumes of raw input coming from the

collection points as rated Event Detail Records.

In the PoC, the EDRs created by the transfer process were aggregated to the appropriate billing accounts in the Invoice Pre-

Processing step, and billing documents were created. The Invoice Creation step merged all billing documents from multiple sources

into invoice documents for each contract account.

Return processing

Upload of failed pay-ments from house bank

Payment lot processing

Upload of incoming pay-ments from house bank

Bank

Inbound interface

Upload of incoming EDR records

Deferred Revenue

Posting from deferred rev. to revenue accounts (after service delivery)

Correspon-dence printing

Print letters to the customer for installment plans and re-turns, security deposit request

Dunning activity

Creation of dunning letters

Dunning proposal

Creation of list with customers that didn’t pay in time

Bank file creation

Payment medium pro-gram, prepare files to be sent to banks

Payment run

Balancing open items, creation of files to be transferred to house bank for direct debit customers

Convergent Invoicing

Invoicing of billed EDR records

EDRbilling

Billing of EDR records

Figure 6: ‘Service to cash’ within the billing system - the ten processing steps of the PoC

PoC reference model – defining challenges and targets

The reference model depicted a “service to cash” business process with one million business accounts, each of which had 50

incremental charging records (EDRs) per day, and which needed to provide same-day billing. The maximum window for processing

was set at between eight and ten hours (see Fig. 6).

8

The chart shows the physical resources used per step to process the billing volume in 1.5 hours. This is depicted in SAPS (SAP

Application Performance Standard) broken down over the two major components: database and application servers. The intent

behind the compressed runtime is to prove the potential in scalability. The same volume delivered in a full 8 hour processing window

would require far less parallelization and fewer resources. From the results of the baseline proof of concept, a variety of use cases

can be derived and their performance, scaling options and system resource requirements assessed. Using the reference model, we

investigate the different options for the telecommunications model.

APPS

DB-CI

Reference Run 1.5Hrs - Physical CPU-Load per Business Step

14448 17647

39357

24983 24983

114015715 3071

11635 11603

74601

45219

70141

50936

82506

83360

14974

5111

2419817583

0

20000

40000

60000

80000

100000

120000

Business Step

SAPs

DunnP

ro

DunnA

ct

CorrPrin

t

BankF

ile

PayRun

PayMed

InvPreP

roc

InvCrea

tion

BillOrde

r

DefRev

Inbou

nd

Figure 8: Reference model: 1 million accounts, 50 million EDRs

results from the proof of concept reference model

Process step No. of objects processed per hour Object type

Transfer of Event Detail Records 197,292,857 Event Detail Records

Billing Orders 19,582,418 Billing Accounts

Invoice Pre-processing 9,417,219 Billing Accounts

Invoice Creation 4,886,413 Contract Accounts

Correspondence Print 2,373,626 Contract Accounts

Figure 7: Critical path steps and volume achievement

Proving application scalability was one major target for the PoC. If the application design does not scale, if there are inherent

bottlenecks, then the solution is limited in capacity and no amount of additional hardware can effectively remedy this.

With the PoC reference model for the “service to cash” business process, we could demonstrated that the system was able to deliver

end-to-end processing of one million billing accounts and 50 million EDRs in 1.5 hours. The peak volume was run using between 120

-140 parallel processes to demonstrate the capabilities of the application design to scale out over the available infrastructure. The

ability of the application to run in massive parallel mode reduces the runtime by delivering an extremely high combined processing

volume over a short time. Using parallelization, we reduced the 8 hour window to 1.5 hours by spreading the load over more CPU

resources (see Fig.8).

9

Derived industry use cases: the telecommunications model

For telecommunications, we look at three different size requirements and two different processing approaches. The “T-shirt sizes”

used for the models are taken from actual telco providers.

3 million subscribers – tier 2 / tier 3 model

The requirements defined for a small (Tier 2/3) telecommunications model expect 3 million subscribers using a mix of services, and a

total of 16 million event data records per day (see Fig. 9).

Subscriber Subscription:Billing Account (1:n)

Billing Account:Contract Account (1:1)

EDR billing Convergent Invoicing

Payment run Bank file creation

Dunning proposal

Dunning activity

Correspon-dence printing

Deferred Revenue

Postpaid

Prepaid

Inbound interface

Figure 9

Figure 10: End to end for telecommunications model - prepaid and postpaid

The model is based on the following assumptions:

Subscribers to Billing Accounts ratio is 1:1.3, ie. subscribers may have more than one service contract 1.

Billing Account to Contract Accounts ratio is 1:1. Each service contract / subscription receives a separate invoice (convergence 2.

of invoices further improves performance)

Each account will receive a printed invoice (to be processed in correspondence printing). 3.

Prepaid accounts do not require payment or dunning processing (See Fig. 10). 4.

In the model there is a ratio of 50:50 for prepaid and post-paid accounts. 5.

Billing / Invoicing is handled in 4 Billing Cycles per month.6.

10

The following two graphs (see Figs. 11 & 12) depict the two ends of the spectrum for runtime vs. resource consumption for 3M

subscribers. In the first graph, the mode is massive parallel, allowing the end to end processing to complete in just over 1 hr. This

model consumes 100k SAPS. The 2nd graph extends the runtime over the full 6 hour processing window, and can manage the

distributed volume using 19k SAPS.

Telco 3M Subscribers - Sequential EDR Upload (52 Min)

8393479492

117739109742

109742

4556038086

88134

41641

0

20000

40000

60000

80000

100000

120000

SAPS

0

5

10

15

20

25

Runt

ime

(Min

)

SAPS

RunTime

Inbou

nd

InvPreP

roc

InvCrea

tion

PayRun

PayMed

DunPro

DunAct

CorrPrin

t

DefRev

Telco 3M Subscribers - Sequential EDR Upload (6 Hrs)

624515769 13952

3841 38723886 7885

15641 15572

0

20000

40000

60000

80000

100000

120000

SAPS

0

20

40

60

80

100

120

Runt

ime

(Min

)

SAPS

RunTime

Inbou

nd

InvPreP

roc

InvCrea

tion

PayRun

PayMed

DunPro

DunAct

CorrPrin

t

DefRev

Figure 11

Figure 12

11

Scaling the model: small, medium, large

This table depicts the variation in key parameters for the three T-shirt models, based on the assumptions defined above and using 4

billing cycles (see Fig. 13).

Telco Model Components Small Medium Large

Subscribers 3,000,000 12,000,000 30,000,000

Billing Accounts (average 1.3 per subscriber) 3,900,000 15,600,000 39,000,000

Contract Accounts (subscriber accounts) 3,900,000 15,600,000 39,000,000

Prepaid elements per day (SMS + CDR) 3,400,000 13,600,000 34,000,000

Postpaid elements per day (calculated SMS + CDR) 12,600,000 50,400,000 126,000,000

High-volume EDU (SMS + CDR peak incoming) / hour 1,865,000 5,282,222 13,205,556

Total elements (EDRs) per day 16,000,000 64,000,000 160,000,000

Ratio prepaid:postpaid 50:50 50:50 50:50

Billing cycles 4 4 4

Contract / Billing Accounts per billing cycle 975,000 3,900,000 9,750,000

Figure 13

Reference volumes Small telco Medium telco Large telco

Step Objects per minute

Objects Objects per day

Runtime (minutes)

Objects per day

Runtime (minutes)

Objects per day

Runtime (minutes)

Inbound 3,327,787.022 EDR records 16,000,000 4.81 64,000,000 19.23 160,000,000 48.08

InvPreProc 149,246.2312 Billing accounts

975,000 6.53 3,900,000 26.13 9,750,000 65.33

InvCreation 80,706.52174 Contract accounts

975,000 12.08 3,900,000 48.32 9,750,000 120.81

PayRun 284,210.5263 Contract accounts 487,500 1.72 1,950,000 6.86 4,875,000 17.15

PayMed 751,898.7342 Contract accounts

487,500 0.65 1,950,000 2.59 4,875,000 6.48

DunPro 654,545.4545 Contract accounts

487,500 0.74 1,950,000 2.98 4,875,000 7.45

DunAct 276,923.0769 Contract accounts 487,500 1.76 1,950,000 7.04 4,875,000 17.60

CorrPrint 47,903.22581 Contract accounts

975,000 20.35 3,900,000 81.41 9,750,000 203.54

DefRev 262,831.8584 Contract accounts

975,000 3.71 3,900,000 14.84 9,750,000 37.10

Total (minutes) 52.35 Total

(minutes) 209.41 Total (minutes) 523.54

Total (hours)

0.87 Total (hours)

3.49 Total (hours)

88..7733

Large telco

Objects per day

Runtime (minutes)

160,000,000 48.08

4,875,000 32.66

4,875,000 60.40

2,437,500 8.58

2,437,500 3.24

2,437,500 3.72

2,437,500 8.80

4,875,000 101.77

4,875,000 18.55

Total (minutes) 285.81

Total (hours)

44..7766

4 Billing Cycles 8 Billing CyclesFigure 14

relative runtimes

Based on the throughput of the reference model, we can determine the runtimes for all three models. We can see from this table that

the large telco volume cannot be handled in the 6 hr window using the available architecture. There are two approaches – add more

capacity, or increase the number of billing cycles (see Fig.14).

By increasing the number of billing cycles from 4 to 8, we can bring the volume through within the 6 hr window by reducing the number

of accounts we need to process within each billing cycle, allowing us to handle the largest telco scenario on the available hardware.

12

Continuous EDr upload with a 4-hour peak

The processing modes up to now have assumed that the EDRs will be buffered and processed as a step in a sequential step chain.

An alternative model may have a constant stream of EDRs arriving and being processed concurrent with the Convergent Invoicing

steps. This removes a large processing step in the critical path, and also has an effect on the resource requirements. The

requirements for the small telco module assume that during the peak usage, the system must manage a volume of 1.3 million EDRs

per hour (see Fig. 15).

The two graphs below depict the small telco model running with concurrent EDR data. The SAPS for the processing steps and the

concurrent EDR upload are stacked for total resource requirement. The Inbound step shows the requirements of the peak EDR upload

phase which runs outside of the processing window (see Figs. 16 & 17).

EDR Peak10:00 - 14:00

Continuous EDR Upload 14:00 - 10:00

Processing Window23:00 - 05:00

08:0007:0006:0005:0004:0003:0002:0001:0024:0023:0022:0021:0020:0019:0018:0017:0016:0015:0014:0013:0012:0011:0010:00 09:00

Figure 15

0

79492

117739109742 109742

82173

45561 3808630378

2253

6245

22532253 2253

2253

22532253

2253

0

20000

40000

60000

80000

100000

120000

SAPS

3 Million Subscribers - Concurrent Loading (<1Hr)

Inbou

nd /

Peak E

DR Load

InvPreP

roc

InvCrea

tion

PayRun

PayMed

DunPro

DunAct

CorrPrin

t

DefRev

"EDR-upload"

Steps

3 Million Subscribers - Concurrent Loading (6 Hrs)

0

13951

3841 3871 38867885

15641 1557215768

2252

6245

2252

2252 2252 2252

2252

2252 2252

0

10000

20000

30000

40000

SAPS

Inbou

nd /

Peak E

DR Load

InvPreP

roc

InvCrea

tion

PayRun

PayMed

DunPro

DunAct

CorrPrin

t

DefRev

"EDR-upload"

Steps

Figure 16: Concurrent processing in shortest possible time

Figure 17: Concurrent processing with smallest infrastructure

13

the contributions and benefits of the infrastructure

Design and benefits of the Power Systems server

The PoC was executed using an IBM POWER5 processor-based IBM Power Systems server and IBM PowerVM hardware

virtualization. PowerVM provides the functionality for processor sharing by means of a shared processor pool. With processor

sharing, the system automatically and immediately realigns itself to changes in the load profile and load distribution over the partitions

in the system. The POC used two active partitions – one for the database and SAP central instance (CI), and one for the production

application servers. The partitions communicated with each other over the Virtual Ethernet functionality of PowerVM, which supports

inter-machine memory to memory communication. This provides the flexibility of a 3-tier design without the network latency (see Fig.

18). A third LPAR in the configuration (clone) was used for testing modifications to the infrastructure prior to use in “production” –

simulating the SAP Test and Assurance system methodology.

LPAR2 (is03d2) Application ServersProcessing mode SharedEntitlement 24Virtual processors 48Sharing mode Uncapped Weight=128Memory 64GB

LPAR3 (Test Clone)Processing mode SharedProcessing units 14Virtual processors 32Sharing mode Uncapped Weight=128Memory 80GB

LPAR1 (is03d1) Database + CIProcessing mode SharedEntitlement 24Virtual processors 48Sharing mode Uncapped Weight=128Memory 98GB

IBM System p5 595 serverInstalled memory 262144MBPhysical processors 64 x 2.3GHz

Figure 18

resource utilization and distribution

Looking at the CPU utilization in the graph below (see Fig. 19), we can see how the CPU requirements (and the distribution of these

requirements across the database and application) servers vary between the multiple steps of the processing chain. This is driven by

the level of parallelization the application can achieve in the various processing steps. In a three-tier architecture, with dedicated

resources, around 60 CPUs would be required to support the peak workload of the application servers (which occurs during the

printing of correspondence) and of the database servers (which occurs during Invoice Creation). Using resource realignment in the

shared processor pool, this peak load was achieved with 52 physical CPUs.

Physical CPU-Load per Business Step

8 1022

14 146 3 2 7 7

42

26

40

29

47

47

3

1410

9

0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

Inbou

nd

BillOrde

r

InvPreP

roc

InvCrea

tion

PayRun

PayMed

CorrPrin

t

BankF

ile

DunnP

ro

DunnA

ct

DefRev

Business Step

Phys

ical

CPU

APPSDB-CI

Figure 19: Reference model: 1 million accounts, 50 million EDRs

14

Parallelization and application scalability

These two graphs (see Fig. 20) show the runtime for each step in relation to the number of parallel jobs and the resulting CPU

utilization. We see that the critical path steps, those which will consume the most time in the processing window, can scale out and be

run in massive parallel mode as demonstrated by these charts for the 1.5 hour runtime window (high-end scalability).

Even during the critical path processing, there is idle capacity in some of the steps, in fact the two steps which use the highest CPU

capacity only run for 60% of the total runtime. It is these two steps which define the resource requirements. Using virtualization, the

CPU capacity does not need be dedicated; these resources can also be shared with other workloads residing in other partitions on

the same POWER5 processor-based server. Resource distribution can be easily controlled using a simple priority scheme. Thereby

the resource distribution remains predictable, and yet this flexibility via dynamic realignment provides a higher total processing

capacity. This is very beneficial for a fluctuating volume or highly deviant processing requirements, as represented by this processing

chain, and typical in multi-step processing.

Benefits of DB2 database technology

The EDR-based Convergent Invoicing scenario has several characteristics which directly relate to database technology. The influx of

mass billing data (EDRs) into the system results in the creation of several extremely large database tables. The table holding the EDRs

for this PoC reached nearly 500GB; the size prediction for production implementations is in the terabytes. The entries in this table will

need to be maintained for a given period of time (for example 180 days online), depending on legal requirements, and then dropped

after a set period. In order to facilitate this periodic dropping of data, some type of table partitioning is recommended to allow this to

occur with as little disruption as possible.

IBM DB2 offers two solutions which fulfill the table data management requirements: range partitioning and Multi Dimensional

Clustering (MDC). Of the two, MDC is the preferred approach for SAP solutions and is unique to DB2. MDC provides not only

improved query performance but also fast data roll-in and roll-out operations which eases the data management overhead, in this

case the removal of masses of expired EDR data.

The DB2 Deep Compression feature was used in this proof of concept to compress these very large tables, saving disk and memory

space, and reducing I/O overhead. Savings of 75-85% for most of the key largest tables have been realized which would translate into

an overall savings of 30 to 40% of the total database size.

Inbou

nd

BillOrde

r

InvPreP

roc

InvCrea

tion

PayRun

PayMed

CorrPrin

t

BankF

ile

DunnP

ro

DunnA

ct

DefRev

0%

5%

10%

15%

20%

25%

30%

35%

40%

00

20

40

60

80

100

120

140

160

Para

llel J

obs

% T

otal

Run

time

Step Runtime & Parallelism (1.5 Hr)

%Runtime

Parallel

%Runtime

PhyCpu

00

10

20

30

40

50

60

PhyC

PU

Inbou

nd

BillOrde

r

InvPreP

roc

InvCrea

tion

PayRun

PayMed

CorrPrin

t

BankF

ile

DunnP

ro

DunnA

ct

DefRev

0%

5%

10%

15%

20%

25%

30%

35%

40%

%Ru

ntim

e

CPU & Runtime per Step (1.5Hr)

Figure 20: Reference model: 1 million accounts, 50 million EDRs

15

Conclusions of the solution’s proof of concept

Meeting today’s it challenge

The PoC has shown that by running SAP Convergent Invoicing on Power Systems hardware and DB2, it is possible to process

enormous EDR volumes, and run a same-day billing system, even with relatively modest IT resources.

For businesses facing the challenge of running a complex, high-volume billing environment, the implication of the PoC is clear: IBM

and SAP can provide a rapid, robust and highly economical solution that makes the most of hardware resources by leveraging IBM

virtualization technologies and the highly optimized DB2 database platform.

flexibility for future business challenges

As the service portfolio of telecommunications providers evolves and as subscriber numbers grow – organically in the case of

up-and-coming players or through acquisition and market consolidation – adaptability and flexibility are essential. This requires an

easy-to-adapt data model as well as a system architecture that can grow with the business making good use of initial hardware

investments. The combination of SAP Convergent Invoicing and IBM computing infrastructure fulfills both requirements.

The adaptability and flexibility demanded by the new business processes are reflected in this highly adaptable application design,

and this dynamically responsive infrastructure. The scalability demanded by the business process models and the expected future

growth in volume, is met by the scalability of the application and the high performance Power Systems server infrastructure. The

continuous data capture, inherent to such solutions is supported by unique functionality in the DB2 database in regard to

performance and non-disruptive administration of the mass data.

The PoC set out to answer one critical question: can the solution handle the enormous volumes of data that such applications

will generate?

We know now that it can.

© Copyright 2009 SAP AG SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf

SAP, the SAP logo, SAP and all other SAP products and services mentioned herein are trademarks or registered trademarks of SAP AG in Germany and several other countries.

IBM Deutschland GmbH D-70548 Stuttgart ibm.com/solutions/sap

IBM, the IBM logo and ibm.com are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. A current list of other IBM trademarks is available on the Web at “Copyright and trademark information” at http://www.ibm.com/legal/copytrade.shtml.

Intel, the Intel logo, Intel Xeon and the Intel Xeon logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Other company, product or service names may be trademarks, or service marks of others.

This case study illustrates how one IBM customer uses IBM and/or IBM Business Partner technologies/services. Many factors have contributed to the results and benefits described. IBM does not guarantee comparable results. All information contained herein was provided by the featured customer and/or IBM Business Partner. IBM does not attest to its accuracy. All customer examples cited represent how some customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics will vary depending on individual customer configurations and conditions.

This publication is for general guidance only. Photographs may show design models.

© Copyright IBM Corp. 2009. All rights reserved.

SPL03002-DEEN-01 (May 2009)

This paper is based on a more comprehensive technical document, available at

http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101231

To learn more about the solutions from IBM and SAP, visit ibm-sap.com

For more information about SAP products and services, contact

an SAP representative or visit sap.com

For more information about IBM products and services, contact an IBM

representative or visit ibm.com

For more information on this specific solution, visit

ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101231

Contacts:

SAP

www.sap.com/contactsap for enquiries/requests

www.sap.com/telecommunications for further info

IBM

For further questions please contact the IBM SAP International Competency

Center via isicc@de.ibm.com