Systems Evolution Through Architecture

1. Systems Evolution Through Architecture June 6, 2004 Art Akerman & Jeff Tyree Enterprise Architects, Capital One

2. Objectives • Review several practical applications of architecture-driven system evolution • Compare system architecture theory and practice • Share lessons learned

3. Agenda • 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

4. 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

5. Revolutionary Information-Based Strategy Account Acquisition Account Management Tests Executed Strategies Developed Strategies Developed Accounts Sequenced Account Performance Assessed Tests Developed Results Analyzed Results Analyzed Drives New Product Development

6. Call Center Transactions Remittance Transactions Information Technology Cross-sell Responses Card Usage Transactions Analytical Engine Results ACTION Technology is our central nervous system

7. IT Creates Game-ChangingOpportunities forCapital One. Architecture: Consistent, standards-based, reusable components provide a strong foundation for Capital One’s future. Role of IT at Capital One People: We hire the best and the brightest, provide a challenging and engaging work environment, and reward success. Value: IT creates game-changing possibilities for our business partners. • 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) • IT is the central nervous system of COF • Fully aligned with COF’s business operations • Drives efficiencies through technology innovation Delivery: We deliver high-quality, reliable service by keeping our commitments and focusing on value creation. Controls & Governance: We take a disciplined approach to risk management and are focused on identifying and mitigating risks. • Increase quality and efficiency through excellence in process discipline and project management • Create and maintain well-defined and executed processes across IT and COF • 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” • 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

8. Built a powerful technology infrastructure . . . • 3,000 IT associates (worldwide) • 800 Contractors • 400 Consultants • 750 Unix servers • 450 Intel servers • 5330 MIPS mainframe processing power • 180 terabytes of useable disk space

9. Problem • 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

10. The Process: Architecture-Driven Systems Evolution Start withthe Business Needs inmind Document Current Environment“ApplicationBlueprint” Assign a dollarcost to the risk for each area usingORM methodology …and a corresponding investment & risk reduction plan Guided by “target” architecture plota transition roadmap Validate architecture Develop a “target” architecture

11. Application to system and domain (business area) levels* Business Area System • Narrow focus • Shorter timeframes • Concrete business needs • “Executable” architecture • Broad scope • Longer timeframe • Abstract business needs • “Reference” architecture to be implemented by projects * Enterprise Architecture is out of scope of this presentation

12. Case Study: Credit Decision System

13. The System Under Review - Credit 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

14. VisioningThe What and the Why Architects Need to Be Involved System Context • IT Drivers • Provide comprehensive data management strategy. • Support real-time Processing • Support Service Levels • Complexity vs. Availability Operational Context Architects Need to Sell, Sell, Sell • Business Drivers • Increase in approval rate • Decrease in risk level • Opportunities for higher credit limit • Increased marketing opportunities

15. Current As-Is ArchitectureThe Where: The Starting Point Important to Customer • 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 Important to Designers

16. Target ArchitectureThe Where: The Ending Point Principle Name • Constraining the Solution • Service Levels: • How fast and how many applications per/hour? • Principles: • Simplicity • Scalable at the component level • Change Cases • Real Time Decisioning • Fraud Meta-Model • Current AsIs Environment • Satisfaction of Constraints • Architectural Decisions • No System Cloning • Batch & Real-Time on Same Platform • Patterns • Validation • Architectural Review • Extensive Prototyping Rationale Implications Architect Review Prototype

17. Q4 - 2002 Q1 - 2003 Q2 - 2003 Q3 - 2003 Database Version Upgrade Cache DB Phase 2 Configuration Mgmt SCM CSCR Subsystem Version Upgrade Bureaus Version Upgrade Version Upgrade MQ Version Upgrade ODBC Version Upgrade Ab Initio Version Upgrade Dependencies DB Link Removal The RoadmapThe 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. Scope Project Details Rationale Risks Mitigated

18. Results • Roadmap Executed • Lines of Business Migrated to New System • Architecture met Scalability Requirements • Real-Time Processing Added with Very Good Response Times

19. Lessons 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.

20. Case Study: Direct Marketing Domain

21. Direct 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.

22. Visioning • Participation in business strategy sessions • Interview key stakeholders • Prioritization of needs • Review existing business process documentation

23. Current As-Is ArchitectureThe Where: The Starting Point Many applications and interfaces 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

24. Target ArchitectureThe Where: The Ending Point Target Architecture simplifies the environment while enabling the domain’s operations strategy “A good solution somehow looks nice” Robert Spinrad, 1991 Target Architecture Process • Start with Enterprise Reference Architecture • Apply patterns • Make significant architectural decisions • Document architecture • Review, review, review

25. 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

26. The RoadmapThe When and The How • Assumptions / Dependencies • Costs / benefits • Phases • Risks • Alternatives

27. After Architecture is Completed (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

28. Early 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

29. Lessons 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

30. Impact 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)