Systems Evolution Through Architecture Systems Evolution Through Architecture

Art Akerman & Jeff TyreeArt Akerman & Jeff TyreeEnterprise Architects, Capital One

June 6, 2004

ObjectivesObjectives

Review several practical applications of architecture-driven system evolution

Compare system architecture theory and practice

Share lessons learned

AgendaAgenda

Capital One at Glance Role of Capital One IT Organization Problem Overview Architecture-based Systems Evolution

Approach Case Study: Application to Mission-Critical

Business System Case Study: Application to Business

Domain Lessons Learned

Capital One at a Glance

• A leading financial services company

• 6th largest credit card issuer in the U.S.-- $71.8 billion in loans outstanding-- 46.7 million managed accounts

• Located in 8 U.S. cities, Canada, U.K., France and South Africa

• A FORTUNE 500 Company - #191!

• Numerous awards including:– Top 100 training organization – Training magazine

– 20/20 Vision Award – CIO magazine

– One of the “Best Companies to Work for” in the U.K.-The Sunday Times

– “A top 100 company in Customer Relationship Management” - CIO magazine

– CIO Insight IT/Business Alignment Award

Revolutionary Information-Based StrategyRevolutionary Information-Based Strategy

Account AcquisitionAccount Acquisition Account ManagementAccount Management

Tests Tests ExecutedExecuted

StrategiesStrategiesDevelopedDeveloped

ResultsResultsAnalyzedAnalyzed

AccountsAccountsSequencedSequenced

StrategiesStrategiesDevelopedDeveloped

TestsTestsDevelopedDeveloped

ResultsResultsAnalyzedAnalyzed

Account Account PerformancePerformance

AssessedAssessed

Drives New Product DevelopmentDrives New Product Development

Technology is our central nervous systemTechnology is our central nervous system

ACTIONACTION

Analytical EngineAnalytical Engine

ResultsResults

Call CenterCall CenterTransactionsTransactions

RemittanceRemittanceTransactionsTransactions

Cross-sellCross-sellResponsesResponses

Card UsageCard UsageTransactionsTransactions

InformationInformationTechnologyTechnology

IT Creates IT Creates Game-ChangingGame-ChangingOpportunities forOpportunities for

Capital One.Capital One.

Controls & Governance:We take a disciplined approach to risk management and are focused on identifying and mitigating risks.

Value:IT creates game-changing

possibilities for our business partners.

• IT is the central nervous system of COF• Fully aligned with COF’s business

operations• Drives efficiencies through technology

innovation

Architecture:Consistent, standards-based,

reusable components provide a strong foundation for Capital

One’s future.• Create targeted architectures to meet

business priorities• Re-engineer current capabilities to

reduce complexity and increase effectiveness and flexibility

• Innovate through iterations• Compartmentalize to avoid ripple effects

• C&G makes the ship faster and more nimble• Build a state of the art risk management process• Make effective process controls commonplace• Create a culture that values “managed risk

taking”

Delivery:We deliver high-quality, reliable

service by keeping our commitments and focusing on

value creation.

• Increase quality and efficiency through excellence in process discipline and project management

• Create and maintain well-defined and executed processes across IT and COF

People:We hire the best and the brightest, provide a challenging and engaging

work environment, and reward success.

• Hire 5/100 candidates - multiple interviews (case studies, cognitive tests, math/logic tests)

• Collaborative environment; great place to work• Performance-based culture (high incentives for

high performance)

Role of IT at Capital OneRole of IT at Capital One

Built a powerful technology infrastructure . . . Built a powerful technology infrastructure . . .

• 3,000 IT associates (worldwide)3,000 IT associates (worldwide)

• 800 Contractors800 Contractors

• 400 Consultants400 Consultants

• 750 Unix servers750 Unix servers

• 450 Intel servers450 Intel servers

• 5330 MIPS mainframe processing power5330 MIPS mainframe processing power

• 180 terabytes of useable disk space180 terabytes of useable disk space

ProblemProblem

IT systems were developed in silos during high growth period

“Run the engine” costs constrained IT departments’ ability to deliver new functionality

Major risks associated with system failures Architecture theory focuses on building

systems from scratch, which is rare opportunity Urgent need to evolve “legacy” IT

environments to meet demands of current and future business strategies

The Process: The Process: Architecture-Driven Systems Evolution Architecture-Driven Systems Evolution

Start withthe Business

Needs inmind

Document Current Environment“ApplicationBlueprint”

Develop a “target” architecture

…and a corresponding investment & risk

reduction plan

Assign a dollarcost to the risk for each area using

ORM methodology

Guided by “target” architecture plot

a transition roadmap

Validate architecture

Browser

Agent

Phone

Middleware

Presentation Services Application Services Enterprise ResourcesClients

Desktop

CTI Client

Soft Phone

VRU

DB

Legacy

Log DB

Dialer CTI Client

Customer

Phone

Dialer Server

Voice

Network

Web Server

Web Server

Agent DesktopGUI

ACDACDACDACD

Dialer

Dialer CTI

LegacySystem

Legacy

Middleware

CrossSell

DW

Wan/Lan

Router

1 2CTI

TerminalEmulator Server

3Switch

Calculators

CampaignDirector (Dialer)

Image Viewer

Desktop GUI

ManagementClient

Web Server

Web Server

Client-ServerApp

Web Server

TerminalEmulators

Intranet

Mainframe

4

4

4

Internet /

Extranet

Load Balancer

Online ServicingWeb Server

Marketing WebServer

Partners WebServer

Web App

Web App

Web DB

Web DB

Web DB

DB

4

Web DB

Accounting

4

5

Images AppServer

Images AppServer

6

6

Staging Area

DesktopDatabase DW

7

Images

Images

DB

PaymentSystem

Comm

DB DW

Outbound

Protocol Fire Wall

Domain Fire Wall

Browser HTTPServer

EnterpriseSystems

Internet /

Extranet

Presentation Services Application Services Enterprise ResourcesClients

Static

Content

Protocol Fire Wall

Intranet

(wan/lan)

ReverseProxy

Enterprise Systems Management

Enterprise Security Management

HTTP

Server

StaticContent

DynamicContent

EDW

Enterprise DWSystem

Directory andSecurity

Services

ETL Server

Domain Fire Wall

Log DB

Dialer ServerDialer

Router

AgentPhone

CustomerPhone

VoiceBrowser

Application Server

Presentation

Logic

AppLogic

I/F

CustomerDatabase

Data Source

Integration,Messaging andUser Interface

Voice

Network

CTI

Gateway

Gateway

Controller

SpeechEngine

Application Server

Customer

Load Balancer

1

1

2

Account

Collections Recoveries

FTP Server

T1 T2 T3Today Target

Improve Servicing

Efficiency

Optimize ContactHandling

ExternalDependencies

Enterprise

Initiatives

Beyond T3

Modernize Self-Service

Capabilities

TBD

TBD

TBD

InProgress

On theRadar

New Enterprise

Legend

Cornerstone

Initiatives

Phase 2Phase 1 Phase 3 Phase 4

Phase 1Vendor Selection Phase 2 Advanced Capabilities

ASC PilotVendor Selection ASC FullImplementationPhase 1 Phase 2

Web site enhancements

Customer Service Solution

Internet middleware Migrate existingbusiness services

CRM Internet Bus Logic Integration

Phase 2

Internet HardwareConsolidation

Phase 1

CMS integration

Advanced Contact Infrastrcuture

Win-help migrationto HTML Knowledge

System

Middleware WebServices

EDW

Phase 1

HardwareConsolidation Portal Framework

Internet Portal

Application to system and domain Application to system and domain (business area) levels*(business area) levels*

Narrow focus Shorter timeframes Concrete business needs “Executable” architecture

Broad scope Longer timeframe Abstract business needs “Reference” architecture to

be implemented by projects

SystemBusiness Area

* Enterprise Architecture is out of scope of this presentation* Enterprise Architecture is out of scope of this presentation

Case Study: Credit Decision SystemCase Study: Credit Decision System

The System Under Review - Credit The System Under Review - Credit Decisioning Decisioning

Context– Customers are solicited primarily through the mail– Applications are received via mail, internet, partner and

telephone channels– Applications are processed and decisions are either

Processing Flow– Accepts application, credit, and verification data

electronically– Executes models based upon application, bureau and other

data sources at any step– Makes a final approve/decline and line assignment decision

based on model outcomes– Imports and exports applications, letter generation data,

account set up transactions and other interface data using a variety of open systems protocols

– Provides operational and analysis reporting

VisioningVisioningThe What and the WhyThe What and the Why

IT Drivers– Provide comprehensive data

management strategy.– Support real-time Processing– Support Service Levels– Complexity vs. Availability

Architects Need to Be Involved

Architects Need to Be Involved

Decisioning Database Server

S1

S2

Decisioning Server 1

Master

Decisioning Server 2

Slave

Interfaces

TNS Fraud Bureaus

Workstations

PB

COM

Credit Server

credit Decision DB

D2_1

D2_2

D1_1

D1_2

D1_3

D2_3

D1_4

D2_4

Cache DB

Reporting Server

S3 D3_1

D3_2

Reporting DB

Oracle Parallel Server Environment

Analyst

Call Relations Rep

Work Flow Down Queue CRMS

Credit Bureau Internet

Inquires/Updates Application

Decisions Application

continue decisioning fraud detection

name lookup

credit report

process request for application

re-decision

book accounts File Load System

process request for application

Business Drivers– Increase in approval rate– Decrease in risk level– Opportunities for higher credit limit– Increased marketing opportunities

Operational ContextSystem Context

Architects Need to Sell, Sell, Sell

Architects Need to Sell, Sell, Sell

Current As-Is ArchitectureCurrent As-Is ArchitectureThe Where: The Starting PointThe Where: The Starting Point

How much to document?– 80+ pages – Architecture is more

than boxes and arrows What existing documentation

can be trusted?– Urban legend and tribal

knowledge What Views are Important?

– Consumer Reports View– Interface View

Patterns & Anti-Patterns– The good, the bad, and the ugly

System Metrics/Statistics– “One Measurement is worth more

than a 1000 Expert Opinions” – A. Levy

Key Features Rules Engine WorkFlow User Interface

Bureau Integration External Integration

Scalability Decision Server Decision Database Reporting Server

User Interface Bureau Server

Manageability . Config Management

Data Architecture Unix Configuration

Instrumentation Performance

Decision Response Time . Msg Prioritization

Availability Open Architecture

Credit

Subsystem

Database

Server

Decision

Server (Neptune)

PDB1

PDBR

PDB3PDB2

DW2

NS

UNID

Export

Import Dup Check

Acct Xref

File

Dup CheckResponse

AnalystWorkstation

Web

Acct SetupFiles

Conf File

Print

File Load

RT MQ RT MQ

RT MQ

FTP Batch

Batch FTP

RT SQL*Net

FTP Batch

FTP Batch

FTP Batch FTP BatchFTP

RT SocketRT Socket

RT Socket

FTP Batch

RT SQL Net

RT SQLNET

AbInitio via

SQL*Net

RT

DBLINKRT

DBLINK

PDB4

Batch DBLink

DW1

AbInitio via

SQL*NetReport

Server

RT SQL Net

OCP

RT MQ

Status:

bStatus

Status:

DataSend

DataObject:

DataRequest

Status:

DataReceive

DataObject:

DataController

returnStatus = getCallbackStatus()

transition

ImportProc:

iImport

setRequestStatus("received")

transition

importStd()

queryChildren("unsent")

transition'

{OR}

Important to Customer

Important to Customer

Important to Designers

Important to Designers

Target ArchitectureTarget ArchitectureThe Where: The Ending PointThe Where: The Ending Point

Constraining the Solution– Service Levels:

How fast and how many applications per/hour?

– Principles: SimplicityScalable at the

component level– Change Cases

Real Time DecisioningFraud Meta-Model

– Current AsIs Environment Satisfaction of Constraints

– Architectural DecisionsNo System CloningBatch & Real-Time on Same

Platform– Patterns

Validation– Architectural Review– Extensive Prototyping

Principle Name Component Level Scaling.

Description The system should be scalable at the component level.

Rationale/Benefits It is desired that each component have a set of mechanisms to allow it to scale to the desired levels.

Implications This prevents cloning environments to scale applications, which increases complexity and costs.

Counter Argument From a configuration point of view, it simpler to clone the environment.

RationaleRationale

ImplicationsImplications

Principle Name

Principle Name

ArchitectArchitect

PrototypePrototypeReviewReview

The RoadmapThe RoadmapThe When and The HowThe When and The How

Roadmap Aligns with Business or IT drivers Example: Driver is Manageability

– Goal: All software will be upgraded to supported releases, manageable sized database objects, source control for all source code, and code maintainable as possible.

RisksMitigated

RisksMitigated

ScopeScope

RationaleRationale

Q4 - 2002 Q1 - 2003 Q2 - 2003 Q3 - 2003Database Version Upgrade Cache DB Phase 2Configuration Mgmt SCMCSCR Subsystem Version UpgradeBureaus Version Upgrade Version UpgradeMQ Version UpgradeODBC Version UpgradeAb Initio Version UpgradeDependencies DB Link Removal

Version Upgr ade ? Prerequisite: The CSCR upgrade is preferred, but not absolutely necessary. ? Scope: This effort will bring the software version to the current release. It

involves the following: o Installing new releases in the test environment and production o Regression testing with the new release o Validating existing models as some of the attributes changed between

releases ? Rationale: This release provides support for DMS running as a service as we ll as

improved instrumentation. ? Risks Mitigated:

o Puts platform on a recent version of the software. The platform is currently several versions behind.

o More manageable in terms of operations due to running as a service. Deferrable

Project Details

ResultsResults

Roadmap Executed Lines of Business Migrated to New

System Architecture met Scalability

Requirements Real-Time Processing Added with

Very Good Response Times

Lessons LearnedLessons Learned

Migration Process Needs Clear Definition Several key activities struggled, namely the Prioritization

and Re-factoring activities. Clear expectations need to be set as to who sets the

priority, what socialization has to be done.

Supporting Processes Need to be in Place Supporting key processes were broken to support the

migration. Had a dramatic affect on the Socialization, Prioritization

and Implementation of the Migration Projects.

All Teams Need Integration in Migration Process – The Migration (and its scope) was not clearly assimilated

by the team. – Communication was frequent and abundant, but its

importance was clearly not accepted universally.

Case Study: Direct Marketing DomainCase Study: Direct Marketing Domain

Direct Marketing Domain ContextDirect Marketing Domain Context

Developing financial product strategies,

Marketing products through solicitations to consumers,

Processing applications, Making decisions on how much credit

to extend to customers.

VisioningVisioning

Participation in business strategy sessions Interview key stakeholders Prioritization of needs Review existing business process documentation

Many applications Many applications and interfacesand interfaces

Current As-Is ArchitectureCurrent As-Is ArchitectureThe Where: The Starting PointThe Where: The Starting Point

As-Is Architecture Documentation Process Determine necessary level of detail Interview domain experts (developers, production

support, etc.) Review existing system documentation

“If you don’t understand existing system, you can’t be sure you’re re-architecturing a better one”

Susan Ruth, 1993

Browser

Agent

Phone

Middleware

Presentation Services Application Services Enterprise ResourcesClients

Desktop

CTI Client

Soft Phone

VRU

DB

Legacy

Log DB

Dialer CTI Client

Customer

Phone

Dialer Server

Voice

Network

Web Server

Web Server

Agent DesktopGUI

ACDACDACDACD

Dialer

Dialer CTI

LegacySystem

Legacy

Middleware

CrossSell

DW

Wan/Lan

Router

1 2CTI

TerminalEmulator Server

3Switch

Calculators

CampaignDirector (Dialer)

Image Viewer

Desktop GUI

ManagementClient

Web Server

Web Server

Client-ServerApp

Web Server

TerminalEmulators

Intranet

Mainframe

4

4

4

Internet /

Extranet

Load Balancer

Online ServicingWeb Server

Marketing WebServer

Partners WebServer

Web App

Web App

Web DB

Web DB

Web DB

DB

4

Web DB

Accounting

4

5

Images AppServer

Images AppServer

6

6

Staging Area

DesktopDatabase DW

7

Images

Images

DB

PaymentSystem

Comm

DB DW

Outbound

Protocol Fire Wall

Domain Fire Wall

Target ArchitectureTarget ArchitectureThe Where: The Ending PointThe Where: The Ending Point

Target Architecture simplifies the environment while enabling the domain’s operations strategy

Target Architecture Process Start with Enterprise Reference Architecture Apply patterns Make significant architectural decisions Document architecture Review, review, review

“A good solution somehow looks nice”

Robert Spinrad, 1991

Browser HTTPServer

EnterpriseSystems

Internet /

Extranet

Presentation Services Application Services Enterprise ResourcesClients

Static

Content

Protocol Fire Wall

Intranet

(wan/lan)

ReverseProxy

Enterprise Systems Management

Enterprise Security Management

HTTP

Server

StaticContent

DynamicContent

EDW

Enterprise DWSystem

Directory andSecurity

Services

ETL Server

Domain Fire Wall

Log DB

Dialer ServerDialer

Router

AgentPhone

CustomerPhone

VoiceBrowser

Application Server

Presentation

Logic

AppLogic

I/F

CustomerDatabase

Data Source

Integration,Messaging andUser Interface

Voice

Network

CTI

Gateway

Gateway

Controller

SpeechEngine

Application Server

Customer

Load Balancer

1

1

2

Account

Collections Recoveries

FTP Server

Architecture Decisions (Examples)Architecture Decisions (Examples)

One system will be used for all credit decisioning processing

All desktop applications will use thin client technology

All application integration will be done using a messaging hub

All analytical and historical data will be stored in the Enterprise Data Warehouse

All file-based data exchange will be done using a central staging area

The RoadmapThe RoadmapThe When and The HowThe When and The How

Assumptions / Dependencies Costs / benefits Phases Risks Alternatives

T1 T2 T3Today Target

ImprovedDecisioning

Data Integration

IntegratedCredit

Decisioning

ExternalDependencies

Enterprise

Initiatives

Beyond T3

DecisioningPortal

InProgress

On theRadar

New Enterprise

Legend

Initiatives

Phase 2Phase 1 Phase 3 Phase 4

Phase 1Vendor Selection Phase 2 Advanced Capabilities

PilotVendor Selection Full ImplementationDecommission OldSystem

Migrate to NewSystem

Web site enhancements

Integration Framework

Internet middleware Migrate existingbusiness services

CRM Internet Bus Logic Integration

Phase 2

Internet HardwareConsolidation

Phase 1

CMS integration

Advanced Decisioning Infrastructure

Win-help migrationto HTML Knowledge

System

Middleware WebServices

EDW

Phase 1

HardwareConsolidation Portal Framework

Internet Portal

Impacts:

• Deploy completely• Decommission

Telbert

• Limited rollout• Convert and optimize

• Select vendor and platform

• Quick benefits• Build framework to

migrate

Full DeploymentDeploy Proven AppsPlan and Pilot

• Deploy completely• Decommission

Telbert

• Limited rollout• Convert and optimize

• Select vendor and platform

• Quick benefits• Build framework to

migrate

Full DeploymentDeploy Proven AppsPlan and Pilot

Risk Reduction

Time to Market

Game Changing

Speech Recognition and VRU Renovation Project

Description:Optimizations to the in-house developed VRU platform are increasing in difficulty with marginal return. A new bread of applications, utilizing speech recognition technology, have been proven through recent tests. In addition to new functionality, further optimizations to existing applications, a reduction in senior development resources, reuses of development bandwidth across channels and opportunities to source support and maintenance are expected. To realize the benefit identified,a renovation of the existing platform is required. We recommendreplacing our existing VRU system with a Speech recognition COTS solution.

Alternatives Considered:(1) 1) Maintain Telbert for 3 years; reevaluate in 2. (2) Replace VRU with Speech recognition COTS solution. (3) Utilize an ASP such as TellMe (4) Rebuild Telbert with open source VXML software solution.

Assumptions:Previous studies have recommended replacement of Telbert with a standards-based Speech Recognition enabled VRU platform. 2 prior Requests for information and one Request for proposal has demonstrated limited movement among the industry leaders in this domain

Benefits:

• Increased mitigation, satisfaction and optimizations.

• Separation of business rules from user interface to enable reuse across channels

• Reduction of over $5MM annual risks associated with current VRU platform

• Support of Brand and Cross Sell objectives

• Potential consolidation of inbound and outbound IVR into a Single platform

• Ability to meet current and new business requests.

Benefits:

• Increased mitigation, satisfaction and optimizations.

• Separation of business rules from user interface to enable reuse across channels

• Reduction of over $5MM annual risks associated with current VRU platform

• Support of Brand and Cross Sell objectives

• Potential consolidation of inbound and outbound IVR into a Single platform

• Ability to meet current and new business requests.

Gap and Risks:

• Solution must support integration with MCI toll free network including current tariff and advanced features.

• ICM integration as defined in prior studies remains crucial

• Cannot disrupt VRU service as it handles 75% of 1 MM calls per day.

• Managing a dual environment, projects and migration efforts will create challenges

Gap and Risks:

• Solution must support integration with MCI toll free network including current tariff and advanced features.

• ICM integration as defined in prior studies remains crucial

• Cannot disrupt VRU service as it handles 75% of 1 MM calls per day.

• Managing a dual environment, projects and migration efforts will create challenges

Costs:• Outsource / ASP pricing is under

evaluation, however, industry pricing models are transactional. Transactional models at our call volumes are likely non-viable

• An evaluation of our existing cost structure has been initiated to benchmark against potential off the shelf solutions.

Costs:• Outsource / ASP pricing is under

evaluation, however, industry pricing models are transactional. Transactional models at our call volumes are likely non-viable

• An evaluation of our existing cost structure has been initiated to benchmark against potential off the shelf solutions.

TCO:

-40M

40M

TCO:

-40M

40M

-40M

40M

1 2 3 4

NPV: Ç $50M IRR: Ç 300%

Initiative: Modernize Self-Service Capabilities

Goals

Phase

-7M

39M

-12M -5M -5M

39M 39M

After Architecture is CompletedAfter Architecture is Completed (The Real Work Begins) (The Real Work Begins)

Awareness campaign, getting “buy-in” from business customers

Getting development organization on board

Communicating trade-offs between short term system improvements and major long term infrastructure investments

“If the politics don’t fly, hardware never will.”Brenda Forman, 1990

Early ResultsEarly Results

Commitment from business customers to align all future projects with target architecture

Stronger bind between architecture and development organizations

Development organization now “owns” roadmap

Focus on tracking of progress and realized business value

Completed over 20% of roadmap“The power of the ideas and the simplicity it brings to our environment, exceeds my expectations”

VP of Design & Platform Delivery Services, Capital One

Lessons LearnedLessons Learned

Document key architecture decisions early

Presentation formats are extremely important (sell, sell, sell!!!)

Templates define content and should be well understood

Current system documentation may not be as useful as it originally appears

Need to communicate value of architecture work to stakeholders using their language ($$$, risks, etc.)

Domain architecture should be well connected with enterprise-wide efforts

Impact on EnterpriseImpact on Enterprise

Business partners requested roadmaps for ALL domains (over 50% complete as of now)

Target Domain Architecture Process is formally documented and integrated into company’s software development methodology

More focus on business process (domains are defined using Level 0 and Level 1 processes)