Learn & improve

Get Started

API Canvases help your architects, solution owners, product managers and business analysts answer these and many other questions: Which APIs are missing, which APIs will bring the most value? Who are your API consumers? What are the benefits and costs?

Learn & improve

The goal of Lean is to improve so-called cycle time and quality. With Lean API Development and APIOps Cycles, it means you can make good APIs in a short time. And not just good, but better for business.

1

Improve APIs

How efficient is the API for API consumers? How good is the quality of APIs?

Review the qualitative and quantitative data. Organize improvement and innovation walkthroughs to find bottlenecks. Make sure your API management and API adoption tools and strategies are in place.

Start with small, for example auditing the current APIs or API designs (see API Audit phase). After audit, adopt the APIOps Cycles method at least to improve the areas that need it the most.

Learn & improve
2

Improve API development and consumption

How efficient is the API development process for the development teams and organization?  Are creating or consuming APIs making the organization feel better and more innovative or worse?

Create an innovative culture and a supporting operating model. Invest in organization’s as well as customers’ and partners’ skills. Operating models and API consumer experience should be the key areas to concentrate on.

Use APIOps Cycles to clarify roles and processes and as a common language and collaboration model.

Learn & improve
3

Improve connection between APIs and strategy

Do APIs help with the strategic goals? Is the business growing? Are there more satisfied partners and/or customers? Are the compliance, sustainability or other requirements and goals being met? Is the API related budgeting supporting teaching strategic goals?

Align business strategy with API strategy and plan how that should affect the other areas such as API consumer experience, API management and adoption and operating model.

Use APIOps Cycles to create clear message between the value, segments, benefits (revenue and others) and costs associated with APIs and business strategy. Measure business value and make the data transparent.

Learn & improve

In Prototyping phase, the API Consumers are different when the API is in production. Learning can be achieved by gathering feedback or by interviewing API consumers and studying the analytics reports. In building just enough phase you'll learn what works, really. And in scaling phase you learn to remove bottleneck

If you are already a pro with the method, continue to improve and start the next cycle.

The Cycle

Great APIs are born when skilled people work collaboratively using a great business model.

Jump start implementing APIs by picking up any of the eight phases befitting you

  1. Business model. Use API Canvases. Find the right value proposition to your API. Define impact to business model.
  2. Lean Architecture. Follow the Minimum Viable API Architecture process.
  3. Build API. Prototype, build or scale depending on what architecture phase you are on.
  4. Audit your API. Use the checklists to verify your API meets style, API management and security needs.
  5. Publish the API.
  6. Mind the Developer Experience: Support and build developer community.
  7. Measure business and technical KPIs to reach goals.
  8. Learn from the results and improve your API and the process.

API Management key concepts and roles

API business models

API based business models are the core and starting point of of this method, together with value proposition. Business models are important, so the true purpose and customer segments for the API are found early. This not only helps transform business to new data and platform business models, but it helps to focus the development and secure customer buy-in and budget.

Value proposition

The value proposition describes the value that the customer/user of a specific product or service feels they receive as the result of using the product or service. APIs are products and just like in all products, users will need a good reason (=value proposition) to decide to use it (=conversion).

You will use the API Value proposition canvas to work out the possible contents of the value proposition. When writing the value proposition down to the API business model canvas, you need to make sure it answers these questions:

  • How API Product in question solves problems or improves the situation for the selected API consumers?
  • What specific benefits are there to use this particular API instead of other integration methods for the selected API consumers?

And then when building the API business model, you should also consider

  • Why external partners or customers should use our API instead of competitors’? (think about this if you are offering the API to external parties)

API Product manager (or product owner)

Traditional product managers are commercially and analytically oriented persons who rely on tools like market research and user studies, work with sales, marketing, and other stakeholders to create a product that will sell. In Agile development, product owner has typically less commercial responsibilities but is still a customer/stakeholder advocate and prioritizes items in the backlog according to the value they bring to the customers.

The technical nature of APIs as products requires API Product owners to translate the value proposition into technical capabilities and the technical capabilities into business terms.

Customers of API Product owners are software and technology developers, but also business developers of customers and partners. API Product owner needs to understand the specific nature and needs of these user groups. They also need to translate these into capabilities that his own team of backend developers understand and can actually build.

One major task of API Product Manager is to explain and mitigate the risks and values of opening their company’s data and value propositions to the world as a platform and also figure out how to build customer value from networks of other companies and their API using or offering products.

API Product managers require great communication, business and technical skills.

Application service manager

CRM application serves as an (indirect or direct) backend for specific APIs. Any changes to the CRM or any service breaks may affect the APIs depending on it and the API consuming applications. Any needs to add or make changes to the dependent APIs may require changes in the application serving as a backend. If requirements come from other teams or external partners and customers, funding and priority have to be negotiated. Service manager needs to do release plans, change requests and service break down notifications minding the APIs and API consumers. Requirements depend on architecture and dependency of the API layer.

Information architect

Responsible for designing how requirements need to be split into independent APIs, endpoints and attributes and how to negotiate requirements between payload sizes, privacy and confidentiality requirements, local legal requirements and business processes. In charge of making sure the naming standards and values are valid also outside the company data architecture and naming conventions. Ideally creates guidelines for API publishing developers and conducts reviews.

Developer segments

Developers are our API consumers, but also your potential paying customers, sales channel, outsourcing partners or innovation partners. Each segment has its reasons why we are interested in them, and they are interested in us, as well as their own unique needs, behaviours and logic.

Typical developer segments regarding APIs are

  • Business developers (selling or developing new business models, products and services that use our APIs)
  • Software developers (software applications using APIs)
  • Technology developers (devices using APIs)

It may be useful to split the segments even more, to internal developers and external developers or according to the product or platform segment or their interface expectation or their knowledge and skills about our company, our products or using APIs in general.

User groups

Depending on what kind of API management solution or product you use, there may be different names for specific default user groups, and usually, all management products allow creating company-specific user groups. Typically, users related to APIs are divided into these high-level groups

  • Guest users or unauthenticated users, who can see available APIs but are not able to make API calls
  • API consuming developers
  • API publishing developers
  • API management platform administrators (users who can administrate network settings, API publishing user accounts, overall security settings, etc.).

In big companies, these user groups need almost always to be separated into smaller user groups, as not all consumers are allowed to use all APIs (private or partner APIs) and not all teams of API providing developers can even see, know or administrate all APIs.

APIOps Cycles

method for lean api development

Great APIs need skilled people and a good method, which let's you create APIs as products - fast.
APIOps Cycles method is vendor & technology-neutral.

Read the free e-book "The 8 wastes of lean in API development". Learn quick tips on how to remove the wastes using the APIOps Cycles method.