API Platform Architecture
Get StartedThe API Design station is where you refine your API concept into actionable, detailed design specifications. This phase builds upon the insights from API Product Strategy and API Consumer Experience stations, incorporating the foundational architecture and requirements. Whether you're designing a new API or redesigning an existing one, this phase ensures the API meets functional, non-functional, and consumer needs. API Design is about balancing usability, functionality, and performance while aligning with existing platform constraints. This is also where consumer feedback is integrated into the technical blueprint for a seamless handoff to development.
API Platform Architecture
The API Platform Architecture station focuses on ensuring that your API fits seamlessly into your existing platform architecture or establishes clear requirements to guide necessary architectural changes. It balances the core needs of API producers, API consumers, and broader organizational goals, providing a foundation for scalability, security, and performance. By the time you reach this station, you should have already: Defined the API Value Proposition and Business Model in the API Product Strategy station. Understood your API Consumer Needs in the API Consumer Experience station. This station takes the insights from those prior steps and applies them to your platform architecture, ensuring your API is built on a robust, future-proof technical foundation.
Evaluate the Existing Platform or Environment
Assess how well your current platform architecture supports the API’s functional and non-functional requirements.
Key focus areas:
- Data and Systems: Are the necessary systems and data already integrated into the platform? If not, what gaps exist?
- Regulatory Compliance: Are there geographic or industry-specific rules (e.g., GDPR, HIPAA)?
Use the Locations of Data and Systems Canvas to map where API producers and consumers interact across networks and regions.
Locations of Data and SystemsDefine Capacity Requirements for the API
From the API Value Proposition and API Consumer Needs, any existing traffic patterns, and also the business knowledge of customer behavior trends to identify specific platform requirements, such as:some text
- Performance: Can the platform handle the expected load (including peak traffic)?
- Scalability: What peak loads or transaction rates should the platform support?
- Latency: What are the tolerable delays for API consumers?
Use the Capacity Canvas to project the API’s transaction patterns and infrastructure needs.
Calculating CapacityAssess Risks and Mitigation
Prioritize potential risks based on business impact:some text
- Availability risks: What happens if the API goes down?
- Security risks: What are the consequences of unauthorized access or data breaches?
- Functionality risks: What if the API delivers incorrect or outdated data?
Use the Business Impact Canvas to document risks, impacts, and mitigation strategies, ensuring alignment with organizational risk tolerance and budgets.
Assessing Business ImpactWhat 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.
