Skip to main content

Architecture Governance

Purpose​

Architecture governance defines how AI initiatives are reviewed for integrations, infrastructure, reliability, security, observability, and operation.

The goal is not to draw a pretty diagram, but to understand whether the solution can be safely embedded into a real business process and who will be responsible for its operation after launch.

Related section: AI Conveyor architecture.

Core ideas​

  • Architecture is reviewed before launch, not after a prototype. If integrations, environments, and access are not thought through in advance, delivery almost always stalls.
  • The AI product defines a standard architecture. A knowledge assistant, a machine learning model, automation, and a development agent require different checks.
  • The solution must be operationally ready. You need an owner, monitoring, logging, a rollback plan, and an understanding of cost.
  • Integrations matter more than the demo. A prototype may run on a manual export, but adoption requires a stable flow of data and events.
  • Closed environments and sensitive data change the architecture. You cannot choose an architecture separately from the data class and risk.

Where architecture is embedded in the conveyor​

StageArchitectural questionOutcome
Newis there an obvious technological dependencya note on the card or a task to clarify
Assessmentwhich product fits and which systems are affecteda preliminary delivery route
Deliveryhow the solution will be embedded, secured, deployed, and supportedarchitectural sign-off
Awaiting impactdoes the solution work in the target processconfirmation of operation and metrics
Supportwho maintains, how it is monitored and updatedmaintenance mode

Minimum architectural questions​

Before delivery you need to answer:

  • which AI product is used;
  • which systems are data sources;
  • which systems receive the result;
  • where processing takes place;
  • which data passes through the solution;
  • who has access;
  • how the solution scales;
  • what happens on error;
  • how logs are kept;
  • how quality and usage are measured;
  • who maintains the solution after launch;
  • how to perform a rollback.

If the answers are unknown, an initiative may remain in assessment or prototype, but it should not be considered ready for adoption.

Standard architectural patterns​

Knowledge assistant​

Checked:

  • document sources;
  • access rights to documents;
  • knowledge base updates;
  • references to sources in answers;
  • separation of internal and external access;
  • query log;
  • rules for deleting or updating documents.

Machine learning​

Checked:

  • data marts;
  • quality and stability of features;
  • the training and validation process;
  • model versioning;
  • quality monitoring;
  • rollback to a previous version;
  • compute cost.

Process automation​

Checked:

  • the sequence of actions;
  • points of manual confirmation;
  • the rights of the service account;
  • error handling;
  • action log;
  • limits on automatic execution;
  • the ability to stop the chain.

Development agent​

Checked:

  • where the task is formed;
  • which data is passed to an external environment;
  • who accepts the result;
  • how the result is linked to the initiative;
  • what remains in the AI Conveyor: the card, tasks, stages, history, and impact.

Architectural sign-off​

For initiatives with medium and high risk, an architectural sign-off must be recorded.

Minimum structure:

  • a brief description of the solution;
  • affected systems;
  • data sources and consumers;
  • processing environment;
  • access requirements;
  • integrations;
  • monitoring;
  • fault tolerance;
  • rollback plan;
  • constraints;
  • the architect's decision: approve, approve with conditions, return for rework, reject.

The architectural sign-off must be linked to the stage gate before the transition to adoption or awaiting impact.

What blocks adoption​

An initiative should not go into a production environment if:

  • the data processing environment is not defined;
  • there is no clear integration with the source or consumer of the result;
  • there is no operations owner;
  • the rollback plan is not described;
  • there is no monitoring;
  • it is unclear how access will be managed;
  • the solution violates security or data constraints;
  • the operating cost is not estimated for a significant initiative.

The role of the platform​

The platform supports architecture governance through:

  • linking the initiative to a product;
  • product delivery tracks;
  • tasks and accountable owners;
  • artifacts by stage;
  • mandatory fields;
  • checks before a transition;
  • decision history;
  • analytics on initiatives in delivery and awaiting impact.

In a mature setup, each AI product should have its own standard architectural requirements and artifact templates.

Anti-patterns​

Bad architectural practice:

  • a prototype works only on a manual export but is considered almost adopted;
  • there is no operations owner;
  • there is no rollback plan;
  • there are no action logs;
  • access is granted more broadly than necessary;
  • the solution depends on an external service without assessing failure;
  • the architecture does not account for the data class;
  • monitoring appears after the first incident.

Good architectural practice makes adoption boring: it is clear where the solution runs, who supports it, how to observe it, and how to stop it safely.