This week on the API Intersection podcast, we interviewed Marjukka Niinioja, a co-founder of Osango, an organization that specializes in API business consulting, including architectural work, information architecture auditing, API business models, and ecosystem design. The Osango team works with companies that specialize in designing IoT platforms. Marjukka focuses on teaching and consulting about APIs, AI and platform economy, and digital services.
As the queen of the APIOps Cycles method, Marjukka shared with us a glimpse into the world of the APIOps and tips from it that we could apply to our own API development. This approach is a methodology that guides people through creating and managing APIs, combining different business methodologies like product management, lean, and design thinking. By focusing on the right things, this method eliminates the eight wastes of lean management and reduces the lifetime costs of their APIs.
Create an API Canvas
One part of the APIOPs Cycle Method that helps developers be successful is this idea of API Canvases to help your architects, product managers, and business stakeholders answer all necessary questions.
The API value proposition canvas reveals the “product-market fit” of your API, exposing the features that will deliver value to your consumers. Some of these questions you can ask yourself when creating this canvas could be, ‘Which APIs are missing? Which APIs will bring the most value? Who are your API consumers, and what are the benefits and costs?’
Conduct Regular API Audits
Another component of this method is an API Audit phase that seeks to confirm whether your team’s API designs comply with guidelines (again, standardization and consistency are key). An API audit can consist of checklists or style guidelines if you have those implemented. For example, Stoplight users on Pro and above plans can enjoy public style guide templates already built into their API design Workspace. Others can also utilize our open-source tool, Spectral, to help with some of this consistency creation.
These checklists and audits often will ensure that business requirements, developer experience, standards, functionality, and security measures are all met within your API design.
Standardizing Verbiage and Breaking Down Silos
Speaking of style guides, standardization is a must. While the APIOPs Cycle method can avert many challenges, Marjukka shared that there can still be communications challenges that come up from time to time that can be fixed with standardization. When incorporating team members from different specialty areas, sometimes different teams will have unique ways of referencing words within the API development process. Each team member may have a slightly different way of defining, describing, and understanding various terms, which can lead to confusion and decreased productivity for API teams. Standardizing on terminology and naming conventions can help ease the internal developer experience overall.
“Whether it’s taxonomy, a glossary, or whatever vocabulary discussion or domain models you’re using, you can and should standardize it. But it’s only one part; you don’t want to have to go into heavy detail to describe the thing you need from another team. It’s like ordering a cup of coffee, you want the coffee shop barista to know what that order entails, and we want that same experience for our APIs,” shares Marjukka.
And on top of that–when it comes to external terminology, whenever possible–using customer language and having a customer-centric view of API development can help organizations avoid confusing their customers with unfamiliar technical terms.
Break Down Silos and Avoid Information Compartmentalizing
“Consider your business strategy and the value proposition of the API before development. Often, people list the APIs that they think should be built without considering their value proposition, which can get you into trouble,” shares Marjukka.
Marjukka stresses the importance of reducing information compartmentalization, breaking down departmental silos within your API team, and exposing your API business strategy early on amongst your internal stakeholders to avoid issues down the line. You can accomplish this by deciding how to structure your API team early. Here are a few structures to consider:
- Centralized- Keeping all stakeholders aligned and together in one place during the API development
- Embedded- Contrary to centralized, there is embedded; this method involves cross-functional teams working on the same project. Designers will work alongside other business units side by side to get the job done as opposed to working in silos with their respective teams.
- Flexible – A flexible structure will allow you to pivot and obtain external resources. Flexibility allows for adaptable execution to accomplish desired business outcomes.
One reason the APIOPs Cycle method is so successful is that it’s a highly collaborative method inclusive of all stakeholders, including people who are not traditionally into software development and APIs (sounds similar to the design-first approach we tout here at Stoplight, no?).
Overall, the goal of the APIOps Cycle method is to utilize the Lean approach and improve cycle time and quality, allowing teams to build great APIs in a short time. You can check out Marjukka’s work around this here. For more insights from industry leaders, check out the API Intersection podcast.
