Skip to main content

Architecture review

Purpose​

The architecture review records whether the solution can be safely embedded into the workflow: which systems are affected, where data is processed, how the solution is observed, who supports it, and how to stop it in case of a problem.

The review is required before moving an initiative from delivery to awaiting impact, especially if the solution works with sensitive data or affects customers, money, risk, legally significant actions, or critical operations.

Document structure​

Integration architecture​

  • Diagram of how the solution interacts with target systems.
  • Data sources and consumers of the result.
  • Integration method: requests, queues, files, events, manual input.
  • Input and output data contracts.
  • Dependencies on external systems and services.

Data flows​

  • Data movement diagram: sources → preprocessing → model → result → target system.
  • Data refresh frequency.
  • Data transformations at each stage.
  • Storage of intermediate and final results.
  • Deletion, archiving, and retention period.

Security and compliance​

  • Classification of processed data (personal data, trade secrets, banking secrets).
  • Encryption of data at rest and in transit.
  • Access control: authentication, authorization, role model.
  • Compliance with internal policies and regulatory requirements.
  • Log of access to the solution and user actions.
  • Restrictions on the use of external services.

Infrastructure requirements​

  • Compute resources: processor, GPU, memory, storage.
  • Runtime environment: servers, containers, cloud or closed perimeter.
  • Network requirements: latency, throughput, access zones.
  • Estimate of operating cost.

Monitoring and observability​

  • Solution quality metrics.
  • Technical metrics: latency, errors, availability, cost.
  • Business metrics: tracking of target indicators.
  • Alerts: thresholds, notification channels, escalation.
  • Logging: requests, responses, actions, errors.
  • Dashboards for the team and the business owner.

Scalability​

  • Current load and growth forecast (requests/sec, data volume).
  • Horizontal and vertical scaling.
  • Limits, quotas, and usage restrictions.

Fault tolerance​

  • Behavior when the model, data source, or external service is unavailable.
  • Component redundancy.
  • Target availability and response-time indicators.
  • Recovery procedure in case of failure.

Rollback plan​

  • Rollback strategy: disabling the feature, reverting to a previous version, manual process.
  • Rollback criteria.
  • Rollback time and procedure.
  • Those responsible for the rollback decision.

Operating model​

  • Who owns the solution after launch.
  • Who responds to incidents.
  • Who updates data, rules, prompts, or the model.
  • How often reviews are conducted.
  • Which changes require a new stage gate.

Final decision​

One of the following decisions:

  • approve for deployment — there are no blockers;
  • approve with conditions — there are restrictions and tasks to complete before launch;
  • return for rework — architectural risks are not closed;
  • reject the current approach — the solution cannot be safely deployed in the chosen architecture.

Use in the process​

The architecture review is prepared by the architect together with the delivery team, the product owner, infrastructure, security, and the data owner.

Identified discrepancies are recorded as tasks or blockers for the transition to awaiting impact.

The target architecture is described in system architecture. The approach to architectural management is described in architecture governance.