We’re gradually adding more processes, roles, systems, and dependencies to our ARIS environment. As the repository grows, maintaining a clear structure and avoiding duplicate or outdated process models becomes more challenging.
What practices do you use to keep a large ARIS repository organized and easy to maintain? Do you rely mainly on naming conventions, folder structures, governance rules, regular reviews, or a combination of these?
I’d be interested to hear what has worked well for teams managing larger ARIS environments.
Alexander Cherednichenko on
Hi,
It depends on how your team and the overall BPM initiative are organized: how you add content (centralized or decentralized approach), who owns process architecture, access management, quality assurance, and repository maintenance, and how you distribute responsibilities across these roles.
These questions are actually more important than the technical organization of the repository itself. You've already mentioned most of the key elements, but I would look at them from a slightly broader perspective.
1. Modeling conventions and access management
Conventions are definitely essential, especially as the number of modelers grows. But implementing a modeling convention in ARIS (filters, templates, etc.) is only half the story. The real question is how you enforce it, who controls compliance, how you manage access rights, and how much freedom individual modelers have.
2. Repository structure
A clear folder structure matters, but repository organization doesn't have to be limited to folders. For example, you can separate development and production environments into different ARIS databases. You create and modify models in the development database, then transfer them to production using the merge functionality.
The right approach depends on your governance model and how strictly you need to control changes.
3. Governance and lifecycle management
This brings us back to team organization. It depends on who can initiate changes, who reviews and approves them, and who decides whether to update an existing process or create a new one; what is the lifecycle of a model, from initial development to publication.
I would say establishing a clear, practical workflow for these activities matters far more than having a well-organized folder structure.
4. Automation — probably the most practical part when the repository gets large
This is where ARIS scripting can make a huge difference.
In larger repositories, we use many custom scripts to reduce the workload of process architects and QA teams.
Just a few examples:
Once you have hundreds or thousands of models, these tools can save significant time and make quality control much more consistent.
But I want to emphasize one important point - automation doesn't replace governance. And unfortunately, I sometimes see what happens when organizations let things run without proper control. Usually, when such ARIS projects come to me for an audit, people have already spent years modeling whatever, and however they wanted, with little or no governance over the repository.
At that point, cleaning up and aligning the repository becomes almost impossible. And in a large organization, I would say practically impossible.
That's why you need to establish these things from the beginning. Otherwise, ARIS eventually turns into Visio on steroids. Instead of a relatively small mess, you end up with a huge, highly automated mess.