(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) Continuous API Management (2018)

• Continuous API Management: Making the Right Decisions in an Evolving Landscape
  • O'Reilly book page [http://shop.oreilly.com/product/0636920201755.do]
  • 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]

(8) Digital Transformation is a Challenge

(9) Digital Transformation: Business & Technology Align

(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) The Execution Gap

(12) The Wonders of APIs

(13) APIs Fix Anything!

(14) APIs Deliver Product Value

(15) This is GraphQL

(16) APIs Are Just Plumbing

(17) Digital Transformation is Continuous

• Digital transformation happens at two different levels
  • Transforming the organization to become better at adapting to changes
  • Identifying and implementing capabilities that improve the organization
• You're never done with digital transformation
  • Business must be empowered and capable to identify opportunities
  • Organization must be capable of acting fast to capture opportunities
  • Technology must be able to realize opportunities quickly and safely

(19) Interface Design

(20) Interface Continuity and Evolution

(21) The Essence of Continuous Architecting

• Architecture is informed by solutions
• Architecture's job is to support solutions
• Architecture's job is to optimize the solution landscape
• Architecture focuses on solution interfaces
  • Strictly separate interface and implementation architecture

(22) Emerging API 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
• API your APIs: Self-description for APIs is increasing
  • Design-time allows automation of API landscape overview
  • Runtime allows automation of API landscape status

(24) 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

(25) CAM Landscape Compass

(26) CAM Product Compass: Aspects 1-4

• Variety example: How easy is it for your landscape to embrace and support a new API technology?
• Vocabulary example: Is there an easy way for developers to discover the vocabularies that are in use throughout existing APIs?
• Volume example: How easy is it for developers to design, implement, and deploy a new product?
• Velocity example: Does anything in the API landscape slow down teams when creating or changing APIs?

(27) CAM Product Compass: Aspects 5-8

• Vulnerability example: Are APIs designed from the ground up to be potentially externalizable?
• Visibility example: How easy it is for architects, teams, and consumers to explore the entire API landscape?
• Versioning example: Are APIs designed and implemented so that changes create as little disruption as possible?
• Volatility example: Are all dependencies implemented to be visible and to behave responsibly when some APIs fail?

(28) The API Stylebook

(30) Product Pillars and Maturity

• API Products are created in the context of (possibly implicit) API landscapes
  • They are influenced by 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

(31) CAM Product Compass

(32) CAM Product Compass: Maturity

(33) CAM Product Compass: Pillars 1-5

• Change Management example: If your design includes a plan for evolving the API itself, do you document this clearly so that clients know what to expect?
• Deployment example: Deployment is aligned with the change management principles, so that if necessary, multiple versions can be operated and potentially discovered in parallel.
• Design example: Given the API's style and technology, is it using a recommended and/or standardized description format that makes it easier for consumers to gain an initial understanding of the API, possibly aided by tooling they can use?
• Development example: Does development include technologies and/or tools that are not part of the recommended development technologies and/or tools in the organization?
• Discovery example: Based on the change management strategy, it is made sure that it is always the most recent version that is made available through all discovery channels.

(34) CAM Product Compass: Pillars 6-10

• Documentation example: Is the documentation and learning experience for the API based on the strategic goals of the API product?
• Monitoring example: Is all the monitoring information collected in a way that it can be easily accessed and reused?
• Security example: Documentation and design expose as little information about implementation details as possible to reduce the attack surface.
• Strategy example: Do you have a clearly defined and documented reason why the API exists?
• Testing example: Do your tests include scenarios where consumed APIs are not performing or are not reachable, in order to test for resiliency of the API product?

(35) CAM Product Compass: Results

(37) Practicing Continuous Architecting

• Create rules what to do and not how to do it
• When you say what to do also explain why this constraint exists
• Propose/suggest/support at least one way how to satisfy the constraint
• Be open to new ways of how constraints can be satisfied
• Explain how to verify compliance with the constraint

(38) Thank You!

• Slides online: dret.net/lectures/tag-2019 [http://dret.net/lectures/tag-2019]
• More information about myself:
  • 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/]