IBM Scalable Architecture for Financial Reporting

Building in performance from the ground up
Using detailed transaction-level data as the backbone of financial reporting systems offers almost endless adaptability to changing business demands. However, the effort needed to effectively utilize high volumes of data should not be underestimated. Implementing workarounds that do not leverage the power of detailed transaction data can create larger, more pervasive, and complex problems in the long run. IBM's experience dictates that scale must be built-in—it cannot be added after the fact. Converting a one-story building into a five-story building is much more expensive than building a five-story building in the beginning. The same is true when working with Business Intelligence systems. IBM® Scalable Architecture for Financial Reporting™ (SAFR) applies proven methods and techniques to deal with high-volume problems and scalability.

Coping with ever-shrinking batch windows
SAFR is designed to deal with batch window pain—the inability to quickly create multiple outputs such as cubes, reports, data marts, etc. This pain is caused by high query volumes, high table lookup (join) volumes, and high data volumes. SAFR provides solutions to the following issues:

• High query volumes. SAFR responds by processing multiple queries in a single scan, avoiding the use of indexes—that is, by providing a "single—pass architecture"
• High table lookup volumes. SAFR responds by doing the following:
  • Exploiting shared in-memory tables and 64-bit memory
  • Leveraging the symmetric multiprocessor (SMP) architecture of the mainframe
• High data volumes. SAFR responds by doing the following:
  • Generating machine code, tailored to the specific problem at hand
  • Highly tuning code for System z, with short instruction path lengths
  • Exploiting efficient I/O techniques for both disk and tape
  • Processing data partitions in parallel
  • Summarizing large quantities of data in memory
  • Piping data from one transform to the next, reducing I/O

The SAFR architecture improves performance for data scanning operations, which are traditionally very expensive. Scans make sense under the following conditions:

• When you need to summarize a whole table to get balances, as in financial reporting
• When you need to scan a whole table for data mining purposes
• When you do not have the appropriate indexes on your database tables for random access
• When your data is on sequential media, such as tapes

SAFR can efficiently process data from sequential, VSAM, and DB2 sources.

The System z advantage
This SAFR solution can be made possible only with the inherent architectural strengths of z/OS™ and System z™. The platform you know as the best of breed for online transaction processing (OLTP) can be a solid foundation for Operational Business Intelligence in your enterprise. Many vendors cannot supply a truly efficient and high- performance operational reporting solution because using operational data has drawbacks—the volume of detail history can be overwhelming and multiple requests contending for access to the data may cause bottlenecks and performance issues in traditionally distributed systems. System z thrives in this environment.

SAFR can run during prime time with minimal effect on your online systems. And it can run during off hours, generating massive amounts of standard reports efficiently within your batch window. It requires the following hardware and software components:

• System z9® or z10™
• z/OS V1.8 or later
• DB2® for z/OS or DB2 LUW V8 or later (for use as a metadata repository and optionally as a data source)
• z/OS DFSORT™ or equivalent

In addition to making good use of traditional System z resources, SAFR can offload standard CPU cycles to the System z Integrated Information Processor (zIIP). By doing so, SAFR can make batch reporting workloads very cost-effective.

Solving enterprise-class problems
The complexity of airline ticketing processing makes it an easy target for fraud. Statistical sampling at a major airline found millions of dollars in losses each month, but statistical sampling couldn't stop the problem. They decided to see if SAFR could. Programmers used the SAFR application programming interface (API) to connect to their legacy hierarchical database. They executed queries against the database looking for cases of fraud and suspicious patterns. SAFR spawned 30 parallel processes which read 170 different partitions from the production database and resolved 23 different queries in a single scan of the source data. As a result, the company identified all the cases of fraud detected within the statistical sample. But SAFR took them beyond sampling, identifying all similar cases from an entire year's worth of tickets. The company immediately dismissed a number of employees and issued debit memos to violating travel agencies. It recovered millions of dollars in lost revenue.

Increasing return on IT investment
IBM Scalable Architecture for Financial Reporting is designed to offer a low total cost of ownership by providing the following:

• Enterprise reporting at a low cost on a per-unit basis
• Scalability to grow with your organization's needs
• Efficient use of system resources, such as CPUs, I/O channels, and memory
• Customizable systems that enable you to buy only the technology you need
• Reduced need for manpower to build systems and rules, which can help save time and money