Reference Models - best practices

Started by m4ttmcg, February 16, 2024, 03:50:18 AM

Previous topic - Next topic

m4ttmcg

Hi all,

This is maybe not so much an archi tool question as a general archimate/modelling tool question.

I know it is a common practice to keep separate models for different purposes, but I am wondering how people maintain these, and the relationships when elements are merged betweem models.

For example -Let's say I am modelling a solution, and I want to demonstrate security controls mapping. I have a separate model for the NIST controls, that I have built using a script. Whenever NIST update their controls, I can download them and run my script and my NIST model will add the new controls or update the properties of elements.

I copy elements from this model to my working solution architecture model, in order to create relationships between them and the application components or whatever.

In the event that there are changes to the reference model, the copied elements are now adrift. My thought is to use specific ID's as the element ID instead of the auto generated GUID values(for NIST it would be the actual control ID for example) as these are already unique and easily referenced.

Another use case I have, is where I am managing the mappings to multiple external control sets. I can automate a model of these, and the relationships between them based on the source material, and if I copy a control to my application model the mappings and relationships will come across, but if the mappings change in the reference model, I am not sure how best to merge changes back to the application model.

Anyone else having the same dilemma? What are your thoughts?

Cheers,

Matt


Jean-Baptiste Sarrodie

Hi,

I share the same needs and have defined some ways to work on that topic. That's something I plan to write about in the near future (I need this both internally in my company and because The Open Group ArchiMate Forum plan to write on this topic too).

I'll share this here in the coming weeks.

Regards,

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

m4ttmcg

Thanks JB, Any advice would be greatly appreciated!

m4ttmcg

Bump - anyone have any thoughts on this?

rchevallier

uid are opaque and technical and specific to a model

Just for reconciling shared objects between imported sources, I'm using an custom uri built, and which is stored as a property.

ex: for a database table data object the uri I create is __uri=db://<instance>/<database>.<schema>.<table>
The source extraction and reconciliation scripts/programs are using this property __uri as the identifier

Jean-Baptiste Sarrodie

Hi,

Quote from: Jean-Baptiste Sarrodie on February 16, 2024, 10:58:21 AMI'll share this here in the coming weeks.

I'm still working on it internally (as usual, this takes more time than expected)...

Quote from: rchevallier on March 28, 2024, 13:09:14 PMuid are opaque and technical and specific to a model
Just for reconciling shared objects between imported sources, I'm using an custom uri built, and which is stored as a property.

Some advices:
- A reference model is a model which has its own lifecycle
- Stable versions of a reference model are imported into other models, which can then reuse some views of concepts (but not alter them)
- When a newer version is published, the reference model is imported again, which updates its content into the target model, without impacting other part of the model
- Because importing a model cannot remove objects, a good practice is to set a property (e.g. "Lifecycle Status") on each objects to know if they are CURRENT or DEPRECATED. This way, it becomes possible to check objects which are now deprecated and analyse the impact on the target model.

Regards,

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.