transitioning from objects to services – a report from the ...risk management total cost of...

Max Dolgicer Gerhard Bayer

Managing Director Senior Consultant

[email protected] [email protected]

Transitioning From Objects To Services –A Report From The Trenches

From Chaos To Order - Delivering e-Business Integration Solutions

© 2008 International Systems Group (ISG),Inc. 2

International Systems Group (ISG), Inc.

� Founded on the premises of Middleware technologies 17 years ago in New York City

� Three practice areas:

� �IT Strategy and SOA Architecture practice

� Definition of SOA

� SOA Assessment and SOA Compliance Verification

� SOA Roadmap

� SOA Mentoring

� SOA Migration Strategies

� CIO Summits / IT and Business Alignment

� �SOA Modeling, Design and Implementation practice

� Development of applications and infrastructure services

� Application Integration solutions (A2A and B2B)



� �Education and Training practice� Public and on-site training

� Out-of-the-box classes

� Customized classes

� Service Oriented Integration (SOI) - Concepts, Technologies, and Best Practices

� Service Oriented Architecture (SOA) – Architecture, Governance, Standards and Technologies

� Designing and Implementing Service Oriented Architecture (SOA) Based Applications

� When SOA Is Not Enough – Achieving Agility Through Business Event Processing



� ISG professionals average 17+ years of experience in development and integration of distributed systems

� Real hands-on experience spans end-user corporations and software vendors

� Domain expertise includes financial, insurance, transportation, telecommunication and government


Agenda

� Business process walk-through

� Business objectives and IT approach

� From “accidental” architecture to SOA� Review of the legacy architecture

� Objectives and scope of the new architecture� Encapsulation & migration of legacy system

� Legacy system replacement

� The layered services architecture � Services, components, and legacy systems

� Service reuse for B2B

� Service reusability enables business agility

� Return on investment (ROI) calculation

� Conclusions


Case Study: Chauffeured Services Company

� The Company provides premium limousine services

� The clientele of The Company comprises � Individual customers including many celebrities

� Corporate clients

� Travel agencies

� The Company provides services to its customers via� Subsidiaries, Affiliates, Licensees and farm outs

� In addition, there are external sources of business information� E.g. Global Distribution Systems (GDSs)


Typical Business Process Walk-Through

B2B

Gateway Or

Portal

Reservations &

Profiles Services

DispatchingServices

Billing

Services

76

5 4

3

21

8

9


Typical Business Process Walk-Through

� A complete business process that covers all phases of a car service booking consists of the following steps:

1. A customer or travel agent request the creation of a new reservation

2. The Reservation system makes a new reservation

3. The Dispatching system picks up the new reservation

4. The Dispatching system sends a job allocation to a driver through a 3rd-party wireless network

5. The driver receives the job allocation

6. The driver reports end-of-job billing information via the 3rd-party wireless network

7. The Billing system receives the end-of-job information and calculates the bill

8. The Billing system sends and invoice to the customer

9. The customer receives the invoice


Business Objectives & IT Approach

� Core services (foundation and some application) are implemented by highly skilled designers/developers

Risk management

� Service reuse, decreased complexityTotal cost of ownership (TCO)

� Automated B2B integration with major GDSs and other types of business partners.

Allow travel agents to book with The Company using major GDS systems.

� Creation of a centralized reservation system with customer profiles

� SOA enables efficient integration of a portal with back office systems

� Centralized SOA leads to improved business process consistency

Customer Service Enrichment• Single view if the customer

• Better customer self-service

• Improved business process

consistency

� Better leverage of the IT infrastructure and processes

� Increased extensibility and adaptability of the core applications

� Avoid one-off integration solutions

Revenue Enhancement• New service offerings

• Cross-selling

• Acquisitions

Addressed by ITBusiness Objectives


Evolution Of IT

� IT at The Company’s subsidiaries consists of locally installed and managed applications � Legacy software (CSW)

� Manages reservations, dispatches and end-of-job functions at local subsidiaries and franchises

� Hudson software - third party software, same as CSW but includes also billing functions

� Odyssey - third party software

� IT at Corporate Headquarters consist of � CESRes – home-grown, distributed application

� Provides reservation, profiles and customer service functions

� Centrally deployed in the data center

� Now WebSphere J2EE based� Originally developed as Java/Corba and ported to WebSphere

� Supports multiple inbound channels� Internet bookings through company web site

� Call center where rich client (i.e. Swing) is used


Evolution Of IT

� “Friendly Billing”

� Provides generation of invoices

� Centrally deployed

� Legacy, 4GL (i.e. Magic based) system

� Oracle/PeopleSoft to perform all AR/AP functions

� Centrally deployed


Hudson

Old “Accidental” Architecture

Reservation

CSW

Corporate

Reservation

Dispatching

Dispatch

EOJ

Pricing/Costing

Billing

Cash/AR

PeopleSoft

Friendly Billing

Reservation/CES

Typical Local Office Headquarters


Business Requirements For IT

� This “accidental architecture” has hampered the business

� About 80% of reservations are made at one of the local offices

� Creates a huge integration problem and a lot of manual labor especially when it comes to handling exceptions

� Only about 20% reservations are made at the call center or via the company web site

� The goals:

� Support all of the core business functionality from one (logically) central location

� Support the expansion of service offerings

� Support the acquisition of other companies


Target New Architecture

Booking Agents

Dispatch

Chauffeurs

Back Office / Customer Service

BusinessAviationSystems

Travel Web Sites

Customers

GDS Systems

Electronic Distribution

Channels

Customer Intranet

Sites

Supply Chain

Partners

Service Network

Po

rtal

B2B

Gate

wa

y

Reservation & Profiles

Billing

Dispatch

Wireless EOJ

Business Intelligence

Orchestration Services

Application Services

Infrastructure Services


Objectives Of The SOA

� The main objectives of the Service Oriented Architecture at The Company include:

� Contain cost

� Maximize the efficiency of services by eliminating redundancies and increasing reusability

� Reduce the number of applications from 35 to 15

� Decrease in software license cost & maintenance complexity

� Create a comprehensive “big picture” view of the enterprise systems

� Old services can be migrated

� New services can be created without significant risk or investment of additional resources

� Introduce a high level of accountability, trace-ability, and accuracy to the application development process


Architecture Scope

� The overall goal is to define a central system that delivers full business functionality to all sites, but that is maintained in a single location.

� The scope of the architecture includes

� Consolidation of the reservation system

� Migrate to the new J2EE environment

� Encapsulate existing services

� Surround by new services

� Replace legacy implementation

� Expand the reach: more and more reservations will be handled by the central reservation system

� Really “surround and retire” as opposed to “rip and replace” or “leave and layer” strategy


“Surround & Retire”

New Functionality

Replacement

Reservation System

EnhancementE

ncap

su

lati

on

Replacement

Dispatching System

Replacement

Billing System


Encapsulation Of Existing Business Logic

GT3 Orchestration

Service

CES interface object APIs

CSI Orchestration

Service

Old Web Application New Reservation Service Interface

JSP

Struts

Utility Services

Business Delegates

Session Bean

Facades

Unified code base

WebClient

Swing Client


Encapsulation Of Existing Business Logic

� The unified code base is a consolidation of all current versions of the Web application code that resides below the presentation logic

� This means that there will be only one code base that all types of clients can utilize to interact with the reservation system

� A client could be

� The presentation component of the legacy Web application

� The Swing client of the desktop application

� Any of the B2B channels that are part of the B2B Gateway, like for example the GT3 channel and the standard B2B channel


Architecture Scope

� The scope of the architecture includes� Replacement of the billing system

� Current: central legacy 4GL system (i.e. Friendly Billing)

� Some subsidiaries manage billing locally, others use a manual process to transfer billing to the central system

� The new system will handle pricing, costing, and adjustments centrally

� End-Of-Job information will be sent from subsidiaries to the central system

� Drivers can send adjustments directly from their J2ME enabled handheld devices

� Replacement of the local dispatching applications by a new central dispatching system

� SLA for this application is a big challenge

� Common infrastructure (i.e. foundation) and common application services


Service Layer Model

� Key architectural principles for SOA design are

� Separation of concerns

� Design for reusability

� Separation of concerns is achieved by a separation of functionality into layers

� Breakdown into distinct layers facilitates decouplingof the services

� One of the most important characteristics of a well-defined SOA

� Service layer model for SOA:

� Orchestration Services layer

� Application Services layer

� Infrastructure Services layer


Component 1Component 1

Component 1

Services, Components, Legacy Systems




Components Legacy Systems

Service 1

Service 2 Service 3

Service 4 Service 5 Service 6

Component 1 Legacy 1


Service Layer Model

� Orchestration services:

� Orchestration services implement the business processes that traditionally constitute an application

� Dispatching application

� Example: Job assignment – a list of available resources (driver/car pairs) is built, one resource is selected, the driver is notified and sends an acknowledgement back

� Billing application

� Example: End of job processing – business expense information is collected from the driver, combined with the basefare and additional items to construct the final bill for the customer

� They also map B2B partner requests to activities that are internal to The Company


Service Layer Model

� Application services:

� These are business process agnostic

� They are used by multiple business processes (e.g. Dispatching, Billing, B2B partners, etc)

� Legacy reservation system wrapper service

� Encapsulates the existing reservation application

� The legacy system is a object oriented application with proprietary data formats

� There is an inbound and an outbound wrapper service

� City of Service calculation service

� Calculates the location of the nearest service hub based on pick-up and drop-off location

� Invoice service

� Encapsulates the billing system in order to provide external partners limited access


Service Layer Model

� Infrastructure services:� This layer contains services that are technology

specific� Message store service

� Captures an audit trail of all messages that are exchanged with business partners

� Communication service

� Provides an abstraction to several communication mechanisms� HTTP, RMI, JMS, SOAP

� Notification service

� Facilitates sending a notification message to operations personnel, e.g. via email

� Security service

� Provides authentication, encryption and decryption

� Transformation service

� Transforms data between partner formats, internal standard format, and the format of the legacy back office systems


The Layered Services Architecture

� The breakdown into distinct layers facilitates decoupling of the services� One of the most important characteristics of a well-

defined SOA

� Reusability is achieved by designing key application services and infrastructure services that are autonomous and are agnostic of the business process context within which they are executed� For example, the same services are being utilized by

different presentation layers� Web interface (customer portal)

� Thick client (Swing interface for internal users)

� B2B channels (business partners)


Transformation

Architecture Overview

Enterprise Resources

Legacy Systems

Message Store

Communication

Security

Account

Provider

Advisory

Job Passenger

Rate

Dispatch ReservationsBilling

Local Offices

Call Center Customer Partner

InternetPrivate Network



CESRes

Notification

Infrastructure

Services

Reservation Service Wrapper


SOA Core

� The SOA prescribes a multi-tier architectural foundation� Presentation tier

� Subsidiaries, call center, customers, business partners

� Business process tier� High-level, adaptable business logic

� Core business logic tier, i.e. application services� Reusable domain logic, independent of business processes

� Infrastructure tier� Insulates applications from low-level system services

� Back-office tier� ERP, legacy systems

� This core supports all business applications and a B2B Gateway

© 2008 International Systems Group (ISG), Inc. 29

B2B Integration Strategy

Booking Agents

Dispatch

Chauffeurs

Back Office / Customer Service

BusinessAviationSystems

Travel Web Sites

Customers

GDS Systems

Electronic Distribution

Channels

Customer Intranet

Sites

Supply Chain

Partners

Service Network

B2B Gateway

Core Application Services

Reservations

Reservations And

Profiles Services

Passengers

Accounts

Price Quotes

Service Providers

Locations

DispatchingServices

BillingServices

© 2008 International Systems Group (ISG), Inc. 30

B2B Gateway Service Layers

CSI Reservation

Services

CSI Reservation

Services

CSI Reservation

Services

CSI Reservation

Services

CSI Reservation

Services

Business Partners

Vettro Inbound Request Service

GT3 Reservation

Request Service

GT3 Customer

Cancel Service

CSI Reservation

Services

Reservation Service Wrapper

City of Service

Calculation


Orchestration Services Application Services

Vettro GT3Future

Partners

Sockets, Web Service (HTTP)

Message Store SecurityCommunication Notification Transformation

Invoice Service


The Layered Services Architecture - Example

� A multitude of business partners interact with The Company through different B2B channels

� One partner is the Ground Travel Technology Team (GT3)

� It provides an interface to the major computerized reservation systems

� E.g. Sabre, Apollo and Worldspan

� Reservation requests are being sent from GT3 to The Company



CommunicationMessage Store Security Transformation

Reservation

GT3 Reservation Request

Notification




City of Service



� The GT3 Reservation Request service model implements a business process where the GT3 system sends a request to The Company to create a new reservation, change or delete an existing reservation adhering to some well defined business rules

� An Orchestration Service manages the flow of business transactions between The Company and GT3� It also maps the reservation requests to activities that

are internal to The Company

� It uses common infrastructure and application services� Reservation, City of Service Calculation, Message Store,

Security, Transformation, Notification, and Communication


How To Align Business And IT Through SOA

� Most companies face an increasing complexity of their enterprise application portfolios

� Fulfilling business demands by adding new applications and packages

� Building more connections between systems in order to achieve integration

� Portfolio complexity slows down responsiveness of IT to business requests and in turn negatively affects business agility

� SOA allows to streamline application portfolios

� Reduce redundancies

� Simplify connectivity across internal and external enterprise boundaries through standardization


Service Reuse = Business Agility

Business Process (Orchestration Service)

Service Registry


The Company

?


Portal

Business Partner

Business Process

Service Registry

Internal Systems

?

Partner Facing Orchestration

Services


Service Reuse = Business Agility

� Across a number of projects, more and more application services and infrastructure services are implemented

� Build-out of service repository

� New business processes are implemented as new orchestration services

� Potentially, additional application and infrastructure services need to be developed

� Develop as you go approach

� Services implemented for use by internal processes can be reused for B2B

� External partners do not utilize specific services, but typically connect to exposed orchestration services


Reusability: Example

� SOA principle: reusability

� Application and infrastructure services provide business process agnostic functionality that can be reused across different business processes

� Reservation Service Wrapper:

� Under certain circumstances a change reservation request will require a cancellation followed by a rebooking

� Don’t put into orchestration service that is business process specific

� Implement something like this in the application service that isbusiness process agnostic and can be reused across processes


Reusability: Example

� SOA principle: reusability

� Application service example: City of Service calculation service

� Calculates the location of the nearest service hub based on pick-up and drop-off location

� This application service is reused in many business processes

� Find the optimal location from which to dispatch a car

� Calculate a rate quote

� In case the company has no available inventory, find the nearestaffiliate


Process Composition = Business Agility


Repository

Business Analyst

Application Developer


Composition

Development

Software Engineer



Process Composition = Business Agility

� The SOA facilitates a separation of concerns

� Therefore the skill sets can be separated

� Software Engineer

� Implement infrastructure services that require experience with system software, e.g. persistence service, security service, scheduling service, reporting services

� Develop design guidelines for application services that ensure non-functional requirements are met (e.g. clustering, fail-over)

� Application Developer

� Possess good business domain knowledge and develop application services that fulfill functional requirements

� Business Analyst

� Assemble application services into new business processes through the definition of orchestration services


ROI Through Service Reuse

� ROI in a SOA comes from reusing services across a number of projects

� This means that a service is used in the context of different business processes

� Requires that application services and infrastructure services are designed such that they are autonomous and agnostic of the business process context within which they are executed

� Application service reuse

� Based on identifying functionality that is common to a particular business domain



� Application service reuse (cont.)

� The Company implements a number of applications (i.e. business processes) that all need several common application services:

� Reservation service – provides business logic to create, change, delete reservations,

� Job service – manages all information related to one travel arrangement,

� Rate service – handles requests for rate quotes,

� Provider service – deals with the business partner who fulfills the travel request,

� Passenger service – implements functionality to manage a passenger



� Application service reuse achieved across three applications / business processes

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

Lines of code

Dispatch EPCAB Reservations

Process

Reservation

Job

Advisory

Rate

Provider

Passenger

Arranger

Account

Infrastructure Pricing/Billing

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

Lines of code


Process

Reservation

Job

Advisory

Rate

Provider

Passenger

Arranger

Account


0

5000

10000

15000

20000

25000

30000

35000

40000

45000

Lines of code


Process

Reservation

Job

Advisory

Rate

Provider

Passenger

Arranger

Account


0

5000

10000

15000

20000

25000

30000

35000

40000

45000

Lines of code


Process

Reservation

Job

Advisory

Rate

Provider

Passenger

Arranger

Account




� Infrastructure service reuse� Infrastructure services generally have the highest

reuse potential since they provide functionality that is needed in most applications, independent of a particular business domain

� Some of the infrastructure structure services that were implemented include:

� transformation service – converts data between XML representation and legacy system formats and business partner formats;

� audit trail service – captures all information exchange with business partner (B2B);

� notification service – sends messages to email, fax, pager, and other devices;

� reservation service wrapper – encapsulates the legacy reservation system


ROI Model For Software Reuse

� A ROI model needs to consider two factors:

� Cost savings based on service reuse

� Additional cost in designing and implementing reusable services

� Popular software ROI model:

� J.S. Poulin and J.M. Caruso in “A Reuse Measurement and Return on Investment Model,”Proceedings of the Second International Workshop on Software Reusability, Lucca, Italy, March 1993

� Dates back in time, but the fundamental assumptions are still correct

� The numbers have to be adjusted for today’s kind of projects

� I.e. given today’s technologies, application development approaches, and tools



$40 (multiplier 1.33)

Multiplier: 1.2

$150Cost of non-reusable line of code multiplied by 1.5

Cost per reusable line of code

$5 (multiplier 0.16)

Multiplier: 0.1

$20 per line of reused code

Cost of non-reusable line of code multiplied by 0.2

Cost of reusing code engineered for reuse

$5,000$15,000 per defect

The cost of repairing defects once they have been promoted into production code.

Cost of defect repair

1.01.0The number of defects contained in a typical project’s production code; averaged over 10 or more projects.

Defects per 1000 lines of code

$30$100Cost for all development exercises of a project divided by number of lines of code; averaged over 10 or more projects.

Cost per non-reusable line of code

Case study

Poulin SOA values

Original Poulin Numbers

RationaleMetric



� Applying the ROI model to three projects of The Company

� i.e. the three applications “Dispatch”, “Pricing/Billing”, and “Reservations”


Conclusions: Service Reuse

� The success of the SOA migration depends to a large degree on service reusability

� The potential for reusing a service is significantly improved when the SOA follows a proper layering of the services

� Orchestration, application, and infrastructure services

� Application and infrastructure services provide business process agnostic functionality that can be reused across different business processes

� An initial investment into the architecture is required

� The overall SOA needs to be defined

� The first architected sub-project does not benefit, since it contributes services for later reuse


Conclusions: Keeping Track Of Reuse

� Reusability doesn’t just happen

� It is the product of a development process that addresses reusability as one of its principals

� IT organizations will not create highly reusable services over night, but their capabilities to achieve this will grow over time

� The progress that an IT organization makes along the path of SOA reuse can be visualized using a bubble chart

� Helps to monitor how the benefits of a service oriented approach are achieved over time and across projects

� Allows the stake holders who invest in SOA to easily grasp that the money is well spent


Conclusions: Keeping Track Of Reuse

-2

0

2

4

6

8

10

12

-2 0 2 4 6 8 10 12 14

1

2

3

4

11

5

10

6

9

7

8

Contribution to SOA

Exploitation of SOA

Bubble size = cost of project


Conclusions: Project Risks

� Components vs. services

� The client’s development organization had been specializing in J2EE and Spring

� Moving to SOA required a paradigm shift

� This was sometimes met with resistance

� Budgeting for reuse

� The cost savings of service reuse can easily be demonstrated

� However, developing for reuse incurs additional upfront cost

� Business pressures have sometimes forced a shorter term view on the project

250 West 57 Street, Suite 2532 New York, NY 10107

Tel: (212) 489-0400 Fax: (212) 489-1125

email: [email protected] http://www.isg-inc.com

From Chaos To Order - Delivering e-Business Integration Solutions

transitioning from objects to services – a report from the ...risk management total cost of...

Documents