archigov · docs
  1. Docs
  2. Tutorials

Governance at Every Level

One board decides each review. Boards can sit at four levels — enterprise, domain, delivery and team — and routing sends each review to the right one. Choose the levels your organisation needs.

#One Board Decides Each Review

Every review in Archigov goes to one board, and that board's chair declares the outcome. You choose where boards sit. A small organisation runs everything through its Design Authority. A larger one adds boards at the levels where decisions are actually made, and keeps the Design Authority for what crosses them.

LevelExampleWhat it decidesA typical policySince
EnterpriseDesign Authority, Policy & Compliance BoardEverything no other board claims; standards and policiesPositions per area of responsibility; sessions0.2
DomainData & AI BoardDecisions on its topics; catalogue items in its categoriesPositions from its own area owners0.2
DeliveryEngineering BoardDesign reviews for systems no team board coversOne approval and the fast lane; refers up the rest0.2
TeamClinical Systems BoardDesigns, decisions and exceptions for the applications the team ownsOne approval and the fast lane0.3
The Boards list with a board at each level
Governance → Boards in the demo after these tutorials: the Design Authority and the Policy & Compliance Board, a Data & AI domain board, an Engineering delivery board and a Clinical Systems team board.

#How a Review Finds Its Board

When a review is created, routing rules choose its board. Each rule names a review type, and may also name:

  • a category: a decision's topic, or a catalogue item's category;
  • a kind of catalogue item;
  • the applications it covers: those listed, or every application whose resources carry an owner tag.

The most specific matching rule wins. Applications count for more than a kind, and a kind for more than a category. Priority breaks a tie, lowest number first. A review no rule matches goes to the Design Authority.

In the demo, after these tutorials:

A review for…Goes toBecause
A design for AppointmentsClinical Systems BoardAppointments' resources carry the owner tag clinical-systems
A data-store decision for PatientFlowClinical Systems BoardThe team's rule names its applications, which outweighs the Data & AI topic
A data-store decision for Data PlatformData & AI BoardNo team claims Data Platform; the topic rule matches
A design for IntranetEngineering BoardNo team claims Intranet; the Engineering Board's design rule beats the Design Authority's on priority
A hosting decision for Finance ERPDesign AuthorityNo other rule matches
A policyPolicy & Compliance BoardIts rule for the policy type

The submission form shows where a review will go before you submit it: Will be reviewed by ….

#When Something Belongs Higher Up

A board's chair can refer a review to another board, with a reason. The review moves, the positions recorded so far are superseded, and its areas are derived again for the new board. Referral is how a delivery or team board hands up what goes beyond its remit.

Other groups can contribute to a decision without deciding it:

  • areas of responsibility, so each specialist records a position;
  • requested assessments, such as a security assessment from the CISO's team;
  • dependent decisions, so an item is approved pending another board's decision.

#The Tutorials

  1. Run your Design Authority: the enterprise level, which the demo already has.
  2. Add a domain board: data-store and AI decisions go to a Data & AI board.
  3. Give engineering a board for designs: one approval, the fast lane, and referral up.
  4. Give each team its own board: routing by application.

Each one works on the demo tenant, so you can follow it on a fresh instance. Creating a board needs the platform admin. Setting its routing needs the board's chair or secretary, or the platform admin.