SOA: What It Means To The Enterprise
0 likes537 views
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.
SOA: What It Means To The Enterprise
- 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
- 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