We also structure our enterprise model in packages based on the archimate domain which will contain the various catalogue elements, in addition we have a "View" package which primarly contain diagrams. We would like to have the matrices represented as elements in View package as well, but as far as i know this is not possible in Sparx EA.
I've encountered a white paper (W174) from the open group which adresses this issue as well;
One of the most challenging aspects of a well-run repository is managing transitions over time. In most simple terms, every architecture will exist in up to four states. The current state is what exists in the Enterprise today; this baseline provides the reference for all change. The target state is what stakeholders have approved; this state provides the reference for governing all change activity. Transition states are partially realized targets between the current state in the target state. The candidate state is what has been developed by the EA team but has not been approved for a status sufficient to govern change.
I consider this a reasonable way to structure our model, meaning we'll have something like this;
- Clinical Architecture
- Clinical Candidate
- Business
- Business Process
- Business Role
- Information
- Application
- Technology
- Views
- Workflow Diagram
- Application Commuincation Diagram
- Clinical Current
- Business
- Business Process
- Business Role
- Information
- Application
- Technology
- Views
- Clinical Target
- Business
- Business Process
- Business Role
- Information
- Application
- Technology
- Views
- Clinical Transition - Project X
- Business
- Business Process
- Business Role
- Information
- Application
- Technology
- Views
Do you only consider it neceassy to track different architecture states for views/diagrams?
In my proposed structure mentioned we would have states for the different catalogues (including as elements) as well. The transition relationship which Paolo is mentioning might perhaps eliminate the need to do this?