FT
Dear Aris Community,
Does anyone know what would be the recommended way to activate user audit trails in ARIS Architect/Designer v10?
I need an easy way to see the list of changes done on a certain object in ARIS.
So far I found how to display who did only the LAST change on a diagram. But I would need more than that. I would need the list of last changes (not only the last one).
Our team is getting bigger and bigger (including people with different level of knowledge) and we would need a way to identify who did what.
Searching this forum, the only thing I found is a very old macro that could be run every time when an object is saved:
https://www.ariscommunity.com/users/thaase/2010-02-19-free-charge-aris-report-aris-audit-trail-macro
There are two problems with that macro:
- It is more than 10 years old and I expect that it does not work anymore.
- I understood that that macro introduces a huge performance penalty. (The UI will be frozen several seconds every time when that macro runs even if we chose to not display a message.)
Hence the question:
Is there a better way to activate and display user audit trails? (Because, honestly, that macro is not a feasible solution.)
Thank you in advance for any feedback.
Hi
I think the idea of Macro is good, and you could just create your own macro based in this post information. However thinking in log information there is no detailed information about changes in object or models, but the available information is about deleted objects or models, and you find out in modifications.log available in server from ABS folder. Other hand, should use the versioned databases and maybe create the versions to keep the changes history.
BR
AO
Hi,
here is one solution, provided you can do with a little less information. I will tell you good reasons why you should:
1. Install a rigorous regime which people may do modelling in which part of the database. Process owners choose their modellers. Permissions on groups enforce only those modellers can modify those models. This way even 50 or 100 modellers are not much of a problem, because any place you know which 2-3 modellers have worked there.
2. Write information about your governance workflow in Audit log attributes. This way you can see who was involved in the QA and approval of a model version. When it comes down to it, it's not so important who corrected a typo, but who took responsibility for the content.
3. Give reviewers and approvers the possibility to compare the previous state with the current state.to be approved. Place locks on the models to be approved for the duration of the review process until the approved version is conserved in a change list. This gives you complete auditability of those accountable.
4. You could even discard the former audit logs in the next approval round for the artefact, because you keep the logs leading to an approved version in the change list. Remember that also such logs may contain person related data in the sense of European GDPR. So it is good, if you have the possibility to discard the oldest change lists when the minimum period of records-keeping is over. If you wrote an infinite log, you do not have the possibility to forget irrelevant data that you are obliged to forget, because even the oldest data is still part of your newest version.
Hello,
We have implemented some elements of an audit trail on object level without the need of a macro to be run which will eat up resources on client side.
We are using a combination of schedule report, and versioning. there is one caveat, schedule report are running every 30 min so we could miss changes made to one object by two persons in that window.
Our schedule report is checking if any object has been recently saved (in the last 30 min), and if yes, will check against the version of that object to compare all changes (we have also introduced a check if the person is authorized to make changes (ie: using contribution)), all identified changes (attributes) are then saved in a history attribute in structured format (for later reporting/dashboarding). The object is then versionned so that we can compare with most recent saved version.
Disadvantage of this approach is obviously the number of change list which is increasing rapidly when lots of changes happen.
We are also looking at making a similar concept for model audit trail but not yet implemented.
I hope it can help in your reflexion and if anyone has better ideas, I'll be glad to discuss them.
Cheers
Tanguy
Thank you all for your feedback and interesting ideas.
I think an acceptable compromise would be to go with a hybrid solution, a mix between what Zschuckelt and Tanguy proposed. (Thank you both for detailed explanations.)
I mean, we could have some permissions on groups (but not extremely rigorous) and a scheduled report based on versioning (as suggested by Tanguy).
If anyone has any other ideas, please feel free to come up with suggestions.
