This document discusses service oriented architecture (SOA) and the challenges and benefits of adopting an SOA approach. It provides definitions of SOA and describes how SOA works by decomposing applications into services that can be composed together. The document outlines both the business challenges and technology challenges that SOA aims to address, such as brittle applications and inconsistent user experiences. It discusses how SOA enables greater business agility and flexibility compared to traditional application development approaches.

1. Service Oriented Architecture
Enabling Interoperability and
Business Agility
Michael K. Wons
March 2009

2. State of SOA in the Enterprise
Too many competing IT blueprints (SOA, Web 2.0 Grid

2.0, EDA, Social Networking, Cloud Computing, etc) with
little real meat
IT infrastructure is complex, fragmented and brittle

Projects continue to drive IT development

IT‟s confidence is impaired by confusing vendor

messages (marketecture) and industry standards
SOA is growing in acceptance but is still undefined and

lacking collective industry experience, tools and
standards

3. The Business Challenge
App 4
App 1
App 3
App 2
Business user - “I need one place to get customer,
transactional, and internal information”
Business user - “I want to log in once and have
information be relevant to me and my customer”
CIO – “I want to build services once and expose to
customer and employees across access points
(channels) using common processes”
DDA, Financial, CRM,
External data, Partner, Data Warehouses,
Documents Websites
Trading
Transactional, Lending

4. The Technology Challenge
Brittle applications

Multiple sources of truth

Inconsistent user experiences

Heterogeneous technology platforms

Overhauling is very expensive and time consuming

Lots of single independent applications

No reusability of services – build same thing many times

Over capacity due to siloed implementations

Business processes are inconsistent from channel to

channel

5. Context
The road to service-oriented architecture

Dream of faster, cheaper, easier integration

Web Services makes service orientation practical

Industry interoperability

Vendor and Partners role

Industry catalyst – services enable at the core of all products

Broad products and tools support

Developer ecosystem and skills

Results

Faster, easier, cheaper integration

Agility, Time-to-value

Successful customers “snowball”


6. SOA, Business Process Management
and Multi-Channel Integration shift
the way we think
Traditional Applications Service-Oriented Architecture
Designed to last Designed to change
Loosely coupled, agile and
Tightly coupled
adaptive
Integrated silos Composed of services
Code-oriented Process-oriented
Interactive and iterative
Long development cycle
development
Cost centered Business centered
Fixed, limited capacity Dynamic on-demand capacity

7. Service Orientated
Architecture
The Transformation Shift

8. SOA – Defined
Service Orientated Architecture is an emerging industry

architecture that emphasizes the provision of services to
consumers via published interfaces
Service Oriented Architecture is an approach to

organizing information technology in which data, logic,
and infrastructure resources are accessed by routing
messages between network interfaces
Basic value proposition is to provide consistent, stable

interfaces in front of diverse or volatile implementations
Establish context for information exchange across

organizations
Encapsulate complexity within organizations

Enable context-sensitive information processing


9. SOA an Organizational Commitment
A service-oriented architecture is an organizational

commitment to build its application portfolio around a
service component model
The goal of an SOA is to allow business activities to be

orchestrated as components in applications targeting
both internal and extra-organizational actors, ultimately
enhancing business agility
An SOA is the product of the self-awareness developed

through the practice of enterprise architecture

10. SOA – How it works
Service Orientated Architecture:

Is based on the disaggregation of 'applications' into

set of services, which are:
Decomposed to a base set of services, which:

Encapsulate non-service oriented architectures and

technical detail, and:
Are then recursively composed into higher order

services, which:
Are orchestrated using workflow technology to

provide support for a particular business process.

11. Pressures on the Business
Key Drivers for SOA Adoption
Supplier Customer Partner
Evolving Business Objectives
Technology
Growth, profit,
and value
Changing Markets
Regulation/
Continuous Deregulation
Leadership Business
Mergers &
Transformation acquisitions
Customer
satisfaction
Compliance
Innovation
Satisfying Unpredictable Needs
Competition
Business efficiency & agility

12. SOA Design Principles
Business-level entities
and their relationships
Relationship between
to services
business entities and
Service Model
SOA/operational services
Technical Model Domain Model
Domain-specific
General architectural Service Architecture architectural services
services (e.g., discovery, (e.g., auditing of bank
SOA Services Domain Services
security, source of truth ) transactions,
confirmation of
Service Enablement
delivery)
Operational Domain
Web services managing Domain-specific Web
the domain (e.g., services (e.g., flight
application server mgmt) status, pump level,
checking account
balance service)

13. SOA – more details
SOA is not dependent specifically on web services, but

the modern implementation is driven by this industry
trend, and it will be necessary in the general case to
expose a 'canonical form' of a service that can be
consumed from any platform. This does not preclude the
simultaneous exposure of any other binding, native or
otherwise
SOA includes both event-based (asynchronous) and

request-response (synchronous) messaging paradigms,
and properly implemented is a key enabler for flexibly
implementing „real-time‟ or „right-time‟ enterprise
capabilities

14. SOA – It‟s About Business!
Business  Information  Technology

IT exists to support business

We are looking for an overarching architecture that supports

the business needs of IT
Businesses have huge existing investments in IT

These investments:

• Fill different needs,
• Are implemented on different platforms, and
• Are of different vintages
No one in their right mind believes these huge investments

will be discarded!
Businesses are evolving to be IT centric

More and more virtual businesses are emerging

Information is their key to survival…


15. Agility => SOA?
Every company aspires to be more „agile‟ these days.

IT solutions should in theory assist companies in being

agile, but in practice:
A lot of corporate data and process assets are „locked‟ in

legacy systems
The investment in and dependence on those systems

means that „rip and replace‟ is just not a sensible option
Traditional – and even current state – application building

techniques don‟t support nimble „refactoring‟ to meet new
business challenges or improved/different processes
The increasingly collaborative, partner-based working

environment is barely reflected in most IT infrastructure and
capability
…


16. Agility => SOA?
SOA – built on canonical, industry standard web services

– enables the following:
Leverage and progressive migration for existing assets

New applications to be constructed using „workflow‟

technologies – intrinsically more „rewireable‟ on demand
Increased reuse capabilities, enabling better-faster-cheaper

application development
„Real time enterprise‟ where information flows at event

time, not in batch time – enabling much more responsive
and collaborative processes to be used to manage the
business, and better decision making at a micro level
Improved visibility of business process and associated

data, enabling business intelligence and better decision
making at a macro level

17. Isn‟t This Just EAI (or EDI!)?
“Yes, but based on broader standards”
HTTP for communication

Thanks to Internet ubiquity

XML for data representation

Thanks to success of HTML

SOAP for interoperation

Thanks to experience with DCOM, Corba, …

Unprecedented industry cooperation

Thanks to entrenched platforms and legacy systems

Rapid agreement on SOA standards

Thanks to WS-I, W3C and the SOA Consortium (Oracle,

HP, Microsoft, IBM, Cisco, Sun, BEA, and others)
Rapid roll-out of SOA development tools

Thanks to long experience with OOP, modularity, …


18. The Role of Web Services
Web Services are optimized for XML transport /

messaging
Web Services is the only true cross-platform messaging

and invocation stack
Web Services is based on open standards

Web Services implementations are becoming

increasingly versatile and performant
Web Services implements a loosely coupled (late

binding), multi-protocol, multi-format, multi-semantic,
self-describing contract-based interface with very broad
industry support…

19. The Industry Is Aligning
Standards groups for technology and industry

Consortium groups for business, IT and vendor efforts

Vendors now include in core messaging and importantly

are services enabling application, products and solutions
at the core

20. Benefits of SOA
A service-oriented architecture views the businesses
operating model and the supporting technology
model as a network of services
 Services model business capabilities
Business
 Systems serve the business, not vice versa
 Inter-departmental or inter-org relationships formalized and
expressed through service interaction
 Facilitates outsourcing and focus on core competencies
 Formal interaction model facilitates simplicity, correctness,
Architecture
and implementation independence, dependency management
Development
 The communication connections can involve either simple
data passing or it could involve two or more services
coordinating some business activities or processes
 Explicit interaction points are more discoverable, operable
IT and
Operations
 Crisply isolates service capability from IT environment
 Independent deployment, versioning, management, topology

21. For many, SOA matters and here is
what folks are saying “The challenges
in moving to SOA…”
From a technical perspective

we think we understand what SOA is from a technical perspective

we talk a lot about it amongst ourselves and with suppliers

we have started to imagine what it could mean to the business -

but we have no methods, techniques or tools to engage the
business in a structured dialog about it
From a business perspective

we are hearing a lot about it but are not sure what it means at a

business level
we cannot fund the transition to SOA as a technical project – it is

too big, we need to have real business impact and value every
step of the way
early projects should both prove the benefits of the new

architecture (technical and business) and deliver business results
we have no methods, techniques or tools to engage with the

technical organization in a structured dialog about it

22. The Business Value of SOA
• Something
distinctly new and
better TRANSFORMATIONAL
(Capability Management, SOA…)
• What is really
needed in a
marketplace
• Radically new and better
• Cut Costs
Potential ideas that do not
• Reduce Cycle
Impact EVOLUTIONARY operate within the
Time (BPR, Process Management)
existing structure of the
• Improve Quality organization or
marketplace but may, in
fact, dismantle those
structures
EFFICIENCY, QUALITY
• Radically distributed
(TQM, TOC, LEAN, CMM…)
• Industry Solutions
Scope/Disruption

23. Roadmap for SOA
Implementation

24. SOA Journey
Migration to SOA is a journey – not a “big bang”

The journey involves people and process – not just

technology
Not all journeys are the same

Addresses existing pain points and prepares for long-

term transformation
Embraces heterogeneity – leverages investments, not

“rip and replace”
Requires a collaborative approach


25. What‟s required for successful SOA?
SOA Governance
(Business and IT stakeholders)
Process Education and SOA Methodology
Business Process Management
(For process orchestration)
Business Case Analysis
Service Lifecycle
Frameworks, Tools and Templates
Manageability
Management
Security and
(For developing enterprise class modules and services)
Enterprise Service Bus / Messaging Layer
(For routing, brokering and managing service
invocations )
Infrastructure
(For hosting and provisioning services on-demand)

26. Easy Steps towards SOA
Join WS-I, W3C and SOA Consortium

Leverage web services & XML for internal application

integration
Consider replacing / extending existing B2B

infrastructure to use web services / XML based solutions
where feasible (common EAI/B2B/EDI)
Commonize business modelling efforts to build a

portfolio of business functions and data access that over
time can be implemented as services
Choose your vendor(s) carefully… ensure you have a

good roadmap from current state forward

27. Less Easy Steps to SOA
Establish enterprise architecture & associated

governance (warning: does NOT mean „one size fits all‟)
Build a „fabric‟ or „framework‟ of common services to

support loosely coupled integration (security & isolation,
routing, transformation, monitoring…)
Refactor modelling and portfolio management efforts into

enterprise-wide efforts arranged around a Business
Conceptual Enterprise Object Model

28. Less Easy Steps to SOA (continued…)
Migrate from „batch‟ to „real time enterprise‟ using event-

based, asynchronous messages as default paradigm
Build out applications as sets of services aligned around

an enterprise-class object (process/data) model
Leverage orchestration and human-orientated workflow

where feasible, evolving to be the default paradigm
„above the encapsulation boundary‟
Proactively look for simple processes to make agile,

particularly with partners

29. SOA: a Groundswell of Good Design
Applications that use an SOA have a built-in integration

model
 Incremental development of an interoperable
application portfolio
 Requires rigorous design driven by best practices
 Proof of concept prods community engagement
 Complying with emergent standards relatively
inexpensive, thanks to encapsulation
Incompleteness of requirements suggests use of agile

development methodologies
Idea implicit in global web services architecture, which

cannot be top-down

30. Closing Comments
Service-orientation enables differentiated ways of doing

business
Service-orientation allows an organization to get control

of unmanageable IT assets
Once in control, you can

• Optimize
• Orchestrate
• Open access points to processes
• Create agility
Top down or bottom up, SOA is a path to better

alignment of business and technology
SOA helps enable other key strategic IT initiatives

including cloud computing, social networking
convergence and “green” initiatives

31. Additional Information
SOA Consortium

http://www.soa-consortium.org/index.htm

Worldwide Web Consortium

http://www.w3.org/

WebServices Interoperability Organization

http://www.ws-i.org/

Winners of SOA Case Study Competition

http://www.soa-consortium.org/contest-winners.htm
