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.

‍

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.

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.

‍