(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 [http://cambook.io/]
  • 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 API Academy [http://www.apiacademy.co/] members Mehdi Medjaoui, Erik Wilde, Ronnie Mitra, and Mike Amundsen

(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 puts a focus on 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 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) The Execution Gap

(11) Transformation 1-2-3

1. Set a vision as the goal to improve the organization
2. Define a strategy that details the vision into concrete goals
3. Have a program how to achieve the goals defined in the strategy

(12) Brownfield Transformation

1. Understand the existing landscape of proto-APIs and their genesis
2. Understand the existing culture of teams for their integration tasks
3. Your initial API Strategy is the sum of all these parts
4. Drive change through communications and support (make API development easier)

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

• Many organizations have some form of API Guidelines [http://apistylebook.com/]
• 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

(15) Understanding the Past

Archaeology is the practice of unearthing artifacts, and understanding them in the context of their origins in time and location. That exact concept can be applied to APIs as well. API Archaeology thus is the practice of finding integrations, understanding why and how they were created, and documenting them as a way to better understand the history and structure of complex IT landscapes. Practicing 'API Archaeology' in organizations can be extremely valuable in terms of finding out about existing ways in which IT components interact (in some shape or form).

[Continuous API Management: Making the Right Decisions in an Evolving Landscape [http://www.oreilly.com/catalog/0636920201755]]

(16) Sharing and Scaling

• 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 sharing and scaling the API practice
  • Empowerment and enlightenment of teams
  • Enterprise IT as managing ecosystems of autonomous components
  • Identify and remove bottlenecks to make teams more effective

(18) Learning from Legacy Landscapes

• Various teams or units have an existing (proto-)API culture
• The organizational landscape should combine and harmonize these
  • Learning across teams/units and establish good practices
  • Identify where support and tooling can make the biggest impact
• Landscapes can be analyzed according to landscape aspects
  • Aspects can be used to better understand how APIs are designed and implemented
  • Aspects can be used to observe the landscape and understand its evolution

(19) API Landscape Aspects

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

Example Question: How easy is it for your landscape to embrace and support a new API technology?

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

Example Question: Is there an easy way for developers to discover the vocabularies that are in use throughout existing APIs?

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

Example Question: How easy is it for developers to design, implement, and deploy a new product?

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

Example Question: Does anything in the API landscape slow down teams when creating or changing APIs?

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

Example Question: Are APIs designed from the ground up to be potentially externalizable?

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

Example Question: How easy it is for architects, teams, and consumers to explore the entire API landscape?

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

Example Question: Are APIs designed and implemented so that changes create as little disruption as possible?

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

Example Question: Are all dependencies implemented to be visible and to behave responsibly when some APIs fail?

(28) API Archaeology Compass

(29) Guideline Convergence

• Analyze and merge guidelines/practices where possible
• Document diverging guidelines/practices where present
  • All guidelines are good practices and not best practices
• Units are free to fork and refine/subset the converged guidelines
• Contributions to the guidelines are openly managed
  • Central team are editors of the guidelines (and not authors)

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

(32) API Product Pillars

(33) API Product Maturity Compass

(34) Assessing API Products: 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?

(35) API Product Compass

(37) Guiding the API Journey

• Gather and combine and evolve guidelines for your API journey
• Help teams with investing the right effort at the right time
• Understand where your APIs are and where you want them to be

(38) Thanks! Q&A

• Slides online: dret.net/lectures/api-days-paris-dec-2018 [http://dret.net/lectures/api-days-paris-dec-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]