The document discusses Service Oriented Architecture (SOA) as a best practice for building distributed systems that utilize open formats and well-defined interactions, which enhances enterprise architecture by enabling scalability, flexibility, and the integration of old and new technologies. It highlights case studies from Amazon and a bond trading house, illustrating how SOA allows for improved agility, reduces downtime, and increases development efficiency. Key challenges and opportunities for SOA are also identified, including complexity, performance, security, and the potential for faster time to market.

1. SOA: What it means to the Enterprise
Paul Fremantle
paul@wso2.com
CTO and Co-Founder, WSO2
VP, Apache Synapse

2. Service Oriented Architecture
• SOA is the best practice for building distributed
interconnected systems
– Using well-defined interactions between systems
– Moving from proprietary formats to open formats:
• XML, HTTP, SOAP
– Integration is dependent on external interfaces not on
internal code
• SOA is the basis of all modern Enterprise Architecture

3. Stovepipes

4. The Enterprise Architecture landscape
has changed
• Development cycles:
– From 18 to 6 months to 3 months
• Real standards
– HTTP, HTML, XML, Java
• Supply chain management and integration are key
– Companies without integration are falling behind

5. Tightly Coupled Systems
• Tightly coupled systems have significant problems:
– Errors, delays and downtime spread through the system
– The resilience of the whole system is based on the weakest
part
– Cost of upgrading or migrating spreads
– Hard to evaluate the useful parts from the dead weight

6. Loose Coupling

7. Loose Coupling
• Location and Access
– Scale up, failover, contingency
• Programming Language
– Work with available skills
– Integrate old and new
• Stack/Vendor
– No tie in to a particular proprietary solution
• Time
– Asynchronous interactions avoid gridlock

8. Services
• Services are application assets that provide useful
function
• The service is not just the software… it is the running
system
• Services are accessible in a common way across the
network and organisation
• Services are re-usable building blocks that can be re-
used to build other applications

9. Case Study - Amazon
• Amazon initially built a standard web application
• Browser tier / Web tier / Database tier
Web App
Web App Database
Web App
Single application

10. It was too successful
Web App
Web App
Web App
Web App
Web App
Web App
Web App
Web App
Web App Database
Web App
Web App
Web App
Web App
Web App
Web App
Single application

11. Problems
• Too many complex pieces of software in a single
system
• No evolution possible
• Need to scale independently
– Parts sharing resources with other unknown code paths
• No isolation
• No clear ownership of components
• The database became a choke point
– Both at runtime – constant involvement from Oracle scaling
– And at development time as different teams struggled to
implement change control on a shared resource

12. The solution: SOA
• Before the term SOA was widely used
• Split into separate teams
– Each team owned the complete problem:
• Hosting, maintenance, scaling, development, design
– Each system was loosely coupled with consistent interfaces
• A single visit to the homepage can call between 10 and
100 services
• And by the way, this architecture led directly to
Amazon’s cloud model

13. Organization
• “Each service has a team associated with it, and that team is
completely responsible for the service—from scoping out the
functionality, to architecting it, to building it, and operating it…
You build it, you run it” Werner Vogels, CTO, Amazon
– Promotes Customer Focus and Innovation
– Gives developers direct access to customers
– And experience of how their code performs

14. Lessons learnt
• Isolation
– Service Orientation promotes ownership and control
• Scalability
– By preventing direct database access, can scale the
services without affecting clients
• Need a common service-access mechanism
– Aggregation
– Routing
– Tracking

15. Another case study
• Chapdelaine is a leading bond trading house in Wall Street
• Had a monolithic application built mainly using thick client
technology together with Database (stored procedures)
• New regulatory rules required reporting trades within 5
minutes of completion
– Daily batch no longer suitable
• Increasing partnership meant connecting to partners is
essential
• Put in place an ESB and SOA approach
– Two weeks to build an initial working environment
– Saved $250k in year one with a $50k project
• Radically more agile development environment and enterprise
architecture is enabling faster moving IT to meet business
needs.

16. SOA – Enterprise Expectations

17. Challenges and Opportunities
for SOA
Challenges
• Complexity
• Performance of distributed applications
• Security
• Management, problem determination
• Free-for-all vs Governance
• Standards and best practises
Opportunities
• Process management
• Faster time to market, Agility, time to value
• Business intelligence and activity monitoring
• Rules and Event Processing
• Cloud readiness

18. Questions