If you are sitting there thinking that you could modernize and evolve legacy systems and processes used as part of API operations by introducing a new service or tool, API Evangelist always encourages you to first spend the time mapping as much of the existing service and tooling landscape as you can before taking your first step. What are the services and tools that are currently being used by teams and already are baked into the enterprise and existing teams regular work. It doesn’t need to be exhaustive, but take the time to inventory from the following areas of your API operations.
Pick a handful of relevant areas from this list: automation, changes., command line interface., clients, code, dashboards, design, discovery, engagement, explorers, gateways, governance. Integrated development environments. logging. monetization. monitoring, observability, pipelines, proxies, sandboxes, security, source control, specifications, testing, traceability, workspaces.
Get to work gathering and producing APIs.json, OpenAPI, and JSON Schema artifacts for the services and tools you are already using across these areas. Then consider how you can better tag and organize these artifacts, and even consider producing Arazzo specifications for some of the most common or relevant workflows teams may already be performing. This is your low-hanging fruit for maximizing the infrastructure you are already using beneath API operations. This is your existing API platform. Before you take that first step to introduce yet another tool or service into this mix, take the time to understand where it fits in with the rest of your existing operations. Then see if there is another automation or workflow you could introduce using existing APIs, CLIs, and business processes. This is where the opportunity lies with making the greatest impact on your API operations without having to do the heavy lifting of bringing in yet another service or tool, leveraging existing infrastructure to have the impact you are envisioning.
