1. Copyright © Tactical Strategy Group, Inc. 2006 Aligning Existing IT Architecture with SOA: ----------- A Phased Transition Strategy to MDA SOA William M. Ulrich Tactical Strategy Group, Inc. tsginc@cruzio.com www.systemtransformation.com

2. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 2 Overview of Session Why existing architectures must be transformed to deliver on SOA promise Why existing architectures must be transformed to deliver on SOA promise Transition strategy definition Transition strategy definition Functional decomposition & gap analysis Functional decomposition & gap analysis Data definition rationalization, target mapping & redesign Data definition rationalization, target mapping & redesign Business logic extraction, mapping & reuse Business logic extraction, mapping & reuse Phased deactivation of existing architecture Phased deactivation of existing architecture

3. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 3 State of Data & Application Architectures Implementation logic coupled with business logic Implementation logic coupled with business logic Redundant, inconsistent & fragmented data & functional definitions Redundant, inconsistent & fragmented data & functional definitions Systems are not aligned around services- driven focus Systems are not aligned around services- driven focus Poorly aligned systems typically caused by poorly aligned data Poorly aligned systems typically caused by poorly aligned data

4. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 4 Existing Architectures: Segregated into Stovepipes with Significant Cross-Functional Redundancy Existing Business Processes Existing Data & System Architectures Existing Organizational Governance Structures

5. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 5 Existing Architectures are Not Service-Based Numerous systems run in batch mode Numerous systems run in batch mode Online modules tend to be multi-functional Online modules tend to be multi-functional Logic & data has highly intertwined dependencies across stovepipe environments Logic & data has highly intertwined dependencies across stovepipe environments Redundant data & functionality is rampant Redundant data & functionality is rampant IT cannot just wrap an online transaction and call it a service IT cannot just wrap an online transaction and call it a service

6. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 6 Application Architecture: A Slave to Data Architecture Persistent data is fragmented, redundant & misaligned Persistent data is fragmented, redundant & misaligned Data defined inconsistently, redundantly Data defined inconsistently, redundantly Data contained in archaic, ill-defined structures Data contained in archaic, ill-defined structures Applications are intertwined with and basically slaves to data architecture Applications are intertwined with and basically slaves to data architecture Services architecture must be built on reliable data foundation Services architecture must be built on reliable data foundation

7. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 7 Sample Cross-Section of Existing IT Architecture Procurement Tracking Distribution Order Processing Special Order Processing Inventory Specialty Items Accounts Receivable (A/R) Billing System Standard Inventory IMS VSAM Agency Payments Billing Agency A/R Tracking Sales Proposal User Spreadsheets Payments VSAM DB2 VSAM Redundant functions & data, convoluted architecture not conducive to SOA

8. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 8 Defining End-State Architecture Relies on Data & Functional Views OrderCustomer DataInventory Data Data architecture designed around market & business-driven requirements Applications decompose into single function modules (i.e. services) Common Order Modules Common Customer Mgmt. Modules Sub- modules Sub- modules Common Inventory Mgmt. Modules Sub- modules Sub- modules Sub- modules Sub- modules Common Distribution Modules Sub- modules Sub- modules

9. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 9 Existing Systems Transformation Strategy is Target Dependent Code-based target SOA: Code-based target SOA: Retains & reuses business logic in code-based implementations Retains & reuses business logic in code-based implementations Relies on source code refactoring & modularization Relies on source code refactoring & modularization Model driven target SOA: Model driven target SOA: Requires business rule extraction, transformation & reuse in model driven target Requires business rule extraction, transformation & reuse in model driven target Limited refactoring supports phased deactivation Limited refactoring supports phased deactivation This discussion focuses on model driven SOA target This discussion focuses on model driven SOA target

10. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 10 Transformation Roadmap to MDA SOA Establish target SOA framework Establish target SOA framework (e.g. MDA, code-based, rules engines, etc.) (e.g. MDA, code-based, rules engines, etc.) Establish transformation process & tool support Establish transformation process & tool support Establish scope & initial transition strategy Establish scope & initial transition strategy Decompose current architecture Decompose current architecture Use current-to-target mapping to refine transition strategy Use current-to-target mapping to refine transition strategy Further decompose existing systems data and application functionality Further decompose existing systems data and application functionality Apply refactoring options to support phased legacy deactivation Apply refactoring options to support phased legacy deactivation

11. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 11 Setting SOA Transition Project Scope Broad-based approach: Broad-based approach: Requires cross-functional assessment Requires cross-functional assessment Examines multiple interrelated applications Examines multiple interrelated applications Narrow approach: Narrow approach: Bypasses cross-functional mapping & decomposition Bypasses cross-functional mapping & decomposition May ignore redundant functionality across stovepipe environments May ignore redundant functionality across stovepipe environments Scope is based on breadth of desired functionality to be reused Scope is based on breadth of desired functionality to be reused

12. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 12 Current Applications Current Functions Target Functions Application A5 Application B4 Application B1 FUNCTION 1 FUNCTION 2 FUNCTION 3 FUNCTION 4 FUNCTION 5 FUNCTION A FUNCTION B FUNCTION C FUNCTION D FUNCTION E User System X No Map Broad-Based Assessment – Enterprise Level Functional GAP Analysis

13. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 13 Broad-Based Data Architecture Analysis: Existing-Data-to-Business-Data Mapping HR Data Order Processing Data Inventory Data Supply Chain Management Data Customer Management Data Target Data Subject Areas & Entities Existing system-to-target data mapping highlights redundancies, inconsistencies and fragmentation within current data architecture.

14. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 14 Refine Transition Plan Based on Broad- Based Assessment Findings Individual projects are established to capture, reconcile, migrate & deploy functionality within model driven, services oriented architecture Extract business rules & data definitions Rationalize/consolidate data & logic as needed Migrate/merge extracted logic & data definitions into applicable models Selectively deactivate legacy functionality Existing applications & data definitions Sample models Register Claim Approve Claim Trigger Object From object data model Precondition Employee makes a claim Register claim Trigger Daily claim review process Source: Martin/Odell Insured Employee Produce packing list Decrement FGI Ship order Shipping Clerk Drop ship from remote warehouse Individual Project Scope

15. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 15 CURRENT SYSTEM TARGET SYSTEM Interviews Mapping Interviews Current-to-target data mapping extracts bottom-up data usage to create or validate target data models. Entities Retained by Target Entities Not Mapped Top-Down Analysis Entities by System Existing Documentation Identify Unique & Redundant Entities Legacy Data Records & Elements Current System Models Target Data Architecture Mapping

16. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 16 Bottom-up Data Definition Analysis, Rationalization, Redesign & Reuse Top-down, business data model Data grouping analysis system-wide record, segment & table definitions Analysts selectively review results to augment top-down data models Analysts selectively review results to augment top-down data models Selected Data Groups Yearly Pay Gross Pay Net Pay

17. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 17 Program-to-function mapping helps determine level of existing functional reuse within target architecture. Current Programs Current Functions Target Functions PROGRAM 1 PROGRAM 2 PROGRAM 3 FUNCTION 1 FUNCTION 2 FUNCTION 3 FUNCTION 4 FUNCTION 5 FUNCTION A FUNCTION B FUNCTION C FUNCTION D FUNCTION E MANUAL No Map Targeted Functional GAP Analysis

18. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 18 Business Rule Derivation: Multi-Phased Discipline Logic Capture: Process of capturing logic blocks that serve as business rule candidates Logic Capture: Process of capturing logic blocks that serve as business rule candidates Logic Filtering: Eliminating non-business logic Logic Filtering: Eliminating non-business logic Logic Packaging: Putting logic into a context that makes sense to business and design analysts Logic Packaging: Putting logic into a context that makes sense to business and design analysts Rule Analysis: Categorizing, leveraging and reusing captured business rules Rule Analysis: Categorizing, leveraging and reusing captured business rules

19. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 19 Extracted, Categorized & Packaged Business Rule Candidate System / Application Name: Accounting / Accounts Receivable Program Name: PGREG117 Paragraph Name: REGION-VALIDATION Data Element Search Argument: Element = REGION-CODE Logic: IF REGION-CODE NOT = ZERO AND ACCOUNTING-CLEARANCE NOT = ZERO ADD WS-VALIDATION-AMT (WRK-SUB) TO RGN-TOTAL (IE-REGION).

20. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 20 Phased Deactivation Strategy Modularization & deactivation of existing logic, modules and/or sub-systems Modularization & deactivation of existing logic, modules and/or sub-systems Phased reconciliation & deactivation of redundant functionality Phased reconciliation & deactivation of redundant functionality May involve parallel processing during transition May involve parallel processing during transition

21. Copyright © Tactical Strategy Group, Inc. 2006 Copyright © Tactical Strategy Group, Inc. 2006 21 In Summary… SOA is goes beyond basic wrapping options SOA is goes beyond basic wrapping options Strategy driven by target architecture paradigm & requirements Strategy driven by target architecture paradigm & requirements Functional mapping & reuse occurs at several levels that include: Functional mapping & reuse occurs at several levels that include: Enterprise level vs. more subset of applications Enterprise level vs. more subset of applications Data vs. application functionality Data vs. application functionality Functional decomposition vs. business rule capture Functional decomposition vs. business rule capture Transition strategy should include: Transition strategy should include: Redundancy identification & consolidation Redundancy identification & consolidation Phased deactivation of legacy artifacts Phased deactivation of legacy artifacts

22. Copyright © Tactical Strategy Group, Inc. 2006 Aligning Existing IT Architecture with SOA: ----------- A Phased Transition Strategy to MDA SOA William M. Ulrich Tactical Strategy Group, Inc. tsginc@cruzio.com www.systemtransformation.com