The Power of Internal API Programs


Published on

Download Web API eBook:
Watch the webcast:
Listen to the webcast:

Digital enterprises have developed powerful playbooks to address the needs of rapidly evolving consumer-facing API and app programs.

But can these external strategies be effective as “internal” API programs that enable apps for employees and strategic business partners? Can the range of services within an organization be managed using the same “API-first” strategies that have been successful in external programs? Which best practices should be employed?

Join Chris von See and Bala Kasiviswanathan to explore how Apigee Edge and an API-first architecture form a foundation for managing internal use cases.

- internal use cases that benefit from an “API-First” architecture
- implementing internal API programs that manage internally focused apps
- surmounting challenges that arise in the service exposure layer
- the proper hosting model for your business needs

Published in: Technology, Business
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The Power of Internal API Programs

  1. 1. April 10, 2014 The Power of Internal API Programs
  2. 2. Bala Kasiviswanathan @balak Chris von See @apigee
  3. 3. CC-BY-SA 3
  4. 4. CC-BY-SA 4
  5. 5. CC-BY-SA 5
  6. 6. CC-BY-SA The Nature of API Relationships API relationshipCuration Control Consumption Exposure Open adoption API consumers Business partners Internally-developed applications Internal-only business systems 6
  7. 7. CC-BY-SA The Nature of API Relationships API relationship “External” API program Curation Control Consumption Exposure Open adoption API consumers Business partners Internally-developed applications Internal-only business systems 7
  8. 8. CC-BY-SA The Nature of API Relationships API relationship “External” API program Curation Control Consumption Exposure “Internal” API program Open adoption API consumers Business partners Internally-developed applications Internal-only business systems 8
  9. 9. CC-BY-SA “API First” 9 • 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 APIAPI API consumption API exposure API tier ServicesApp Analytics
  10. 10. CC-BY-SA External API programs Internal API programs Comparing External and Internal API Programs • For open-adoption APIs, developer outreach/evangelism is important • Exclusively externally-accessible APIs • Developer support resources (docs, tools, etc.) all open • Security on untrusted developers is tighter • Tighter resource access controls and constraints are an integral part of the developer relationship • Monetization is often an important aspect • API capacity is usually shared • Design is often optimized for specific use cases • Normally no evangelism except internal • Combined externally and internally accessible APIs • Some developer support resources not available externally • Security constraints may be implemented differently • Resource controls may be substantially loosened, at the risk of possible (and inadvertent) over-consumption • Monetization is rarely important, but resource accounting may be • API capacity can be shared or dedicated • Design is more general in nature 10
  11. 11. CC-BY-SA Thinking “Internally” about API Consumption • Consolidate interaction channels at the API tier • Develop a strategy for leveraging things you already know in reusable ways • User interactions • Social media data • Establish mechanisms for bi-directional data sharing that don’t necessarily involve APIs • Backend-as-a-Service • State data • Re-evaluate authentication, authorization, resource allocation access scope definitions, and threat protection API Consumption API API Tier ServicesApp API API Exposure 11
  12. 12. CC-BY-SA “Internal” Consumption Case Study: Apparel 12 The challenge: • Be a social brand and control the social conversation • Enhance the customer experience by building an application that brings disparate customer data sources together to help employees personalize customer shopping experiences Apigee infrastructure Web Mobile Point of sale B2E application
  13. 13. CC-BY-SA Thinking “Internally” About API Exposure 13 • Ensure that you have visibility into the ways that services or systems interact for: • Point-to-point interactions • Operational visibility • Resource accounting • Business continuity • Auditing • Elimination of redundancy • Consistency in API contracts can facilitate consumption-layer development • Evaluate your API versioning and deprecation strategy in order to avoid “gut- wrenching” change • Build authentication into even your origin server interactions • Think about ways to share data across APIs and services API Exposure API API tier ServicesApp API API Consumption
  14. 14. CC-BY-SA “Internal” Exposure Case Study: News and Information 1414 The challenge: • Build a shared service to integrate siloed business units • Allow leveraging of services across business units without point-to-point integration • Maintain visibility into and understanding of service usage • Build a resource accounting model based on service consumption Shared Apigee infrastructure Business unit one Business unit two Business unit three
  15. 15. CC-BY-SA • There’s a need to get “out of the box” and start thinking of APIs in ways beyond the traditional external API program. • This new “internal API program” can be thought of in terms of the “API first” architecture and the distinctions drawn between API consumption and API exposure. • Both perspectives can benefit significantly from key functionality available in the “API tier” – Visibility through analytics that can give a clear understanding of service interactions and help to avoid nasty surprises – Control and threat protection through common authorization/authentication and threat protection – Shared state that facilitates building an optimal user experience – Backend-as-a-Service capabilities to support API consumption and provide an additional data-level integration capability The Take-Aways 15
  16. 16. Bala Kasiviswanathan @balak Chris von See @apigee Questions?
  17. 17. Thank you