(4) @dret on Twitter/GitHub

(5) About Me

• Ph.D. in Communications Systems [http://dret.net/netdret/publications#wil97b] from ETH Zürich [http://www.ethz.ch/] (1997)
• Research work at ETH Zürich [http://www.ethz.ch/] (1997-2006) and UC Berkeley [http://www.berkeley.edu/] (2006-2011)
• EMC (2011-2014), working on transforming software products into service platforms
• Siemens (2014-2015), working on using IoT to build WoT (APIs for Things)
• Part of CA [http://www.ca.com/]'s API Academy [http://www.apiacademy.co/] 2016-2019 focusing on API Design and Management
• Joined Good API [https://www.goodapi.co/] in 2019 focusing on Digital Transformation and API Strategy
• Joined Axway [https://www.axway.com/]'s Catalysts [https://www.axway.com/services/catalysts] in 2019 for driving the Accelerate program [https://accelerate.axway.com/]
• Active in the usual places such as Twitter [http://twitter.com/dret], GitHub [http://github.com/dret], and LinkedIn [http://www.linkedin.com/in/netdret]

(6) Axway [https://www.axway.com/] Catalysts [https://www.axway.com/catalysts]

• Small team with three core missions
  • Provide thought-leadership in the API and digital transformation space
  • Improve customer success by shifting focus to outcomes
  • Improve Axway by following the principles that we preach
• Team members are distributed globally
  • Uli Hitzel: @u1i [http://twitter.com/u1i]
  • Kay Lummitsch: @lummitsch [http://twitter.com/lummitsch]
  • Emmanuel Methivier: @e_methivier [http://twitter.com/e_methivier]
  • David Morgan
  • Brian Otten: @bottencatalyst [http://twitter.com/bottencatalyst]
  • Brian Pagano: @brianpagano [http://twitter.com/brianpagano]
  • Emmelyn Wang: @lifewingmate [http://twitter.com/lifewingmate]
  • John Wiese
  • Erik Wilde: @dret [http://twitter.com/dret]

(7) Continuous API Management (2018)

• Continuous API Management: Making the Right Decisions in an Evolving Landscape
  • O'Reilly book page [https://www.oreilly.com/library/view/continuous-api-management/9781492043546/]
  • Amazon book page [https://www.amazon.com/Continuous-Api-Management-Decisions-Landscape/dp/1492043559]
• Authored by 2018 API Academy [http://www.apiacademy.co/] members
  • Mehdi Medjaoui: @medjawii [http://twitter.com/medjawii]
  • Erik Wilde: @dret [http://twitter.com/dret]
  • Ronnie Mitra: @mitraman [http://twitter.com/mitraman]
  • Mike Amundsen: @mamund [http://twitter.com/mamund]

(9) Digital Transformation is Global

(10) Digital Transformation Definition

Digital Transformation means adapting an organization's strategy and structure to capture opportunities enabled by digital technology. (Nathan Furr and Andrew Shipilov, Digital Doesn't Have to Be Disruptive, Harvard Business Review 97(4), July/August 2019, pp. 94-103) [https://hbr.org/2019/07/digital-doesnt-have-to-be-disruptive]

(11) Digital Transformation Vision

Our Digital Transformation Initiative drives innovation by allowing us to more quickly develop and execute on new ideas. Innovation is the driving force that allows us to improve engagement with existing customers and to explore new markets.

The Digital Transformation Initiative will turn us into the leader of the industry. 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.

(12) The Execution Gap

(13) The Wonders of APIs

(14) APIs Fix Anything!

(15) But APIs Are Just Plumbing…

(16) The Web

• Providers and consumers are loosely coupled
• Providers can implement their services any way they like
• Consumers can implement their clients any way they like
• There are no hidden shared assumptions or components
• Providers and consumers evolve independently
• All these things are equally true for the API Web

(18) API Product Lifecycle

(19) Product Pillars and Maturity

• API Products are created in the context of API landscapes
  • They are influenced by the culture and constraints of the landscape
  • They influence the culture and constraints of the landscape
• Product Pillars identify areas of investment during an API's lifetime
• Product Maturity describes stages of an API product's lifetime

(20) CAM Product Compass

(21) CAM Product Compass: Change Management

• Does your design include a plan how to make any changes to the API?
• Do you have an idea of what your API should and shouldn't be, so that you can more easily decide which evolution paths you are trying to keep open?
• If your design does not plan on evolving the API itself, do you have a plan how to operate multiple versions and how to manage the consumers of these multiple versions?
• If your design includes a plan for evolving the API itself, do you document this clearly so that clients know what to expect?
• Does your documentation include a history of changes so that it is possible for consumers to understand how the API evolved?
• Do you have a plan how to decommission the API, and how this will be communicated to active consumers?

(22) CAM Product Compass: Maturity

(23) CAM Product Compass: Results

(24) API Complexity: Results

(25) Consume Responsibly

• Distributed programming is different
• Well-behaving code needs to be resilient
• Test resilience by testing in non-optimal environments

(26) CAM Consumption Compass

(28) CAM Strategy Compass

(29) Guidelines: Increasing Product/Landscapes 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

(30) Guidelines: Why? What? How? Test?

• Guidance 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

(31) CAM Landscape Compass

(32) The Evolution of API Design Patterns

• 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

(33) Web Concepts

• Web APIs are always based on shared architectural concepts
  • Some concepts [http://webconcepts.info/concepts/] matter for interaction at the Web level
  • Each concept has a value space (such as HTTP request methods [http://webconcepts.info/concepts/http-method/])
  • Specifications establishing values are created by organizations [http://webconcepts.info/specs/]
• Web concepts [http://webconcepts.info/] provides a starter set of concepts and specifications
  • Currently there are 33 concepts with a total of 803 distinct values [http://webconcepts.info/concepts/]
  • These concepts are taken from 288 specifications from 6 organizations [http://webconcepts.info/specs/]
• Web concepts is designed to be usable along two major axes
  1. Adding or removing concepts/values to represent the organizational Web surface
  2. Adding API-level usage to link APIs and the concepts they use

(34) HTTP Problems: JSON Format

(35) RFC 7807

(36) Specifications

     "7807": {
      "id": "http://webconcepts.info/specs/IETF/RFC/7807",
      "title": "Problem Details for HTTP APIs",
      "name": "RFC 7807",
      "URI": "urn:ietf:rfc:7807",
      "URL": "http://tools.ietf.org/html/rfc7807",
      "abstract": "This document defines a \"problem detail\" as a way to carry machine-readable details of errors in a HTTP response, to avoid the need to invent new error response formats for HTTP APIs.",
      "concepts": [{
       "http://webconcepts.info/concepts/media-type/": "http://webconcepts.info/concepts/media-type/application/problem+json" }, {
       "http://webconcepts.info/concepts/media-type/": "http://webconcepts.info/concepts/media-type/application/problem+xml" }]}},{

(37) Concepts

        { "value" : "application\/problem+json",
          "concept" : "http:\/\/webconcepts.info\/concepts\/media-type\/",
          "id" : "http:\/\/webconcepts.info\/concepts\/media-type\/application\/problem+json",
          "details" : 
          [ 
            { "description" : "The canonical model for problem details is a JSON object. When serialised as a JSON document, that format is identified with the \"application\/problem+json\" media type.",
              "documentation" : "http:\/\/tools.ietf.org\/html\/rfc7807#section-3",
              "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7807",
              "spec-name" : "RFC 7807" } ] },

(39) Continuous Architecting

• Strategy: Have a well-defined and clear goal for your ecosystem
• Program: Provide a platform and support to use and extend the platform
• Landscape: Make sure that your platform can and does evolve continuously
• Product: Help product teams to develop products that fit into the platform
• Consumption: Ensure that teams build responsibly on the platform

(40) Thank You!

• Slides online: dret.net/lectures/wjax-2019 [http://dret.net/lectures/wjax-2019]
• More information:
  • Twitter: @dret [http://twitter.com/dret]
  • LinkedIn: linkedin.com/in/netdret [http://www.linkedin.com/in/netdret]
  • Web page: dret.net/netdret/ [http://dret.net/netdret/]