some SOA practitioners claim


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

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)
  • some SOA practitioners claim

    1. 1. Quarterly Technology Briefing
    2. 2. Guerrilla SOA How to fight back when a vendor tries to take control of your enterprise Dr. Jim Webber [email_address]
    3. 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. 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. 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. 6. Today’s Enterprise Architecture
    7. 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. 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> </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. 9. Integration Two Years Later Enterprise Service Bus
    10. 10. Skeletons in the Closet... Enterprise Service Bus
    11. 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. 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. 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. 14. Integration five years from now Enterprise Service Bus
    15. 15. Integration ten years from now ESB
    16. 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. 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. 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. 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. 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. 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. 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. 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. 24. “WS-Fabric” SOAP messaging is the communication channel for applications. The ESB (if it exists) is pushed to the endpoints.
    25. 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. 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. 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. 28. Questions? <ul><li> </li></ul>
    29. 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. 30. Brisbane | Melbourne | Sydney