Services-Oriented Architecture

Services-Oriented Architecture
How IST is joining the migration to a new way of
organizing software and why…
A discussion with IST architects
June 5, 2007
A statistical introduction
(with thanks to Karen Eft)
Goals for this talk
• Improve shared understanding of what’s meant by
Services-Oriented Architecture and “SOA”
• Share some enthusiasm for its potential
– To improve the reach and value of our solutions
– To increase satisfaction and reduce drudgery in IT
– To transform the way work is done
• Talk about the roadmap for SOA uptake
– Enablers
– Challenges
• Describe some early impact of SOA on the work of IST
and Data Services
• Discuss what architects are doing to enable SOA uptake
• Enlist interest, discussion, good ideas and participation
What is SOA?
1. Software architecture (what we’ll discuss).
•
An approach to delivering information to support real-world
activity in which the basic element is a “service”.
•
•
•
•
•
An abstract unit of functionality, defined in terms of capabilities, not
in terms of computing components (applications, programs, files,
tables, etc…)
Service is delivered when requested by a message.
Implementations of services are invisible to users of the service
and change independently.
“Service” capabilities are data or behavior or both.
Services work together as needed to deliver larger capabilities
(systems). I.e., they communicate
2. Also, business architecture.
•
•
Enterprises organize their resources in order to deliver
services which correspond to external needs.
Capability to deliver a given service may entail aggregating
other services from within or outside the enterprise.
Some pictures to illustrate
Service is an abstract
set of capabilities
Capabilities defined explicitly.
-what the service does
-what messages it understands
To deliver its capabilities, a service often
makes use of other services
Key elements are interfaces and messages
Source: Gartner
Payoffs from this loosely coupled model:
flexibility, reuse, business alignment
Source: Gartner
Solutions can combine services from inside and outside. Services can come
from anywhere.
Services can be reused as new ways of
doing business evolve
Source: Gartner
Services allow richer workflows, increasing the power of
systems support which can be delivered to individual
people and growing the scope of their jobs
Source: Gartner
Is SOA the same thing as “Web Services”?
• Properly designed and delivered, web services are contributing
elements in a services-oriented architecture
• Web services are software services invoked through web
technology, usually HTTP
• Not all services are web services
Other kinds of transport work: ESB, JMS, etc
Source: Gartner
Why Service-Oriented Architecture? Business
Drivers Prevail Over IT Drivers






M & A/Divestitures
Multichannel sales/support
Time-to-market
Continuous innovation
Process flexibility
Process visibility
"Top-Down" Enterprise
Drivers
"Perennial" IT Challenges
"Doing more with less"
 Business/IT alignment
 Data consistency/quality
 Time-to-deployment

SOA




Call center integration
Single face to clients,
suppliers, employees
Process Integration
Real-time B2B
"Bottom Up" Business Unit
Drivers
Source: Gartner
Beyond the SOA Hype: What's for
Real?
Benefits
Implications
Architectural Partitioning
Higher Upfront Costs
•
•
•
•
•
•
•
•
•
•
•
Diverse life cycle "speeds"
Synergy of different technologies
Optimal tech skills allocation
Processes visibility
Greater maintainability
Easier outsourcing/offshoring
Incremental Deployment
• Gradual migration
• Cost "spreading" across projects
• Reduced maintenance cost
Sharing (Reuse) of Services:
• Faster time to deployment
• Lower development cost
• Greater adaptability
Common "Language" Between
Business and IT
Cultural change
Infrastructure (SOA backplane)
More formal methodology
Longer design time for services
Testing (unit/end-to-end)
More Distributed Infrastructure
•
•
•
•
•
•
Extensive use of middleware
Transaction management
Debugging/troubleshooting
End-to-end management
More granular security
Metering/logging
Tighter Management/Governance
• Ownership/accountability
• Cost allocation
• Prioritization/conflict resolution
Source: Gartner
Challenges
• Services are developed and used across
organizational boundaries.
• Performance
• Management
– What happens if
• Security
• Change/versioning
• Quality of service; cross-service dependencies
Migrating to SOA is a multi-stage transition
• Learn to develop good services
• “Service-enable” existing software
• Develop the needed processes
– Governance
– Service level management
• Grow skills
– Business analysis
– Technical design
• Acquire middleware backbone
SOA-Enabling Established Applications
Wrapping
Re-engineering
Use of screen-scraping to
package "pseudo-services"
Business logic is modularized
and separated from presentation
Business logic of services is
redesigned from scratch or
replaces with packages.
Data Model
Data Model
Data Model
Mixed
Business Logic
and Presentation
Logic
Business Logic
Business Logic
Wrapper
Wrapper
Interface
Interface
Presentation Orchestration Orchestration
Logic
Interface
Interface
Pros:
Noninvasiveness
 Low cost/Fast

Suboptimal granularity
 Hard to maintain
Orchestration Orchestration
Interface
Pros:
Easier to maintain
 Better performance/scalability

Cons:

Introduction
Replacement
Pros:
Optimal granularity/reuse
 Enables technology change

Cons:
Invasive/high cost
 Granularity might be suboptimal

Interface
Cons:
Risk is higher
 High cost

Source: Gartner
Service-Oriented Enterprise Runs On Application
Platform Suites
Old: Monolithic
Application "Stovepipes"
New: Service-oriented
"Bazaar"
Userfacing
software
Composite
services
Process
services
Data
services
Application Server
Business
data
Monolithic Application
Enterprise
Service-oriented
Application Enterprise
Source: Gartner
How Do You Enforce Sharing of
Services?
"Good" SOA
"Bad" SOA
Services
Services
Services
Services
Metrics
 # Services/# Consumers >>20
 # of reused services <10%
Potential Issues:
 Too-fine services granularity
 Duplicated services
 Over-specified SOA
S
R
e
e
w
rr
vi
vi
a
c
cer
e
d"
Exploitation
SOA Governance
• The organizational and technical support
infrastructures needed to maximize the
likelihood of SOA success
• Provides answers to questions like:
– Who owns web services?
– What policies govern service publication and
consumption?
– How do we encourage service discovery, reusability,
security?
– Who manages and monitors production services?
SOA Governance (continued)
• Organizational support infrastructure
– SOA center of excellence or equivalent
• Technical support infrastructure
–
–
–
–
Registry/repository
Policy management
Quality assurance and validation
Service monitoring
Early steps at IST
• IST architecture group SOA initiatives
• ASD web service experience (COA validation)
• Shared services design for Berkeley Natural
History Museums
• Involvement in Kuali community-source student
systems project
IST architecture group
• Represents architecture groups from across IST and
CIO
• Self-led team
• Meets regularly
• Early decision that SOA adoption was key priority.
• So far: look at service styles (SOAP/REST), security
mechanisms
• First deliverable: a proposed service registry
– Goals: increase visibility of services
– Develop initial governance and design skills
A First Service Registry for UCB
• Simple, high-level, human-oriented/readable
• Facilitate discovery, reduce service-duplication, and
encourage best practices in the near-term.
• Initiate movement toward recognizing a need for and
exploring modes of SOA governance for the campus.
• Sharpen ability to perform and evaluate service design.
• Encourage campus community-building around shared
services with an "Amazon reviews" style response/reviews
component.
Where to go to learn more
• Leading web sites
– IBM Developer Works
– BEA: Dev2Dev and Arch2Arch
– Oracle, Microsoft, Gartner
• Good example: Amazon.com
– Probably the world’s biggest SOA
– Built to include outsiders as full participants
• Web services sold as products
• Very good developer web site
• Many good articles and books
e.g., Pat Helland, “Data on the inside”