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

(10) Digital Transformation: The Default Choice

(11) Focus and Scale

(12) The Execution Gap

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

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

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

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

(18) API Landscape Aspects

(19) V1: Variety

• APIs come in many different shapes (on different levels)
  • API style moved from RPC (SOAP) to Web APIs
  • Web API style starts embracing query-style APIs (GraphQL)
• Allow more than one way to address a problem
  • Embrace diversity as a way to explore new ways to solve a problem

(20) V2: Vocabulary

• APIs are languages that define how two parties communicate
• Each API is a mix of reused technology and problem-specific definitions
  • Reusing generic metamodels such as XML or JSON is a natural choice for most
  • Reusing specific models is a harder design task
• Maximizing reuse benefits producers and consumers
  • Producers don't have to re-invent the wheel for solved problems
  • Consumers can understand part of the API because they know it already

(21) V3: Volume

• API volume is a good thing and should be encouraged
  • More components in an ecosystem mean more choice and better selection
  • Selection should be within the ecosystem, not getting into the ecosystem
• Guidelines and support needs to grow and evolve along ecosystem growth
  • Identifying bottlenecks for the product teams helps to make teams more productive
  • Identifying bottlenecks for the ecosystem helps to eliminate participation barriers

(22) V4: Velocity

• Change frequency is a good thing and should be encouraged
• Changes in consumption ideally are invisible to producers
  • Onboarding is invisible to producers
  • Scalability should be built into each product
• Changes in products ideally are invisible to consumers
  1. Change management [V7: Versioning (1)] provides a robust product evolution path
  2. Product evolution is opaque and consumers always use their favorite version

(23) V5: Vulnerability

• Every API is a possible attack vector into a capability
• Security is easy to get wrong and hard to get right
• Security often gets API programs started
• Identity can become an important asset for large organizations
  • GDPR is hard to get right without solid identity management

(24) V6: Visibility

• Product catalogs are essential for product success
• Visibility refinement depends on the expected target audience
  • Private APIs may be able to get away with just making them findable
  • Partner APIs already need some marketing so that partners will notice
  • Public APIs may need a comprehensive plan for a competitive market presence

(25) V7: Versioning

• API success creates potential problem for API products
  • More usage means more feedback means more input and motivation to improve the product
  • More usage means greater risk for potential disruption of existing consumers
• Managing products and their implementations
  • Implementations should use well-know schemes such as Semantic Versioning [http://semver.org/]
  • APIs should expose a subset of the implementation version information
  • API management can take care of some product management issues

(26) V8: Volatility

• Products in ecosystems appear, change, and disappear
  • Change is not a problem but a feature that is essential for ecosystem growth
• Treating dependencies responsibly increases product resilience
  • Not making any assumptions about APIs always being accessible
  • Always behaving well when APIs are inaccessible
• Client-side products (such as SDKs) need to be resilient
• Testing always should include degraded and inaccessible API dependencies

(27) Good Plumbing Matters

(29) Interface Design

(30) Interface Continuity and Evolution

(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) Ecosystems win over Systems

• Ecosystems have built-in mechanisms for determining fitness
  • Systems are easy to build but hard to improve over time
  • Ecosystems are hard to build but easy to improve over time
• APIs are the plumbing that make product ecosystems work
  • Good plumbing allows the ecosystem to change and evolve organically
  • Bad plumbing means that not all potential product value is realized

(35) Thanks! Q&A

• Slides online: dret.net/lectures/nordic-apis-2018 [http://dret.net/lectures/nordic-apis-2018]
  • Slide sources: dret/lectures [http://github.com/dret/lectures/tree/master/nordic-apis-2018] on GitHub [http://github.com/]
• 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]