Reference Models - best practices

[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

[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

Code Select Expand

__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,

I'll share this here in the coming weeks.

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

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.

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