Minimum Viable API Architecture

Get Started

With a good interface the API consumers do not know what technology is used to build the API. Nor do they need to know what the provider's internal data model looks like. Building APIs involves designing simple and useful data and interaction models. Use design style guides and standards like OpenAPI where possible.

Minimum Viable API Architecture

Each API has its own set of non-functional requirements. These often cost the most to fix later while being easy to handle in the first design phases. Traditional approaches concentrate on the project or solution level - not single API. The idea is to use the Minimum Viable Architecture approach so we design and build only as robust architecture as we need right now so we can optimize the work, schedule, complexity, and cost

1

Assess business impact

What happens to the business if the API is unavailable? What if there is a data breach or incorrect data or functionality? Does someone die, or is it only a PR disaster? How you can mitigate the risk?

Have you already found the right value proposition and initial business model in the previous phase of APIOps Cycles?

Traditionally, you do a risk analysis for a project or a system. Since we live in a distributed and connected world, every API counts. Big solutions use many APIs to serve customers.


Minimum Viable API ArchitectureAssessing Business Impact
2

Consider locations of data and systems

Where is the data stored? What regulations impact the data and features of the API? Are the API consumers located far from the API provider? Are the networks connected and secure?

Use the Locations of data and systems canvas to discover more non-functional requirements. Discover legal and geopolitical requirements and considerations. Investigate the integration architecture and network requirements.

Minimum Viable API ArchitectureLocations of Data and Systems
3

Calculate capacity

How much will the API be used? What should be the rate limit for API consumers? Or should we measure how much data is transferred? How much can our API gateway handle?

Scaling API infrastructure up or down fast is not always easy or cheap, even in a cloud environment.

Discussing with the business helps. Ask how many business transactions are estimated to happen in the next 1-12 months. How many packages are sent to customers or money transfers made?  Use the Capacity canvas to plan for single API or API gateway capacity needs.


Minimum Viable API ArchitectureCalculating Capacity

The Phases

Minimum Viable API Architecture consists of Prototyping, Build Just Enough and Scaling -phase

Prototype

Use when building a new API

  • Do not code, create only executable definitions (like OpenAPI).
  • Make it easy to change plans with just a simple text file or definition edit instead of code change
  • Collect the requirements but concentrate on information architecture and interface design, unless you are just starting with an API program in your organization or considering implementing an API management solution. In these cases, go through the Business Impact, Capacity, and Network and location requirement canvases first.
  • Add only the endpoints and fields you absolutely are sure that are needed for the first consumers. If there is no clear answer to whether something should be added, leave it out. It’s better for versioning, no one will start using it and depending on it and changes are kept to a minimum later.
  • Design with the API Audit criteria in mind, using a style guide as your guideline.

Build Just Enough

Use when building a new API for few consumers

  • Nothing is built “Just in Case”
  • Use only components you know and have easy access. Stick to familiar architecture. When risks are small designs don’t have to be heavy and perfect.
  • Customer needs can evolve while building, with an as small budget as possible
  • Meet customer need in a few hours or days, not in months.
  • Do NOT think about scaling.

Scale

Use when existing API has growing number of consumers

  • Any peak times coming in near future?
  • Are the non-functional requirements changing, for example, allowed downtime? Response times? New users from far away?
  • Growing concurrency brings new bottlenecks to the architecture, load test first and monitor existing production, design improvements after that.
  • Growing number of APIs need more teams and team members.
  • API management needs to have more fine-grained user roles and separation.
  • APIs and micro-services need more decoupled modules that can be scaled and developed independently.
  • API design and information architecture need to be designed from the scalability point of view. For example, different customer segments or customers from different countries require different API features.
  • Think about separation, not centralization all through, even in databases and Identity management, authorization and access management.
  • Start with a load balancer and 1 run-time node, this way more nodes can be added easily.
  • Consider when and how to do caching, fail-saves etc. but don’t implement them before they are actually needed, just know you can.

Assessing Business Impact

What is the Minimum Viable Architecture?

Why is the MVA architecture chosen for this method


The MVA (Minimum Viable Architecture) approach is usable for any architecture design process.


Each Phase of MVAA goes through the entire APIOps Cycle. Development from here on goes in cycles and is iterative.

One of the key elements in Agile methodologies is Minimum Viable Product. MVP is a product with "just enough" features to satisfy early customers.

When they see and can try the MVP, they can give feedback for future development. Minimum Viable Architecture has a similar idea.

Designing architecture so they can be prototyped and built fast. The sooner the consumers get to use the API the faster you discover the real requirements.


Scaling -phase in more detail

  1. Any peak times coming in near future?
  2. Are the non-functional requirements changing, for example, allowed downtime? Response times? New users from far away?
  3. Growing concurrency brings new bottlenecks to the architecture, load test first and monitor existing production, design improvements after that.
  4. Growing number of APIs need more teams and team members.
  5. API management needs to have more fine-grained user roles and separation.
  6. APIs and micro-services need more decoupled modules that can be scaled and developed independently.
  7. API design and information architecture need to be designed from the scalability point of view. For example, different customer segments or customers from different countries require different API features.
  8. Think about separation, not centralization all through, even in databases and Identity management, authorization and access management.
  9. Start with a load balancer and 1 run-time node, this way more nodes can be added easily.
  10. Consider when and how to do caching, fail-saves etc. but don’t implement them before they are actually needed, just know you can.

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.