---
published: true
layout: post
title: '68 Stops In A Comprehensive API Strategy Transit Map'
image: https://s3.amazonaws.com/kinlane-productions2/transit/calcagno-2017-01-01.png
---

<p><img src="https://s3.amazonaws.com/kinlane-productions2/transit/calcagno-2017-01-01.png" align="right" width="45%" style="padding: 15px;" />
<p>I am refining my comprehensive list of stops that I highlight as part of the API lifecycle, or what I call <a href="https://apievangelist.com/2017/08/17/testing-out-the-concept-of-api-transit-instead-of-api-lifecycle/">API Transit</a>–the stops that each of the services we deliver will have “pass through” at some point. I’m sharing this list with other team members as part of existing consulting arrangements I’m engaged in with Streamdata.io, as well as baking into my API transit work for some workshops I’m doing in April. All of these are available on <a href="http://apievangelist.com/api-lifecycle/">the API lifecycle section of API Evangelist</a>, but I will be pushing them to become a first class citizen on the home page of API Evangelist once again.

<p>Here are 68 potential stops I’d consider for any microservice to be exposed to, as part of a larger API transit strategy map:

<ul>
  <li><strong>Definitions</strong> - From the simplest definition of what a service does, all the way to the complete OpenAPI definition for each service.</li>
  <li><strong>Design</strong> - The consistent design of each service leverage existing patterns, as well as the web to deliver each service.</li>
  <li><strong>Versioning</strong> - Plan for handling changes, and the inevitable evolution of each service, its definitions, and supporting code.</li>
  <li><strong>DNS</strong> - The domain addressing being used for routing, management and auditing of all service traffic.</li>
  <li><strong>Database</strong> - The backend database schema, infrastructure, and other relevant information regarding how data is managed.</li>
  <li><strong>Compute</strong> - How is the underlying compute delivered for each service using containers, serverless, cloud, and on-premise infrastructure.</li>
  <li><strong>Storage</strong> - What does storage of all heavy objects, media, and other assets involved with the delivery of services.</li>
  <li><strong>Deployment</strong> - Details services developed, and deployed, including frameworks and other libraries being used.</li>
  <li><strong>Orchestration</strong> - Defining what the build, syndication, and orchestration of service deployments and integrations look like, and are executed.</li>
  <li><strong>Dependencies</strong> - Identifying all backend service, code and infrastructure dependencies present for each service.</li>
  <li><strong>Search</strong> - Strategy for understanding what search will look like for each individual service, and play a role in larger, more comprehensive search across services.</li>
  <li><strong>Proxy</strong> - What proxies are in place to translate, cache, stream, and make services more efficient and secure?</li>
  <li><strong>Gateway</strong> - What gateways are in place to defend, protect, route, translate, and act as gatekeeper for service operations?</li>
  <li><strong>Virtualization</strong> - Details how how services and their underlying data are mocked, virtualized, sandboxed, and made available for non-production usage.</li>
  <li><strong>Authentication</strong> - What is involved with authentication across all services, including key-based approaches, basic authentication, JWT, and OAuth solutions.</li>
  <li><strong>Management</strong> - Information about how services are composed, limited, measured, reported upon, and managed consistently across all services.</li>
  <li><strong>Logging</strong> - What is being logged as part of service operations, and what is required to participate in overall logging strategy?</li>
  <li><strong>Portal</strong> - The strategy for how all services are required to be published to one or many public, private, and partner developer portals.</li>
  <li><strong>Documentation</strong> - The requirements for what documentation is expected as part of each service presence, defining what the services delivers.</li>
  <li><strong>Support</strong> - Relevant support channels, points of contact, and best practices for receiving support as an API consumer.</li>
  <li><strong>Communications</strong> - Information about the communication strategy around each service, and how blogs, social, and other channels should be leveraged.</li>
  <li><strong>Road Map</strong> - Details on a services road map, and what the future will hold, providing individual service, as well as larger organizational details on what is next.</li>
  <li><strong>Issues</strong> - Expectations, communications, and transparency around what the current bugs, issues, and other active problems exist on a platform.</li>
  <li><strong>Change Log</strong> - Translating the road map, and issues into a log of activity that has occurred for each service, providing a history of the service.</li>
  <li><strong>Monitoring</strong> - What is required when it comes to monitoring the availability and activity of each individual service.</li>
  <li><strong>Testing</strong> - The tactical, as well as strategic testing that is involved with each service, ensuring it is meeting service level agreements.</li>
  <li><strong>Performance</strong> - How is the performance of each service measured and report upon, providing a benchmark for the quality of service.</li>
  <li><strong>Observability</strong> - What does observability of the service look like, providing transparency and accountability using all of its existing outputs?</li>
  <li><strong>Caching</strong> - What caching exists at the server, CDN, and DNS layers for each service to provide a higher level of performance?</li>
  <li><strong>Encryption</strong> - Details regarding what is expected regarding encryption on disk, as well as in transport for each service.</li>
  <li><strong>Security</strong> - Detailed strategy and processes regarding how each service is secured on a regular basis as part of operations.</li>
  <li><strong>Terms of Service (TOS)</strong> - Considerations, and legal requirements applied to each service as part of the overall, or individual terms of services.</li>
  <li><strong>Privacy</strong> - Details regarding the privacy of platform owners, developers, and end users as it pertains to service usage.</li>
  <li><strong>Service Level Agreements (SLA)</strong> - Details regarding what service levels are required to be met when it comes to partner and public engagements.</li>
  <li><strong>Licensing</strong> - Information about backend server code, API surface area, data, and client licensing in play.</li>
  <li><strong>Branding</strong> - What branding requirements are in place for the platforms and its partners when it comes to the service.</li>
  <li><strong>Regulation</strong> - Information regarding regulations in place that effect service operations, and are required as part of its usage.</li>
  <li><strong>Discovery</strong> - How are services catalogued and made discoverable, making them accessible to other systems, developers, as well as to internal, partner, or public groups.</li>
  <li><strong>Client</strong> - Information about clients being used to interface with and work with the service, allowing it to be put to use without code.</li>
  <li><strong>Command Line Interface</strong> - The command line interface (CLI) tooling being used to developer or consume a service.</li>
  <li><strong>SDKs</strong> - What software development kits (SDK) are generated, or developed and maintained as part of a service’s operation?</li>
  <li><strong>Plugin</strong> - What platform plugins are developed and maintained as part of a services operations, allowing it to work with other platforms and services.</li>
  <li><strong>IDE</strong> - Are there integrated development environment (IDE) integrations, libraries, plugins, or availability considerations for each service?</li>
  <li><strong>Browsers</strong> - Are there any browser plugins, add-ons, bookmarklets and integrations used as part of each service’s operation?</li>
  <li><strong>Embeddable</strong> - Information about any embeddable badges, buttons, widgets, and other JavaScript enabled solutions built on top of a service?</li>
  <li><strong>Bots</strong> - What type of automation and bot implementations are in development or being supported as part of a service’s operation?</li>
  <li><strong>Visualization</strong> - Are there specific visualizations that exist to help present the resources available within any service?</li>
  <li><strong>Analysis</strong> - How are logs, APIs, and other aspects of a service being used as part of wider analysis, and analytics strategy?</li>
  <li><strong>Aggregation</strong> - Are there any aggregation solutions in place that involve the service, and depend on its availability?</li>
  <li><strong>Integration</strong> - What 3rd party integrations are available for working with a service in existing integration platforms like IFTTT, and Zapier.</li>
  <li><strong>Network</strong> - Information about networks that are setup, used, and allocated for each service governing how it can be accessed and consumed.</li>
  <li><strong>Regions</strong> - Which regions does a service operate within, making it available in specific regions, and jurisdictions–also which regions is it not allowed to operate within.</li>
  <li><strong>Webhooks</strong> - Are there webhooks employed to respond to events that occur via the service, pushing data, and notification externally to consumers?</li>
  <li><strong>Migration</strong> - What solutions are available for migrating an API between regions, cloud environments, and on-premise?</li>
  <li><strong>Backup</strong> - What types of backups are in place to bring redundancy to the database, server, storage, and other essential aspects of a service’s operations?</li>
  <li><strong>Real Time</strong> - Are there Server-Sent Events (SSE), Websocket, Kafka, and other real time aspects of a service’s delivery?</li>
  <li><strong>Voice</strong> - Are there any voice or speech enablement, integrating services with Alex, Siri, Google Home, or other conversational interface?</li>
  <li><strong>Spreadsheets</strong> - What types of spreadsheet integrations, connectors, and publishing solutions are available for a service?</li>
  <li><strong>Investment</strong> - Where do the funds for operating a service come from within a company, from external organizations, or VC funds?</li>
  <li><strong>Monetization</strong> - What does it cost to operate a service, breaking down the one time and recurring costs involved with delivering the service.</li>
  <li><strong>Plans</strong> - Outline of plans involved with defining, measuring, reporting, and quantifying value generated around a service’s operation.</li>
  <li><strong>Partners</strong> - An overview of partner program involved with a service’s operation, and how a wider partner strategy affects a service’s access and consumption.</li>
  <li><strong>Certification</strong> - Are there certification channels available for applications and developers, defining the knowledge required to competently operate and integrate a service.</li>
  <li><strong>Evangelism</strong> - What does internal, public, and partner evangelism efforts and requirements look like for a service, and its overall presence?</li>
  <li><strong>Showcase</strong> - How are developers and applications using a service showcased, and presented to the community, demonstrating the valuable around a service?</li>
  <li><strong>Deprecation</strong> - What are the plans for deprecating a service, involved the road map and communication around the individual and overall deprecation of service(s).</li>
  <li><strong>Training</strong> - What training materials need to be developed, or already exist to support the service.</li>
  <li><strong>Governance</strong> - How are all steps measured, quantified, aggregated, reported upon, and audited as part of a larger quality of service effort for each service.</li>
</ul>

<p>I struggle calling this a lifecycle, as most of these do not occur in any sort of linear fashion. This is why I’m resorting to using the API Transit approach, as it is something that reflects the ever-changing, but also hopefully eventually more consistent nature of delivering microservices. Ideally, every microservice passes through each of these stops in a consistent fashion, making sure that they operate in concert with a larger API platform strategy. However, I know what the reality on the ground is, and know that not all of these relevant to each organization I am talking with, requiring me to trim down and change the order in which I present these.

<p>If you’d like to talk about how these stops apply to your API operations, feel free to reach out. I’m doing more API lifecycle and governance strategy consulting with my partners Streamdata.io, and I’m happy to help your company, organization, institution, or government agency develop your own API transit map, which can be used across your API operations.