Transition from SOA to APIs for the App Economy - Bending the Spoon


Published on

Does your business need to deploy functionality to mobile devices? To multiple channels simultaneously? At a faster pace than ever before? You have a solid SOA but it's just not flexible enough to fulfill the requirements of today's projects. You need a path to evolve your SOA.

Join Brian Pagano and David Andrzejek to discuss the imperative for APIs. Walk away an approach to extend SOA with APIs to meet the demands of business in the growing app economy.

We'll Cover:
- Complex, stateful transactions and other things SOA is good at
- Agility, scalability, transformations, and other things APIs are good at
- Expose functionality not services & use APIs to be relevant and successful in the app economy

Published in: Technology
1 Comment
1 Like
  • <br /><iframe width="350" height="288" src="" frameborder="0"></iframe>
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Creative Commons Attribution-Share Alike 3.0 United States License
  • New requirements include: mobile, delivering onto multiple platforms simultaneously, and faster iterations.
  • Expose functionality not systemsAPIs to leverage existing assetsAPI for business intelligenceAPIs for innovation/agility/dev adoption
  • Transition from SOA to APIs for the App Economy - Bending the Spoon

    1. 1. Bending the SpoonTransition from SOA to APIs for the App EconomyBrian Pagano@brianpaganoDavid Andrzejek Apigee@davidandrz @apigee
    2. 2.
    3. 3.
    4. 4.
    5. 5. @brianpagano @davidandrzBrian Pagano David Andrzejek
    6. 6. OverviewSOA adventures in API-landSOA - does it mean what you think it means?All the checkboxesTransactions – working hand-in-handMaking the world awesome - one API at a time
    7. 7. SOA Adventures inAPI-Land
    8. 8. A man is sitting at a table, staring at a spoon
    9. 9. He seems to be doing nothing, but his forehead startsto sweat
    10. 10. The man is trying to bend the spoon
    11. 11. Two problems . . .You can’t bend a spoon using only your mind
    12. 12. Bending the spoon manually weakens the structure andmangles the spoon
    13. 13. Why are we talking about spoons?The “spoon” is the company’s SOA-based architectureIt made sense at the time. And it still makes sense forsome functionsBut rapidly evolving businesses have new requirements
    14. 14. The Architect has two choicesBend the spoon and hope it doesn’t breakBend the world around the spoon
    15. 15. Let’s talk about bending the world
    16. 16. SOA: Advanced Patterns
    17. 17. SOA recapLet’s make sure we’re all talking about the same thingLet’s only talk about the core principles of SOA - not thecruft that vendors have addedSome product features have started to be thought of asnecessary for SOA
    18. 18. SOA is Service Oriented ArchitectureServices are goodTapping into the deeper philosophy of breaking downproblems into componentsComponents are good
    19. 19. SOA might include, but does not require Heavyweight contracts Service registries Dynamic discoveryThese are product “features”
    20. 20. Core SOA Functionality Business Problem Core SOA Principle Consistent look and feel for customers Reusable software components (services) across lines of business Cross selling between lines of business *Reusable services Auditing and compliance Guaranteed asynchronous message delivery helps for non-repudiation The ability to perform complicated, Message Bus + stateful services multi-step transactions Agility *Reusable services * Not completely satisfied using SOA alone
    21. 21. So far, so good
    22. 22. The architect is being asked to deploy functionality tomobile devicesWorse, the business wants to deploy to multiplechannels simultaneouslyAnd timelines are getting crunched to accommodatepartners, conferences, and events
    23. 23. Should we try to bend the spoon?
    24. 24. Patterns have emerged* to try to solve these new requirementsusing existing SOA tools. They work up to a point.The problem is that bolting on active listener functionality toservices or forcing them to implement elaborate configurationframeworks or become temporal event handlers seems contraryto having coarse grained service that are experts for a specificproblem.*SOA Patterns by Arnon Rotem-Gal-Oz for some examples
    25. 25. What’s worse is that some folks have lost sight of theneed to expose functionality not systemsNobody wins through exposing complexity
    26. 26. Nobody benefits from mangled spoons** Except maybe spoon manufacturers
    27. 27. All The Checkboxes
    28. 28.  Agility Security Performance Data Mobile visibility Modern application functionality
    29. 29. These are requirements of today’s projectsWe don’t have time to go into each of these todayBut . . .
    30. 30. The architect should think deeply about thecheckbox items when designing the path from pointA to point B
    31. 31. You may have some of the necessary pieces . . .but that is not sufficient
    32. 32. Modern apps need more than forklifting existingsystems* and their complexities*This is known at the “forklift anti-pattern”.
    33. 33. It’s time to move the world around the spoon
    34. 34. Let’s look at using APIs to extend SOA into this newworld
    35. 35. Transactions:Working Hand In Hand
    36. 36. What is SOA good at?Decoupling producers and consumersComplex transactions
    37. 37. What are APIs good at?Agile layer (changes are fast)Highly consumableOmnichannelLightweightHighly scalable
    38. 38. Sometimes APIs and SOA work beautifully together
    39. 39. For exampleComplex or stateful transactions:Let the API layer handle exposure, transformation,security, caching, and scalingThen pass the request to the SOA/integration layer
    40. 40. Making the World AwesomeOne API at a Time
    41. 41. Getting from Point A . . .Moving forward means satisfying the checkboxes(agility, scalability, …) without creating disruptionThis often means changing our thinking from exposingservices to exposing functionality
    42. 42. . . . to Point BAnd moving from the minimum necessary to getsomething exposed (avoiding the forklift anti-pattern)toproviding everything that will be sufficient to bring ourbusinesses into the app economy
    43. 43. . . . and beyondanalytics to give us visibility into behavior on mobiledevicesproviding the modern app functionality which is oftenabsent in our existing systems (location, notifications, ...)
    44. 44. In SummaryTo meet changing business demands: Expose functionality not systems Use APIs to leverage & extend existing SOA assets Use APIs for analytics – end to end visibility into your business from the backend to mobile apps Use APIs for innovation - modern app functionality
    45. 45. Future deep divesSecurityBig Data vs. Fast DataPerformanceMobile and Modern App Functionality
    46. 46. Questions
    47. 47.
    48. 48. THANK YOUQuestions and ideas