Upload
kimberly-dawson
View
222
Download
0
Tags:
Embed Size (px)
Citation preview
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
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)