June 2015!Steve Emmerich!Chief Architect / Technical Fellow!ACI Worldwide Inc.!

Data Management for Mission-Critical Real-Time Financial Systems!

Who am I, Steve Emmerich?

●  Involved in data analysis/management software since 1970 ●  High School, University, Grad School studies in Computer Science ●  Consistent computer-related interests

●  Overcoming I/O challenges of Super- & Parallel-processing ●  Persistence technologies that support OLTP, analytics ●  I/O architecture matching other hardware trends (e.g. Cloud) ●  Design (anti-) patterns for non-functional requirements ●  Continuous learning, teaching, mentoring, influencing

●  Professional experience ●  Engineering (leadership) in UNIX / microprocessor / parallel processing startups ●  Founded and ran data warehousing/business intelligence firm ●  General manager of national systems integration practice ●  Chief Architect, VP Engineering for quite a few data-centric firms ●  Currently Chief Architect at ACI Worldwide Inc.

●  Helped establish strong foundational NFR focus ●  Leading many aspects of data management strategy ●  Influencing software architecture across 20+ strategic areas

2

Who (in the World) is ACI Worldwide Inc.?

$1B Payment Software Provider (Maybe the World’s Largest)

Global customer base in 80+ countries on 6 continents

40 years of payments expertise

24x7x365 global support organization

4,600+ customers use hosted solutions

~$1 Billion Revenue 18% on R&D annually

21 of the world’s top 25 banks rely on ACI software; many payment processors as well

Prevent fraud for 360+ payment organizations worldwide

Serve 300+ retailers globally

Handle bill pay for 3,600+ organizations

Four Market Segments of ACI’s Business … ACI delivers solutions that serve four broad but distinct market segments

PAYMENT RISK MANAGEMENT

Consumer Bank **

Transaction Bank †

Retailers Billers

FRAMEWORK, MOBILITY & TOOLS

HOSTED & ON PREMISE SUPPORT MODELS

** Includes Consumer-facing payment ecosystem players, such as Card payment acquirers and issuers, payment processors, associations, etc. † Includes Business-facing payment ecosystem players, such as Treasury departments of corporations, network and institutional intermediaries supporting “wire” payments, ACH payments, etc.

Channels and Interfaces

ACI’s Legacy: 30-Year Old Real-Time Architecture

BASE24

ATM

Auth

DB

Bank’s System

Other Systems

HOST

HSM

ATM POS Networks

On Tandem Non-Stop Architecture

… ACI’s original claim to fame in the Banking and Merchant Retail worlds, NSK (TAL) only

BASE24

ATM

Auth

DB

Bank’s System

Other Systems

HOST

HSM

Asynchronous Replication

router

Integrated Server

Integrated Server

SAN

Websphere MQ Websphere MQ

OS Clustering DB Server DB Server

ICE-XS ICE-XS

High-Availability Cluster Multi-Processing

ACI’s Next-Generation Switch: “Base24-eps” … C++, database-neutral, runs on modern HW architectures, more or less infinitely scalable

router

Integrated Server

Integrated Server

SAN

Websphere MQ Websphere MQ

OS Clustering DB Server DB Server

ICE-XS ICE-XS

High-Availability Cluster Multi-Processing

Asynchronous Replication

BASE24-eps Performance/Scalability

●  Deeply performance-architected with no known performance inhibitors ●  Generalized resource partitioning (no bottlenecks) ●  Symmetric, no process- or memory-affinities that create asymmetries ●  Potential database bottleneck mitigated by extensive partitioning of

application journals ●  Throughput

●  >= 2000+ sustained business transactions-per-second / “node” ●  Linear resource consumption per transaction ●  No resource constraints at peak (other than cpu)

●  Response-time (latency) ●  Extremely low, stable response times ●  50-100ms at peak load ●  The lower the latency, the more room in the transaction path for

additional value-added services (e.g. Fraud detection)

… Requirements include completely predictable performance and scalability, with no spikes

Fast, scalable authorization & switching of payment transactions

●  Continuous availability ●  No single points of failure ●  Real-time logic and schema changes

●  Strong geo-distribution with active/active support ●  Elimination of both planned and unplanned outages ●  Removes the need for fault-tolerant hardware

●  System behavior under stress predictable and manageable ●  Queuing to handle volume spikes

●  Application is first line of defense ●  No single point of failure in transaction path ●  Context/state-free processing ●  Designed from ground-up for High Availability at all levels ●  Network Overload Management (NOM) at endpoints

BASE24(-eps) Availability … Requirements include withholding permission for downtime (planned or unplanned)

No-fail authorization & switching of payment transactions with deployment-time adaptability

●  Deployment-time/On-line logic updates ●  Rolling process changes ●  Instantaneous introduction of new authorization scripts ●  Dynamic addition and removal of business services

●  Deployment-time/On-line application and schema changes ●  Application-level database versioning ●  Real-time table conversions ●  Rolling software upgrades

●  Deployment-time/On-line configuration changes ●  Command-level or bulk

BASE24(-eps) Availability Requirement

No-fail authorization & switching of payment transactions with deployment-time adaptability

… Requirements include withholding permission for downtime (planned or unplanned)

Next-Gen Architecture Requirements for ACI ●  Experience since Base24-eps indicate that real unmet

business needs exist ●  Away from discrete systems for siloed LOBs and payment types

and towards combined functionalities, to avoid redundancy ●  Towards real-time (“Immediate”, “Faster”) payments – not just

payment initiation, but also clearing, settlement, reconciliation ●  Towards any-to-any payments (e.g. persons and/or businesses) ●  Towards truly global (notwithstanding cross-border challenges)

●  Existing payment systems will remain and be very important. But the traditional LOB boundaries will diminish ●  Example: solutions for Merchant Retail POS and BillPay support

will converge (since the only essential difference as far as the consumer is concerned is when payment is made)

●  Example: the need for and trend towards real-time payments will apply to any type of payment (high or low value, high or low volume). These types of payments have historically been handled by different systems.

Implications of Change for Next-Gen Architecture

●  Imperative: create an architecture that enables satisfying both continuing needs of existing payments ecosystems and new payments ecosystems, that overcomes the following impediments to business and technical change ●  Payment service consumers: some don’t want change ●  Payment service suppliers: existing LOBs threatened by change ●  Regulatory: government-led change varies greatly by region ●  Integration: legacy systems are hard to replace ●  Nevertheless, our customers are continually demanding much

more comprehensive functionalities that span our traditional segments (Consumer, Transaction, Biller, Merchant Retail)

●  Deployment architectures desired by customers are trended towards outsourced, hosted, “Cloud-based” elastic deployments that shield them from security threats

Implications of Change for Next-Gen Architecture

●  Conclusions: ●  Move towards integration of discrete functionalities (“products”) into

configurable “solutions” that – at deployment-time, based on specific customer needs – blends multiple functionalities.

●  Support elastic, hosted deployment architecture that enable customers to outsource security threats and in which elastic system resources can be applied transparently

CHANNELS

BATCH

MOBILE

ONLINE

BRANCH

POS

ATM

Bill Pay

P2P

FI Core Systems

Batch Network

Debit / Credit

Remittances

SOA Business Services

SOA Business Services

SOA Business Services

SOA Business Services

SOA Business Services

SOA Business Services

SOA Business Services

SOA Business Services

SOA Business Services

Payment Information Model

Monitoring Management

Templates

Session Orchestration

Reporting

ACI’s Next-Gen Architecture: SOA + Framework … Meets the need to continue to support incumbent requirements and support unmet needs

Confidential MEETS THE CHALLENGE OF CHANGE

Component Architecture

Channel Interfaces Network Interfaces

ATM POS Mobile Online Branch Debit / Credit Bill Pay P2P FI Core Batch Remittances

Payment Services and Frameworks

Service Enabled Solutions Consumer Payments

Transaction Services

Transaction Security

Customer Account

Journal Services

Instrument Verify

Limits and Velocities

Transaction Banking

Template Management

Liquidity Management

ACH Services

Wire Services

Sanctions Filtering

Exception Management

Retailers

Transaction Services

Loyalty Services

Value Card Management

Refund Services

Wallet Management

Cheque Processing

Billers

Bill Payment

Bill Presentment

VCA Services

Account Validation

Liquidity Management

Scheduled Payments

Payments Risk

RT Fraud Analysis

NRT Fraud Analysis

Entity Block Services

Account Activity

Fraud Scoring

Demographic Profile

Omni-Channel

Teller Services

Platform Services

Balances

Transfers

Cheque Services

Online Banking Services

Consolidated Payment Data Management

Core Infrastructure and Common Services

But what are the requirements for this piece?

… Meets the need for SOLUTIONS that support incumbent requirements and unmet needs

Confidential MEETS THE CHALLENGE OF CHANGE

Consolidated Payment Data Management

Shared Service Data

Shared Solution Data

Data Management Requirements

Users

Fraud

Tokenization Entitlements

Notification

Accounts

Customers

Transactions

Config Data

Availability Security Manageability Performance Scalability Multi Tenancy

Service Data

Supportability

Contributing Apps UOB CG MCM Bill Pay

Private Data

Private Data

Private Data

Private Data

… Supports the data needs for SOLUTIONS that support incumbent and unmet needs

Distributed Deployment with SQL and Transactional Access Required

Performance/Scalability Needs at the Data Tier

●  Deeply performance-architected with no known performance inhibitors ●  Generalized resource partitioning (no bottlenecks) ●  Symmetric, no process- or memory-affinities that create asymmetries ●  Potential database bottleneck mitigated by extensive partitioning of

database journals ●  Throughput

●  >= 20000+ (10X) sustained business transactions-per-second ●  Linear resource consumption per transaction ●  No adverse impact of one component’s workload on another’s

throughput ●  Response-time (latency)

●  Extremely low, stable response times ●  No adverse impact of one component’s workload on another’s

latency

… Requirements include completely predictable performance and scalability, with no spikes

Fast, scalable payment transactions (anticipating future volumes across all solution components, not just one discrete product)

●  Continuous availability ●  No single points of failure ●  Real-time logic and schema changes

●  Strong geo-distribution with active/active support ●  Elimination of both planned and unplanned outages ●  Removes the need for fault-tolerant hardware

●  System behavior under stress predictable and manageable ●  Queuing to handle volume spikes

●  Database becomes first line of defense ●  No single point of failure in transaction path ●  Context/state-free processing ●  Designed from ground-up for High Availability at all levels ●  Network Overload Management (NOM) at endpoints

… Requirements include withholding permission for downtime (planned or unplanned)

No-fail operation at the data-tier with deployment-time adaptability

Availability Needs at the Data Tier

●  Deployment-time/On-line logic updates ●  Rolling process changes ●  Instantaneous introduction of new authorization scripts ●  Dynamic addition and removal of business services

●  Deployment-time/On-line application and schema changes ●  Application-level database versioning ●  Real-time table conversions ●  Rolling software upgrades

●  Deployment-time/On-line configuration changes ●  Command-level or bulk

BASE24(-eps) Availability Requirement … Requirements include withholding permission for downtime (planned or unplanned)

No-fail operation at the data-tier

Elasticity Needs at the Data Tier

●  Enable transparent run-time elasticity of transaction processing bandwidth

●  Enable transparent, run-time elasticity of I/O bandwidth ●  Enable transparent, run-time elasticity of availability

… Requirements include completely predictable performance and scalability, with no spikes

Fast, scalable payment transactions (with elasticity of both capacity and availability)

Q & A

Architecting for the Cloud

Seth Proctor, CTO @technicallyseth

What’s unique about “cloud”?

Cloud architecture   On-demand

  Scale-out for capacity & availability   Public infrastructure; dynamic provisioning

  Flexible   Commodity   Hybrid (public & private)

  Simple   Monitoring & management   Platform APIs and automation

  Resilient

Goals

  All the reasons Steve cited…   Greater capacity   Cost-effectiveness   Higher availability and better failure-

handling   Lower latencies for global deployment   Online upgrade & evolution   Hybrid workloads

Challenges

  Distribution brings challenges   Lots of failures happen with frequency   More difficult to get a global view   Security & data lifecycle is harder   Everything else about “distributed computing”

  Still, we can scale most layers   Load-balancers & name services at the top   Horizontally-scaled app servers   Caches & CDNs for content   Redundant disks and object stores

Scaling the database is the real challenge

Traditional database design

  RDBMS architectures start at the disk   Vertical scale follows   Caching helps, but often breaks consistency   HA systems become very expensive

  Schema & operation is hard to evolve   Hard to harness commodity infrastructure   Not designed to scale-out

Common options

  Replication   Active-passive or (gulp) multi-master   Replicated data but visible delays & conflict

Sharding   Split one database into many sub-sets   More capacity but hard to evolve and relate

  Abandon consistency   Push correctness & conflict to the application   Simpler core architecture but painful for

applications and hard to reconcile failures

Side-effects

  Applications are tied to deployment   Driver for dev-ops   Complex for on-demand changes, failures

  More, independent pieces   Harder to interpret failures   Complexity

Global deployment

  Many motivations   Disaster Recovery   Lower-latency for distributed users   Data access & storage residency rules

  Trade-offs between latencies and safety or consistency   Storage should be separate from service

Approach Shared Disk Shared-Nothing/Sharded

Durable Distributed Cache

Key Idea Sharing a file system. Independent databases for disjoint subsets of data.

Replicating data in memory on-demand.

Topology

Example Oracle RAC DB2 Pure Scale

MySQL Cluster and most NoSQL/NewSQL

solutions

Distributed Database Designs

*Note: Most major web properties include custom-sharded MySQL or sharded PostgreSQL, including Facebook, GOOGLE, Wikipedia, Amazon, Flickr, Box.net, and Heroku.   11

Peer to Peer Architecture

P

P P

S3Disk , ...

P

P NuoDB Database Peer Process

Provisioned, Manageable Resources

Peer to Peer Communications

SQL Client

Management Client

SQL Front-EndSQL Optimizer

Transaction Handling

Object CachingObject Coordination

Durability

P

Magic Quadrant 2013

About NuoDB

Magic Quadrant 2013 & 2014

NuoDB delivers a distributed SQL database management system specifically designed for the cloud and the modern datacenter.

Magic Quadrant 2013

Summary

  When architecting for the cloud..   Look for distributed architectures with on-

demand capabilities   Layer & abstract to support evolution and

react gracefully to failures   Assume your needs will evolve; plan with

scale in mind

  Please try out NuoDB!   http://dev.nuodb.com

Thank you!