# Architecture & Platform Decisions

Canonical page: https://apiopscycles.com/stations/api-platform-architecture

Language: en

Entity ID: api-platform-architecture

## Description

Select the integration architecture, implementation style, platform capabilities, and governance model from evidence.

## Why it matters

Architecture choices should follow from evidence about business impact, locations, trust boundaries, capacity, latency, data ownership, consistency, operability, security, privacy, governance, and cost.

## Apply in work

Compare viable architecture styles against the gathered requirements and document the selected pattern and rationale.

## Outcomes

- A justified integration architecture decision
- Selected style or hybrid and platform decision documented
- Rejected alternatives, risks, assumptions, and supporting evidence recorded

## Steps

1. Compare candidate styles such as API, event, messaging, file, stream, ETL/ELT, data product, direct database, managed connector, point-to-point, custom, shared platform, or hybrid.
2. Evaluate candidates using timing, coupling, data ownership, consistency, reliability, delivery guarantees, replay, latency, volume, security, maintainability, observability, platform fit, cost, governance, vendor dependency, and skills.
3. Record the selected style or hybrid, platform decision, rationale, rejected alternatives, open risks, and assumptions.
4. Use Business Impact, Location, and Capacity evidence only where they are relevant inputs to the decision.

## Questions

- Compare candidate styles such as API, event, messaging, file, stream, ETL/ELT, data product, direct database, managed connector, point-to-point, custom, shared platform, or hybrid.
- Evaluate candidates using timing, coupling, data ownership, consistency, reliability, delivery guarantees, replay, latency, volume, security, maintainability, observability, platform fit, cost, governance, vendor dependency, and skills.
- Record the selected style or hybrid, platform decision, rationale, rejected alternatives, open risks, and assumptions.
- Use Business Impact, Location, and Capacity evidence only where they are relevant inputs to the decision.
- Compare viable architecture styles against the gathered requirements and document the selected pattern and rationale.
- Architecture choices should follow from evidence about business impact, locations, trust boundaries, capacity, latency, data ownership, consistency, operability, security, privacy, governance, and cost.

## Evidence

- architecture-decision
- documentation
- platform-config
- metrics

## Completion criteria

- The capability addresses a clear business need and is reusable by its intended consumers. — The API meets a clear business need and is reusable for multiple API consumers. (ID: api-reusability)
- The selected interface provides an appropriate abstraction for consumers. — The API is intended to shield consumers from backend complexity and inconsistencies. (ID: hide-backend-discrepancies)
- The capability value proposition has been validated with business and consumer stakeholders. — The API value proposition has been reviewed and validated with the relevant business and consumer stakeholders. (ID: value-prop-validated)
- Consumer segments are identified. — API consumer segments (internal and external) are identified. (ID: consumer-segments-identified)
- A high-level implementation roadmap is defined. — High-level roadmaps for API development are established. (ID: api-roadmap-defined)

## Role participation and responsibilities

- [Platform Architect](https://apiopscycles.com/roles/platform-architect.md) (lead): Guides platform, integration, scalability, and architecture decisions that shape how the capability or API is built and operated.; suggested-answer-owner: [Capability Architecture Decision Canvas](https://apiopscycles.com/resources/capability-architecture-decision-canvas.md)
- [API Architect](https://apiopscycles.com/roles/api-architect.md) (core): Owns API architecture, design principles, and interface contract quality.; suggested-answer-owner: [Location Canvas](https://apiopscycles.com/resources/location-canvas.md); suggested-answer-owner: [Capacity Canvas](https://apiopscycles.com/resources/capacity-canvas.md)
- [API Product Owner](https://apiopscycles.com/roles/api-product-owner.md) (core): Drives the API opportunity, prioritization, and product-level decisions across the lifecycle.; suggested-answer-owner: [Business Impact Canvas](https://apiopscycles.com/resources/business-impact-canvas.md)
- [Automation Engineer](https://apiopscycles.com/roles/automation-engineer.md) (core): Implements, tests, integrates, and maintains automation solutions and supporting workflows.
- [Automation Owner](https://apiopscycles.com/roles/automation-owner.md) (core): Owns automation goals, business value, priorities, controls, and lifecycle outcomes.
- [Capability Owner](https://apiopscycles.com/roles/capability-owner.md) (core): Owns the capability vision, value, priorities, lifecycle, and reuse across consumers.
- [Compliance and Legal Specialist](https://apiopscycles.com/roles/compliance-specialist.md) (core): Clarifies legal, privacy, regulatory, and contractual requirements that affect the capability, API, interface, or automation.
- [Domain Expert](https://apiopscycles.com/roles/domain-specialist.md) (core): Brings deep knowledge of the business domain, concepts, rules, and constraints the capability or interface must reflect.
- [Integration Architect](https://apiopscycles.com/roles/integration-architect.md) (core): Designs integration approaches and implementation styles that connect the capability or API with other systems.
- [Platform Owner](https://apiopscycles.com/roles/platform-owner.md) (core): Owns platform capabilities, roadmap, operational model, and service expectations.
- [Security Specialist](https://apiopscycles.com/roles/security-specialist.md) (core): Ensures security risks, controls, and trust boundaries are addressed throughout the API lifecycle.
- [Support and Operations Owner](https://apiopscycles.com/roles/operations-specialist.md) (core): Represents runtime support, incident handling, observability, and operational readiness for the capability, API, or automation.
- [API Consumer Representative](https://apiopscycles.com/roles/api-consumer-specialist.md) (consulted): Represents the needs of developers, integrators, or other API consumers who use the API directly.
- [Business Owner](https://apiopscycles.com/roles/business-owner.md) (consulted): Represents business goals, funding, and expected outcomes for the capability, API, or automation initiative.
- [Delivery Engineer](https://apiopscycles.com/roles/api-engineer.md) (consulted): Owns implementation, automation, testing, and release flow concerns needed to deliver the capability, API, or automation reliably.
- [Process Owner](https://apiopscycles.com/roles/process-owner.md) (consulted): Owns the business process being automated, including objectives, rules, outcomes, and improvement priorities.

## Cycle-specific guidance

- [Capability Productization Cycle](https://apiopscycles.com/cycles/capability-productization-cycle/stations/api-platform-architecture.md)
- [API Productization Cycle](https://apiopscycles.com/cycles/api-productization-cycle/stations/api-platform-architecture.md)
- [Integration Productization Cycle](https://apiopscycles.com/cycles/integration-productization-cycle/stations/api-platform-architecture.md)
- [Automation Cycle](https://apiopscycles.com/cycles/automation-cycle/stations/api-platform-architecture.md)