Sponsored by the U.S. Department of Defense © 2006 by Carnegie Mellon University Version 1.3 (ICSM...

Sponsored by the U.S. Department of Defense© 2006 by Carnegie Mellon University

Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 1

Pittsburgh, PA 15213-3890

Migration of Legacy Assets to SOA Environments

Dennis Smith and Grace LewisSoftware Engineering Institute

© 2006 by Carnegie Mellon University Version 1.3 (ICSM 2006) Migration to SOA Tutorial - 2

Our Goal Today

Present and discuss

• Basic concepts related to SOA

• Challenges of implementing SOA-based systems

• Effects of SOA characteristics on migration of legacy assets to services

• Technique for determining feasibility and effort required to migrate legacy assets as services for a specific SOA environment

Goal


Agenda

Introduction to SOA

Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments

SMART (Service Migration and Reuse Technique)

Conclusions and Next Steps

Agenda


Agenda

Introduction to SOA• The 50,000 Foot View

- Basic Concepts- Common Misconceptions

• The 5,000 Foot View• The 1,000 Foot View

Pillars of SOA-Based Systems Development

Issues in Migration to SOA Environments



SOA: 50,000 Foot View


What is SOA?

Service-oriented architecture is a way of designing systems that enables• Cost-efficiency• Agility• Adaptability• Leverage of legacy investments

SOA: The 50,000 Foot View—Basic Concepts


Services

Services are reusable components that represent business tasks.• Customer lookup• Account lookup• Credit card validation• Credit check• Hotel reservation• Interest calculation

Services can be• Globally distributed across

organizations• Reconfigured into new business

processes



Services and Cost-Efficiency

Order Processing Application

Customer Lookup - 1

Invoicing Application

Customer Lookup - 2

CRM Application

Customer Lookup - 3

Customer Lookup Service

A service with equivalent

functionality can be

implemented and used by all

three applications



Services and Agility



Credit Check

Service

Item Lookup Service

Inventory Check

Service

Course Management Application

Room Availability

Service

The new application can

easily use available services.

New services can be used by

other applications as

well.



Services and AdaptabilityOrder Processing

Application


Credit Check

Service

Item Lookup Service

Inventory Check

Service

SOA Infrastructure

The SOA Infrastructure

provides a standard

communication mechanism

between applications and

services.

Changes in services have potentially no

impact on existing

applications that use them.



Services and Legacy Leverage



Credit Check

Service

Item Lookup Service

Inventory Check

Service

SOA Infrastructure

Customer Management

System

The applications access the

services in a standard way.

It is the service’s task to

invoke the legacy

system.

Legacy platform

diversity and complexity is transparent

to the application.


Manufacturing System


Components of an SOA-Based System

Application X

Service A

SOA Infrastructure

Enterprise Information System

Application Y

Application Z

Internet

Internet

External System

Service B

Service C

Service D

Internal Users

DiscoverySecurityDevelopment Tools

Legacy or New Code



In Summary …SOA is an approach to software development where• Services provide reusable functionality with well-defined

interfaces.• An SOA infrastructure enables discovery, composition

and invocation of services. • Applications are built using functionality from available

services.

If managed well, SOA adoption can lead to• Cost-efficiency• Agility• Adaptability• Leverage of legacy investments

The hard part is the “if managed well”.



Agenda

Introduction to SOA• The 50,000 Foot View

- Basic Concepts- Common Misconceptions

• The 5,000 Foot View• The 1,000 Foot View





SOA: The 50,000 Foot View—Common Misconceptions


An SOA Provides The Complete Architecture For A System SOA is an architectural pattern/style/paradigm and not the architecture of the system itself.

An architectural pattern provides guidance that embodies best practices.• The concrete elements and their interactions are the

architecture of the system.

Any number of systems can be developed based on an architectural pattern.• An architecture based on SOA inherits both the good and the

bad.

Corollary: SOA cannot be bought off-the shelf.• System qualities have to be built into the architecture of the

system.• Decisions have to be made—service design and

implementation, technologies, tradeoffs.



Legacy Systems Can Be Easily Integrated Into An SOA Environment Upfront hands-on analysis on the technical feasibility and return on investment must be performed to avoid last minute surprises.

Is it technically feasible to create a service from the legacy system or part of the system?

How much would it cost to expose the legacy system as services?

Is this cost plus the cost of maintaining the legacy system more than the cost of replacing it with a new one?

What changes will have to be done to the legacy system?

How much will these changes affect current users and other production systems?



Using XML and WSDL Guarantees Interoperability Among Web Services Provided by Multiple OrganizationsWeb Services enable syntactic interoperability• XML Schema defines structure and data types• WSDL defines the interfaces: operations, parameters

and return values• Available information, technologies and tool support

Web Services do not guarantee semantic interoperability• XML and WSDL do not define the meaning of data• WSDL does not define what a service does• Active research area—unresolved issues

Interoperability needs agreement on both syntax and semantics



SOA Is All About Technology

SOA not only means a shift in technology but also changes in the organizational governance model.

• Service definition• Service repositories• Ownership

- Common services? Data?• Evolution • Conflict resolution• Deployment mechanisms• Monitoring mechanisms• Enterprise-wide policies• Service-level agreements



It Is Easy To Develop Applications Based on ServicesIt is relatively easy to build services to work with a particular infrastructure … but designing a “good” service might not be that easy.

• From a implementation standpoint- Ease depends on tool availability for SOA

infrastructure- Most difficult part is composition—data

mismatches

• From a design standpoint- Not many best practices for designing services- Have to anticipate potential users and usage

patterns- What is the right Quality of Service? Can you

guarantee it?- “If you build it they will come” – Can you afford

this?



It is Easy to Compose Services Dynamically at RuntimeCurrent technologies have not advanced to the point that this is possible in production environments.

Requires the use of a common ontology by service providers and client applications within a domain

Requires the construction of extremely intelligent applications that• Construct the right queries for the discovery of

services• Compose services when there is not a single service

that can process the request• Provide the right data to invoke a service that was

discovered at runtime



In Summary …

Our intent is not to discourage, but to caution.

An SOA approach may be the best way to achieve common goals of interoperability, agility, and reuse.

But …• Most of the mentioned issues are active areas of research.• Some solutions will require time to mature.

Also keep in mind …• Not everything in an SOA-based system has to be a service

- It might not make sense for your whole system• Most case studies will show that the key is governance

- Which has very little to do with technology



Agenda

Introduction to SOA• The 50,000 Foot View• The 5,000 Foot View

- Web Services• The 1,000 Foot View





SOA: The 5,000 Foot View


Web Services

Web services is one mechanism for implementing an SOA-based system.

• Service interfaces are described using Web Services Description Language (WSDL)

• Data is transmitted using SOAP over HTTP

• UDDI is optionally used as the directory service

Because it is the most common mechanism, it is often equated to SOA.

SOA: The 5,000 Foot View—Web Services


Web Service Protocol Stack

The highlighted standards are the most commonly used

Most Web Service standards are emerging and even competing

Security, QoS, Transactions, and Management have to be addressed in all layers

DiscoveryUDDI

DescriptionWSDL

Message FormatSOAP

EncodingXML

TransportHTTP

Se

curity

Ma

na

ge

me

nt

Tra

nsa

ction

s

Qu

ality of S

ervice

Orchestration and Choreography

WSCL, WSCI, BPEL4WS, WS-Coordination

BPML, BPSS

Base Stack

Adapted from “XML and Web Services Unleashed”, SAMS Publishing



Web Services At Design Time

Alice obtains the WSDL

corresponding to Bob’s web

service

Alice runs the WSDL document

through tools that generate all the necessary

message construction code (e.g.

WSDL2Java)

Bob exposes functionality in a system as a

service (or creates a specific

service) and places a WSDL

document in an “accessible

place”

Alice adds code to her application that executes the

message construction

code to connect to Bob’s web

service and any additional code that uses the

response obtained from

Bob’s web service



Web Services At Run Time

1. User executes Alice’s application

3. When Bob’s HTTP server sees a SOAP message it sends it to the SOAP engine

2. Application builds a SOAP message and sends it to Bob’s service via HTTP

4. SOAP engine parses the message and constructs the call to Bob’s system

5. Bob’s system executes the invoked operation

6. Bob’s system returns operation results

HTTPRequest Call

ReturnHTTPResponse

7. SOAP engine builds response message and returns it via HTTP

HTTP Server Bob’s SystemUser at Alice’s Application

8. Alice’s application interprets response and displays results to the user.



Static vs. Dynamic

With today’s technology, discovery and composition of services are done at design time—Static• Developer discovers services and obtains addresses• Developer writes code to invoke the services located at these

addresses

There is a great amount of research to enable discovery and composition at runtime—Dynamic• Application discovers services and obtains addresses• Application contains code to invoke the discovered services

and “knows” what information to provide

There are a lot of “In-Between” techniques• Application discovers services but requires user intervention to

select services and provide the required information• Portals are configured such that “portlets” correspond to

services



In Summary …

Web Services are the most currently used approach to SOA implementation.• Basic infrastructure standards are fairly stable• More higher level standards are emerging

Web Services are not the only approach to SOA implementation.



Agenda

Introduction to SOA• The 50,000 Foot View• The 5,000 Foot View• The 1,000 Foot View






Components of an SOA-Based Systems

1. Services

2. Applications

3. SOA Infrastructure



Our Scenario: SOA-Based System Components

Order Management

System

Financial System

Organization 1

Organization 2

Credit Card Validation

System

SO

A In

frastru

ctu

re


CRM Application

Shipping System

FedEx

Shipping System

UPS

Shipping System

DHL

Order Placement Application

Customer Organization

Internet

Internet



Distribution of SOA-Based System Development


Organizational ESB

Incorporation of Map Data

“Just-In-Time” Inventory Management

Software as a Service

Single Organization

Multiple Organizations

Net-Centric Operations

On the left side of the spectrum all three types of components are developed within the same organization.

On the right side of the spectrum each type of component is developed by a different organization.

There are many possibilities in between.

As you move to the right, the challenges are greater.


Application Developers 1

Focus on the discovery, composition and invocation of services, either statically at design time or dynamically at run time



Application Developers 2

1. Identify appropriate

services (both

internal and external)

that can be reused

Order Management

System

Financial System

Organization 1

Organization 2


System

SO

A In

frastru

ctu

re


CRM Application

Shipping System

FedEx

Shipping System

UPS

Shipping System

DHL

Order Placement Application

Customer Organization

Internet

Internet

… as well as if it needs to become a service

provider itself

2. Understand the interfaces in terms of the functionality and QoS

provided by them

Application Developer needs to create a new application

using the SOA approach


3. Create the new system

using as many existing services

as possible

4. The application needs to be architected in such a way

that it can easily accommodate changes in

services interfaces …


Tasks for Application Developers

Understand the SOA infrastructure

Discover appropriate services to be incorporated into applications

Retrieve service description documentation

Invoke the identified services in applications• Data conversions• Error handling• Availability handling

Test the services for correctness in the context of the application being developed



Service Developers

Focus on the description and granularity of services so that applications can easily locate and use them with acceptable Quality of Service (QoS)



Service Developers

1. Identify what existing business

functionality can be

exposed/reused as services

Order Management

System

Financial System

Organization 1

Organization 2


System

SO

A In

frastru

ctu

re


CRM Application

Shipping System

FedEx

Shipping System

UPS

Shipping System

DHL

Internet

Internet

4. Design, create and

publish services to internal and

external organizations

3. Anticipate requirements for future consumer systems and architect services in a

scalable fashion

2. Analyze service

interface, functionality and

QoS requirements for new consumer

systems



Tasks for Service Developers

Understand requirements of potential service users

Understand SOA infrastructure

Develop code that receives the service request, translates it into calls into new or existing systems, and produces a response

Describe and publish the service

Develop service initialization code and operational procedures• Service-Level Agreements (SLAs) are a topic of current

interest among service providers.



Infrastructure Developers

Focus on providing a stable infrastructure• Standards• Common services• Development tools

NOTE: The Enterprise Service Bus (ESB) is an example of an infrastructure designed to support the SOA paradigm.



Infrastructure Developers 2

Order Management

System

Financial System

Organization 1

Organization 2


System

SO

A In

frastru

ctu

re


CRM Application

Shipping System

FedEx

Shipping System

UPS

Shipping System

DHL

Internet

Internet

Infrastructure developers have to design, create

and maintain these common services for

both internal and external use (if required)

Discovery

Security

Development Tools

Service Registry

There are common

services that are used by all applications



Tasks for Infrastructure DevelopersSelection of standards to implement as part of the infrastructure

Development of a set of common infrastructure services for discovery, communication, security, etc.

Identification and development of binding mechanisms to satisfy the largest set of potential service users

Provision of tools for application and service developers

Documentation and support for the infrastructure



The Potential Problem

If the three types of components are developed within the same organization, the challenges are less.• Simpler communication between developers (or might

even be the same developers)

However, it is becoming increasingly common for these three types of components to be developed independently by separate organizations. • Decisions made locally by any one of these development

groups can have an effect on the other groups.



Sample Consequences of Decisions: Service Granularity 1The granularity of service interfaces can affect the end-to-end performance of an SoS because services are executed across a network as an exchange of a service request and a service response.

• If service interfaces are too coarse-grained, clients will receive more data than they need in their response message.

• If service interfaces are too fine-grained, clients will have to make multiple trips to the service to get all the data they need.



Sample Consequences of Decisions: Service Granularity 2

Order Management

System

[Basic Info, Order History, Pending Orders] getCustomerInfo( CustomerId )

The Order Management System can expose the business functionality of

getting all the customer information in one call

OrderHistory getOrderHistory( CustomerId )

CustInfo getCustBasicInfo( CustomerId )

Order[] getPendingOrders( CustomerId )

Or the service can be more granular and provide three

different operations for each type of information



Sample Consequences of Decisions: Requirements 1

If service developers do not understand functionality and QoS needs of potential users of services, they might end up developing and deploying services that are never used



In Summary …SOA-based systems are about more than just technology.

SOA-based systems development requires

1. Strategic approach to SOA implementation• Alignment with business goals

2. SOA governance• Policies, coordination and guidance for SOA

infrastructure providers, service providers, and application developers

3. Realistic technology evaluation• Context-based technology evaluations

4. Change of mindset• Different development and implementation approach



Agenda

Introduction to SOA






Strateg

ic A

lign

men

t

SOA Design Principles

SOA-Based Systems Development

Tech

no

log

y E

valuatio

n

SO

A

Go

vernan

ce

Ch

ang

e of

Min

dset


Strategic Alignment

Strateg

ic A

lign

men

t



Tech

no

log

y E

valuatio

n

SO

A

Go

vernan

ce

Ch

ang

e of

Min

dset

Pillars: Strategic Alignment


Alignment with Business Goals

Any successful SOA strategy has to be aligned with business goals.

Examples• Reduce time to market for applications• Increase information available to customers• Integrate business partners• Decrease development cost by increasing reuse• Reduce maintenance costs• Improve customer service• Improve internal processes



Service Conception

1. Business processes to support business goals are identified.

2. Candidate services are identified.• Top-Down

- Shared steps between business processes are identified as service candidates.

• Bottom-Up- Legacy system inventory is performed.- Systems with functionality to support business

processes are identified as migration candidates.

3. Services are selected based on relationship to business goals.



SOA Governance

Strateg

ic A

lign

men

t



Tech

no

log

y E

valuatio

n

SO

A

Go

vernan

ce

Ch

ang

e of

Min

dset

Pillars: SOA Governance


Lack of Governance Inhibits SOA AdoptionAn InfoWorld 2006 SOA Trend Survey indicates that Lack of Governance is the main inhibitor for SOA adoption (48%)

Greater than other inhibitors that would seem more obvious• Unresolved security issues (40%)• Performance and reliability (39%)• Incomplete and immature standards (38%)



SOA Governance

Policies and procedures

Roles and responsibilities

Design-time governance

Run-time governance


Source: Integration and SOA: Concepts, Technologies and Best Practices. Beth Gold-Bernstein & Gary So.


Policies and ProceduresService providers• Service conception• Service modeling• Service development• Service deployment

Infrastructure providers• Infrastructure versioning• Upgrades

Application developers• Service composition• Application testing



Roles and Responsibilities

Roles• SOA Governance Manager• Close work with

- Business process managers and analysts- Project managers- Infrastructure managers- Service managers

Responsibilities• Creation• Approval• Implementation• Enforcement



Challenges of SOA Governance

Seems counterintuitive• If SOA is all about loose coupling and flexibility, why all this

central control?

Multiple organizations• How to create governance for service providers, infrastructure

providers, and application developers? What if policies conflict?

Dealing with exceptions• How to record and maintain sometimes necessary

exceptions?

Enforcing compliance• How to make sure that policies and procedures are being

followed at design time and runtime?• What are the incentives for compliance?



Technology Evaluation

Strateg

ic A

lign

men

t



Tech

no

log

y E

valuatio

n

SO

A

Go

vernan

ce

Ch

ang

e of

Min

dset

Pillars: Technology Evaluation


Match of Technologies to the Problem Domain

Realistic understanding on what technologies can do in the specific problem domain.

How to understand and keep up with the “alphabet soup”?• XML, SOAP, WSDL, UDDI, WS-Security?

How to determine which standards and technologies to implement in specific situations?

How to build systems that are resilient to changes in standards and commercial products that implement them?



Technology Checks

TechChecks are prototypes, situated in a specific context, with the goal of providing a “technology sanity check”.

Model problems are ruthlessly efficient—no glitz; just answer the question.

The model problem approach involves1. Formulating hypotheses about

the technology2. Examining these hypotheses

against very specific criteria through experimentation

Develop Hypotheses

Develop Criteria

Design and Implement Solution

Evaluate Solution Against Criteria

[Hypothesis Sustained] [Hypothesis Refuted]



TechCheck Example: Context

Organization migrating from a federated suite of legacy applications and data stores to a solution based on Web services.

Establish feasibility of• Adapting current systems• Maintaining (or improving) current response time• Allowing image transfer• Providing single sign-on.



TechCheck Example: Hypotheses and Criteria


Hypothesis Criteria

75% or more of existing applications can be adapted to Web services.

1. There are SOAP libraries that can be easily linked into 75% of existing applications.

2. If not, there are clear mappings between native data types and XML Schema data types that will allow for manual serialization and deserialization of SOAP messages.

Response time will not be degraded due to the use of Web services.

Response times using Web services will be within the same order of magnitude from current response times for representative applications.

Images can be transmitted as part of SOAP messages.

An image can be requested using Web services and viewed on a client application.

It is possible to have single sign-on using Web services.

A user is able to login once and obtain information from three different Web services residing on three different machines.


Change of Mindset

Strateg

ic A

lign

men

t



Tech

no

log

y E

valuatio

n

SO

A

Go

vernan

ce

Ch

ang

e of

Min

dset

Pillars: Change of Mindset


SOA-Based Systems Require a Different Development Approach

Traditional System Development

Tight coupling between system components

Shared semantics at design time

Known set of users and usage patterns

System components all within the same organization

SOA-Based System Development

Loose coupling between applications and services

Semantics ideally enable dynamic discovery and execution of services

Potentially unknown service users and usage patterns

Multiple organizations providing system components



Less Control

Requires giving up control—not easy

Anticipate objections and understand validity• Security• Performance• Control

Greatest challenges come from• Single organization may not own the system• Services used in unknown ways by (potentially) unknown

users

Education and training on new mindset is needed



Agenda

Introduction to SOA

Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments• Reuse Issues• SOA Issues




Reuse in the SOA Context

Reuse at a higher level• Reuse of business functionality• Encapsulation of technical details

Reuse across organizations• Organizations can “sell” their core business expertise as

services • Functionality can be acquired as opposed to developed

from scratch—potential savings

Option for leveraging legacy system investment• In most cases, legacy components can be reused by

exposing them as services, independent of vendor, platform and technology

Migration Issues: Reuse


Reuse Issues 1

Reuse at the service level is more complex than reuse at module or component level• Designing reusable services requires a different

approach, skill set, and mindset• Bigger stakeholder community because services are

typically reused at organization and sub-organization level



Reuse Issues 2

It may not always be possible to reuse business functionality of legacy applications by exposing them as services

• Technical constraints due to the nature of the legacy application - A batch system needs to be exposed as a service for

an interactive online web application

• Immature technology or lack of technology for a particular legacy environment

Cost of exposing a legacy business application as services may be higher than actually replacing the system with a new SOA-based system



Addressing Reuse Issues

Identify relevant and non-relevant legacy assets• Not all legacy assets can be meaningfully reused as

services—both from a strategic and technical perspective

Make decisions based on “hands-on”, contextual analysis• System-specific analysis is important because every

system is unique• Previous analysis and results can be used a guidelines

Estimate cost, risk and confidence of estimates of changes required to each legacy component



Agenda

Introduction to SOA

Pillars of SOA-Based Systems Development Issues in Migration to SOA Environments• Reuse Issues• SOA Issues




Migration to SOA Environments: A Complex Engineering TaskThe characteristics of SOA enable the exposure of legacy system functionality as services• Presumably without making significant changes to the

legacy systems

Constructing services from existing systems in order to obtain the benefits of SOA is neither easy nor automatic

Such a migration can represent a complex engineering task• Particularly when the services are expected to execute

within a tightly constrained environment

Migration Issues: SOA Characteristics


Legacy System Characteristics

There are aspects of the legacy system that could make the effort challenging• Poor separation of concerns

- User interface code tightly coupled with business function code

• Tool availability- XML and SOAP libraries are not available for all legacy

platforms• Architectural mismatch

- The asynchronous call to the service might be in conflict with legacy system synchronous behavior

• Operational mismatch- The legacy system is batch-oriented, the service user

expects an immediate response• Dependencies on commercial products

- Licensing issues?



Bottom Line

There are issues to take into consideration that go beyond adding a service interface to an existing system.

SMART is an initial approach to the identification and analysis of issues in migration to services.



Agenda

Introduction to SOA





SMART: The Service-Oriented Migration and Reuse TechniqueAssists organizations in making initial decisions when analyzing legacy components for reuse as services

Focuses on the reuse of legacy components as services in an SOA

Outcome is a migration strategy for the organization

SMART: Introduction


Three Elements of SMART

1. Process that • Gathers information about

- Goals of migration effort- Candidate services- Legacy components- Target SOA

• Analyzes gap between legacy and target state

2. Service Migration Interview Guide (SMIG)• Guides discussions in initial SMART activities

3. Templates for Output Products – examples:• Component table• Service table• Migration strategies

SMART: Elements


SMART Process Activities

Establish Migration Context

Describe Existing

Capability

Describe Target SOA

State

Analyze the Gap

Develop Migration Strategy

SMART Elements: Process Activities


Sample SMIG Content

Migration Context• Goals and Expectations• Critical Business Processes• Potential Service Users• Legacy System Developers,

End Users and Owners

Existing Capabilities• Legacy System

Characteristics• System Architecture• Code Characteristics• Interfaces with Other

Systems

Target SOA State• Service Requirements• Target SOA• Data Models• Legacy System Adaptation• Service-Oriented Changes• Quality of Service

Support• Service Setup• Problem Reporting and

Feedback• Updates and Upgrades• User Communities

SMART Elements: SMIG


SMART ArtifactsEstablish

Migration ContextDescribe Existing

Capability Describe the

Target SOA State Analyze the Gap

Develop Migration Strategy

Stakeholder List Create Update Update Update Update

Characteristics List

Create Update Update Update

Migration Issues List

Create Update Update Update

Critical Business Processes

Create UpdateUpdate Update

Service Table Create Update Update Update

Component Table Create Update Update

Component Service Options

Table Create Update

Migration Alternatives Table

Create

Service Migration Strategy

Create

Final Presentation Create

SMART Artifacts


Case Study: Clinical Lab System

SMART Case Study: Context

Patient

Clinic

Doctor’s visit

Hospital

Hospital

Admission

Clinical Lab

Order Test

Order Test

Billing information

Insurance

Aggregate data for research

Clinical Research Center/

University

Results

Patient

Portal

Patient Data

Patient Data

Results

Results


Case Study: Clinical Lab System Context DiagramLab information shared between many systems

Need to move to a SOA environment to increase reusability of common lab tasks

Key questions:

1. Which services should be created from legacy assets?

2. In what order? 3. Should some legacy

components be replaced with new components?

Lab System

Inpatient System

Outpatient System

Research System

Patient Information

Online

Insurance

SMART Case Study: Context

SMART Engagement Scope


Establish Migration Context

Understand the business and technical context for migration

Identify stakeholders

Select candidate services for migration

SMART Activities: Establish Migration Context


Case Study: Understand Business Drivers for Legacy Migration Improve patient care by • Standardizing the access to lab information using services• Providing access to lab information from any clinical

system in real time (current access is mostly batch-oriented)

• Making lab information accessible to patients via the Internet using a patient portal

Reduce IT costs by • Creating common and reusable services • Reducing the multiple redundant interaction points

(interfaces)• Lowering maintenance and upgrade costs by using an

SOA environment

SMART Case Study: Understand Business Context


Case Study: Identify Stakeholders

Lab System

InpatientSystem

Outpatient System

Research System

PatientInformation

Online Insurance

Legacy system: Clinical Lab

Legacy system developers, service designers, business manager, project manager

Outpatient physicians, architects, Service designer, IT/Infrastructure staff

Inpatient doctors, software architects, service designers, IT/Infrastructure staff

Patients, Portal architect, Developers

Researchers, IT infrastructure developers

Insurance policy makers, architect

Existing system: Medical School

Existing system: Clinics Existing system: Hospitals

New system: Patients on Internet Existing system: Insurance Companies

SMART Case Study: Identify Stakeholders


Establish Migration Context: SMIG Examples

Discussion Topic

Related Questions

Rationale Why is the migration to an SOA environment being considered?

Expectations What are the expectations from the migration effort?

Potential Service Users

Have users or systems that will use the services been identified? How were their service requirements identified?

Legacy System Stakeholders

Who owns the legacy system? Who developed the legacy system?

Business Goals and Processes

What are the main business goals?What are the main business processes that support these goals?What are common steps/tasks between these business processes?



Establish Migration Context: Tasks

Create Stakeholder List

Create Stakeholder List

Create Characteristics

List

Create Characteristics

List

CreateMigration Issues

List

CreateMigration Issues

List

Update at any time!

•Stakeholders•Contact

Information•Information to

be elicited from each

•Identify component characteristics to be gathered

•Some are predefined•Others vary with

context•Provides data for

analysis process

Identify issues as they become evident

•General issues affect the overall migration effort

•Component- or service-specific issues

Create Service Table

Create Service Table

•Identify candidate services and the business processes they support

•Identify potential information sources

• Architects• Service users• Domain groups• Communities of Interest

(COIs)



Case Study: Service Table

Service Description Service Type Business Process Supported

Get Test Results Details

Obtains detailed test results either for one patient or for all the patients for which tests were completed on a day for a particular location.

Business

• Analysis and mining for trends

• Review and report of results• Archival and retrieval of test

results

Data Transfer Service Wraps and transfers all data payload to external systems. Infrastructure

• Business services internal to the Lab system

• External applications or services that need to provide bulk data back to the Lab system

ServicePotential

Service Users… … … …

Get Test Results Details Hospital, Clinic and Patient applications

Data Transfer Service Internal services and external applications and services

SMART Case Study: Service Table


Describe Existing Capability: Tasks

Update Characteristics

List

Update Characteristics

List

Create Component

Table

Create Component

Table

UpdateMigration Issues

List

UpdateMigration Issues

List

•Identify components for potential migration

•Gather characteristic data for each component

•Characteristics become columns of the component table

•Indicate data to be gathered about each component

•Issues will appear as data is gathered

SMART Activities: Describe Existing Capability


Case Study: Implementation Characteristics Written in C++ and Java

Some components run on Windows operating system and some on Unix OS

~2500 C++ classes and ~1500 Java class

800,000 lines of code

Dependencies on several commercial products:• Oracle Database• Weblogic Application Server

SMART Case Study: Legacy System Characteristics


Case Study: Updated Migration Issues

Description: All service consumers do not plan to move to the XML compliant version (v3) of HL7Description: Some legacy components are designed only for

batch operations …..

Description: Some legacy components have direct calls to UI embedded in the core business logic of the codeIssue Type: Technical

Related Component: Lab Results Reporting, Order Processing Complexity: Medium

Description: Different data filtering policies are applied to the same data depending upon on the interacting external system Issue Type: Business, Policy

Related Component: Results Retrieval

Complexity: Low

SMART Case Study: Migration Issues

New

New


Describe Target SOA State: Tasks

Update Characteristic

s List

Update Characteristic

s List

Create SOA

Description

Create SOA

Description

Update Service and Component

Tables

Update Service and Component

Tables

Update Migration

Issues List

Update Migration

Issues List

SOA Description will most likely provide additional characteristics to be gathered about services and components

SMART Activities: Describe Target SOA State


Case Study: Updated Component Table

Component Programming Language Age (years) Size (SLOC) Complexity Level of

Documentation Version

LabTestCatalog Java 6 12,000 Medium High 5.6

OrderProcessor C++ 8 8,000 Very High Medium 8.2

ComponentLast Release

DateMax. Depth of

InheritanceCoupling

(# of classes)Cohesion COTS Dependency

LabTestCatalog 02/10/2005 5 60 MediumOracle database, Weblogic

Application Server, HL7 v2.3

OrderProcessor 06/01/2005 8 80 FairCustomer Interface Engine, Some 3rd

party libraries

ComponentDirect Calls to UI Hard coded

Policies and RulesSecurity

Requirement LevelUpdated Detailed Design Document

Available?

LabTestCatalog Yes No Medium No

OrderProcessor Yes Yes High Yes

SMART Case Study: Component Table


Case Study: Target SOA StateBusiness Services• Reusable business services that are created by reusing the

existing legacy code base

Policy Manager • Centralizes the configuration, deployment, change management

and storage of policies

Infrastructure Data Transfer Service• Used by all the business services to transfer and receive data

from external systems

Infrastructure Security Service• Provides secure transmission of a confidential data • Provides authorization and authentication services from external

interacting systems

Infrastructure Data Format Service• Formats messages according to HL7 v2.x or HL7 v3 as needed

by business services and external applications

SMART Case Study: Target SOA Characteristics


Case Study: Target SOA Constraints

Services shall support different versions of the HL7 standard• Patient Portal will use the new XML complaint version (v3)

of HL7• Some other systems (Outpatient, Inpatient) plan to move to

HL7 v3 in near term while others don’t have any plans

Services shall take into account the different policy requirements for the same data• Research data should be completely anonymous (without

any Personally Identifiable Information – PII) • Inpatient/outpatient data should be completely identifiable

for each patient



Case Study: High-Level Target SOA

Research Database

Test Results Service

Security Service

Order Lab Test Service

Get Patient

Information

Enterprise Service Bus (ESB)

Results and Reporting

Order Processing Component

Inpatient System

Outpatient System

Insurance Company System

Data Transfer Service


Data Format Service

Patient Portal

Policy Manager


Analyze the Gap: Tasks

Create Component

Service Options

Table

Create Component

Service Options

Table

Identify Additional

Data Needed

Identify Additional

Data Needed

Gather Additional

Data

Gather Additional

Data

Analyze Component/Servic

eOptions

Map components to services

•Need not be one-to-one

•Alternate approaches may be possible

Incomplete or untrustworthy data?

• Architectural analysis• Architectural

reconstruction• Code analysis

Update all tables!

•Estimate cost/effort

•Determine risk

SMART Activities: Analyze the Gap


Case Study: Analyses Performed

Three types of analysis performed

• Informal evaluation of code quality - No consistent coding standards in force- Parts of the code had little cohesion- Awkward and non-standard class/modules

organization

• Architectural reconstruction to gain a better understanding of code dependencies when the SMART team found discrepancies

• Effort and cost estimation of changes necessary to migrate legacy components

SMART Case Study: Gap Analysis


Case Study: Key Findings

Insufficient architectural and other high-level documentation to accurately determine class dependencies• Potential for underestimation of the amount of code used

by the potential services• No details on code module dependencies

No consistent programming standard • Automated code analysis is not easy

Violation of Model-View-Controller architecture• Undocumented dependencies between potential

services and user interface code have to be identified and removed

SMART Case Study: Gap Analysis


Select Recommended

Options

Select Recommended

Options

Develop Migration Strategy: Tasks

Create Migration Alternatives

Table

Create Migration Alternatives

Table

Analyze OptionsAnalyze Options PresentFindings

PresentFindings

•What components?

•What services?

There can be more than one viable strategy

• Different sequencing

• Use of external services

• Use of COTS products

Estimate comparative cost, effort, and risks

SMART Activities: Develop Migration Strategy


Migration Alternatives Table

$K % % Q QQ QQ Q Q $KMM MMN

MigrationOption

# 1

ServiceNeed

Satisfied

OptionNumber

MigrationEstimates

New DevelopmentEstimates

Migration VersusNew Development

Name of Service Need

OptionSummation


MigrationOption

# 3


OptionSummation


MigrationOption

# 2


OptionSummation



Outcome of SMART

Summary

Report

RESULTS

List of stakeholders List of candidate services Description of legacy components, target SOA Results of analyses Description of various migration options Cost and effort of selected options

RESULTS

List of stakeholders List of candidate services Description of legacy components, target SOA Results of analyses Description of various migration options Cost and effort of selected options



Case Study: Recommendations

• Perform a workshop with all the key stakeholders to- Validate the expectations and requirements for the new

services- Define a roadmap for the migration effort

• Identify services that are both important and less complex than the ones initially identified

• Implement these services a pilot using the current target architecture

• Revisit the new architecture (SOA) after the pilot phase to make changes based on the lessons learned in pilot phase

• Identify the order in which services should be implemented based on greatest impact with lowest risk; prioritize and plan accordingly

• Recalculate cost/effort when- Code dependencies are better documented- User requirements are better understood- Target SOA is better defined

SMART Case Study: Migration Strategy


Agenda

Introduction to SOA

Pillars of SOA-Based Systems Development Migration to SOA




Conclusions 1

SOA offers significant potential for • Leveraging investments in legacy systems by providing a

modern interface to existing capabilities• Exposing functionality to a greater number of users

They accomplish this by promoting• Assembly of applications from existing services • Platform and language independence• Reuse of services through loose coupling• Easy service upgrade due to separation of service

interface from implementation

Conclusions


Conclusions 2

End-to-end engineering approach for SOA requires addressing the unique challenges, risks and technical issues of three different development perspectives

• Applications that make use of services

• Services used by applications and other services

• Infrastructure that allows the discovery of services and the data exchange between application and services

Conclusions


Conclusions 3

Reuse at the service level is more complex than reuse at module or component level• Designing reusable services requires a different

approach, skill set, and mindset• Bigger stakeholder community because services are

typically reused at organization and sub-organization level

Cost of exposing legacy system functionality as services may be higher than actually replacing the system with a new SOA-based system• Detailed analyses are needed

Conclusions


Conclusions 4

Reuse in the services world requires

• Identification of needs of the target architecture

• Clear distinction between the needs that can be satisfied by the legacy system and those that cannot be satisfied

• Systematic analysis of changes that need to be made to fit into target architecture

Conclusions


Conclusions 5

SMART analyzes the viability of reusing legacy components as the basis for services by answering these questions:

• What services make sense to develop?• What components can be mined to derive these

services?• What changes are needed to accomplish the migration?• What migration strategies are most appropriate?• What are the preliminary estimates of cost and risk?

Conclusions


References

Pointers to Technologies and StandardsISIS Guide to Interoperability http://www.sei.cmu.edu/isis/isis-guide.htm

SMART: The Service-oriented Migration and Reuse Techniquehttp://www.sei.cmu.edu/publications/documents/05.reports/05tn029.html

References

Sponsored by the U.S. Department of Defense © 2006 by Carnegie Mellon University Version 1.3 (ICSM...

Documents

Transcript of Sponsored by the U.S. Department of Defense © 2006 by Carnegie Mellon University Version 1.3 (ICSM...