(4) @dret on Twitter/GitHub

(5) API Academy [http://www.apiacademy.co/]

• Global Team working on API Strategy and Design topics
  • Matt McLarty [http://www.apiacademy.co/team_member/matt-mclarty/] (Vancouver): @MattMcLartyBC [http://twitter.com/MattMcLartyBC]
  • Mike Amundsen [http://www.apiacademy.co/team_member/mike-amundsen/] (Cincinnati): @mamund [http://twitter.com/mamund]
  • Mehdi Medjaoui [http://www.apiacademy.co/team_member/mehdi-medjaoui/] (San Francisco): @medjawii [http://twitter.com/medjawii]
  • Ronnie Mitra [http://www.apiacademy.co/team_member/ronnie-mitra/] (London): @mitraman [http://twitter.com/mitraman]
  • Erik Wilde [http://www.apiacademy.co/team_member/erik-wilde/] (Zürich): @dret [http://twitter.com/dret]
• Evangelizing ideas and technologies
  • Speaking (conferences, events)
  • Teaching (workshops, bootcamps)
  • Publishing (blogs, articles, books, podcasts [https://soundcloud.com/user-426834320])
  • Doing (side projects on API-related topics)
  • Standardizing (participating in specification work)

(6) Continuous API Management

• Continuous API Management: Making the Right Decisions in an Evolving Landscape [https://www.amazon.com/Continuous-Api-Management-Decisions-Landscape/dp/1492043559]
• Authored by API Academy [http://www.apiacademy.co/] members Mehdi Medjaoui, Erik Wilde, Ronnie Mitra, and Mike Amundsen
• To be published December 2018

(7) About Me

• Ph.D. in Communications Systems [http://dret.net/netdret/publications#wil97b] from ETH Zürich [http://www.ethz.ch/]
• Working on Web Architecture after writing the first Web Technology book [http://dret.net/netdret/publications#wil98]
• UC Berkeley (2006-2011), working on Service Models for Open Government [http://dret.net/netdret/publications#wil09g]
• EMC (2011-2014), working on transforming software products into service platforms
• Siemens (2014-2015), working on using IoT to build WoT (APIs for Things)
• Joined CA [http://www.ca.com/]'s API Academy [http://www.apiacademy.co/] in 2016 and now all about API Strategy and Design
• Active in the usual places such as Twitter [http://twitter.com/dret], GitHub [http://github.com/dret], my blog [http://dret.typepad.com/dretblog/], LinkedIn [http://www.linkedin.com/in/netdret], and flickr [https://www.flickr.com/photos/dret/]

(9) Internal and External API Usage

(10) Digital Transformation Vision

Our Digital Transformation Initiative will turn us into the leader of the industry by allowing us to interact with our customers more easily, and more frequently. By increasing the number of customer touchpoints and using the resulting feedback to quickly and relentlessly adapt and improve our offerings, we will be able to outperform our competition and turn into the market leader within the next three years.

(11) Digital Transformation is Scary

(12) Digital Transformation is Global

(13) Focus and Scale

(14) The Execution Gap

(15) Leadership 1-2-3

• Set a vision as the goal to improve the organization
• Define a strategy how to turn the vision into reality
• Have a program to turn the defined strategy into reality

(16) API Archaeology

• Most organizations have proto-APIs from integration projects
  • One-off integrations not intended or designed for reuse
  • Unearthing and documenting help with analysis and improvement
• API Craft is about establishing API practice in the organization
  • Cultivate Product as API mindset across teams
  • Build experience around design, implementation, and operations
• API Landscapes focus on scaling the API practice
  • Enlightenment and empowerment of teams
  • Re-imagine enterprise IT as managing ecosystems
  • Identify and remove bottlenecks to make teams more effective

(18) Jeff Bezos' Services Rant: The Rules [https://gist.github.com/chitchcock/1281611]

• Famous small set of SOA design rules
  • Teams must expose functionality through services
  • Communication happens only through service interfaces
  • There are no hard guidelines for service design
  • Internal/external service is a matter of policy, not one of design
• Going against the let's pick a platform spirit of old-school SOA

(19) Jeff Bezos' Services Rant: The Consequences [https://plus.google.com/+RipRowan/posts/eVeouesvaVX]

• With more freedom comes more responsibility
  • Monitoring and metrics are necessary for finding root causes
  • All APIs must be hardened against DoS attacks
  • Automated QA is necessary to really understand service health
  • Services must be documented and registered so that they can be discovered
  • Debugging becomes harder because of service dependencies
• Sophisticated tooling required to manage the new SOA landscape
• Much easier in today's technology landscape than 16 years ago

(21) Increasing Product Team Productivity

• API product teams need guidance, autonomy, and support
  • Guidance helps understanding and navigating the current landscape
  • Autonomy allows choices to be made driven by product and user needs
  • Support increases productivity of teams for cross-cutting concerns
• Balancing product value and product portfolio value
  • Products focus on achieving local maxima for product value
  • Landscapes focus on achieving global maxima across all products

(22) Guidelines: Why? What? How? Test!

• API Guidance [http://apistylebook.com/] needs to be motivated, clear, actionable, and testable
  • Why explains why a problem is a problem
  • What explains a design to address the problem
  • How explains how to implement the solution
  • Test provides feedback to verify compliance
• Guidance is further qualified by when it is applicable
  • Guidance evolution has stages such as experimental/production/deprecated
  • Guidance applicability is decided by API maturity stage
• Governance is about how the guidelines are enforced/encouraged

(23) CAM Compass: API Product Pillars

(24) CAM Compass: API Landscape Aspects

(25) Good Plumbing Matters

(27) Interface Design

(28) Interface Continuity and Evolution

(29) Continuous Architecting: Continuity and Scale

(30) Observability

• Continuous Architecting is based on four main principles
  1. Design Products with feedback and changeability in mind
  2. Evolve Products based on feedback and with minimal breakage
  3. Landscape Design supports product continuity and landscape evolvability
  4. Landscape Evolution is based on product and consumer feedback
• Observability is a key principle complementing APIs and Microservices
  • Implementation details are hidden and APIs are the only interface
  • API your APIs: Anything that is interesting should become an API
• Observability is based on and complements Continuous Architecting
  • When new observability needs arise they can be added to the landscape and/or products
  • Observability makes sure that the landscape can be observed and improved

(31) API your APIs

• Expose design-time and runtime API information in the API
  • Design-time allows automation of API landscape overview
  • Runtime allows automation of API landscape status
• Follow robust extensibility principles [http://dret.typepad.com/dretblog/2016/04/robust-extensibility.html] for these API APIs
  • Meaningful Core: Start with a simple but useful scenario
  • Extension Points: Think about how scenarios might evolve
  • Processing Model: Be clear about how extensions are handled

(32) Emerging API Patterns

• Self-description for APIs is increasing
• Problem details [http://webconcepts.info/specs/IETF/RFC/7807] as a way how APIs expose error information
  • Enables generic error handling but also allows additional information
• Home documents [http://webconcepts.info/specs/IETF/I-D/nottingham-json-home] as a way how APIs provide starting pages
  • Enables harvesting of API start points but also allows additional information
• Healthcheck reports [http://webconcepts.info/specs/IETF/I-D/inadarei-api-health-check] as a way how APIs expose status information
  • Enables landscape-level status reports but also allows additional information
• API Labels [http://dret.net/lectures/apistrat-2018] as a way for representing API product labels
  • Share API labels as a way to describe cross-cutting aspects of APIs

(34) Internal and External API Usage

(35) API Management is about Vision and Strategy

• 1: API as a Product needs a strategy for DX and product management
• 2: Product as API needs a strategy for APIs as the new IT component
• 3: API Economy needs a strategy for managing dependency and risk

(36) Thanks! Q&A

• Slides online: dret.net/lectures/devday-2018 [http://dret.net/lectures/devday-2018]
• More information about myself:
  • Web page: dret.net/netdret/ [http://dret.net/netdret/]
  • LinkedIn: linkedin.com/in/netdret [http://www.linkedin.com/in/netdret]
• Twitter handles:
  • Erik Wilde: @dret [http://twitter.com/dret]
  • API Academy: @APIacademy [http://twitter.com/APIacademy]
  • Standards Daily: @StandardsDaily [http://twitter.com/StandardsDaily]