Why APIs are not SOA++
Upcoming SlideShare
Loading in...5
×
 

Why APIs are not SOA++

on

  • 6,943 views

 

Statistics

Views

Total Views
6,943
Views on SlideShare
2,094
Embed Views
4,849

Actions

Likes
20
Downloads
207
Comments
0

20 Embeds 4,849

https://blog.apigee.com 3578
http://apigee.com 1108
http://tspace.web.att.com 52
http://feedly.com 42
http://www.newsblur.com 17
http://mktg-dev.apigee.com 16
http://www.linkedin.com 6
http://mktg-new.local 5
http://newsblur.com 5
https://feedly.com 4
http://plus.url.google.com 3
https://digg.com 3
http://blog.apigee.com 2
https://www.newsblur.com 2
https://www.google.com 1
http://gml-go-read.appspot.com 1
http://www.feedspot.com 1
http://digg.com 1
http://www.hanrss.com 1
http://apigee.launchbrigade.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • The idea behind pace-layering is that applications and the toolsets used for creating, managing and governing these apps depends on the need for business change, differentiation and innovation needs. Look at the pace of innovation of the platforms where apps are delivered to users. Innovation, differentiation, business value requires that enterprise app evolve at that pace. When it comes to backend systems stability, standardization and security are key. This essentially creates an impedance mismatch between the existing enterprise systems and the myriad of apps that consume them. <br /> The concept of pace layers as developed in a book titled, "How Buildings Learn” by Stewart Brand. He was addressing the challenge of designing a building that would have a long and useful life, be resilient to change, and be able to accommodate the needs of various owners and occupants. His technique was to identify a series of layers, ranging from the building site, which never changes, to the "stuff," such as chairs, lamps and pictures, that might move around on a daily or weekly basis. In between are layers, like the building structure, which could last 100 years; the skin or exterior surface, which might be redone every 20 years; and the services, such as plumbing; heating, ventilation and air-conditioning (HVAC) or electrical wiring, which are often replaced or updated in seven to 15 years. These architectural layers have very different paces of change, but they must be designed to work together for the building to function effectively. We believe this same idea of pace layers can be used to build a business application strategy that delivers a faster response and a better ROI, without sacrificing integration, integrity and/or governance. <br />
  • E: So, things get interesting when we add mobile into the mix <br /> D: There are two APIs <br /> E: Right, this is where we get the revenge of client/server, we have an app talking over an API to an App Server and the App Server talking via an API to the rest of your services <br /> E: For a lot of enterprises, they have hundreds of these APIs on the left that they’re completely unaware of <br /> D: This is like the proliferation of Sharepoint <br />

Why APIs are not SOA++ Why APIs are not SOA++ Presentation Transcript

  • APIs are NOT SOA++
  • @edanuff Ed Anuff Dilshad Simons
  • groups.google.com/group/api-craft
  • youtube.com/apigee
  • slideshare.com/apigee
  • community.apigee.com
  • Agenda • • • • • CC-BY-SA Recap The A in API is for Apps Top-down vs. Bottom-up Getting there from here What comes next
  • What we’ve said before Separate SOA as an architecture from specific products SOA is good practice CC-BY-SA
  • Classic Differences Self-service & lightweight governance External, fine-grained security (OAuth) Pace-layering CC-BY-SA
  • Pace Layered Building CC-BY-SA
  • This is SOA++ (sort of…) CC-BY-SA
  • The A in API is for Apps Rich Clients (Visual Basic, Delphi, etc.) Web Applications (App Servers) Rich Clients (Mobile Apps) CC-BY-SA
  • App Servers Emerged at the same time as SOA Monolithic presentation and business logic Hide deficiencies in SOA architectures CC-BY-SA
  • Client/Server/Service HTTP Browser UI CC-BY-SA App Server Page Templates Business Logic Services Customers Orders
  • Where do APIs fit in? ? HTTP API Browser UI CC-BY-SA App Server Page Templates Business Logic Services Customers Orders
  • Governance? Scope of SOA Governance HTTP API Browser UI CC-BY-SA App Server Page Templates Business Logic Services Customers Orders
  • What about Apps? Scope of SOA Governance ? API App UI Interaction Logic Business Logic CC-BY-SA API App Server Service Facades Business Logic Services Customers Orders
  • Apps Need API Tier Scope of API Governance API App UI Interaction Logic Business Logic CC-BY-SA Scope of SOA Governance API App Server Service Facades Business Logic App Server Service Facades Business Logic
  • Who builds the API Tier? API Team? App Team? SOA Team? CC-BY-SA
  • Who builds the API Tier? API Team? App Team? SOA Team? CC-BY-SA
  • Who builds the API Tier? API Team? App Team? SOA Team? All of the above CC-BY-SA
  • What does API Tier do? API exposure - loosely coupled App-specific consumption - tightly coupled CC-BY-SA
  • API Tier App Consumption API Exposure • API adaptations needed for apps • APIs architected for abstraction • Enable developers for business • Enable developers for API use • Security for app-to-API • Security for API-to-backend API App CC-BY-SA API App Server Services
  • Evolving towards API First
  • Monolithic Web App Web Apps App Server Backend Services CC-BY-SA
  • API-adapted Web Apps App Server Other Apps API Web Apps Backend Services Consumption focused CC-BY-SA
  • API-adapted SOA Web Apps Other Apps ESB API App Server Exposure focused Internal Services CC-BY-SA
  • API First All Apps Mobile Apps Web Apps Social Apps API Tier Persistence App Servers CC-BY-SA Security Orchestration ESB Analytics Backend Services
  • What comes next?
  • API Mass Customization App “A” App “B” App “C” API “A” API “B” API “C” API Tier App Servers CC-BY-SA ESB Backend Services
  • API Tier Analytics All Channels Correlations Cohorts All Interactions API Tier Conversions Segmentation A/B & Multivariate Analytics All Backends CC-BY-SA
  • API Tier with Analytics App Consumption • • • • API Exposure API adaptations needed for apps Enable developers for business Security for app-to-API App and behavior analytics • • • • APIs architected for abstraction Enable developers for API use Security for API-to-backend API Analytics Analytics API App CC-BY-SA API App Server Services
  • to summarize…
  • APIs are not SOA++ APIs are built for both exposure and app-specific usage APIs are a channel strategy as much or more so than an integration strategy Web-tier is now built against the same set of APIs as the mobile tier All interactions across mobile, web, social, and partners are observable API Tier is the last stop before mobile CC-BY-SA
  • @edanuff Ed Anuff Dilshad Simons Questions?
  • community.apigee.com
  • Resources Community: http://community.apigee.com/ Webcasts: http://apigee.com/about/api-best-practices/all/webcast eBooks: http://apigee.com/about/api-best-practices/all/ebook Institute: http://pages.apigee.com/institute.html Learn: http://community.apigee.com/learn I Love APIs: http://apigee.com/about/iloveapis-conference
  • Thank you!