Copyright © Tactical Strategy Group, Inc. 2006 Aligning Existing IT Architecture with SOA: ----------- A Phased Transition Strategy to MDA SOA William.

Copyright © Tactical Strategy Group, Inc. 2006Copyright © Tactical Strategy Group, Inc. 2006

Aligning Existing IT Aligning Existing IT Architecture with SOA:Architecture with SOA:

----------------------A Phased Transition Strategy to MDA A Phased Transition Strategy to MDA

SOASOA

William M. UlrichWilliam M. Ulrich

Tactical Strategy Group, Inc.Tactical Strategy Group, Inc.

[email protected]@cruzio.com

www.systemtransformation.comwww.systemtransformation.com


Overview of SessionOverview of SessionWhy existing architectures must be Why existing architectures must be

transformed to deliver on SOA promisetransformed to deliver on SOA promiseTransition strategy definitionTransition strategy definitionFunctional decomposition & gap analysisFunctional decomposition & gap analysisData definition rationalization, target Data definition rationalization, target

mapping & redesignmapping & redesignBusiness logic extraction, mapping & Business logic extraction, mapping &

reusereusePhased deactivation of existing Phased deactivation of existing

architecturearchitecture


State of Data & Application State of Data & Application ArchitecturesArchitectures

Implementation logic coupled with Implementation logic coupled with business logicbusiness logic

Redundant, inconsistent & Redundant, inconsistent & fragmented data & functional fragmented data & functional definitionsdefinitions

Systems are not aligned around Systems are not aligned around services-driven focusservices-driven focus

Poorly aligned systems typically Poorly aligned systems typically caused by poorly aligned datacaused by poorly aligned data


Existing Architectures: Segregated into Existing Architectures: Segregated into Stovepipes with Significant Cross-Functional Stovepipes with Significant Cross-Functional

Redundancy Redundancy

Existing Business Processes

Existing Data & System Architectures

Existing Organizational Governance Structures


Existing Architectures are Not Service-Existing Architectures are Not Service-BasedBased

Numerous systems run in batch modeNumerous systems run in batch mode Online modules tend to be multi-functionalOnline modules tend to be multi-functional Logic & data has highly intertwined Logic & data has highly intertwined

dependencies across stovepipe dependencies across stovepipe environmentsenvironments

Redundant data & functionality is rampantRedundant data & functionality is rampant IT cannot just wrap an online transaction IT cannot just wrap an online transaction

and call it a serviceand call it a service


Application Architecture: A Slave Application Architecture: A Slave to Data Architectureto Data Architecture

Persistent data is fragmented, redundant Persistent data is fragmented, redundant & misaligned& misaligned

Data defined inconsistently, redundantlyData defined inconsistently, redundantly Data contained in archaic, ill-defined Data contained in archaic, ill-defined

structuresstructures Applications are intertwined with and Applications are intertwined with and

basically slaves to data architecturebasically slaves to data architecture Services architecture must be built on Services architecture must be built on

reliable data foundationreliable data foundation


Sample Cross-Section of Existing IT Sample Cross-Section of Existing IT ArchitectureArchitecture

Procurement Tracking

Distribution

OrderProcessing

SpecialOrder

Processing

InventorySpecialty

Items

AccountsReceivable

(A/R)

BillingSystem

StandardInventory

IMS

IMS

VSAMAgency

AgencyPayments

Billing

Agency

A/R

Tracking

Sales

Proposal

User Spreadsheets Payments

VSAM

DB2DB2

DB2

VSAM

VSAM

VSAM

Redundant functions & data, convoluted architecture not conducive to SOA


Defining End-State Architecture Defining End-State Architecture Relies on Data & Functional ViewsRelies on Data & Functional Views

Order Customer Data InventoryData Data

Data architecture designed around market & business-driven requirements

Applications decompose into single function modules (i.e. services)

Common OrderModules Common Customer

Mgmt. Modules

Sub-modules

Sub-modules

Common InventoryMgmt. Modules

Sub-modules

Sub-modules

Sub-modules

Sub-modules

Common Distribution Modules

Sub-modules

Sub-modules


Existing Systems Transformation Existing Systems Transformation Strategy is Target DependentStrategy is Target Dependent

Code-based target SOA:Code-based target SOA: Retains & reuses business logic in code-based Retains & reuses business logic in code-based

implementations implementations Relies on source code refactoring & Relies on source code refactoring &

modularizationmodularization Model driven target SOA: Model driven target SOA:

Requires business rule extraction, Requires business rule extraction, transformation & reuse in model driven targettransformation & reuse in model driven target

Limited refactoring supports phased deactivationLimited refactoring supports phased deactivation This discussion focuses on model driven This discussion focuses on model driven

SOA targetSOA target


Transformation Roadmap to MDA Transformation Roadmap to MDA SOASOA

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 supportEstablish transformation process & tool support Establish scope & initial transition strategyEstablish scope & initial transition strategy Decompose current architectureDecompose current architecture Use current-to-target mapping to refine transition Use current-to-target mapping to refine transition

strategystrategy Further decompose existing systems data and Further decompose existing systems data and

application functionalityapplication functionality Apply refactoring options to support phased Apply refactoring options to support phased

legacy deactivationlegacy deactivation


Setting SOA Transition Project Setting SOA Transition Project ScopeScope

Broad-based approach:Broad-based approach:Requires cross-functional assessmentRequires cross-functional assessmentExamines multiple interrelated Examines multiple interrelated

applicationsapplicationsNarrow approach:Narrow approach:

Bypasses cross-functional mapping & Bypasses cross-functional mapping & decompositiondecomposition

May ignore redundant functionality May ignore redundant functionality across stovepipe environmentsacross stovepipe environments

Scope is based on breadth of desired Scope is based on breadth of desired functionality to be reusedfunctionality to be reused


CurrentApplications

CurrentFunctions

TargetFunctions

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 EUser System X

NoNoMapMap

Broad-Based Assessment – Broad-Based Assessment – Enterprise Level Functional GAP Enterprise Level Functional GAP

AnalysisAnalysis


Broad-Based Data Architecture Analysis:Broad-Based Data Architecture Analysis:Existing-Data-to-Business-Data MappingExisting-Data-to-Business-Data Mapping

HRData

OrderProcessing

Data

InventoryData

Supply ChainManagement

Data

CustomerManagement

Data

Target Data Subject Areas & EntitiesTarget Data Subject Areas & Entities

Existing system-to-target data mapping highlights redundancies, inconsistencies and fragmentation within current data architecture.


Refine Transition Plan Based on Refine Transition Plan Based on Broad-Based Assessment FindingsBroad-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 functionalityExisting applications

& data definitions Sample models

RegisterClaim

ApproveClaim

Trigger

ObjectFrom objectdata model

PreconditionEmployee makes

a claim Register claim

Trigger

Daily claimreview process

Source: Martin/Odell

InsuredEmployee

Producepacking list

DecrementFGI

Ship orderShip order

Shipping Clerk

Drop shipfrom remotewarehouse

Individual Project Scope


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-DownAnalysis

Entitiesby System

Existing Documentation

Identify Unique

& Redundant Entities

Legacy Data

Records &Elements

Current System Models

Target Data Architecture Target Data Architecture MappingMapping


Bottom-up Data Definition Analysis, Bottom-up Data Definition Analysis, Rationalization, Redesign & ReuseRationalization, Redesign & Reuse

Top-down, business data model

• Data grouping analysis system-wide Data grouping analysis system-wide record, segment & table definitions record, segment & table definitions • Analysts selectively review results to Analysts selectively review results to augment top-down data modelsaugment top-down data models

Selected DataGroups

Selected DataGroups

Yearly PayGross PayNet Pay


Program-to-function mapping helps determine level of existing functional reuse within target architecture.

CurrentPrograms

CurrentFunctions

TargetFunctions

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 EMANUAL

NoNoMapMap

Targeted Functional GAP Targeted Functional GAP AnalysisAnalysis


Business Rule Derivation: Multi-Business Rule Derivation: Multi-Phased DisciplinePhased Discipline

Logic Capture: Process of capturing logic Logic Capture: Process of capturing logic blocks that serve as business rule blocks that serve as business rule candidatescandidates

Logic Filtering: Eliminating non-business Logic Filtering: Eliminating non-business logiclogic

Logic Packaging: Putting logic into a Logic Packaging: Putting logic into a context that makes sense to business and context that makes sense to business and design analystsdesign analysts

Rule Analysis: Categorizing, leveraging Rule Analysis: Categorizing, leveraging and reusing captured business rulesand reusing captured business rules


Extracted, Categorized & Extracted, Categorized & Packaged Business Rule CandidatePackaged 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 = ZEROAND ACCOUNTING-CLEARANCE NOT = ZERO

ADD WS-VALIDATION-AMT (WRK-SUB) TO RGN-TOTAL (IE-REGION).


Phased Deactivation StrategyPhased Deactivation Strategy

Modularization & deactivation of Modularization & deactivation of existing logic, modules and/or sub-existing logic, modules and/or sub-systemssystems

Phased reconciliation & deactivation Phased reconciliation & deactivation of redundant functionalityof redundant functionality

May involve parallel processing May involve parallel processing during transition during transition


In Summary…In Summary… SOA is goes beyond basic wrapping optionsSOA is goes beyond basic wrapping options Strategy driven by target architecture Strategy driven by target architecture

paradigm & requirementsparadigm & requirements Functional mapping & reuse occurs at Functional mapping & reuse occurs at

several levels that include:several levels that include: Enterprise level vs. more subset of applicationsEnterprise level vs. more subset of applications Data vs. application functionalityData vs. application functionality Functional decomposition vs. business rule Functional decomposition vs. business rule

capturecapture Transition strategy should include:Transition strategy should include:

Redundancy identification & consolidationRedundancy identification & consolidation Phased deactivation of legacy artifactsPhased deactivation of legacy artifacts


Aligning Existing IT Aligning Existing IT Architecture with SOA:Architecture with SOA:

----------------------A Phased Transition Strategy to MDA A Phased Transition Strategy to MDA

SOASOA

William M. UlrichWilliam M. Ulrich

Tactical Strategy Group, Inc.Tactical Strategy Group, Inc.

[email protected]@cruzio.com

www.systemtransformation.comwww.systemtransformation.com

Copyright © Tactical Strategy Group, Inc. 2006 Aligning Existing IT Architecture with SOA: ----------- A Phased Transition Strategy to MDA SOA William.

Documents

aligned data slide

data architecture applications

redundant misaligned

ulrich tactical strategy

multifunctional logic

illdefined structures

existing architectures

phased transition strategy