Sizing and Planning Questionnaire

IBM / ACI

IBM AMERICAS TECHLINE SIZING CENTER

Phone: 800-426-0222 or 770-835-6690
E-mail: [email protected]

What is a sizing estimate?

A sizing estimate is an approximation of the hardware resources
required to support an application. It is a pre-sales effort based on
information available from a specific benchmark, providing an entry
into understanding the customer’s hardware requirements.
Customers’ actual experiences will vary from the sizing estimate for
many reasons, including differences in implementing the application,
batch and reporting workloads, and custom code. The degree of
variability can range from small to very significant. IBM assumes no
liability for actual results that differ from the sizing estimate. Once
the product(s) are installed in the customer environment, it is the
customer’s responsibility to verify the sizing and evaluate the future
capacity requirements.

IBM/ACI/ENTERPRISE PAYMENT SYSTEM SIZING AND PLANNING QUESTIONNAIRE

VERSION 2.0
MARCH 27, 2002

IBM / ACI/Enterprise Payment System Sizing Questionnaire Version 2.0 Page 1

 Table of Contents

PURPOSE OF THE QUESTIONNAIRE...................................................................................................................3

IMPORTANT CONTACT INFORMATION............................................................................................................4

SYSTEM CONFIGURATION....................................................................................................................................5
ENTERPRISE PAYMENT SYSTEM REQUIREMENTS........................................................................................................5
APPLICATION SIZING..............................................................................................................................................6
THROUGHPUT CONSIDERATIONS.................................................................................................................................6
AVAILABILITY CONSIDERATIONS................................................................................................................................7
ASSUMPTIONS AND CAVEATS.....................................................................................................................................8
PROFILE OF ENTERPRISE PAYMENT SYSTEM...............................................................................................................9
SIZING INPUTS.........................................................................................................................................................10
ON-LINE TRANSACTION VOLUMES............................................................................................................................10
RESERVE SYSTEM CAPACITY....................................................................................................................................10
DISK REQUIREMENTS................................................................................................................................................11
Sizing Output Information.........................................................................................................................................13

IBM / ACI/Enterprise Payment System Sizing Questionnaire Version 1.0 Page 2

PURPOSE OF THE QUESTIONNAIRE

The purpose of this questionnaire is to collect information that will be used to develop a sizing estimate
for the implementation of ACI/Enterprise Payment System Applications on IBM zSeries hardware. The
definition of a sizing estimate was defined on the cover above. Please make sure the meaning of
sizing is clearly understood.

Instructions for Completing the Questionnaire

1. Make Sure You Have the Current Version of the Questionnaire

Over time we revise the Sizing Questionnaire, and before taking the time to complete it you should
make sure you have the most recent version. For a softcopy of the questionnaire, please download
from http://www.ibm.com/erp/sizing or send a request to the IBM Americas Techline Sizing Center at
[email protected].

2. Obtain Assistance if Necessary

If you need assistance Dan Archer ([email protected]), the ACI/Enterprise Payment

System representative, can provide support or you can send your questions to the IBM Americas
Techline Sizing Center at [email protected] or call us at 800-IBM-0222.

3. Complete the questionnaire.

Instructions are located within each section. All information in the General Information Section must
be provided before a sizing estimate can be developed. The Database Disk Requirements section
may be left blank if you do not wish to receive a database sizing estimate.

4. Return the completed Questionnaire to IBM

Send a softcopy of your completed questionnaire to IBM via e-mail it to [email protected] . We

will return your questionnaire along with the completed sizing estimates.

IBM / ACI/Enterprise Payment System Sizing Questionnaire Version 1.0 Page 3

IMPORTANT CONTACT INFORMATION

It is often necessary during the sizing of a system to contact the customer or reseller for further
information. Completion of the following details will help avoid delays in processing the sizing request.
Company Name:

Company Address:
Include: Street, City,
State, Province,
Country
Industry:

Contact Primary Secondary

Name:

Contact Title:

Telephone Number:

Contact Fax Number:

Email Address:

Questionnaire Completed by:

Name: Title:
Phone Number: e-mail:
Date Completed:
Date Sizing estimate
required by:
IBM Contact (if
known)
Contact Name Phone Number e-mail
IBM Client Rep:
IBM Product
Specialist:
IBM ACI/Enterprise
Payment System
Specialist:
IBM Opportunity OMSYS #:
IBM Business
Partner:
ACI/EPS Rep:
System Integrator:

IBM / ACI/Enterprise Payment System Sizing Questionnaire Version 1.0 Page 4

SYSTEM CONFIGURATION

Indicate Version of ACI Software to be installed:

 APPLICATION SUITE (check one):
ACI – Enterprise Payment System

Select Platform for ACI/Enterprise Payment System:

 PLATFORM (check one) Configuration (check one where needed)
zSeries
S/390

Enterprise Payment System Requirements

ACI Enterprise Payment System is designed to operate on any IBM or IBM compatible processor that
supports one of the current releases of the MVS operating system and meets the combined
requirements of CICS, the operating system and the application. Hardware and software
configurations depend on customer application and performance requirements.

Platforms capable of supporting this environment include the S/390 Parallel Enterprise Server and the
z900 running z/OS.

The Enterprise Payment System requires the following software components on the host* system:
 OS/390 version 2, release 10 – or – z/OS version 1, release 1
 CICS Transaction Server (TS) – version 1, release 3
 Communications Server for OS/390 Version 2 Release 10
 TCP/IP CICS Support
 DFSMS/MVS
 VSAM with Record Level Sharing (RLS)
 UNIX System Services
 JES2 or JES3
 DFSORT (or compatible product)
 Language Environment
 Assembler (High-level)
 COBOL for MVS, or COBOL for OS/390 (ATM acquirer only)

*Additional components are required for the client.

IBM / ACI/Enterprise Payment System Sizing Questionnaire Version 1.0 Page 5

APPLICATION SIZING

To preface these guidelines, it is important to understand that good performance is the achievement of
agreed service levels. This means that system availability and response times meet the user's
expectations using resources available within the institution’s budget. Key factors of computing
system performance include:
 System response time: this depends on the design and implementation of the code, and the
power of the processor. ACI has over 25 years of experience optimizing applications to process
financial transactions. While this is not the only factor to consider it is the element over which ACI
has the most control regarding excellent performance. However, ACI endeavors to affect all
aspects of computing system performance.
 Network response time: this can amount to seconds, while responses in the processor are
likely to be in fractions of seconds. This means that a system can never deliver good responses
through an overloaded network, however good the processor may be.
 Data Storage (DASD) response time: this is generally responsible for most of the internal
processing time required for a transaction. When implementing an application ACI considers all
I/O operations that affect a transaction.
 Existing workload: applications sharing resources (CPU, Memory, DASD, etc.) may affect
the performance of new transactions, and vice versa. In planning the capacity of a system, an
institution must consider the total load on each major resource, not just the load for the new
application.
This section is intended to outline some of the factors involved in a hardware sizing exercise of an
Enterprise Payment System implementation. The data presented takes two standpoints into account:
1) from a throughput perspective and 2) from an availability perspective. The user should determine
the appropriate mix of this information based on the priority defined in the institution’s business
requirements.

Throughput Considerations
An institution processing financial transactions must be concerned with the measure of Financial
Transactions Per Second (FTPS) it is able to process. If the peak volumes of the day cannot be
processed within acceptable time parameters, additional system resources or system configuration
changes may be necessary. The following areas of configuration should be taken into account for an
Enterprise Payment System sizing exercise.

Multiple Transaction Servers

The Enterprise Payment System is designed to allow the user to configure the optimal number of
payment “engines” for processing financial transactions. This number dictates how many times the
transaction server will “replicate” itself to assist in processing financial transactions that have been
placed on the Transient Data Queue for a specific CICS region.

Multiple CICS Regions (CICSPlex)

Exclusive of high availability benefits, the Enterprise Payment System can be configured to operate in
a CICSPlex environment to facilitate higher throughput of financial transactions (a.k.a. – Multiple
Region Option or MRO). This section focuses on the performance of the application within configured
“Target Regions” (formerly AOR) and does not take into account the “Routing Regions” (formerly TOR)
where communication with devices and interchanges is managed.

Using IBM’s Workload Manager financial transactions can be distributed among multiple Target
Regions running the Enterprise Payment System. The allocation of transaction volume is controlled by
Workload Manager and is based on the user’s available system resources and their business
priorities.

IBM / ACI/Enterprise Payment System Sizing Questionnaire Version 1.0 Page 6

Multiple CPUs
Within a Central Processing Complex, the number of CPU’s available for financial transaction
processing workload is transparent to the Enterprise Payment System. However, like any other
application, there are practical limits to the number of CICS regions and Enterprise Payment System
transaction servers that could be associated with a single CPU. This is due to the architecture of CICS
and the manner in which it accesses the system resources that have been allocated to each region.

Dedicated CPUs
Performance benchmark1 exercises of the various test scenarios to date have been performed using
combinations of CICS regions and Enterprise Payment System transaction servers with dedicated
CPUs. In a production environment, CPU resources are commonly shared among applications and
CICS regions, as well as Logical Partitions (LPAR). A sizing of the Enterprise Payment System in a
shared CPU environment would require further performance analysis that considers the impact of
other application running in the shared environment.

Disk I/O and File Structure

As with any CICS application, it is important to consider the optimum VSAM file definitions to provide
for the most efficient use of I/O resources. The most recent Enterprise Payment System performance
tests utilized IBM’s Enterprise Storage Server (a.k.a. “Shark”) connected via ESCON channels
(Enterprise System Connection). IBM has indicated that FICON channels (FIber CONection) will be
made available with the Shark Server on the zSeries providing Full Duplex data transfer instead of Half
Duplex thereby reducing the impact of I/O performance in the transaction path.

Availability Considerations
While the ability to handle peak transaction volumes is critical, it is of little value if the network is not
accessible 24 hours a day. Financial service providers must consider a system configuration that
allows for planned and unplanned outages. A key factor in providing such a level of service is an
application that is designed to operate without ever having to stop for either of these scenarios. The
Enterprise Payment System is such an application.

Application Level
Application configuration settings and authorization scripts are loaded into CICS memory at region
startup time and upon user request. Changes to configurations and to authorization logic controlled by
scripting can be implemented without interrupting financial transaction processing. If changes are
required, the application’s user interface provides the flexibility to load and re-load these values into
memory. This major contributor to the high availability of the application is a standard feature and
does not impact the sizing of an Enterprise Payment System implementation.

Allowing the dynamic initiation of multiple transaction servers within a single CICS region allows for
greater throughput and maximizes the resource utilization allocated to the region. Benchmark tests
have shown throughput improvements by running three transaction servers per CICS region. This
assumes there are sufficient hardware resources available to sustain the higher transaction rate.

Within A CICSPlex
VSAM Record Level Sharing (RLS) provides multiple applications the ability to access shared data.
Because the Enterprise Payment System is designed to take advantage of RLS, it is possible to
operate the application in multiple CICS regions utilizing CICSPlex System Manager (CP/SM) in

1
Benchmark processing was performed using a 4-Central Processor (CP) Logical Partition (LPAR)
configured on a model 2064-116 zSeries Server. The database and other key data were stored on an
IBM 2105 Enterprise Storage Server (ESS or Shark). The tests were conducted in a Parallel Sysplex
environment employing VSAM record-level sharing across the Sysplex.

IBM / ACI/Enterprise Payment System Sizing Questionnaire Version 1.0 Page 7

 conjunction with WorkLoad Manager (WLM) to balance the financial transaction processing workload
and share data. This feature of the Enterprise Payment System allows for scalability of the application
to meet growing transaction volumes.

An important decision point related to CICSPlex configuration is whether to use dedicated or shared
CPU resources. As indicated earlier in this section, ACI’s tests involved dedicated processors in the
various scenarios. CICS architecture employs a single “channel” for application processing and
another “channel” for I/O processing. Assuming each region has a dedicated processor and sufficient
memory, performance should not degrade until all MIPS are consumed.

Operating in a CICSPlex allows for planned outages to perform routine maintenance as well as
unplanned outages due to unforeseen problems. CICS regions can be configured with auto-restart
capabilities to allow for automatic recovery in the event of an unplanned outage. For this reason the
Enterprise Payment System should be configured with at least one CICS region more than what is
required to process the peak financial transactions-per-second volume.

Within A Sysplex
Operating the Enterprise Payment System in a Sysplex environment, whether in multiple LPARs on
the same machine or on different machines, does not pose significant impacts to the sizing
recommendation. However, additional processing power (CPU, memory, DASD, etc.) should be
considered due to the complexities inherent in the varying degrees of availability and fault tolerance
that may be required by any institution’s environment.

Assumptions and Caveats

The resource recommendations are based upon the following assumptions from benchmark testing:

1. The ACI definition of a transaction includes all of the messages required to process a financial
transaction. A financial transaction may include multiple request and response messages.

2. Sizing estimates for Enterprise Payment System are based on the peak financial transactions per
second (FTPS), which can be calculated from the monthly transaction volume. Based on industry
experience and regional knowledge, ACI uses algorithms specific to geographic locations. A peak FTPS value
supplied by the customer should be used if that customer has empirical data to support their transaction rate.

3. IBM recommends that total LPAR CPU utilization for z/OS be at 90% or less and the CPU utilization
for CICS regions be at 70% or less.

4. For CICS regions approaching 70% busy, IBM recommends a dedicated CPU per CICS region.

5. The sizing tool only considers the Enterprise Payment System workload, additional capacity may be
required to support a customer's fault tolerance / high availability requirements.

6. Sizing estimates only include the Enterprise Payment System production workload. Customers
should consider their test system requirements for certification testing, ongoing support, etc. A typical
test system consists of a small subset of the production configuration. If a customer already has excess
discretionary workload capacity additional capacity may not be required to support the test system.

IBM / ACI/Enterprise Payment System Sizing Questionnaire Version 1.0 Page 8

Profile of Enterprise Payment System
ACI Enterprise Payment System is an integrated e-payment processing engine, providing application
software to acquire and authenticate, route, switch, and authorize transactions regardless of the
channel in which they originate. Organizations in many industries – including finance, retail,
telecommunications, and data processing – can use Enterprise Payment System to process
transactions from any endpoint, including Internet shopping networks, mobile phones, Web ATMs, and
home banking systems. The software also can be used to upgrade legacy ATM and point-of-sale
systems, adding support for new features such as smart card programs and electronic check
processing.

Key features of the Enterprise Payment System include:

 Provides comprehensive support for consumer e-payment transactions, including credit,
direct debit, and chip cards.
 Supports consumer authentication and authorization processing through a powerful scripting
engine, giving users the ability to alter application logic without having to modify source code
 Provides flexible switching and routing to major networks, card associations, and processors
 Supports EMV, multi-currency, and multi-language processing
 Supports leading POS devices and ATMs
 Supports new e-commerce delivery channels, including the Internet, PDAs, and mobile
phones
 Integrates with other products within the ACI Commerce Framework to facilitate acquisition,
processing, and management of transactions from both traditional and new “e” channels
 Supports high volume, high availability processing through a scalable 24/7 fault tolerant
architecture optimized for IBM zSeries servers
 Utilizes industry standard technologies, such as C++, Java, Object Oriented Analysis and
Design (OOAD) and XML
 Supports multiple communication protocols
 Provides a task-oriented graphical user interface for management and configuration of the
S ys ple x
system
EXTERNAL
EXTERNAL
-- Acq.
Acq. Host
Host
-- IVR
IVR
-- Other
Other zSeries
CICS VISA
VISA

T Enterprise Payment T
C C
P
System P MasterCard
MasterCard
/ /
I I
P Scripting P
XML

Other
Other

Authorization
Authorization Data
Data
Shared
VSAM

GUI
Security
IBM / ACI/Enterprise Payment System Sizing Questionnaire
Device Version 1.0 Page 9
SIZING INPUTS

This questionnaire can generate up to five separate sizings. Please name them under “application” in
the table below. (e.g. “test”, “production”, “future production”) Ideally, these multiple sizing will be
used to accommodate future growth scenarios

It is important to look at the sizing in terms of the planned roll-out of the ACI/Enterprise Payment
System product. The most important exercise is the short term sizing as it is the most certain. As time
goes on many factors may change including the ACI/Enterprise Payment System product itself.
Therefore, this sizing allows for the immediate requirements and up to four future estimates; the latter
are more likely to change in depending on the user and the product.

On-line Transaction Volumes

Phases1 Peak Financial Transaction Per Total Financial Transactions per
Second 2 Month

1. Customer can provide up to 5 different projected sizing phases for your implementation environment.

2. Peak is the season where the transaction volume per hour is the highest in the whole calendar
year

The formula for calculating peak Financial Transactions Per Second (FTPS) has evolved as a result of
ACI’s 25+ years of commitment to e-payments processing. Providing support for some of the highest
volume processing systems in the world, ACI has an understanding of this metric and has arrived at a
method used to determine a reasonable estimate of an institution’s peak volumes.

At a high level, a peak day is a percentage of that institutions monthly volume. From that point,
regional factors are applied as consumer spending habits vary worldwide. A peak hour is determined
based on this regional factor. With a peak hour volume determined, simple math is used to arrive at
the peak FTPS which is then increased by a factor to accommodate for unknowns.

Reserve System Capacity

Enter the amount of CPU capacity reserved for other workloads:
 The Enterprise Payment System can operate on an existing machine with other applications.
Please consider the amount workload dedicated to any other applications that will share this
machine.
 Include any potential future growth as depicted in the sizing input table.

IBM / ACI/Enterprise Payment System Sizing Questionnaire Version 1.0 Page 10

 The CPU requirement is calculated by projecting the on-line requirements, then considering the
reserve system capacity as percentages of the calculated requirements.
Type Percentage of CPU reserved for sizing projection:
Batch & Other workloads
(zSeries)
System Safety ( zSeries )

Is this application residing on a machine that the customer already has? If the answer is yes, then
supply the machine below and the sizing will add CPs to this machine as the output of the sizing. Also
the “Batch & Other workloads” must contain the amount of the system used already. This can be
100%.

Add to current machine (Yes or No) Machine Type

The following questions refer to the application as it ran in the benchmark described previously. Do
you think your use of the application will be similar to the benchmark? If your reply is “NO” you may
need to consult with ACI/Enterprise Payment System representative to find out how to adjust the sizing
to fit your intended use of the application.

Is your use of the application similar What percent should the sizing be adjusted by?
to the benchmark (Yes or No) (It can be less than 100%)

Disk Requirements
The sizing tool will provide a high level estimate based only the following information. See
descriptions below for clarification of each requirement.

Phases1

Number of days to retain transaction Journal (1 record

created for each financial transaction processed)
Number of cardholder records (only those maintained in
application-owned files)
Number of application accounts (checking, savings, etc.
– associated with the cardholder)
Number of Devices – ATM

Number of Devices – POS

Number of merchants – POS Acquiring

Other

1. Customer can provide up to 5 different projected sizing phases for your implementation environment.

IBM / ACI/Enterprise Payment System Sizing Questionnaire Version 1.0 Page 11

 Sizing an EFT system can vary greatly among implementations. The listed requirements are a
compilation of the variables with the most impact to a sizing.

 Transaction Journal – This is a set of VSAM files used to record the activity through the
Enterprise Payment System. There is one record logged for each financial transaction request
and response combination. The application supports a “ring of files” structure in which the
minimum configuration consists of yesterdays business in one file, today’s business in another file,
and one empty file for the next business days activity. The customer may also specify up to 99
files of business day retention and up to 99 files of future business days (used to log transactions
that will occur in the future). Additionally, for higher volume environments, multiple sets of these
“rings” of files can be configured per institution to overcome restrictions in hardware I/O throughput

 Cardholder Records – This is the actual number of plastics maintained in the application’s
cardholder file. From an Issuer perspective, this file will house one record per plastic card issued
if the application is intended to be used as the database of record or for stand-in authorization
purposes. If the issuer uses some other 3 rd party product to house their plastic cards and that
system also authorizes the transactions, it is possible this file may not be used. From an acquirer
perspective, the cardholder file would typically be used if stand-in is performed for institutions the
acquirer may process for. In this case, the cardholder file and any associated account files
(described later) are typically refreshed nightly with files from the issuer.

 Accounts – This is the number of application accounts (checking, savings, credit, etc.) that may
be associated with the plastic cards. In many instances, there will only be one account per plastic
card. In others, as in US markets, multiple application accounts can be associated with one plastic
card (usually a debit card scenario). In some instances, there may be multiple plastic cards
associated with one application account (usually a credit card scenario).

 ATM Devices – This is the number of actual ATM devices the institution is managing with the
Enterprise Payment System for which a record will be maintained. Regardless of the model(s) of
machines the institution owns, there will be a record created for each of those machines owned
and actually operated with the ACI application.

 POS Devices – This is the number of actual POS devices the institution is managing with the
Enterprise Payment System for which a record will be maintained. Regardless of the model(s) of
machines the institution owns, there will be a record created for each of those machines owned
and actually operated with the ACI application.

 Merchants – This is the number of the actual relationships that this institution has with merchants
to manage their POS transaction acquiring. Regardless of the number or model(s) of machines
the merchant uses, there will be a record created for each of those merchants the institution
manages devices for.

 Other – As implementations vary greatly, any significant data in regard to sizing should be noted
here. This may be related to custom or unique processing requirements or business models.

IBM / ACI/Enterprise Payment System Sizing Questionnaire Version 1.0 Page 12

 SIZING OUTPUT INFORMATION

This section is the output of the Sizing Tool. Refer again to the introduction section for a definition of a
sizing. The meaning of the data in the table below is as follows:

 Run: The name given to this sizing.

 Total LSPR: The “Large System Performance Ratio” is derived from the benchmark machine
using the CBW2 workload. If a single machine will handle the workload, that machine is
derived by the sizing tool based on this LSPR requirements.

 Num: The number of machines required, is more than one, then the full requirement is divided
by “num” and then the machine, “

 Each LSPR: Look up so that a multiple number of these machines is recommended.

 Recommend: This machine is closest to meeting the requirement of “Each LSPR” without
going over. If the user has provided a machine to add this application to, then this represents
the total requirement of the existing workload and the new application.

 MSU is the published Machine Service Unit for the Machine. Some applications use this in
calculations.

 Gartner MIPS is the current Gartner MIPS for the total machines recommended to contain all
specified items. Use the percents in the pie chart to obtain the MIPS for each piece

 The DB Size is the total Megabytes for the data in the data base based on the calculation
given to us by ACI.

Total Each Recomend Gartner DB S izeMemory

Trans /s ec Run LS P R Num LS P R MS U MIP S MB Meg

CPU Pie Chart

The Chart below represents the breakdown as a percent of the total CPU requirement. This indicates
how the proposed CPU is going to be used.

IBM / ACI/Enterprise Payment System Sizing Questionnaire Version 1.0 Page 13