APIs are not SOA++
•Download as PPTX, PDF•
2 likes•1,296 views
APIs are not SOA++: APIs vs. SOA vs. Integration More than an incremental change to business, the use of APIs in the digital economy represents a major paradigm shift that requires harnessing all the Internet innovations of the last 10 years. Learn about an approach designed from the ground up for digital business and what’s required to achieve success.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to APIs are not SOA++
Similar to APIs are not SOA++ (20)
More from Apigee | Google Cloud
More from Apigee | Google Cloud (20)
Recently uploaded
Recently uploaded (20)
APIs are not SOA++
- 1. APIs are not SOA++ A panel hosted by Ed Anuff & Brian Pagano
- 2. Your Hosts 2 Ed Anuff @edanuff Brian Pagano @brianpagano
- 3. What we’ve said before • Separate SOA as an architecture from specific products • SOA is good practice
- 4. Classic Differences • Self-service & lightweight governance • External, fine-grained security (OAuth) • Pace-layering
- 6. API Consumption vs. Exposure 6 App Consumption API Exposure • API adaptations needed for apps • Enable developers for business • Security for app-to-API • APIs architected for abstraction • Enable developers for API use • Security for API-to-backend API API App App Server Services
- 7. The “A” in API is for Apps Rich Clients (Visual Basic, Delphi, etc.) Web Applications (App Servers) Rich Clients (Mobile Apps, Devices)
- 9. Thank you
Editor's Notes
- D: We’ve done previous webinars on this topic E: Yes, Brian Pagano did two very good ones D: So what’s different? E: We’ve always been positive on SOA, but we’ve also always maintained APIs are different
- E: When API’s first appeared in enterprise architecture there were a few key differences E: Governance E: Also, the security model is arguably different D: The concept of pace-layering is critical to this discussion. 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. 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.
- E: It really all comes down to apps E: The A in API is application E: Now, you might argue that’s a vestigial remnant from the annals of programming terminology E: But it’s a useful distinction, and it helps understand why APIs and SOA have some overlap E: We had rich clients, basically the days of client/server, then with web apps, we repartitioned the architecture and a lot of random stuff got thrown into the app server E: Now we’re in the mobile age, which is the return, the revenge of client/server