Your SlideShare is downloading. ×
0
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
some SOA practitioners claim
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

some SOA practitioners claim

176

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
176
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • SPDB story – can run an enterprise reliably on commodity software IF you plan and execute correctly.
  • HP/Arjuna realisation that WS obviated need for proprietary middleware
  • NAB/Commbank have lots of investment in all kinds of plumbing – can re-use this to support SOA (and incrementally replace if necessary)
  • Transcript

    • 1. Quarterly Technology Briefing
    • 2. Guerrilla SOA How to fight back when a vendor tries to take control of your enterprise Dr. Jim Webber [email_address] http://jim.webber.name
    • 3. Roadmap <ul><li>Enterprise Application Integration Approaches </li></ul><ul><li>Enterprise Architecture </li></ul><ul><ul><li>Today, two years later </li></ul></ul><ul><li>The Appealing Rationale for ESB... </li></ul><ul><ul><li>And a reality check </li></ul></ul><ul><li>Enterprise Architecture </li></ul><ul><ul><li>Five years later, ten years later </li></ul></ul><ul><li>Realising SOA with Web Services </li></ul><ul><li>What this means for you </li></ul><ul><li>Conclusions </li></ul><ul><li>Q&A </li></ul>
    • 4. Enterprise Application Integration Approaches <ul><li>Data integration </li></ul><ul><ul><li>Extract, transform, route, inject data </li></ul></ul><ul><li>Application level </li></ul><ul><ul><li>Re-use application APIs, or I/O mechanisms </li></ul></ul><ul><li>EAI implementation </li></ul><ul><ul><li>Queues etc </li></ul></ul><ul><li>Business domain tier </li></ul><ul><ul><li>Integration at the object level, as typified by CORBA, DCOM etc </li></ul></ul><ul><li>User interface </li></ul><ul><ul><li>Screen scraping, revamping, etc. </li></ul></ul><ul><ul><li>Last resort, when an application offers no other hooks </li></ul></ul>
    • 5. To ESB or not to ESB, that is the question <ul><li>Product vendors are keen to provide product solution for everything </li></ul><ul><ul><li>Or to supply “consultantware” solutions </li></ul></ul><ul><li>The Enterprise Service Bus is the latest incarnation of EAI technology that supports a number of useful functions: </li></ul><ul><ul><li>Transformations; adapters; choreography; reliability; security etc </li></ul></ul><ul><li>Seems like a good idea... </li></ul>
    • 6. Today’s Enterprise Architecture
    • 7. How did we get here? <ul><li>Tactical decisions </li></ul><ul><li>Time and technology pressures </li></ul><ul><li>Path of least resistance for individual applications </li></ul><ul><li>This is the thin end of the wedge, technical debt can only increase from here </li></ul><ul><li>Help! </li></ul>
    • 8. Vendor Solutions Appear <ul><li>More proprietary middleware is the answer! </li></ul><ul><ul><li>2 + 2 = 5 </li></ul></ul><ul><li>From: </li></ul><ul><li>http://www.capeclear.com/technology/index.shtml </li></ul><ul><li>Business needs to compete </li></ul><ul><ul><li>IT needs to be responsive </li></ul></ul><ul><li>SOA gives IT a business process focus </li></ul><ul><li>Web Services are the most sensible way to implement SOA </li></ul>
    • 9. Integration Two Years Later Enterprise Service Bus
    • 10. Skeletons in the Closet... Enterprise Service Bus
    • 11. The Appealing Rationale for ESB... <ul><li>Perceived single framework for all integration needs </li></ul><ul><li>Perceived simple connectivity between systems </li></ul><ul><li>Some features for security, reliable delivery, etc. </li></ul><ul><li>All you have to do is agree to lock yourself into a ESB and all this can be yours... </li></ul>
    • 12. ...And the Reality <ul><li>The mess is swept under the carpet </li></ul><ul><ul><li>The spaghetti is still there, but it’s hidden inside a vendor box </li></ul></ul><ul><li>But the spaghetti is worse with an ESB </li></ul><ul><ul><li>Mixing business rules, transformations, QoS etc with connectors </li></ul></ul><ul><li>What if I wanted to remove or replace my current ESB platform? </li></ul><ul><ul><li>Vendor lock-in of the whole network! </li></ul></ul><ul><ul><li>ESBs are proprietary, so no guarantees that the messages transmitted across the bus are actually based on any open protocol </li></ul></ul><ul><li>Held to ransom by the ESB vendor! </li></ul><ul><ul><li>Cannot easily replace one ESB with another </li></ul></ul><ul><ul><li>Can only easily integrate systems for which the ESB vendor provides specific adaptors </li></ul></ul><ul><ul><li>Or invest my money into extending their product </li></ul></ul>
    • 13. Intelligent Networks, Dumb Idea? <ul><li>Isn't this precisely what we're trying to get away from? </li></ul><ul><li>Integration should happen on the wire by default, not inside some server </li></ul><ul><li>The ESB approach eschews the dumb network, clever device notion that underpins scalable, robust systems </li></ul><ul><li>ESB vendors are the new telcos – telling us that smarts in the network is for our own good </li></ul><ul><li>But let’s see how ESBs play out over the longer term </li></ul>
    • 14. Integration five years from now Enterprise Service Bus
    • 15. Integration ten years from now ESB
    • 16. How did this happen? <ul><li>Same old story: </li></ul><ul><ul><li>Tactical decisions </li></ul></ul><ul><ul><li>Time and technology pressures </li></ul></ul><ul><ul><li>Path of least resistance for individual applications </li></ul></ul><ul><li>Centralised ownership of the ESB sometimes is an inhibitor </li></ul><ul><ul><li>Too much effort to get on the bus, technically, politically </li></ul></ul><ul><li>Individuals always mean to redress hacked integrations </li></ul><ul><ul><li>But seldom do – it’s too hard when systems are live </li></ul></ul>
    • 17. Spaghetti is a fact of life <ul><li>Businesses change </li></ul><ul><li>Processes change </li></ul><ul><li>Applications change </li></ul><ul><li>Integration changes </li></ul><ul><li>Need an enterprise computing strategy that: </li></ul><ul><ul><li>Reflects the changing structure of the business; </li></ul></ul><ul><ul><li>Is spaghetti-friendly; </li></ul></ul><ul><ul><li>Commoditised; </li></ul></ul><ul><ul><li>Robust, secure, dependable, etc. </li></ul></ul>
    • 18. Business-Led Integration <ul><li>ESBs integrate with whatever existing systems expose </li></ul><ul><ul><li>Green screen, web pages, CORBA objects, XML, etc </li></ul></ul><ul><li>Integration happens at a low level </li></ul><ul><ul><li>Mapping of bits and bytes of one variety onto bits and bytes of another format </li></ul></ul><ul><li>This makes it hard to engage business in such projects </li></ul><ul><ul><li>Without business benefit no software has value </li></ul></ul><ul><li>Integration is currently opaque to the business </li></ul><ul><li>Business must be involved in integration projects – not just initiate them </li></ul><ul><ul><li>The integration domain must use the same vocabulary as the business domain </li></ul></ul>
    • 19. Spaghetti-Oriented Architecture <ul><li>Fighting against spaghetti is usually unsuccessful </li></ul><ul><ul><li>This does not mean integration should be undertaken without diligence! </li></ul></ul><ul><li>SOA is an approach which is spaghetti-agnostic </li></ul><ul><li>Services are designed for integration with any consumer </li></ul><ul><ul><li>Integration is decentralised </li></ul></ul><ul><li>Result: </li></ul><ul><ul><li>Loosely coupled, re-usable services </li></ul></ul><ul><ul><li>Focus on business-meaningful process orchestration </li></ul></ul>
    • 20. SOA and Web Services Approach <ul><li>Applications (or subsets of applications) are identified as being service-amenable </li></ul><ul><ul><li>Or (sub) processes are identified for which there is no existing application/service </li></ul></ul><ul><li>Web Services infrastructure is layered on top of the application, exposing a SOAP interface to the rest of the network </li></ul><ul><li>Other services consume the functionality via SOAP message exchanges </li></ul><ul><li>Traditional integration infrastructure is kept within the Web Service implementation, if used at all </li></ul>
    • 21. Building the Service-Oriented Enterprise <ul><li>SOAP becomes the ubiquitous transfer mechanism across the enterprise (or Internet!) </li></ul><ul><li>In effect, SOAP messages are the “EAI backbone” </li></ul><ul><ul><li>The underlying transport protocols are arbitrary </li></ul></ul><ul><li>Applications understand SOAP messages natively </li></ul><ul><ul><li>True end to end integration, but maintains loose coupling </li></ul></ul><ul><li>In this context, existing ESB software becomes merely a toolkit for building individual Web Services </li></ul><ul><li>But integration happens at the SOAP level </li></ul><ul><ul><li>Can commoditise what’s underneath! </li></ul></ul>
    • 22. Decentralised Integration <ul><li>The QoS functionality that a Web Service requires is implemented on a per-service basis </li></ul><ul><ul><li>Not “one size fits all” </li></ul></ul><ul><li>Implement only those QoS protocols that the service currently needs </li></ul><ul><ul><li>Push the integration functionality to the edges </li></ul></ul><ul><li>SOAP + WS-Addressing becomes the “bus” </li></ul><ul><li>Incremental and autonomous </li></ul><ul><ul><li>Deliver high business-value services first! </li></ul></ul>Non-Repudiation Reliable Delivery Security Transactions
    • 23. Web Services Standards: The State of Play <ul><li>Not all of the QoS protocols are ready yet </li></ul><ul><ul><li>Generally in late stages of standardisation </li></ul></ul><ul><li>WS-Security is ready; WS-ReliableExchange (WS-RX) in standardisation; WS-AT/BA ready on Java platform; WS-AT on .Net </li></ul><ul><li>Web Services toolkits for the rest will be available in the next year or so </li></ul><ul><ul><li>IndigoWCF, BizTalk, Axis2 etc </li></ul></ul>
    • 24. “WS-Fabric” SOAP messaging is the communication channel for applications. The ESB (if it exists) is pushed to the endpoints.
    • 25. Same Old Architects <ul><li>Business people and application architects design business-centric workflows which consume services </li></ul><ul><ul><li>Re-using the functionality already deployed into the service ecosystem </li></ul></ul><ul><li>Service architects build services </li></ul><ul><ul><li>Using WS toolkits like WCF and Axis </li></ul></ul><ul><li>Enterprise architects control QoS at the SOAP level... </li></ul><ul><ul><li>Using the WS-* specs </li></ul></ul><ul><li>...and at the transport level </li></ul><ul><ul><li>Existing investments can form the underlay for SOA </li></ul></ul><ul><li>And undertake necessary governance roles </li></ul>
    • 26. ESB or SOA? <ul><li>Investing in proprietary integration systems now is investing in future legacy </li></ul><ul><li>ESB not the solution </li></ul><ul><ul><li>It’s oh-so 1990’s integration glue </li></ul></ul><ul><li>SOA is the solution </li></ul><ul><ul><li>Because it focuses on supporting business processes </li></ul></ul><ul><li>Web Services are a robust and commoditised platform for SOA delivery </li></ul>
    • 27. Conclusions <ul><li>SOA is the right integration architecture going forward </li></ul><ul><ul><li>SOA can be implemented incrementally </li></ul></ul><ul><ul><li>Drive SOA from a business perspective </li></ul></ul><ul><ul><ul><li>Most valuable processes/applications/services first </li></ul></ul></ul><ul><ul><li>Commoditisation across the board </li></ul></ul><ul><ul><ul><li>Servers, developers, networking, re-use existing software, etc </li></ul></ul></ul><ul><li>Migrating towards a successful SOA is not always easy </li></ul><ul><ul><li>Learning to build dependable SOAs can be difficult </li></ul></ul><ul><ul><li>ESBs and Wizards cannot help – you need service-savvy geeks and process-aware business people </li></ul></ul><ul><li>No centralised integration middleware needed </li></ul>
    • 28. Questions? <ul><li>http://jim.webber.name </li></ul>
    • 29. ThoughtWorks SOA Workshop <ul><li>Full day workshops </li></ul><ul><ul><li>Sydney: 8 th November </li></ul></ul><ul><ul><li>Melbourne: 9 th November </li></ul></ul><ul><li>Speakers will include: </li></ul><ul><ul><li>Richard McLaren, ThoughtWorks Global VP, Strategy </li></ul></ul><ul><ul><li>Jim Webber, ThoughtWorks SOA Practice Lead </li></ul></ul><ul><ul><li>Prof. Ian Gorton, Senior Principal Research Scientist, NICTA </li></ul></ul><ul><ul><li>Sam Higgins, Senior Analyst, Forrester Research </li></ul></ul><ul><li>Topics will include: </li></ul><ul><ul><li>SOA: A Global Perspective </li></ul></ul><ul><ul><li>Deep Dive into Implementing SOA with Web Services </li></ul></ul><ul><ul><li>Enterprise Architecture for SOA </li></ul></ul><ul><ul><li>Case Studies </li></ul></ul>
    • 30. Brisbane | Melbourne | Sydney

    ×