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
5. @brianpagano @davidandrz
Brian Pagano David Andrzejek
6. Overview
SOA adventures in API-land
SOA - does it mean what you think it means?
All the checkboxes
Transactions – working hand-in-hand
Making the world awesome - one API at a time
12. Two problems . . .
You can’t bend a spoon using only your mind
13. Bending the spoon manually weakens the structure and
mangles the spoon
14. Why are we talking about spoons?
The “spoon” is the company’s SOA-based architecture
It made sense at the time. And it still makes sense for
some functions
But rapidly evolving businesses have new requirements
15. The Architect has two choices
Bend the spoon and hope it doesn’t break
Bend the world around the spoon
19. SOA recap
Let’s make sure we’re all talking about the same thing
Let’s only talk about the core principles of SOA - not the
cruft that vendors have added
Some product features have started to be thought of as
necessary for SOA
20. SOA is Service Oriented Architecture
Services are good
Tapping into the deeper philosophy of breaking down
problems into components
Components are good
21. SOA might include, but does not require
Heavyweight contracts
Service registries
Dynamic discovery
These are product “features”
22. 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
24. The architect is being asked to deploy functionality to
mobile devices
Worse, the business wants to deploy to multiple
channels simultaneously
And timelines are getting crunched to accommodate
partners, conferences, and events
26. Patterns have emerged* to try to solve these new requirements
using existing SOA tools. They work up to a point.
The problem is that bolting on active listener functionality to
services or forcing them to implement elaborate configuration
frameworks or become temporal event handlers seems contrary
to having coarse grained service that are experts for a specific
problem.
*SOA Patterns by Arnon Rotem-Gal-Oz for some examples
27. What’s worse is that some folks have lost sight of the
need to expose functionality not systems
Nobody wins through exposing complexity
42. For example
Complex or stateful transactions:
Let the API layer handle exposure, transformation,
security, caching, and scaling
Then pass the request to the SOA/integration layer
44. Getting from Point A . . .
Moving forward means satisfying the checkboxes
(agility, scalability, …) without creating disruption
This often means changing our thinking from exposing
services to exposing functionality
45. . . . to Point B
And moving from the minimum necessary to get
something exposed (avoiding the forklift anti-pattern)
to
providing everything that will be sufficient to bring our
businesses into the app economy
46. . . . and beyond
analytics to give us visibility into behavior on mobile
devices
providing the modern app functionality which is often
absent in our existing systems (location, notifications, ...)
47. In Summary
To 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