Service-Oriented Architecture:

What Next?

David Chappell
Chappell & Associates
www.davidchappell.com
Presentation Copyrighted - Based on Notes
by Brand Niemann, April 8, 2004

1
 Agenda
• Why? The Value of SOA (slides 3-7)
• Who? Using SOA Today (slide 8)
• How? Getting to SOA (slides 9-14)
• Conclusions (slide 15)
• About the Speaker (slide 16)

2
 Why?
The Value of SOA
• A Fundamental Assumption: Business
Processes Rule
• The Evolution of Application Architecture
• Enterprises Today
• Service-Oriented Enterprises: An Idealized
Picture
• Service-Oriented Enterprises: The Reality
• Why SOA Makes Sense: Technical Benefits
• Why SOA Makes Sense: Business Benefits
3
 A Fundamental Assumption:
Business Processes Rule
• Everything enterprise IT does is in the
service of some business process
• Service-oriented architecture (SOA) is
about making business processes:
– Better
– Easier to change
– Cheaper to create

4
Service-Oriented Enterprises:
The Reality

5
 Why SOA Makes Sense:
Technical Benefits
• Building business processes is faster and
cheaper:
– Existing services can more easily be reused
– Apps can expose their services in a standard
way
• Applications can be exposed more easily
to diverse clients:
– Windows clients, ASP.NET/JSP, etc.

6
 Why SOA Makes Sense:
Business Benefits
• Business people understand services
– So IT people can talk with them more easily
• Business processes become explicit
– So they can more easily be understood and
improved
• Applications or business processes might
be more easily outsourced
– Because they’re well-defined and discrete

7
 Who?
Using SOA Today
• Who Benefits Most From SOA?
• Credit Suisse (1999)
– Credit Suisse: Experience (1)
– Credit Suisse: Experience (2)
• Example: Microsoft (2001)
• Example: Reuters (2003)

8
 How?
Getting to SOA
• Some Guidelines:
– Start Somewhere
– Choosing Where to Start
– Think Services, Not Objects
• Objects and Services
– Characteristics of Services (1)
– Characteristics of Services (2)
– Choosing Which Services to Expose
– Choosing a Communication Mechanism in the .NET
World

9
 How?
Getting to SOA
• Some Guidelines (continued):
– Indigo:
• Illustrating a Class
• A Simple Example
• Accessing Methods
• Communicating With Other Applications
• Secure, Reliable, Transactional Services
– Expect Reuse to be Hard
– Expect Security to be Hard
• An Aside: The Big Bet
– Expect Organizational Issues to be Hard
10
 How?
Getting to SOA
• Some Guidelines (continued):
– Work Toward BPM
– BizTalk Server 2004 in an SOA World
– Platforms for BPM: One View
– Process Implementation: Aggregating
Services

11
 An Aside:
The Big Bet
• Has anybody ever tried to create a
complete, multi-vendor security framework
before?
– Will this work?
• Keep an eye on the progress of WS-
Security implementations
– The success of SOA may depend on this
technology

12
 Guideline:
Expect Organizational Issues to be Hard
• Better application integration requires
better human integration
– What manager wants to give up control?
• Thorny governance issues arise:
– Who’s allowed to use which services?
– How is access controlled and audited?
– Who pays for the additional use?

13
 Guideline:
Work Toward BPM
• The real goal is better business processes
– SOA is a means to this end
• Technology example: BizTalk Server 2004
– BTS 2004 connects applications through
SOAP and other technologies
– BTS 2004 provides a foundation for BPM

14
 Conclusions
• Web services make SOA practical
– We finally have agreement
• SOA will be a reality
– It can knit together a diverse world
• SOA makes BPM possible
– SOA’s benefits are fundamentally about
improving business processes

15
About the Speaker

16