state of washington department of labor & industries l&i’s journey to a service-oriented...
Post on 21-Dec-2015
219 views
TRANSCRIPT
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’s Journey to a Service-Oriented Architecture 3
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
L&I’s Journey to a Service-Oriented Architecture 4
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
L&I’s Journey to a Service-Oriented Architecture 5
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
/
L&I’s Journey to a Service-Oriented Architecture 6
• 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
L&I’s Journey to a Service-Oriented Architecture 7
• 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
L&I’s Journey to a Service-Oriented Architecture 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
L&I’s Journey to a Service-Oriented Architecture 10
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
L&I’s Journey to a Service-Oriented Architecture 11
UserInterface
Security
Reporting
Workflow
Business RulesProcessing
Correspondence
Entity Mgmt
Core BusinessLogic
LIFT analyzed Industrial Insurance Apps
Only about 30% Unique Business Logic 70% Redundant
Functions Common to Most Business
Applications
Bottom-UpIdentify Redundant Functions
L&I’s Journey to a Service-Oriented Architecture 12
UserInterface
Security
Reporting
WorkflowBusiness Rules
Processing
Correspondence
Entity Mgmt
Core BusinessLogic
UserInterface
Security
Reporting
WorkflowBusiness Rules
Processing
Correspondence
Entity Mgmt
Core BusinessLogic
UserInterface
Security
Reporting
Workflow
Business RulesProcessing
Correspondence
Entity Mgmt
Core BusinessLogic
Multiplied times many apps…Lots of redundant functionality
to build and maintain
Bottom-UpIdentify Redundant Functions
WHAT CAN WE DO?
L&I’s Journey to a Service-Oriented Architecture 13
UserInterface
UserInterface
UserInterface
Reporting
Business RulesProcessing
Core BusinessLogic
Security
Correspondence
Core BusinessLogic
Workflow
Entity Mgmt
Core BusinessLogic
WebFacing
InfoDelivery
BusinessRules
SecurityCorresp. WorkflowEntityMgmt
Security
Workflow
Correspondence
Entity Mgmt
Reporting
WorkflowBusiness Rules
Processing
Entity Mgmt Security
Reporting
Business RulesProcessing
Correspondence
SHARED SERVICES
INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE
Tight Coupling?X
Build Functions as Services
L&I’s Journey to a Service-Oriented Architecture 14
Message Bus (asynchronous)
Core BusinessLogic
Core BusinessLogic Core Business
Logic
WebFacing
InfoDelivery
BusinessRules
SecurityCorresp. WorkflowEntityMgmt
SHARED SERVICES
INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE
INTERFACE INTERFACE
INTERFACE
Build Functions as Services
L&I’s Journey to a Service-Oriented Architecture 15
Core BusinessLogic
Core BusinessLogic Core Business
Logic
WebFacing
InfoDelivery
BusinessRules
SecurityCorresp. WorkflowEntityMgmt
Message Bus (asynchronous)
SHARED SERVICES
XML
INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE
INTERFACE INTERFACE
INTERFACE
Build Functions as Services
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
L&I’s Journey to a Service-Oriented Architecture 17
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
L&I’s Journey to a Service-Oriented Architecture 18
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
L&I’s Journey to a Service-Oriented Architecture 19
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
L&I’s Journey to a Service-Oriented Architecture 20
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
L&I’s Journey to a Service-Oriented Architecture 21
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
L&I’s Journey to a Service-Oriented Architecture 22
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
L&I’s Journey to a Service-Oriented Architecture 23
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
L&I’s Journey to a Service-Oriented Architecture 24
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
L&I’s Journey to a Service-Oriented Architecture 25
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
L&I’s Journey to a Service-Oriented Architecture 26
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