best practice for baseline and target arch models

[brback]

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?

[Glassboy]

Is there any new best practices regarding this topic?

We're building an architecture repository based on TOGAF, but have some troubles on finding the best way to organize the repository (architecture landscape) in the time dimension (as-is, to-be, transition, etc.). Time-aware modelling might be useful, but I'd really like to hear what you consider is most practical and feasible.

Google TOGAF CONTENT METAMODEL

[brback]

Google TOGAF CONTENT METAMODEL

The TOGAF Content Metamodel says nothing in regards how to structure a repository for the different states for an architecture. The Architecture Landscape chapter does this, but it's a challenge to find a good way to realize this in Sparx EA.

We have partially solved this now by having different states (as-is, to-be, candidate) packages for diagrams/views, and a single package regardless of states for elements (which would be similar to the TOGAF content metamodel). This means the same element can be used in diagrams describing different states, which means we have to find way to describe which state the connectors (relationships) are in. We also have to make sure different people can work with the same element without getting in conflict with each other.

Another option to solve this is to make an element catalog for each state, but this would probably require too much effort to keep updated. Or one might export the elements a project want to use to make sure they're not in conflict with someone else, and then import it back when the architecture has been developed. The GUID of the elements will make sure the exported elements are merged into the existing ones.