Hello all,
As Geert mentioned earlier, I favour the reusable asset service for this type of scenario. However, nothing in this world is free or even cheap, and you do need to carefully consider your requirements and your options.
Paolo and Qwerty have both expressed the opinion that version control just isn't appropriate for models. With this I disagree in principle.
It's not that you can't do version control for models, it's more that any version control system out there (Git, Subversion, etc etc) is designed to manage versions of source code -- ie text files, individually and as collections. This doesn't work well with EA's XMI structure because one project does not equal one XMI file, and the XMI files from one project are interdependent to a degree that source code files are not.
In the case of source code, the files are presented to a person through an editor (eg Visual Studio). While there may be dependencies between files that need to be resolved in order for the code to compile, crucially, the editor can show each file as is: the text is the relevant data, and the editor does not need to interpret it in order to show it.
By contrast, EA in its role as model editor is not able to show the source data as it is. The model data has to be interpreted in order for EA to draw the contents of each diagram. And an XMI file may well be incomplete in the sense that it may contain diagrams whose included elements are not defined in that same XMI file.
Any tool that supports multiple version-controlled files (again, Visual Studio is a good example) also has a concept of a collection of such files (in Visual Studio, this is realized by projects and solutions). This provides a scope for dependency management, and not only that, the collection itself can be version-controlled, meaning you can manage whole collections of source code in terms of releasing, branching, merging, etc.
EA's corresponding concept is the project, but crucially, an EA project is not a collection of files. It is instead a database. What you version-control with EA is only the model content, but there are masses of critical information that is not included in the model content but only stored as configuration data in the database (and indeed, some of it in the registry and some of it in the file system). This means you can't manage the collection of XMI files as a self-contained whole.
Both these issues, the interpretation by the editor and the absence of critical information in the XMI data, make a version control scheme based on multiple XMI files per EA project fundamentally unsound. Any setup based on this will require a high degree of manual synchronization between participants -- basically, going back to source code version control c:a 1980.
Modesto adds some good insights, but I do have to take issue with one point.
I think it is important to distinguish between version control, (change) auditing, reusable assets - such as patterns - and documentary baselines.
As both qwerty and Paolo have explain, models and, in particular, enterprise models are not best suited for version control. At best, version control gives you a fall-back position in case something happens to the repository.
In addition to distinguishing between version control, auditing and baselines, it is also vital to distinguish backups. If you are using version control with the aim to have that serve as your backup strategy, you will lose your data. Backing up data is a completely separate proposition to tracking changes in it. Do not confuse these. Do not think that setting up a version control system means you've solved your backup problem. It doesn't. You will lose your data.
So that's by way of a preamble.
Moving on to
I would probably say that what we want to get out of this is:
- Auditing, definitely. In that we want the ability to see the history of changes, and revert them if necessary. I understand that this is less practical with the complex structures of some models
- The ability to take a design at a point in time a branch off from it. Then the branched version may or may not make its way back to the original design
- Not just re-using assets, but being able to link them to their attributes, even if those attributes change. It sounds like I may need to check out RAS, which I don't know too much about yet for this one.
First off, "assets" in RAS can mean a few different things, but the core functionality is for packages. And yes, it is based on XMI export. But there is (some level of) dependency management.
Secondly, auditing and change tracking are not the same thing. Modesto was talking about EA's
model audit feature. He also mentioned that it doesn't work very well, and I certainly agree with that.
One of the things auditing should do is tell you who made what change when. EA's auditing functionality does that, but none of its other features in this space (version control, baselines, RAS) do. If that is a requirement, auditing is the only way to go. And I would urge you not to go down this path: it's a performance nightmare and doesn't work well enough.
If you want to compare versions and revert them, you need baselines or RAS. In earlier versions of EA, baselines were stored in the project, but more recent versions have introduced the option of storing them in RAS. I would recommend this over in-project storage.
RAS also provides a rudimentary form of dependency management, so that when importing a package from RAS, EA will offer to also import its dependents. Note, however, that this does not mean you can forget about having a good structure. Indeed, RAS will only work well if your RAS package dependencies form a tree (well, rather a directed acyclic graph).
RAS also allows you to control write access separately from read access, so that you can allow only certain users to update packages in RAS, while a larger number of users can retrieve them.
However, RAS does not give you any meaningful version control. RAS is baselines++, and baselines are just stored snapshots. The concept of branching is not recognized by either baselines or RAS. This is related to what I described earlier, that EA has no concept of a collection of models that itself can be version-controlled. I think you could implement some kind of branch type functionality possibly using multiple RAS storages, but it's a lot of effort for questionable returns.
So for anything approaching what you've been getting out of the box with any source code version control system since the eighties, you will need to do a lot of thinking and planning of your own. Or get a consultant in.
I also have to ask, what exactly do you mean by "tracking enterprise architecture evolution over time"? And what would you recommend for tracking that evolution?
This is a question for Modesto, but I would say that the comparison tools provided by EA (which can be used in conjunction with baselines or RAS) can't do this for you because they track things like elements changing positions in diagrams, attributes added/deleted, etc -- it's at a very fine level of detail which tells you nothing about the grand sweep of changes to your design. There's just no way of doing that using EA's version-control-space functionality. I'm not saying you can't document architectural changes in a model, but I am saying that EA's version comparison facilities don't help.
HTH,
/Uffe
