Organizations of all sizes are scaling their API efforts as a method to deliver all things digital. But as APIs proliferate, there are growing pressures which mean that many of us are starting to outgrow traditional API management offerings.

The answer? Shifting left in mindset, process, and tooling to create a cohesive, accelerated framework that enables technical and business folk alike to deliver on the tangible promises of API-first.

Pressures Associated With APIs at Scale

As APIs continue to become more ubiquitous as a method to deliver all things digital, organizations are under growing pressure to:

1. Manage increasing API sprawl and complexity. Developers are constantly increasing the numbers and types of APIs across platforms and gateways, versions, dependencies, and changes. All this needs to be effectively managed, with visibility, discovery, and reuse enabled to reduce redundancy and wasted effort.
2. Expand the audience of their APIs to business users (e.g., digital product owners). Business and Leadership are being sold the API dream, and they are starting to want in. This is great for driving collaborative innovation, a product mindset, and ultimately differentiated digital experiences and happy customers. But, we can’t expect them to all learn to code!
3. Properly secure APIs to prevent data breaches. Salt Security reported a 681% in API attacks over the last 12 months in their latest API security report. And there are hefty fines for data breaches, especially in heavily regulated industries. API security strategy is more important than ever.
4. Introduce more consistency and better quality in API design and development. API reliability, predictability, and compliance to governance standards are key for a best-of-breed consumer/developer experience, as we all know. But, this is increasingly hard to ensure if developers are manually aligning their APIs to an API style guide or using basic governance checking tools. And consistency and quality aren’t just important for your internal and external ecosystem consumers — there’s a regulatory aspect for industries like banking.
5. Deliver tangible value for the promises of API-first. AKA: an investments and priorities approach. Business capabilities should be reliably exposed in whichever format the consumer wants. This involves evolving toward a composable enterprise model, reducing time and cost to market, and increasing customer retention and growth.

Enterprises Are Balancing a Fracture

While these pressures have been building, there’s been a push to let developers develop with the idea that an API will be a throwaway — the build-fast, project-driven approach. But we all know where this leads — inconsistency, reduced security, unknown impact of changes with increasing consumption, redundancy, and duplication are challenges most API developers face.

At the same time, there’s another push to align Business Architects to a capability model and product owners to a product into the process — the drive investments and priorities approach. But it is hard to throw things away in the enterprise, increasing the complexity of support when something breaks.

Solution: Shift Left

To resolve the fracture and deliver on these API-enabled pressures, it’s time to shift left as you outgrow traditional API management offerings. Gartner predicts that by 2025, less than 50% of APIs will be managed, as exponential growth surpasses the capabilities of traditional API management platforms.

Now, this isn’t an article designed to bash API management platforms — they’re great for what they are — an effective way to run and monitor APIs. But they have their limitations for API-first at scale, and many organizations are outgrowing them. You might be doing so, too, if you have multiple gateways and platforms across regions and teams, APIs coded to specific platforms, and no single source of truth for what’s out there.

The answer? We need to shift left to one location to capture, manage, discover, record relationships and dependencies, and reuse all our APIs — both in-flight and in production. And, we need to shift left to focus on how the APIs are planned, designed, governed, secured, built, updated, and bundled while maintaining focus on where they’re run.

But What Does Shift Left Actually Mean?

Shifting left is a well-known concept in the API testing and security realms. It involves trying to catch issues earlier in the process before they become a problem. But it can be applied to overall API strategy and programs for full effect.

It’s shifting left in mindset, processes, and tooling, upstream of CI/CD pipelines and the runtime. Think firmly in design-time but still loosely coupled to runtime for one cohesive, accelerated framework. Critically, shifting left can’t mean more work for developers! That’s where things like automation and empowerment over enforcement can help.

Benefits of Shifting Left With Your API Strategy

Shifting left of traditional API management helps:

• Create a single source of truth to capture API sprawl and complexity. Capturing all APIs left of their gateways helps you gain an accurate picture of what you already have. This can also help capture communication patterns beyond REST APIs, such as legacy SOAP services, asynchronous event-driven protocols, message rails, etc. Shifting left can mean one holistic catalog.
• Create a view of APIs that non-technical roles can interact with (without learning code!). Again, by working upstream of runtime, you can create abstracted “business view” designs of your APIs. Think code and implementation-agnostic abstractions of the APIs functions, along with key metadata your users need to know to understand and work with the API.
• Ensure security and governance by default before problems arise and without creating bottlenecks. Shifting left helps automate API governance rules by checking security policy conformance upfront, avoiding a manual review process once the API has been created. So, you can design and develop fast without compromising safety and quality! Empowerment over enforcement for developers, just like we discussed before.
• Deliver the promises of API-first. Shifting left in mindset, processes, and tooling for your API program helps your entire organization view APIs as interfaces to business capabilities, not applications and backend systems. Ultimately, evolve our API program into a mature, business-led approach, and reap the rewards and competitive advantage as a digital leader!

Next Steps for Shifting Left

To leave you with some thought starters for how to shift left in practice, here are two questions:

1. Are there any gaps in your reference architecture and tooling to support this shift where collaboration is lacking, where the impacts of change are being missed, or where complexity is unknown?

Many existing tech stacks have focused on the build-fast approach. These organizations often have a gap just left of CI/CD to link their domain-driven-design efforts with a reusable catalog of all APIs and the lifecycle to create new, update, extend or bundle.

2. How will you keep everything active and in sync?

Design and runtime must be connected — otherwise, your single location to shift left from becomes immediately outdated and will lack adoption. The goal is to integrate everything in your framework to “link and sync” automatically, so you’re not relying on support teams to consistently manage and update your design time so it’s accurate.