This week on the API Intersection podcast, we interviewed Daniel Kocot, Head of API Experience and Operations at Codecentric AG. Codecentric AG is a leader in agile software development and innovative technologies in Germany.
Daniel’s job is to get his customers to answer the question, “Why are we thinking in APIs?” He aims to get them to shift their mindset to specialized tools, treating your APIs as products and understanding the end goal that one’s trying to achieve with the desire to design a bunch of APIs.
Specialized Vs. Full-Lifecycle Tools
Daniel’s initial focus with his customers is to steer them away from being too focused on “all-in-one” solutions for all of their API needs. Often, organizations focus on finding one solution simply because industry analysts often prescribe shopping for a sole provider to cover the entire API lifecycle, and that often doesn’t match practitioners’ real needs. Daniel puts focus on understanding what full lifecycle API management means, which should make it obvious that there isn’t a single solution that can do everything.
“There are so many niches and best-in-class options throughout the lifecycle; you don’t want a software monolith or something like that would cover all the needs we have because, again, there is no real option that checks all boxes,” shares Daniel.
Instead, Daniel emphasizes that one should find the tools that work best for what you’re trying to do and the skillsets your developers already have.
“Let’s take Stoplight Studio, for example, which helps many people to really understand how to build an API with this form editor type of thing that we use. Some of the customers we work with at the moment are not able to write OpenAPI directly or YAML or JSON. So, there is a need to have this editor just to plop things there and develop things over time. We’re not dependent on having Stoplight Studio have specific models; we want a reliable design tool to meet developers where they’re at,” shares Daniel.
I actually recently wrote a piece on the full lifecycle management approach, emphasizing that the sole provider guidance in the market today is unrealistic. Stoplight is no different: we don’t do everything, but we get the design part right! Sometimes, a specialized platform for the given phase of the API lifecycle is the answer over a one-size-fits-all monolith.
The Mindset Shift: Viewing APIs as Products
“When building APIs, it’s all about a mindset shift on what’s core and important. You can apply anything to any product, but treat your API platform as a big product, and the individual APIs are a sort of sub-product that should fit into a bigger picture,” shares Daniel.
The next piece of advice Daniel shared with us focused on shifting his customers’ thinking regarding API design. The focus should be on the use case and the ability to reuse parts of that API in back-to-back projects each time you build something.
Addressing reusability in the initial API design phase promises to speed up delivery (by avoiding costly rework) and scale quicker (by avoiding duplicate efforts). Keep in mind that it will take time and dedicated focus to build that velocity in the API Product Management discipline and to build a larger vision for what your platform will be. All of this aligns with the APIs-as-a-product strategy that we touch on time and time again.
“There’s no real blueprint for the strategy kind of thing because it really depends on the needs of your business and customers, and we really have to look at use cases. I always use a mind map to really make sure that I don’t miss a thing when building out the API strategies and integration opportunities. And it’s important to note that even with very different industries, use cases can be more similar than you think!” shares Daniel.
For example, here at Stoplight, some of our biggest customers produce things like beer and electrical parts, and yet there’s so much in common strategically in terms of what their customers need from their APIs and what integrations each customer provides.
What Metrics and Results Matter?
Lastly, Daniel works with his customers to understand how they intend to measure the success of their API design. We recently covered API metrics in a deep dive you should also check out.
In order to build appropriate success measures, don’t focus on the API itself as a result. evaluate the product or capability provided to customers. Without a clear understanding of that product portfolio, there will be a tendency toward API technical or operational measures, which rarely connect to business value.
Alignment on broad success measures is smart to address early, but deciding on detailed measures, metrics, and monetization should come well after initial API design work. Daniel stresses that developers should focus their energy on more customer-centric design than metrics initially. Once you have iterated to a more complete understanding reflected in the design, the specific numbers should be easier to decide.
“Normally, the easiest KPI in API projects to look at is the number of APIs you made or API calls, but you should also be looking at the value of them, not just the quantity,” shares Daniel
When you finally DO get to the metrics and KPIs of your API, though, Daniel focuses on the ‘time to first hello world.’ This means he looks at how long it takes to make a successful API call.
I appreciate Daniel coming on the show and sharing his perspective, and we can all work together on zeroing in on the APIs as a Product mindset! For more insights from industry leaders, check out the API Intersection podcast.
