Versionhandling?

[anderspe]

We are going to use Sparx EA for development and maintenance of our enterprise architecture. The plan is to create a model AS-IS which will hold all approved diagrams and elements. The AS-IS model is not allowed to be changed. The plan is also to create another model PROJECT within the same EA project where all changes to the approved architecture will take place. Changes in the PROJECT model should not affect the AS-IS model before the changes are approved. We want to “merge” back the approved changes to the AS-IS model.

Any advice how to achieve the above?

[Paolo F Cantoni]

See "Time Aware Modelling" in the help.

HTH,
Paolo

[anderspe]

Paolo,

we have looked into the Time Aware Modeling and made some testing. We have found some problems for instance if an element exists in two different diagrams.

1. I clone one of the diagrams
2. Within the cloned diagram I clone the common element.
3. I update the cloned element within the cloned diagram

So far everything is fine but then I want to merge back my changes to the AS-IS model. At this stage I want all diagrams which uses the concerned element to use the changed element. How should the merge be carried out to work as we want?

[Paolo F Cantoni]

We wrote our own bespoke replacer (still a work in progress).  It does what you suggest, it replaces the old with the new in all the appropriate diagrams and will also merge the relationships (according to certain rules).

We don't just use the replacer for this purpose (in fact, we don't use Time Aware Modelling much yet) we use it primarily (and it was initially designed for this use case) to merge multiple instances of an item in an enterprise-wide repository that was aggregated from a number of different specific repositories.

Paolo

[anderspe]

Thanks Paolo for your Quick response!

I think you understand what we want to achieve do you have any idea how to solve this by the use of out of the box functionality of EA?

/Anders

 

[Paolo F Cantoni]

Thanks Paolo for your Quick response!

I think you understand what we want to achieve do you have any idea how to solve this by the use of out of the box functionality of EA?

/Anders

AFAIK you can't.  I also have no knowledge of whether the Sparxians are working on such.

Partly this may be because the "merge" process is not well understood for elements in this type of repository.  All I can say is that the Replacer casts its magic spell according to our needs (and saves us a shirt-load of time and provides a degree of peace of mind), but it might not do what you need.  We are still learning what merging means for our specific circumstances.

If you are interested, we can start a discussion on what merging might mean (in the more general case) and you can decide if "rolling your own" is a viable thing.  There are other consultants in the community who might be able to create an add-in for you.

Paolo

[Uffe]

Hej Anders!


Version control is one of EA's weak spots. There are several features which can be used, none of them perfect: external version control of exported XMI files, baselines, auditing to some extent. For an organization that knows about version control in general and the issues around it, I strongly recommend implementing a version control scheme using the Reusable Asset Service, or RAS. (If you search the forum you'll find older posts by me recommending baselines; RAS is like baselines but with more features.)

With RAS, models are stored in a centralized storage, and uploaded/downloaded to EA projects. There is a diff function to show the differences between the model in storage and a project, and dependency management between models. There is also access control so only certain people may upload models, while others may download them. On the negative side, there is no way to compare two stored versions or even download an earlier version of a model from storage -- you can only access the latest version. But the older versions are still in there, so they could be extracted with a bit of work.

There is no branching, but if that's a key requirement it could be implemented using multiple storages.

RAS is more of a chore to set up since it requires the cloud server, but it's in my opinion the best solution. I haven't looked into time-aware modelling in any detail, but it looks to me to be more of a local feature used within a single project, not something suited for an enterprise deployment.

Whatever solution you choose, you need to be aware that for anything like an enterprise architecture you will need to do a bit of work yourself. EA has no concept of a configuration item, so you have to determine what constitutes a CI in your environment. This is crucial for any version control scheme to work outside of a very small team or a time span of a few months.

With the setup I outline, there are never two versions of a model in the same project. Each version-controlled model is maintained in one project, but accessed in several others. That's not how you described your requirements, but you also said you wanted a merge function and access control, which RAS has but I don't think time-aware modelling does.

The short answer is that there's no simple solution or single best practice. It is possible to set up some sort of version control in EA, but for it to be useful you do need to sit down and think about how you want to work.

HTH,


/Uffe

[anderspe]

Hej Uffe!

Thanks for your advice! Could you please provide some more information regarding what will work and what will not if we choose the RAS solution for version handling?

/Anders

[Uffe]

Hej igen!


Given a set of generic version control requirements, a RAS-based solution gives you:

Access control of "as-is" model updates	YES
See differences between "as-is" and "will-be" models	YES
Dependency tracking between version-controlled models	YES
View "as-is" and "will-be" models side by side in same project	NO
Retrieve not-latest versions of version-controlled models	NO
Ability for different teams to work on different "will-be" models	YES
Merging of different "will-be" models	NO
Selective pull of version-controlled models	YES
Mandated push of version-controlled models	NO

A RAS-supported version control setup is a good fit if you have one team (architecture) working on one set of models, eg information model, basic requirements and test cases, common design components, while other teams (more than one) work on customer-specific requirements and design.

Each team works in their own EA project, to which they download the architectural models. If they make changes to those models, those changes are not automatically uploaded. If the team has sufficient access they can upload the updated models, but otherwise no. It's up to you to implement whatever review and approval process you need on top of that.

The architecture team also work in their own EA project, where they may update the architectural models and upload new versions to the storage. These updates are not automatically pushed to the customer projects; each customer project decides if and when they update their copies of the architectural models. There is no notification mechanism in EA to inform the customer projects of updated architectural models, so again it's up to you to implement one.

As always with EA, there is enough flexibility to allow several different ways of working, but that comes at the price of having to make a number of decisions yourself during deployment.


/Uffe

[PeterHeintz]

Just to add some further information to the stuff provided by Uffe!

With RAS you should be able to retrieve not-last version as well. Well I have not jet done, but by just opening the select box in der Version field in the Registry Browser you should be able to.
We use RAS to share model libraries to be used within projects. However to keep all connectors between the RAS stuff and the stuff in the projects, we need to make a kind of update procedure like follows.
1.   Backup the stuff we have (MSSQL->eap->svn[optional]) {just to be able to fall back if disaster happens}
2.   Create a baseline of all project content (we have one root package for all project content)
3.   Remove full lock from the package containing the RAS stuff
4.   Update the RAS stuff in the package (after that the model misses some connectors between the project stuff and the RAS stuff depending on the kind of the connection
5.   Restore the project stuff baseline
6.   Set the RAS package to Full lock (we do not want the projects to change the RAS stuff)
Remarks:
The package locking feature is in some area not very clean implemented, but in the “library share scenario”, this unclean implementation is somehow a helpful feature.
In general merging stuff can get really complicated even for source code if you e.g. have lots of conflicts you have to solve. So I try with some success to avoid any merges where I have to make decisions what to do in case of conflicts. In other words I do my very best to avoid conflicts.

In your specific scenario the RAS seem to be the best solution within EA because it is very similar to what we are doing with library sharing. Typically in a project, model stuff is created and later it turns out that this content should move the RAS library.
In this case we move that content to a third “root” folder called “Asset Candidate” (just to have one “root” package to treat further). At a certain point in time we export the stuff and import it into an EA reposition intended to model the RAS content to be published later (in your case a separate AS-IS repository). Once the stuff is put to the right place, we publish that stuff in the RAS repository and start within the project repository (in your case TO-BE) the procedure as described above. After that, the exported/imported “Asset Candidate” content is deleted but now the content you find in the project model within the RAS package structure.

[anderspe]

Thanks for your advice! We will setup RAS and carry out some testing. Maybe I will be back with more questions.

/Anders

[Eamonn John Casey]

As mentioned earlier in this thread EA is really bad on version control. The reason for this is at the model level there is no need for it. BUT at the code level where programmers live a line of code, a new field in the database, etc. is important.

Tools like Magic Draw that is close to code do this very well.

My technique is to use a general element (ArchiMate Application Process) that rerely changes and make Specialisations of this. At the modelling level the names of the boxes never change. It is the arrangement and the inclusion and removal over time.

Så EA does not do versioning. Time Aware Modeling I have not tried. But the thought around modelling as apposed to code is: Does it really matter what was delivered in the previous release?

[anderspe]

Eamonn, please give me your argument behind "The reason for this is at the model level there is no need for it".

[anderspe]

I have finally set up the Reusable Asset Service and it works well to import from RAS to a Project. But how to "merge" changes made in Project back to RAS if needed?
 

[PeterHeintz]

Well, we do it in the other direction.
If something need to be changed within the RAS we change the RAS only (a model that contains nothing but RAS stuff and nothing project related).
Once the changes are done, we do the RAS update procedure withing the project as described above.

By doing so we are sure that the RAS stuff does not depend on any project specific stuff.