Service-Oriented Architecture: UW`s Migration Strategy

Service Oriented Architecture:
UW’s Migration Strategy
a.k.a.
What is it and how do we get one?
Jim Phelps
Sr. I.T. Architect, DoIT, UW-Madison
[email protected]
http://arch.doit.wisc.edu/jim
1
What I’ll Cover
•
•
•
•
•
•
•
Data vs. Service
Three Tiers (slides included FREE!)
Migration Strategy
Sticky Bits
Roadmap
Next Steps (2 years)
Summary
2
Integration is..
• Complex:
• Brittle:
When systems change, interfaces need to be rebuilt
When interfaces fail, people are unhappy (and often blame the wrong
people)
• Expensive:
Garther - “up to 50% of large enterprise’s IT budget is spent on
interfaces and integration”(1)
3
A Simple Use Case
eReserves:
•
•
Library has books on reserve for a course.
The Library checks those books out only to
students in the course.
4
Data vs. Service
Data
SIS
Library
Course
Roster
Course
Roster
5
Data vs. Service
Data
SIS
Library
Cours
e
Roster
Cours
e
Roster
Service
SIS
IsEnrolle
d
Service
Library
StudentID,
CourseID
Yes/
No
6
Reusability
Service
SIS
IsEnrolle
d
Service
StudentID,
CourseID
Yes/
No
Libra
ry
7
Reusability
Service
SIS
IsEnrolle
d
Service
StudentID,
CourseID
Yes/
No
LibraPoint
of Sales
rySystem
8
Reusability
Service
SIS
IsEnrolle
d
Service
StudentID,
StudentID
CourseID
Yes/
No
CourseID
LibraPoint
of Sales
Portal
rySystem
9
Data
Service
Replication of all data
Pull as needed
Opaque
Transparent
Disconnected
Connected
Point-to-Point
One-to-Many Reusable
Brittle
Robust
Composite Apps
10
Data vs. Service
• Fundamental shift away from shipping data to
providing services
11
Data vs. Service
• Move to SOA to:
– Reduce cost
– Increase security
– Reduce data duplication
– Gain transparency
– Reusability
12
Migration Strategy - SOA
Process - business process analysis
Information - data definitions and standard
schemas
Infrastructure - architecture and technical gaps
Vendors - helping hands
Organization - Change Management
21
Migration Strategy - SOA
• Process - Business Process Analysis
– Prioritization - Most Pain, Most Gain
– Define/Document Business Process
– Look for optimization opportunities
– Use disruption to your advantage
– Data needs (timeliness, availability, etc)
22
Migration Strategy - SOA
• Information - Enterprise Data Definitions
– Let the Business Process Analysis drive the data
definition process
– Don’t build a complete dictionary
– Start with the most needed definitions
– Build on existing standards
23
Migration Strategy - SOA
• Infrastructure - Architecture and Technology
– Gap analysis - what pieces are missing
– Do we have the right architecture in place?
– Business Process Analysis and Data needs drive
the effort.
24
Migration Strategy - SOA
• Vendor - Evaluation to fill the gaps
– Business Process Analysis
– Enterprise Data Identification
– Data Definitions / Standards Development
– Service Design
– Technology Gaps
25
Migration Strategy - SOA
• Organization - Change Management
– Culture shift from data to services
– Staff training and support
– New Expertise
• Service Interface Designer (2)
• Service Library Manager (2)
– Integration Competency Centers(3)
26
People of the ICC
•
•
•
•
•
Project Manager
Services Architect
Interface Designers
Registry / Library manager
Schema experts
27
Migration Strategy - SOA
28
Building the ICC
• Critical Success Factor
• Centrally funded not a charge-back center
• Unifying practices
• Easier to enact and deploy standards
• Manage the interface library (WS Registry a.k.a.
UDDI Registry)
29
Organizational Change
• New Skills and the ICC
• Forces for Change
• Misalignments
– Funding models
– Employee Evaluation
30
Who is the force for change?
Service
SIS
?
IsEnrolled
Service
StudentID,Co
StudentID
urseID
CourseID1
Yes/No
…
?
Library
Point
of Sales
System
?
Portal
?
31
Force 1: Architectural Purity
Statement: It is good for the Enterprise.
Model: We will all cooperate for the good of the whole.
Never works. People don’t act for the good of all when
their project / budget / timeline / comfort is at risk.
Service
SIS
IsEnrolled
Service
StudentID,Co
StudentID
urseID
Yes/No
CourseID1
…
Library
Point
of Sales
System
Portal
32
Force 2: Consumer
Statement: We want a Web service for …..
Model: The first Consumer will drive the change.
Rarely works. Need an alignment of good will between
the Consumer(s) and Service Provider.
Service
SIS
IsEnrolled
Service
StudentID,Co
StudentID
urseID
Yes/No
CourseID1
…
Library
Point
of Sales
System
Portal
33
Force 3: Service Provider
Statement: It is the new “supported” way
Model: The Service Provider will set the standard
Should work. Especially if the Service Provider can
eliminate other feeds and if they impose costs on new
feeds.
Service
SIS
IsEnrolled
Service
StudentID,Co
StudentID
urseID
Yes/No
CourseID1
…
Library
Point
of Sales
System
Portal
34
How would this work
Service Provider eliminates multiple flat-file
feeds - replaces with single Web Service.
35
How would this work
Service Provider eliminates multiple flat-file
feeds - replaces with single Web Service.
Consumer can:
• Use Web Service
– Agree to SLA
– ICC establish
Security and Policy
– Register use in the
WS Registry
36
How would this work
Service Provider eliminates multiple flat-file
feeds - replaces with single Web Service.
Consumer can:
• Use Web Service
– Agree to SLA
– ICC would
establish Security
and Policy
– Register use in the
WS Registry
• Request a Flat File
– Go through review
– Pay to build & maintain feed
forever
– Pay for whole cost of feed
– Agree to policy re:use,
security, privacy etc.
37
Force 3: Service Provider
Agree Or Pay
Service
SIS
IsEnrolled
Service
StudentID,Co
StudentID
urseID
CourseID1
Yes/No
…
$$$
Library
Point
of Sales
System
Portal
38
Organizational Change
• New Skills and the ICC
• Forces for Change
• Misalignments
– Funding models
– Employee Evaluation
39
Misalignment
• How we fund projects
• How do we measure our employees
40
Misalignment
• How we fund projects
– DATA - “please build an app for me”
– SERVICE - “we need these reusable services”
– Looks a lot like “Overhead”
41
Misalignment
• How we fund projects
– DATA - “please build an app for me”
– SERVICE - “we need these reusable services”
– Looks a lot like “Overhead”
• How do we measure our employees
– DATA - “I built these apps for these customers”
– SERVICE - “I made these reusable services”
– Hard to measure “value”
42
Organizational Change
• New Skills and the ICC
• Forces for Change
• Misalignments
– Funding models
– Employee Evaluation
43
Other Sticky Bits
• Standards
• Policy & Security
• Governance
44
Security/Policy Enforcement
• Two models
– Embedded (written into the interfaces)
– In-line (proxy)
Service
SIS
StudentID, CourseID
IsEnrolled
Service
Embedded
In
Line
Library
Yes/No
45
Phylogeny and Standards
46
Phylogeny and Standards
WS-Security
WS-Policy
WSDL SOAP XML
http://genetics.nbii.gov/systematics.html
47
Security/Policy Enforcement
• Two models
– Embedded (written into the interfaces)
– In-line (proxy)
Service
SIS
StudentID, CourseID
IsEnrolled
Service
Embedded
In
Line
Library
Yes/No
48
Governance - Complex and Difficult Mix
When you hear the words: Funding,
Policy, Security and Architecture in the
same talk, you know that Governance
can’t be far behind.
49
Governance - Complex and Difficult Mix
50
Identity Management framework
Identity Management
Leadership Group
Authentication
Authorization
Coordinating
Team
Access
To
Data
Registrar & H.R. co-chair
Members include:
Business Leaders
Technical Leaders
ID Card
Evaluation
Technical
Assessment and
Policy
Recommendations
51
SOA Management framework
SOA
Leadership Group
Integration
Competency
Center
52
Roadmap to SOA
UW System Highway
Business Application Highway
Campus Highway
53
Roadmap to SOA - 1000’ view
UW System Highway
• Integration Competency Center (ICC)
• Registry
• Establish Governance
• Development Standards
• Common Tools
54
Roadmap to SOA - 1000’ view
Business Application Highway
• Analysis of Interfaces
• Analysis of the Business Processes
• Reduce the number of Interfaces
• Apply standard data definitions (schemas)
• Migration to Services
55
Roadmap to SOA - 1000’ view
Campus Highway
• ICC or ICC Partners
• Establishment of Governance
• Analysis of Business Processes
• Reduction of Interfaces
• Migration to Services
56
Next 2 Years
• Analysis of Interfaces
– Document the interface and business process
– Starting with “Course Roster”
• Look to refactor interfaces
• Reduce the number of interfaces
• Use standards for data representation (IMS)
• Request Official University Transcripts
Electronically (ROUTE)
– Expose two interfaces as Web Services (Student
Bio-Demo and Holds/Fines)
57
Next 2 Years - D2L Interfaces
• Refactoring the Grading Interfaces
– Opportunity to make changes
– Use disruption - Look for opportunities
• Refactor the Course Roster interface
– Already using standards for data representation
(IMS)
58
Building the ICC
• Critical Success Factor
• Looking at building an ICC
• Report to a Deputy CIO
• Service Team model (includes members from
groups working on Web Services)
– Middleware
– Applications Development
– Others
59
Conclusion
• Why SOA/Web Services?
– Reduce the cost of maintaining interfaces.
– Buffer systems from changes.
– Protect data. Provide Security.
– Transparency.
– Enforcement of business rules (FERPA).
• This means Security, Governance and Policy
60
Conclusion
• ICC is critical.
– Must be seen and helpful not an extra cost and
burden to projects.
• Governance, Policy and Security are sticky
issues
• We have opportunities in front of us right now (D2L,
PS8.9, etc)
• The door has opened for SOA.
61
References
1. Enterprise Application Integration, Revere Group Presentation - June 26, 2003
2. Service-Oriented Architecture, A Field Guide to Integrating XML and Web Services,
Thomas Erl - Prentice Hall
3. Introduction to Integration Compentency Centers, Darwinmag.com http://www.darwinmag.com/read/070104/integration.html
4. Enterprise Service Bus, David A. Chappell - O’Reilly
5. VantagePoint 2005-2006 SOA Reality Check, Anne Thomas Manes, Burton Group
62
Thank you.
Questions?
SOA - UW’s Migration Strategy a.k.a. What is it and how do we get one?
Jim Phelps, Sr. I.T. Architect, DoIT, UW-Madison
EDUCAUSE MWRC06, March 2006
[email protected]
http://arch.doit.wisc.edu/jim
Copyright Jim Phelps, 2006. This work is the intellectual property of the author. Permission is granted for this material to be
shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and
notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written
permission from the author.
63