"Reboot" of an aging model database ?

Hi,

The overall plan appears to be good to me: one DB is for DEV, one is for PUB (Prod). There are a few thoughts/ideas that I usually follow (it does not necessarily mean it will work for you):

1. If there are not too many active modelers, I'd prefer to keep DEV/PUB content in a single DB, separating access through user access rights. The main reason is to reduce time/effort for merging especially if your content changes intensively (e.g., when you update the organization structure automatically from an external system, the merge becomes a pure nightmare).

2. Versioning. That is absolutely up to every company, but I do not prefer to use versioning at all (only for some BSC scenarious). There could be a long discussion about WHY,  but IMHO there are a few tangible benefits of versionong and one serious drawback - DB size. So I prefer to use another method:

• Utilizing governance through process statuses and reporting.

• Tracking changes through the change-list (object attribute).
• Adding extra object with versionong hystory for the process:

3. If you are going to perorm point B - the very very recent backuping is your best friend )

Thanks Alexander, I'll look into it.

Meanwhile here is chatGpt answer , most of it makes sens ...

To clean your ARIS database and establish a fresh, consistent versioning baseline — without losing the valuable data and models you’ve already collected — you’ll need to follow a structured approach. Here’s a practical roadmap

✅  1. Assess the Current Situation

• Identify all versioned models in your database, both approved and unapproved.
• Tag or list the models that are considered official, approved, or in active use.
• Identify models that were versioned improperly or are no longer relevant.

Tip: Use ARIS scripts or reports to extract lists of models and their version history, timestamps, and users who created them.

✅ 2. Create a Clean Baseline Environment

You have two options depending on your preferences and constraints:

🔁 Option A: Clean within the current database

• Create a new group structure (e.g. /Cleaned Models) to store validated models.
• Copy only the approved versions of models (process, data, application models, etc.) into this new area.
• Use “Save As” without versioning, so they become the new base models.

📦 Option B: Export and import into a fresh database

• Export validated models as .ADF (ARIS Document Format) or .AML (ARIS Markup Language).
• Create a new ARIS database.
• Import the validated models as the new baseline (again, using “Save As” without versioning).
• Reconfigure versioning settings and governance.

✅ 3. Disable or Restrict Versioning Temporarily

To prevent further inconsistency:

• Set ARIS privileges to restrict versioning to a small set of users (e.g. only the architecture team).
• Or disable versioning entirely in your method filter until a proper policy is implemented.

✅ 4. Reconfigure Governance and Versioning Policies

Once your clean baseline is ready:

• Define and document a versioning policy:
  • When should a version be created (e.g., before approval, after major changes)?
  • Who is allowed to version?
  • Naming and numbering conventions (e.g., v1.0, v1.1, etc.).
•  

• Implement these in ARIS:

  • Method filters
  • Scripted validations or reports
  • User training and documentation

   

✅ 5. Archive or Delete the Old, Messy Versions

Depending on compliance or audit needs:

• Archive old models by exporting and storing them outside ARIS (e.g. as PDF or XML).
• Or simply delete the unapproved/inconsistent version histories from the legacy part of the database.

✅ 6. Communicate the Change to Stakeholders

• Inform users of the reset and explain the new model governance approach.
• Offer training or documentation on the correct use of versioning in ARIS going forward.

🧰 Optional Tools

• ARIS Architect: Ideal for managing and cleaning model hierarchies, groups, and versioning.
• ARIS Script (JavaScript macros): Useful for batch processing of models (e.g., identifying all versions, batch exporting).
• Reports: Use or develop ARIS reports to generate logs of model versions, changes, and authorship.

If you’d like, I can help you:

• Write a custom ARIS report to identify improperly versioned models.
• Draft a versioning policy.
• Suggest a structure for your cleaned-up database (e.g., folders by domain or business area).

Would you like help with any of these?

Great! Let’s take it step by step. Since you’ve confirmed you’d like help, I suggest we focus on three concrete deliverables for your ARIS cleanup:

✅ 1. Custom ARIS Report to Identify Improperly Versioned Models

This report will:

• List all models with versioning information.
• Highlight models that were versioned but not approved.
• Optionally, flag those not matching your naming/versioning conventions.

Questions to tailor it to your needs:

• What constitutes an approved model in your setup? Is it based on:
  • Group/folder location?
  • Specific status attribute (e.g., “Approved”)?
  • User role or specific user who made the last change?
•  
• Which model types do you want to include? (e.g., EPCs, Data Models, Application Landscape, etc.)

✅ 2. Versioning Policy Template (for Future Governance)

A sample versioning policy document will define:

✅ 3. Suggested Group Structure for Clean Models

To support clarity and traceability, we can recommend a cleaned-up group structure such as:

/Company Models

   /Business Processes

      /Validated

      /Drafts

   /Data Models

   /Applications

   /Archived (locked, read-only)

We can also tag validated models with a specific attribute (e.g., Governance status = Approved).

👉 Next Steps

Let’s begin with the ARIS Report. Please confirm the following:

1. How do you currently identify approved models?
   (Group name, attribute value, etc.)
2. Which model types should the report cover?
   (e.g., EPCs, BPMN, Data Models, etc.)
3. Do you have naming or versioning conventions already?
   (E.g., model name ends with _v1.0 or use of a “Version” attribute.)

Once I have this, I can write a script for you and share it in ARIS report format (.ARX or JavaScript code snippet).

I've stopped reading on point A, where it suggested to use the Save As option - there is no such option in ARIS )) 

Most of the content regarding ARIS generated by GPT is a total trash. It does not know anything about the system, even for some primitive tasks, it will generate something very far from reality )) 

"Save As option - there is no such option in ARIS )) " 

You're right, but it's a question of amending the answer : "save as" => create a new database and merge the old one into it.

There are things worth considering in chatgpt answer in my opinion

Oh, look, GPT generates absolute bullshit. 
 

.adf - is ARIS Express format, you cannot generate it from Architect/Designer. Import - yes, export - not.

Even if you export your content as an XML export, the import brings you a great deal of chaos, because you'll get numerous duplications of object definitions... So this overall 'advice' is suitable only for the enemy ))