Definition
An ARIS repository governance model defines how draft models become approved truth, how reusable objects are curated, and how quality is measured—so the repository stays consistent, auditable, and scalable across regions and teams.
- Use **3 zones**: Working (draft), Library (curated objects), Approved (read-only truth).
- Make publishing a workflow with approvals and version logs.
- Measure repository health: duplicates, timeliness, completeness, consistency.
- Define who is allowed to curate library objects (and how consolidation happens).
The 3-zone structure: Working → Library → Approved
This structure solves two systemic problems: accidental change and object duplication.
Zone 1: Working (Draft / Projects)
- Editable space for project teams
- Variants allowed, experimentation encouraged
- Clear expectation: not official
Zone 2: Library (Curated objects)
- Reusable objects: functions, systems, roles, controls, data entities
- Curated by a small admin/curation group
- Consolidation happens here (dedup/merge patterns)
Zone 3: Approved (Read-only truth)
- Published models only
- Read-only for most users
- Changes only via publish workflow
If you only implement one governance concept, implement this.
Governance shortcut
If your ARIS database mixes drafts and approved models, no amount of conventions will stop drift. Separate zones first, then enforce standards.
A publish workflow teams will actually follow
A publish workflow is not a policy. It’s a path of least resistance.
A simple workflow:
- Draft model created in Working
- Review checklist (naming, lanes, gateway usage, metadata completeness)
- Control impact check (if regulated ops)
- Approval by model owner + reviewer
- Publish to Approved with version log
Keep approvals lightweight and time-boxed. If publishing takes weeks, teams will bypass it.
Object governance: avoid duplicates without slowing modeling
Duplicates are not a data issue—they’re a governance issue.
Practical rules:
- Project teams can create objects in Working (speed matters).
- Library curation group consolidates weekly (or on-demand for high-impact objects).
- Approved models reference library objects where possible.
A consolidation workflow should answer:
- Which object becomes the canonical one?
- Which models must be updated?
- How are names and synonyms handled?
Curate by impact, not by completeness
Don’t try to clean the entire repository. Start with objects used in high-risk journeys and high-volume processes.
Repository health scorecards (the missing layer in ARIS programs)
Even with zones and approvals, repositories decay if you don’t measure health.
Start with scorecards:
- Completeness: required metadata present
- Timeliness: last review within policy
- Uniqueness: duplicates/overlaps detected
- Consistency: conventions pass (naming, lanes, gateways)
Then connect scorecards to actions:
- auto-create remediation tasks
- block publishing if critical fields missing
- escalate red items after SLA
Where Process Designer fits (and why teams add it next to ARIS)
ARIS is often the repository. The gap is the operating layer.
Teams add Process Designer to:
- operationalize controls mapping with evidence trails
- run scorecards and drift detection as a living system
- guide execution with HEIDI and automate stable steps
Related:
Implementation checklist (ARIS admin-ready)
- Define zones and permissions
- Define publish workflow and approval roles
- Define required metadata fields for publishing
- Define consolidation cadence and canonical object rules
- Publish scorecards weekly and assign remediation owners
Common mistakes to avoid
Learn from others so you don't repeat the same pitfalls.
One database for everything
Drafts and truth collide and drift becomes inevitable.
Separate zones and enforce publish workflow.
Central team models everything
Throughput collapses and adoption drops.
Let teams model in Working; curate into Library and Approved.
No measurable quality bar
Standards become debates.
Use scorecards and block publishing on critical gaps.
Expert insights
What the experts say
"The repository doesn’t scale by adding more rules. It scales by separating truth from work-in-progress—and measuring health continuously."
ARIS Administrator
Take action
Your action checklist
Apply what you've learned with this practical checklist.
Create Working / Library / Approved zones with permissions
Define publish workflow and roles (owner + reviewer + approver)
Define required metadata for publishing
Define consolidation rules for canonical objects
Publish repository health scorecards weekly