Architecture General Discussion & Examples

1. ArchitectureGeneral Discussion & Examples Distributed Architecture and Infrastructure

2. Agenda • Review of some of the points from last week • Benefits • Solution Stack • Migration Alternatives • Trends • Business Drivers • Client #1 • Client #2 • Open Discussion and Questions

3. Agenda Review of some of the points from last week • Benefits • Solution Stack • Migration Alternatives • Trends • Business Drivers

4. Agenda Client # 1 • Business Drivers /Architecture • Architecture Strategies (Examples) • Infrastructure Strategies • IT Organization Direction

5. Business Architecture Observations Top XXXXX Business Issues

6. Business Architecture Observations Top XXXXX Business Issues (continued)

7. Many of the Issues Originate From the Current “Business Architecture” The current business architecture, represented on the next page, is constrained by the application systems environment with the following consequences: • Current business organization structures are forced by the current design of the systems • Silo’d operations • Limited access and interaction paths across silos • Independent, non-shared processes • Business process duplication across silos • Batch processing environment, not real-time • Complex system development and • release management environment • Prolonged user training cycles • Limited workflow and decision automation Key to‘Silo’ Structure Client Validation CV5 Customer Information C5 Request Interpretation RI5 Duplicated Processes Customer Support CS5 Associates Support AS5 Accounts Support AT5 Adjudicate Flex Claims Unique Processes Billing and Collection of Flex Fees Document Management DM4 (Index and Scan) Load Levels and Metrics LM4 SAMPLE

8. Current Business Architecture Associate Silo’s obstruct effective processing! Common processes are duplicated, multiplied Bank Policyholder/ Insured Payroll Account Broker Access E-mail EDI Walk-in Mail Fax Phone Web IVR Mailroom Routing/Scanning-Indexing Call Routing and Service Direction Policy Flex Flex $ Policy Contract $ Claim List Bill Queries $ Claim Statement Application Bank Draft $ $ $ E-mail Claim Payment Direct Notice Receipts Receipts Client Validation CV1 Client Validation CV2 Client Validation CV3 Client Validation CV4 Client Validation CV5 Client Validation CV6 Customer Information CI1 Customer Information CI2 Customer Information C3 Customer Information C4 Customer Information C5 Customer Information CI6 Request Interpretation RI1 Request Interpretation RI2 Request Interpretation RI3 Request Interpretation RI4 Request Interpretation RI5 Request Interpretation RI6 Policy Maintenance PM1 Policy Maintenance PM2 Policy Maintenance PM3 Policy Maintenance PM4 Policy Maintenance PM5 Customer Support CS5 Customer Support CS1 Customer Support CS2 Customer Support CS3 Customer Support CS4 Customer Support CS6 Associates Support AS5 Associates Support AS1 Associates Support AS2 Associates Support AS3 Associates Support AS4 Associates Support AS6 Accounts Support AT5 Accounts Support AT1 Accounts Support AT2 Accounts Support AT3 Accounts Support AT4 Accounts Support AT6 Direct/Bank Draft Application Audit Adjudicate Flex Claims Payroll Billing Adjudicate Claims Billing and Collection Underwriting Payroll Reconciliation Billing and Collection Document Management DM4 of Flex Fees (Index and Scan) Workflow Management WM2 Workflow Management WM1 Document Management DM2 Document Management DM3 Load Levels and Metrics LM4 Document Management DM4 Document Management DM6 Document Management DM1 (Index and Scan) (Index and Scan) (Index and Scan) (Index and Scan) (Index and Scan) Load Levels and Metrics LM2 Load Levels and Metrics LM3 Load Levels and Metrics LM4 Load Levels and Metrics LM6 Load Levels and Metrics LM1 Customer Services Claims Flex Payroll Accounts Services Call Center New Business Interdepartmental Handoffs Unique processes are minimal, but silos are structured around them Handoffs are manually intensive with minimal workflow automation

9. xxxxx is Designing a Series of Business Shifts Today Tomorrow Goals Aggressive Growth Consistently Aggressive Growth Corporate Goals New Business Focus New Business Retention (Persistence) Focus Market Business Rules Reside with the Individual Business Rules are Shared People Small Business Payroll Accounts Penetrate Untapped Small Payroll Account Market Market Market Leader in Supplemental Health More Diversified Product Portfolio Product Services Linked to Products Offer More Value-Added Services Services Inconsistent and Expensive Service Consistent and Cost-Effective Service Customer Service Communication and Internet Billing Self Service Transactions / Hubs E-Commerce Stove-piped Technology Technology Aligned to the Business Technology

10. The Future Business Architecture Must Provide the Solutions to Future and Existing Challenges… • Sharing of common business processes and information • Maximized automated workflows and decision making • Range of access paths or entry points for any internal or external user (associate, insured, payroll account) • Interactive (real-time) processing • Business organization structure flexibility • Shorter training/cross training cycles

11. Access Modes WEB Phone E-Mail FAX Mail Walk In EDI/XML Future Business Architecture Vision Business org structure not forced by systems Nat’l Accounts Ins Carrier Vendors Banks Brokers Multiple contact paths/entry points regardless of source or media Nat’l Acct Enrollee Payroll Account Broker Agent Policyholder IVR Prep (In and Out) Unique business processes are minimized, componentized Workflow and decision automation can reduce processing time/cost Straight Through Processing Level 1 Processing (80 of 80/20 Rule process requests) Level 2 Processing (20 of 80/20 Rule process requests) Level 3 Processing (Rare Exception Handling) Application Interfaces Common Services Common Processes Product Specific Processing Client Validation Customer Information Claim Adjudication Disbursements Remittance Section 125 AcctSetup Adj. for LOB Application Entry Request Interpretation Change / Inquiry Enrollment Acct. Specific Enrollment Document Management/Imaging Confirmation Account Setup Invoice Reconciliation P1 P2 P3 Pn…. Security Validation Rate Development CPn… Product Development External business rules and shared services reduces training and improves quality Shared services and business processes allow for flexible business operations Transaction Workflow Management Request Status Tracking and Reporting – Q/A Reconciliation Workforce Optimization (scheduling, load leveling and overflow management Operational Management and Performance Metrics Production Reporting and Decision Support

12. IT Strategies Chart The five major IT strategies identified can be categorized as Delivery and Transformation Strategies IT Strategies Delivery Strategies Transformation Strategies Application Services Data Management Strategy Infrastructure Strategy Architecture Strategy Organization

13. Architecture Strategies Architecture Strategy • Implement Enterprise Application Architecture • Develop architectural model and standards • Initiate training • Select vendor support frame work • Develop migration plan • Implement Enterprise Data Architecture • Develop architectural data model and standards • Initiate training • Select vendor support frame work • Develop data dictionary • Develop master plan • Implement Enterprise Business Architecture • Provide value proposition to business community • Establish business community working group • Align long-term business strategies with IT dependencies • Develop integrated IT / business architecture • Implement Enterprise Security Architecture • Assess compliance with internal and external standards on privacy, security, and business continuity • Develop and implement standards compliance • Assure hardened assets and perimeter • Develop intrusion response program • Implement Enterprise Infrastructure Architecture • Implement network and systems management framework • Create network operations center • Update technology infrastructure components to support application services strategies, data management strategies, and other architecture and infrastructure strategies

14. Enterprise Technology Architecture Methodology Articulate Architecture Principles Define Architecture Standards Design Conceptual, Logical and Physical Architecture • Enterprise Technology Architecture is the integration of the components of information systems, including hardware, software, and data across multiple business units, functions, processes and/or geographical areas Initiative Develop Migration Plan Refine Business Drivers and Requirements

15. Architecture Development Process To obtain a robust Conceptual Architecture, we apply business scenarios, and principles, and develop some logical and some physical models. The Logical and Physical models are expanded in later phases and ultimately drive standards/guidelines and a master plan. Principles Business Scenarios Physical Conceptual Logical Standards/ Guidelines validates validates Transition Sequence Transition Sequence Cost Cost This Phase Intermediate Architecture Activities Master Plan Planning Objective

16. EXTERNAL EXTERNAL INTERFACE INTERFACE GUI, EDI, GUI, EDI, PRINTERS PRINTERS To-Be xxxxx Conceptual ArchitectureOverview modern To-Be xxxxx Conceptual Architecture Snapshot at December, 2003 legacy re-built legacy CICS LEGACY PROCESSING LEGACY APPS LEGACY DATA STORE WORKFLOW CONTROL PROCESS REQUESTS ACTIVITY REFACTORED CONTROL LEGACY SYSTEM USER MODERN DATA STORE THIN LAYER DATA REQUESTS SQL THIN LAYER Application BUSINESS for Design ANALYST and Build Application Communications Infrastructure MODERN PRESENTATION INPUT/OUTPUT and DATA PROCESS CONTROL BUSINESS LAYER LAYER LOGIC LOGIC LAYER LAYER

17. To-Be xxxxx Conceptual ArchitectureSnapshot at December, 2003 modern To-Be xxxxx Conceptual Architecture Circled numbers refer to text slides which follow 6 Snapshot at December, 2003 LEGACY BUSINESS LOGIC LEGACY DATA STORE legacy re-built legacy LEGACY ON- LINE CICS LEGACY PROCESSING LEGACY DATA WORKFLOW NATIVE CONTROL LEGACY 3 BATCH Workflow Control data COMPONENTS PROCESS REQUESTS Interface (Common and Manager Unique) NATIVE SQL, VSAM, 4.2 EXTERNAL ADABASE ACTIVITY 5.2 REFACTORED INTERFACE CONTROL LEGACY GUI, EDI, 1 PRINTERS SYSTEM USER MODERN DB BUSINESS OBJECT COMPONENTS THIN LAYER (SYMBOLIC ACCESS) (Data Abstraction) 5.1 DATA REQUESTS 4.1 SQL 2 4.3 Activity Control DB (SYSBOLIC THIN LAYER RDBMS DATA STORE ACCESS) EXTERNAL Application INTERFACE 4 for Design GUI, EDI, and Build PRINTERS 7 BUSINESS ANALYST Application Communications Infrastructure MODERN PRESENTATION INPUT/OUTPUT and DATA PROCESS CONTROL BUSINESS LAYER LAYER LOGIC LOGIC LAYER LAYER

18. Activity Sequence Rules To-Be xxxxx Conceptual ArchitectureClarification of Workflow and Activity Layers Process (Workflow) Control Logic and Business Logic Work Item Refer to item 4 in the text slides which follow Workflow Control Workflow (Process) Controller Stage 1 - Role Assignment Activity Complete - Work Flow Rules- Role Assignment move to next step in Workflow role role Business Logic is in the the activity application and in the Activity Manager rule base 1 2 Workflow (Process) Workflow (Process) Controller Controller Work Flow Rules - Load Assignment Stage 2 - Load Balance Stage 2 - Load Balance Activity Manager Sequence Activities (interactively) Activity Activity Activity Activity

19. Conceptual Architecture Description 1.Actors are users inside the xxxxx perimeter, including end users, business analysts, primary systems administrators. Secondary systems administrators may have more direct access to the system bypassing some of the layers. Users external to the xxxxx perimeter - such as business partners and policy holders are not explicitly addressed in the architecture, but can be accommodated by additional layers on the front end so that thin clients - e.g., web browsers, telephone tones - can be used for access. 2. The external user interfaces are expected to be medium-thin -- with a smaller footprint than a full-logic client/server interface, but a more sophisticated interface than an HTML-only or green screen. Logic which would be included in the interface will likely include screen navigation, some personalization logic, and user-friendly display controls. 3. The process control layer conceptually exists in all applications but may not be manifested as software. Increasingly in the future, process control will become a software automated component - such as a workflow manager. However, human intervention is likely in some applications. If applications are purchased, they may have a process control layer or may need to be interfaced to xxxxx's process control layer. The process controls supported by process control data - which is shown explicitly. Application architectures which do not separate the process control data should be reviewed with caution.

20. Conceptual Architecture Description 4.The Business Logic Layer contains most of the detailed business rules. Conceptual interaction of the Process Control (workflow) layer and the Business Logic (activity) layer is shown on the figure "Workflow and Activity Logic". The Business Logic Layer has three subparts: Activity Control (4.1); Processing Components (4.2); and data access objects (4.3). 4.1. The Activity Control is a layer which controls the flow of logic and navigation within each activity - for example, ordering the tasks needed to execute the activity. It is supported by a rules database. In an ideal application, the layer is explicit (xxxxx, however, may deploy non ideal applications in which this layer is not explicit). 4.2. Process Components contain software logic which executes individual tasks and are launched by the activity controller. Some may be common components shared by multiple applications, while some may be unique to the application (or activity) in which they are invoked. 4.3. Data is accessed primarily through a data abstraction layer which separates the logical name and structure of the data from the physical storage in the data stores.

21. Conceptual Architecture Description 5. Communications to the data stores are primarily through call or file transfer interfaces. The communications is primarily native to the data store. 5.1. For legacy data stores it is often necessary to run legacy logic to access the data due to absence modern logic/data separation architecture. 5.2. In modern systems, there may be an additional thin abstraction layer to de-couple the database physical structure. from the application. 5.3During the extended architecture transition period, some modern front and middle layer applications may interface to more than one type of back end data store. 6. During the extended transition period, data will exist in both legacy and modern data structures. Increasingly over time, modern data structures will dominate. During the transition, detail attention is required to synchronize data which may be logically similar but different in format, syntax and subtle semantics. Temporary processes and operating procedures may be necessary to keep data stores synchronized. 7. A goal of the architecture is to enable use of innovative techniques for making the business logic more accessible to non-programmers. While, the techniques and software for achieving this goal are not fully mature, some may advantageous to xxxxx.

22. Validation using Logical and Physical Models An architecturally significant business scenario (we used Claims Processing) is used to derive a logical component model * The logical model is overlaid on the conceptual layered model to see how the concept would work in practice The layered logical model is overlaid on hardware/system software to see how it would deploy -------------------------- * NOTE: The model does not have to be refined to level of specification; a approximate/preliminary model is sufficient to validate concept

23. Claims Scenario - Hypothetical Claims Processing – Hypothetical High Level Business Scenario sequence view Claim Correspondence Cash Policy Holder Mail Room Finance Adjustment Generation Disbursement 2 1 (numbering maps to Logical Architecture slide which follows) claim stuff 3 claim Part 1 - 9 notice Adjudication request 10 notice 11 4 - 8 notice (mail) adjudication disbursement request 12 book entry Part 2 - 12 check payment Disbursement 13 12 check payment (mail) book entry reconciliation

24. Claims Processing Part 1 (Adjudication) –Layered Logical Architecture sequence mapped to conceptual architecture (numbering corresponds to Sequence Diagram) To-Be xxxxx Conceptual Architecture Snapshot at December, 2003 LEGACY BUSINESS LOGIC LEGACY DATA STORE Claims Processing Example - Part 1 CALL E.G., SCREEN SCRAPING LEGACY ON-LINE CICS LEGACY PROCESSING MAIL ROOM legacy processing Scan Ÿ Mail (option) Ÿ Route FILE LEGACY TRANSFER NATIVE LEGACY BATCH DATA 3 PROCESS REQUESTS Adjudicator Application claim paper invoke NATIVE SQL, VSAM, 1 (arguments) Workflow ADABASE 2 Rules exceptions CALL Adjudication REFACTORED 5 Mail 6 LEGACY US Post Activities CALL Office Manager Policy Holder CALL ACCESS) (SYMBOLIC THIN LAYER Policy Database exception Database 4 Access processing policy audit benefits lookup SQL adjudication rules lookup Benefits 7 CALL Database ACCESS) (SYSBOLIC THIN LAYER Manual 8 Processing NATIVE Claims DATA I/O Activity (avoid if 6 History Control DB Adjudication possible) Rules RDBMS DATA STORE Database Application Communications Infrastructure PRESENTATION CONTROL MODERN INPUT/OUTPUT and DATA LAYER LOGIC BUSINESS LAYER LAYER LOGIC 7

25. Infrastructure Strategies Infrastructure Strategy • Formalize Capacity Planning and Management • Establish capacity planning authority • Select and implement capacity planning standards, reviews and impact analysis • Evaluate and select vendors tools; capacity and analysis monitoring tools • Incorporate impact analysis in SDLC and release management • Develop Complete Operations Strategy • Conduct operation best practice review • Determine enhancement opportunities and implementation plan • Implement review plan and metrics

26. IT Strategies IT Organization Strategies IT Organization • Establish IT Planning Group • Formalize IT Planning Group Structure • Define Governance and Process for IT Planning Group • Establish IT QA Group • Define Roles and Responsibilities • Define the Structure and Governance • Define IT QA processes and linkages to other IT processes • Formalize IT Project Office • Define Structure, Roles and Responsibilities • Define Process and Governance • Implement CMM Level 2 IT Organization • Implement release management structure • Implement software configuration management • Implement System Development Life Cycle methodology • Establish metrics and measurement processes • Establish quality assurance group related processes • Enhance overall IT governance process • Implement IT Vendor Management Office • Define sourcing options and decision criteria • Develop initial preferred sourcing relationships • Roll out IT Sourcing strategy • Formalize IT Resource Management • Implement a skills management program to define skills, roles, job titles, and job families and formalize for IT • Determine process for resource management • Implement Professional Development Program • Establish System Development Group • Formalize system architecture and system analyst roles and groups • Formalize a development team structure to minimize silo structures • Integrate all testing (except QA) into System Development • Establish Enterprise Program Office • TBD

27. Agenda Client # 2 • Future State Need • Future State Description • Future State Diagram • How do we get there? • Impact on current state

28. Future state description THE “system of record” for decision support in P&C Sales & Marketing. A robust analytical & reporting environment that supports standardized, ad hoc and analytical inquires. It provides the mechanisms to report: • Financial performance & trends • Stakeholder non-financial performance & activities • Stakeholder facts & status With tools to support: • Reporting and data access • Analytics & modeling capabilities • Intelligence & knowledge development The environment is designed to satisfy P&C Sales & Marketing requirements, and aligns with L&I requirements where overlaps exist.

29. Future state detail • Where • How • Why (analytical only) • Answers operational and analytical questions • Who • What • When • Targets primary user classes at all responsibility levels • P & C Sales Professional • P & C Sales Management • P & C Marketing Management • Distribution Partners/Channels • Secondary user classes supported at current capability level • Underwriting • Actuaries • Information delivered at composite and detail levels targeted to different user class requirements

30. Future state detail • Integrates multiple data sources to provide complete information views including: • Financial performance • Agency performance planning & management • Sales professional compensation • Sales activity • Sales effectiveness • Distribution Partner management (facts & status) • Information can be presented & analyzed by: • Distribution partner at any level • Initiative/campaign • Line of business • Distribution channel • Geographic area • Corporate operational areas (e.g., Marketing Area)

31. Future state detail • Provides standardized reports with ability to tailor to individual needs • Delivered electronically or via paper copy • Reports accommodate navigation between composite and detail levels • Provides tools to manipulate data • Analytics • Forecasting, trending and modeling • Data mining • Support remote workers • Connectivity/bandwidth • Remote desktops & mobile workers • Web enabled capabilities where required

32. Future state detail • Streamlined access to information • Single point of user access • Internal & external information • Open architecture assimilates new business needs

33. DM DM Data Future State Architectural Diagram: Applications Schematic Presentation Area Data Integration Area Source Systems Area Cubes Translation & Routing System of Record Translation & Routing Data Mart OLAP Engine P&C DP Mgmt Product Systems Corporate Reports Life & Invest. Data Mart Others Non YYYYY Data Mining Metadata Foundation

34. DM DM Data Future State Architectural Diagram: Applications Schematic Presentation Area Data Integration Area Source Systems Area Cubes Translation & Routing System of Record Translation & Routing Data Mart OLAP Engine P&C DP Mgmt Product Systems How Do We Get There? Corporate Reports Life & Invest. Data Mart Others Non YYYYY Data Mining Metadata Foundation

35. Future State How Do We Get There? Step # 1: Define User Classes Presentation Area • Operational • Users • - … • - … • Analytical • Users • - …

36. Future State How Do We Get There? Step # 2: List End-Users’ Needs at the appropriate level of detail Presentation Area Reports Reports • Operational • Users • - … • - … • Analytical • Users • - … Reports

37. Impacts of Future State Development on Current State • If Map goes away, need new solutions for secondary user groups (e.g., underwriting & actuaries) • If Atlas goes away, need to maintain existing dependencies/integration with other systems, including: • financial reporting system, statistical bureau reporting, APR, underwriting and actuarial systems, and processing systems such as Home and Auto • Existing hard-coded, point-to-point interfaces to be replaced/changed

38. Current state – issues & limitations The future solution addresses the following issues: • Current system that currently supports P&C premium and loss detail data (ATLAS): • Reaching technical limitations – scalability insufficient • High maintenance costs • Timing – length month-end closing currently maxed out • Flexibility to respond to new business needs is limited by application integration architecture • Current reporting system that provides detailed performance data (MAP): • Information is not as current as business would like • Lack of data manipulation, analytical, mining tools • Scalability of application platform • Information needs to be captured at more granular level by source systems

39. Agenda Open Discussion and Questions