State of Washington Department of Labor

1
State of WashingtonDepartment of Labor
Industries

• LIs Journey to a
• Service-OrientedIT Architecture

2
Agenda

• Background and Objectives
• Key Concepts of SOA at LI
• LIs Approach to SOA
• LIs Service Model
• LIs 12 Core Shared Services
• Lessons Learned

3
Background LIFT Project
LI 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.
4
LIFT Objectives

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
5
Key SOA Concepts
/

• 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.

6
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).

SOA Concepts and Principles not Technology
7
Key SOA Technologies

• 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.

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

• So how do we get there?

9
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

10
Bottom-UpIdentify Redundant Functions
UserInterface
LIFT analyzed Industrial Insurance Apps
Security
Entity Mgmt
Only about 30 Unique Business Logic
Reporting
Correspondence
Workflow
Business Rules Processing
Core Business Logic
11
Bottom-UpIdentify Redundant Functions
UserInterface
LIFT analyzed Industrial Insurance Apps
Security
Entity Mgmt
Only about 30 Unique Business Logic
Reporting
70 Redundant Functions Common to Most
Business Applications
Correspondence
Workflow
Business Rules Processing
Core Business Logic
12
Bottom-UpIdentify Redundant Functions
UserInterface
UserInterface
UserInterface
Security
Security
Security
Entity Mgmt
Entity Mgmt
Lots of redundant functionality to build and
maintain
Entity Mgmt
Reporting
Reporting
Multiplied times many apps
WHAT CAN WE DO?
Reporting
Correspondence
Correspondence
Correspondence
Workflow
Workflow
Business Rules Processing
Workflow
Business Rules Processing
Business Rules Processing
Core Business Logic
Core Business Logic
Core Business Logic
13
Build Functions as Services
SHARED SERVICES
UserInterface
UserInterface
UserInterface
Web Facing
Info Delivery
Business Rules
Security
Corresp.
Workflow
Entity Mgmt
Security
Security
X
Security
Entity Mgmt
Entity Mgmt
Entity Mgmt
Reporting
Reporting
Tight Coupling?
Correspondence
Correspondence
Reporting
Correspondence
Workflow
Workflow
Business Rules Processing
Workflow
Business Rules Processing
Business Rules Processing
Core Business Logic
Core Business Logic
Core Business Logic
14
Build Functions as Services
SHARED SERVICES
Web Facing
Info Delivery
Business Rules
Security
Corresp.
Workflow
Entity Mgmt
Core Business Logic
Core Business Logic
Core Business Logic
15
Build Functions as Services
LOOSE COUPLING
SHARED SERVICES
Web Facing
Info Delivery
Business Rules
Security
Corresp.
Workflow
Entity Mgmt
INTERFACE
INTERFACE
INTERFACE
INTERFACE
INTERFACE
INTERFACE
INTERFACE
XML over MQ or XML/SOAP
INTERFACE
Core Business Logic
INTERFACE
INTERFACE
Core Business Logic
Core Business Logic
16
Shared Services Overview

• Description of LIs Shared Services and how they
  all work together to deliver a more agile
  technical environment

17
Enterprise Services Model - Definitions
18
Service Classifications

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

High
ExampleAccounts Receivable

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

ExampleBusiness Process Mgmt
Relevance to Developers

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

ExampleSecurity

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

ExampleEnterprise Service BUS
Low
19
LI Services Classified
GREEN available ORANGE being built BLACK
not funded
BUSINESS APPLICATION SERVICES (Common Apps)

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

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

• Finance Budget
• Purchasing Assets
• Safety Mgmt
• HR

BUSINESS FRAMEWORK SERVICES

• In-Correspondence
• Out-Correspondence
• Info Delivery

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

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

INFRASTRUCTURE FRAMEWORK SERVICES

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

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

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

INFRASTRUCTURE FOUNDATION SERVICES

• Service Bus
• XML Cache
• Data Exchange

• Directory services
• Networks
• Load balancing

• Storage
• Computing Platforms
• Databases

20
LIs Core Shared Services

1. Service Bus
2. Security
3. Web Facing (Portal)
4. XML Cache
5. Work Flow/BPM
6. Inbound Correspondence
7. Outbound Correspondence

1. Data Exchange
2. Entity Management
3. Business Rules
4. Information Delivery (NxGen Data Warehouse /
   reporting)
5. Active Metadata Repository

21
Shared Services Schedule
2001
2002
2003
2004
2005
2006
2007
2008
2009

• Message Bus

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

• Work Flow - BPM
• Web Facing Portal
• Security (Internal)
• XML Cache
• Data Exchange (limited)

• Out-Correspondence
• In-Correspondence
• Security (External)
• XML Cache (pilot)

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

• Enhancements
• Out-Correspondence
• Enterprise Service Bus

22
SOA Lessons Learned

• 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
• Dont 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.

23
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

24
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

25
Recent Example of SOA Payback

• 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

26
SOA Bottom Line
Whats the bottom line?
A G I L I T Y
The ability to change IT quickly to fit business
needs. Applications are smaller, faster to
build, easier to change and maintain
Whats the Catch?

• SOA is not easy or cheap
• Must invest in building reusable Services
• Requires major commitment from IT and business

27
QUESTIONS?