data_object
Doing the API work
Ensure APIs integrate seamlessly with the infrastructure and platform, adhering to architecture guidelines and API product-specific requirements.
code_blocks
API Platform Architecture
login
Entry criteria
- The API meets a clear business need and is reusable for multiple API-consumers.
- API consumer onboarding is planned and smooth.
- Insights into developer needs exist.
- Feedback is gathered from the identified API consumer segments.
- Features are updated and ready to be addressed with documentation, architecture, and design.
logout
Exit criteria
- The API uses architecture patterns promoting reusability for multiple API-consumers.
- The architecture ensures the APIs will integrate seamlessly with the infrastructure and platforms.
- Architecture requirements and decisions have been documented and validated with stakeholders.
- API is designed to meet API consumer needs hiding backend data models and discrepancies.
- The API and its endpoints have a description that explains its business value and features.
- API has a consistent design with our other API products.
settings
Enabling the API work
- Establish scalable, secure, and compliant infrastructure for API operations. Provide guidelines on architecture best practices.
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
- 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.
