Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Lessons in Transforming the Enterprise to an API Platform

359 visualizaciones

Publicado el

A look at lessons from our recent consulting engagements on why and how enterprises are moving from an API program to an API platform as part of their digital transformation. Includes 5 common practices we see across successful enterprises as they move to an API platform. Recording: https://www.youtube.com/watch?v=Km-mCx0Zbgo&feature=youtu.be

Publicado en: Empresariales
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

Lessons in Transforming the Enterprise to an API Platform

  1. 1. Confidential and Proprietary Lessons from Transforming the Enterprise to an API Platform 10 April 2018 James Higginbotham @launchany
  2. 2. 2Confidential and Proprietary Introduction • Executive API Consultant • API strategy, program execution • Across multiple verticals: – Commercial Insurance – Healthcare – Hospitality – Finance and Banking – Travel – Airline
  3. 3. 3Confidential and Proprietary A Review of APIs • API, or Application Programming Interface, is a contract between software and developers to support integration • Expose data and capabilities through programmatic interfaces • A successful API program focuses on value, reuse, and innovation • HTTP is the most common protocol for APIs • OpenAPI Specification is a common format to capture API contracts, encourage communication, and drive automation
  4. 4. 4Confidential and Proprietary The Enterprise API Platform Journey
  5. 5. 5Confidential and Proprietary Why Build an Enterprise API Platform? • API Products, commonly used to drive web and mobile applications, are common within the enterprise • However, this typically focuses on system integration or apps • Platforms create an ecosystem between orgs, customers, and partners • Cloud Elements 2018 Survey: “36% of respondents stated that their primary motivation to become a platform provider was sparked by their desire to maintain ‘stickiness’ with customers by integrating easily across the ecosystem of applications”
  6. 6. 6Confidential and Proprietary The Enterprise API Platform Offers API Inventory API Bookings API Identity API Accounts API Rewards API Partners Internal Developers Public App Developers Customers Third-party Approved Apps
  7. 7. 7Confidential and Proprietary 5 Key Steps For Moving to an API Platform 1. Develop a robust API program that supports platform needs 2. Implement federated API governance to increase platform quality 3. Migrate to microservices to enable platform agility 4. Efficient API onboarding and adoption to grow the platform 5. Define platform processes to accelerate and sustain the platform
  8. 8. 8Confidential and Proprietary 1. Developing an Effective API Program
  9. 9. 9Confidential and Proprietary The Top 5 Reasons for Enterprise API Programs 1. Accelerate mobile strategy by making data and services more accessible 2. Adapt to changing customer relationships that go beyond web and mobile to new devices 3. Transform partner integrations by adding efficiency and freeing up resources 4. Foster technical and business innovation by reducing technical barriers to delivery 5. Unsilo channels through easier data sharing across internal teams and systems
  10. 10. 13Confidential and Proprietary API Portfolio Management is Critical • Define a clear path for APIs to go from idea to production through SDLC • Not all APIs are public – define processes for private, partner, and public APIs • Choose the proper level of granularity and bundling necessary to restrict access, enforce entitlements, and encourage understanding of the portfolio • Drive adoption through clear processes that encourage discovery and onboarding through developer-focused support processes • Establish KPIs that define quality APIs – Examples include: API reuse, definition/contract quality, discoverability, NPS scoring
  11. 11. 14Confidential and Proprietary How to Design an Effective API Program 1. Ask why your API program exists and clearly state the objectives 2. Clearly document and share your vision across the organization. Repeat it often as a reminder of the larger vision 3. Identify change agents within the organization that understand the value of an API platform, help them share the vision 4. Evangelize existing/upcoming APIs 5. Implement API governance with a focus on coaching and standards 6. Establish an API training program and build shared knowledge 7. Manage your API portfolio as products that target internal, partner, and public stakeholders
  12. 12. 15Confidential and Proprietary 2. Implementing API Governance
  13. 13. 16Confidential and Proprietary Governance is Changing • SOA governance often brings to mind the idea of rigid, strict, heavy-handed enforcement of rules and processes • Most historical SOA Governance programs were internally focused to remove redundancies • Today's modern API programs are externally focused to drive revenue & efficiencies • API governance should encourage consistency across the organization, mixed with flexibility to support changing requirements
  14. 14. 17Confidential and Proprietary 5 Keys to Effective API Governance 1. Coach teams on API modeling and design techniques, resulting in self- sufficient delivery teams 2. Deliver educational material, training, and other resources to communicate shared knowledge 3. Empower solution teams to discover and consume existing APIs 4. Define clear API standards, protocols, and design patterns supported by the organization 5. Craft flexible processes and practices that encourage innovation
  15. 15. 18Confidential and Proprietary Centralized vs. Federated Governance • Centralized – Creates strict consistency across APIs – Requires a go/no-go decision for every API created – Reduces throughput, limits creativity by teams due to limitations of a single governance team • Federated – Centralized group creates standards, produce shared resources – Teams define APIs and federated coach/enforce standards locally whenever possible – Lends more context to the problem than a centralized group – Better fit for larger organizations or those with distributed workforce • Find the balance between full control and no control – every organization is different
  16. 16. 19Confidential and Proprietary 3. Migrating to Microservices
  17. 17. 20Confidential and Proprietary Review: Microservice Architecture • Loosely-coupled, service-oriented architecture composed of microservices • Apply bounded context to limit cognitive load • Independently deployable via automation • Enable replaceability and experimentation • Note: Best for large organizations, co-located disparate data, and high complexity systems
  18. 18. 21Confidential and Proprietary Microservices Support API-Centric Product Teams Alexa VoiceSkill API Product API Product Messaging (e.g.Kafka) … Microservice … API … Microservice … API … Microservice … API … Microservice … API Slack Chatbot Web+ MobileApp API Product Team B Team A Messaging (e.g.Kafka)
  19. 19. 22Confidential and Proprietary Speed vs. Safety • All organizations want to build software fast • Speed increases bugs, decreases reliability • Every time we depend on another team to finish our work, we slow down • Every time we need to have a meeting to stay in sync, we slow down • The goal of microservices is to reduce coordination between teams, but only if we apply the proper software architecture principles (high cohesion, loose coupling, system design) • APIs define contracts, microservices used for implementation • Automate as much as possible to drive delivery end-to-end quickly
  20. 20. 23Confidential and Proprietary Microservice Architecture is primarily about reducing coordination costs while aligning efforts across multiple teams/developers working on a complex system.
  21. 21. 24Confidential and Proprietary Case Study: Microservice-Based Hospitality Platform • Previous department was comprised of in-house and third-party systems that shared databases + limited knowledge constrained to a few teams • Microservice approach allows specialists to build out necessary capabilities, while limiting the amount of knowledge required to produce solutions • Platform APIs are externalized via an API management layer to hide the details of the microservices • Started as a single team that built out a single API with a few microservices • Now has expanded to multiple teams with product owners
  22. 22. 25Confidential and Proprietary 4. Increasing API Platform Adoption
  23. 23. 26Confidential and Proprietary How We Think of API Consumption
  24. 24. 27Confidential and Proprietary The Reality of API Consumption Consumption Phase Goal Discovery Identify API capabilities Mapping Map solution to Platform API capabilities using reference documentation Exploration Prototype consumption (“Try-it-out”) Onboarding App registration for API access to testing and staging Integration Developers consume the API within the solution via code Certification Obtain final approval for production API access Usage Monitoring Production usage monitoring and throttling Platform Improvement Request platform API enhancements to meet the needs of the solution Platform Updates Build platform awareness; update notifications for enhancements; sunsetting A great API program assists API consumers through all phases of their consumption journey. This results in a healthy, growing platform instead of a stagnating program.
  25. 25. 29Confidential and Proprietary API Adoption Maturity Model Level 1: Adhoc Limited or no adoption, no guidance on capabilities provided or how to get started Level 2: Dev Portal Capabilities and API docs offered to teams for reference and shared understanding Level 3: Enablement Apps onboarding and consuming with guidance Level 4: Self-Onboarding Apps are able to onboard with minimal or no guidance Level 5: Community API platform knowledge shared and coached without council guidance
  26. 26. 30Confidential and Proprietary 5. Accelerating Your Platform Initiative
  27. 27. 31Confidential and Proprietary API Platforms: Moving Beyond APIs to Events and Streams • Many enterprises extending their platform to include message streams and pub/sub eventing as part of the portfolio • Events and streaming enable push-based notifications that extend a platform beyond its original design • API Platforms must move beyond request/response APIs: “40% of those surveyed responded that their apps did not support event-based framework, but it was the number one answer when we asked which API technology area was most in need of innovation.” -- Cloud Elements 2018 Survey
  28. 28. 32Confidential and Proprietary Product-Driven. API-Centric • Digital transformation requires an API-first approach • Transformation begins with managing APIs as long-lived products, not time-boxed projects • Using dedicated product development teams • Each team has a product owner that listens to stakeholders and adjusts the API roadmap based on demand • KPI-driven (e.g. API req/month, tx/day) • Without a product-driven approach, APIs become stale and anemic, resulting in frustrated teams
  29. 29. 33Confidential and Proprietary Fintech Case Study: From Brokered APIs to Direct Consumer-Producer • Engagement with a U.S. bank that has 10k+ developers across multiple cities • Top-down executive vision for an API platform • Started with a few REST-based APIs in high-value areas, today they have 1000s of APIs • Required training, federated governance, and significant cultural shift • Move from centralized “digital product team” that own SOAP services, to productized teams that own APIs & streams and apply a direct-to-consumer approach • Shift from project-to-product-centric approach underway - “you build it, you own it”. No more maintenance teams!
  30. 30. 34Confidential and Proprietary Apply Cross-Functional API Training
  31. 31. 35Confidential and Proprietary Operationalizing the Platform Involves Everyone • Security – Review API designs, identify risks, authority to approve/decline apps consuming sensitive endpoints • Platform – Product ownership, roadmapping, marketing/evangelism, drive onboarding consumers, coach teams new to consuming the platform, education (self-serve and workshops, hackathons) • Infrastructure/DevOps – Ensure network, server, container platforms, necessary resources (e.g. message brokers, kafka, etc) are available and can be installed for a new project/team as required • Engineering – Coach teams on common practices, patterns, delivery; onboard new projects that (most likely) consume the platform • Program Management Office – Assist in the overall process of the platform and API initiatives, implement change management
  32. 32. 36Confidential and Proprietary From IT-Driven to Platform-Driven • Speed and safety in harmony – Safety without speed slows down innovation; speed without safety results in a poor customer experience. The goal is to move safely (PII, NPI, GDPR) at a higher rate of speed • Consistent customer experience across all channels – An API-centric approach ensures consistency across all channels, while each channel applies API capabilities in the manner best suited for the channel • Co-ownership of digital products to support IT and business needs – Business and IT works together to deliver a great customer experience • Federation over centralization – Federation supports increased speed and prevents silo-based delivery processes, while centralization reduces the speed of innovation to the slowest point in the process
  33. 33. 37Confidential and Proprietary Questions? James Higginbotham james@launchany.com @launchany https://apideveloperweekly.com

×