State of Washington Department of Labor & Industries L&I’s Journey to a Service-Oriented IT Architecture

State of WashingtonDepartment of Labor & Industries

L&I’s Journey to a

Service-OrientedIT Architecture

L&I’s Journey to a Service-Oriented Architecture 2

Agenda

Background and Objectives Key Concepts of SOA at L&I L&I’s Approach to SOA L&I’s Service Model L&I’s 12 Core Shared Services Lessons Learned


L&I Future Technology (LIFT) project (2002-2003): Architecture initiative to identify the business-aligned IT strategies and long term technology investments required to achieve them (10 Year Plan).

LIFT GOAL: Create a more agile IT architecture that can quickly respond to changing business needs.

Background – LIFT Project


1. Improve alignment with business

2. Improve sharing and reduce stove-pipes

3. Quickly respond to changing business needs

4. Reduce time to build and maintain business apps

5. Minimize technology support requirements

6. Improve developer efficiency

Service-Oriented Architecture

LIFT Objectives


SOA = Web Services• Service-Oriented Architecture (SOA): An IT

architectural style based on the concept of a collection of services that communicate and coordinate with each other in an enterprise-level, distributed computing environment.

• Service (n): A self-contained, reusable function that is invoked through well-defined interfaces and is independent of the context, state or location of other services or applications.

• Reuse: Services encapsulate business functions that are located and reused at run-time.

Key SOA Concepts

/


• Coarse-Grained: Granularity is the level of detail at which an item is viewed or described. Services tend to be Coarse-Grained where as an API is fine-grained.

• Loose Coupling: Service provider and consumer need no knowledge of how the other is implemented resulting in minimal dependencies. Generally implies asynchronous messaging.

• SOA Governance: The organization and processes to ensure optimal reuse of services and enforcement of policies (eg. Business design, technical design, application security).

Key SOA Concepts

SOA = Concepts and Principlesnot Technology


• Web Services: A specific implementation of SOA that uses standard Web protocols to connect services together via XML messages. Most commonly used scenario is synchronous request/response pattern.

• Message Oriented Middleware (messaging): A category of inter-application communication software that relies on asynchronous message passing as opposed to a request/response metaphor. (eg. MQSeries)

• Enterprise Service Bus: Message Oriented Middleware that provides a robust asynchronous transport service for XML messages and standard Web services protocols.

Key SOA Technologies

SOA is not a new concept – but new technologies, like Web services, have made it more practical

Migrating to SOA

So how do we get there?


Two Approaches to SOA

Top Down – Business-centric Start with high-level picture of Business Processes Decompose processes – look for redundancy,

Service candidates Best approach to demonstrate business value

Bottom Up – Technology-centric Start by looking at existing IT capabilities Look for redundant coarse-grained functions to

expose as Services Prioritize with 80/20 rule – Expose the 20%

functionality that is used 80% of the time LIFT began with this approach


UserInterface

Security

Reporting

Workflow

Business RulesProcessing

Correspondence

Entity Mgmt

Core BusinessLogic

LIFT analyzed Industrial Insurance Apps

Only about 30% Unique Business Logic

Bottom-UpIdentify Redundant Functions


UserInterface

Security

Reporting

Workflow


Correspondence

Entity Mgmt

Core BusinessLogic

LIFT analyzed Industrial Insurance Apps

Only about 30% Unique Business Logic 70% Redundant

Functions Common to Most Business

Applications



UserInterface

Security

Reporting

WorkflowBusiness Rules

Processing

Correspondence

Entity Mgmt

Core BusinessLogic

UserInterface

Security

Reporting


Processing

Correspondence

Entity Mgmt

Core BusinessLogic

UserInterface

Security

Reporting

Workflow


Correspondence

Entity Mgmt

Core BusinessLogic

Multiplied times many apps…Lots of redundant functionality

to build and maintain


WHAT CAN WE DO?


UserInterface

UserInterface

UserInterface

Reporting


Core BusinessLogic

Security

Correspondence

Core BusinessLogic

Workflow

Entity Mgmt

Core BusinessLogic

WebFacing

InfoDelivery

BusinessRules

SecurityCorresp. WorkflowEntityMgmt

Security

Workflow

Correspondence

Entity Mgmt

Reporting


Processing

Entity Mgmt Security

Reporting


Correspondence

SHARED SERVICES

INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE

Tight Coupling?X

Build Functions as Services


Message Bus (asynchronous)

Core BusinessLogic

Core BusinessLogic Core Business

Logic

WebFacing

InfoDelivery

BusinessRules


SHARED SERVICES


INTERFACE INTERFACE

INTERFACE



Core BusinessLogic

Core BusinessLogic Core Business

Logic

WebFacing

InfoDelivery

BusinessRules


Message Bus (asynchronous)

SHARED SERVICES

XML


INTERFACE INTERFACE

INTERFACE


LOOSE COUPLING

XML

XML

XMLXMLXML XML

XML over MQ or XML/SOAP

Shared Services Overview

Description of L&I’s Shared Services and how they all work together to

deliver a more agile technical environment


BusinessApplication

Services

BusinessFramework

Services

InfrastructureFramework

Services

InfrastructureFoundation

Services

Management Security Interaction

Bu

sin

ess

Lo

gic

- D

evel

op

er R

elev

ance

HIGH

LOW

Ge

ner

aliz

ati

on

- S

tan

dar

diz

ati

on

LOW

HIGH

Enables technologies atdifferent layers to interactvia XML messages, i.e.

Web Services

Technologies that protectsecurity and privacy, e.g.

encryption protocols

Standard systemmanagement technologies,

e.g. snmp

Technologies not intended for sharing across multiple processes Applications contain very specific and purposed business logic Contain services from lower levels (Ex: Customer Relationship Management, Human Resources, Inspections)

Technologies shareable across multiple business processes or applications May consist of components from lower layers Broad business logic High degree of relevance to developers (Ex: Accounts Receivable, Payment Processing, Inbound Correspondence)

Generalized, shareable technology Not fully standardized May consist of components from lower layer No business logic natively, but can be programmed Little relevance to business users, but some relevance to developers (Ex: Application servers, Work Flow, Message Routing, Access Control)

Highly generalized and standardized technology High degree of commoditization Broadly shareable across the enterprise Contain no business logic Not very relevant to application designers (Ex: servers, directories, storage, XML Cache, Messaging Middleware)

Enterprise Services Model - Definitions


BUSINESS APPLICATION SERVICES•Not shared across multiple processes•Very specific business logic•Uses services from lower levels

INFRASTRUCTURE FRAMEWORK SERVICES•Generalized, shareable technology•Programmable, no native business logic•Some relevance to developers

BUSINESS FRAMEWORK SERVICES•Shared across multiple business processes•Broad business logic•Highly relevant to developers

INFRASTRUCTURE FOUNDATION SERVICES•Highly standardized technology•Broadly shareable, no business logic•Not very relevant to developers

Example:Accounts Receivable

Example:Business Process Mgmt

Example:Security

Example:Enterprise Service BUS

Service Classifications

High

Low

Rel

evan

ce to

Dev

elop

ers


BUSINESS APPLICATION SERVICES (Common Apps)

INFRASTRUCTURE FRAMEWORK SERVICES

BUSINESS FRAMEWORK SERVICES

INFRASTRUCTURE FOUNDATION SERVICES

•Accts. Receivable•Accts. Payable•Inspections•Permits & Licensing

•Claims Mgmt•Pension Mgmt•Provider Bill Processing•Customer Relationships

•Finance & Budget•Purchasing & Assets•Safety Mgmt•HR

•In-Correspondence•Out-Correspondence•Info Delivery

•Work Flow/BPM (app)•Business Rules (app)•Entity Mgmt (app)

•Personalization (portal)•Content Mgmt (portal)•Payment Processing

•Web Facing (portal)•Portal Servers•App Servers (.NET)

•Work Flow/BPM (engine)•Business Rules (engine)•Shared Security

•Entity Mgmt (engine)•Active Metadata•Message Routing

•Service Bus•XML Cache•Data Exchange

•Directory services•Networks•Load balancing

•Storage•Computing Platforms•Databases

GREEN = available ORANGE = being built BLACK = not funded

L&I Services Classified


1.Service Bus

2.Security

3.Web Facing (Portal)

4.XML Cache

5.Work Flow/BPM

6.Inbound Correspondence

7.Outbound Correspondence

8.Data Exchange

9.Entity Management

10.Business Rules

11.Information Delivery (NxGen Data Warehouse / reporting)

12.Active Metadata Repository

L&I’s Core Shared Services


2001 2002 2003 2004 2005 2006 2007 2008 2009

•Out-Correspondence

•In-Correspondence

•Security (External)

•XML Cache (pilot)

•Message Bus•Work Flow - BPM

•Web Facing Portal

•Security (Internal)

•XML Cache

•Data Exchange (limited)

Enhancements:•Service Bus•Web Facing•Work Flow•Correspondence•Data Exchange

Future:•Business Rules•Entity Mgmt•Metadata Rep•Info Delivery

Enhancements:•Out-Correspondence•Enterprise Service Bus

Shared Services Schedule


SOA principles can be difficult for some – success depends on skilled architects, designers, policies and process - SOA GOVERNANCE A new Web services tool does not equate to SOA. Requires

a different mind-set and the guidance to go with it.

Service development and architecture planning must be done in parallel

Don’t let time, skill and cost issues lead to another generation of stovepipes being built – INVESTMENT GOVERNANCE Very easy to let project schedules, budgets and “legacy skill sets”

derail SOA efforts.

SOA Lessons Learned


SOA is a long-term endeavor that involves all the usual hard business decisions, e.g. data, process ownership – ENTERPRISE GOVERNANCE

ROI is not inherent in SOA – The goal must be productivity and agility not technology

IT organization may need to change to support shared services and applications – bust the stovepipes

Developers may need to “specialize” (eg. Interface, business rules, data access) rather than try to be jack-of-all-trades

SOA Lessons Learned


Not a “quick fix” or “silver bullet”. SOA requires serious, long-term commitment by both business and IT; may involve upfront costs, shared costs, and many other challenges

Top-down or Bottom-up? Best approach is to alternate between the two. Infrastructure services are required early, but must also demonstrate value to business as soon as possible.

Web services are state-of-the-art but immature No specific technologies are ruled in or out Legacy implementations are possible EAI implementations are common, eg. XML over MQ Series

SOA Lessons Learned


DIS migration from Fortress to Secure Access Washington (SAW) Added SAW as trusted authority to Shared Security

Service and all service-aware apps instantly migrated

Non service-aware apps – took the opportunity to move them to Shared Security Service. Avoided refactoring each one for SAW and “retired” redundant code

Conveyance Inspection app Building UI from “portlets” that can be reused for other

inspection applications hosted by Web Facing Service

As more “portlets” are built, UI development time will be greatly reduced

Recent Example of SOA Payback


The ability to change IT quickly to fit business needs. Applications are smaller, faster to build,

easier to change and maintain

What’s the Catch?• SOA is not easy or cheap• Must invest in building reusable Services• Requires major commitment from IT and

business

What’s the bottom line?

A G I L I T Y

SOA – Bottom Line


Documents

State of Washington Department of Labor & Industries L&I’s Journey to a Service-Oriented IT Architecture