Using Multi-hop relationships to display Branch/Merge with EA13

Up to now, the answer has been ‘because it’s hard’, and indeed a full branch/merge solution for EA would be way, WAY more complicated than one just for code, and therefore probably un-usable.

But can we get most of the benefits of a code-style branch/merge with EA, without a 100% fool-proof solution?

With EA v13 we may just have a solution: not a 100% solution, but one which has 10% of the function but which may deliver 90% of the benefits.

A real-life scenario

In a recent client engagement (details changed to protect the innocent) we had a small team of modellers (30+) working on a large but quite simply-structured model.

Now my client spotted this one a mile away. Carrying on like this is going to cause huge problems down the road. They were predicting 80+ actors (real-life, individual roles) and if every team created their own duplicate with the same name, this would rapidly become chaos. They would lose the ability to say ‘what Use Cases does Actor1 get involved with?’ But which ‘Actor1’ are they talking about?

The Team #1 model was now modified.

Which means when we ask which Use Cases Actor1 is involved with (by the EA function ‘insert related elements), EA tells us.:

…which is the combination of team#1 and #2s models, as they are both using the same Actor instances from the common set.

Much more useful – and the best argument for ‘why EA is 1000% better than Visio’.

So, problem solved? Well not quite.

If I want to find out the use cases which really use Actor1, which have a status which means they are suitable for me to think about, then we need something in between the chaos of ‘invent your own’ and ‘always re-use’.

We need an intermediate state of ‘using Actor1’: something like – ‘I’m intending to use Actor1, but I’m not ready to tell the world what I’m doing’.

In the case of this customer – using EA12 – they had to create duplicate Actors with the same name, then, once they were happy, manually merge their ‘temporary’ and ‘reusable’ Actor1s. An alternative would be to give each Use Case a status, but this means we can’t use ‘insert related elements’ quite as simply.

So not a great solution.

Then along came v13

EA V13 introduced the idea of ‘time-aware EA’. Looking past the rather grand title, it does provide a small amount of function which should make this problem a lot simpler.

So now, here is the same story, using EA V13.

This diagram is now simplified.

To see the magic which EA has done in the background, try dropping the original Actor1 back onto the diagram.

With this simple technique, we can now have the best of both worlds:

• Team 2 can carry on modelling, adding whatever crazy stuff they need to add to their cloned Actor1, and ‘real’ Actor1 users won’t see it
  UNLESS
• Those users choose to follow the <<trace>> connector, and find whatever use cases Team 2 are working on.

This is (fairly) easy using the EA traceability view.

You just need to know that the <<trace>> connector which EA created when we cloned the Actor appears as a ‘needed by’ relationship in the traceability window. Here, there are two teams which have create clones of Actor1.

Tools like eaDocX are OK to print ‘multi-hop relationships’ like this, in lots of different ways. For example, we can document the ‘master’ element and its related elements, then also its clones, and their related elements.

Note to Sparx Systems: Next Steps?

Now that we have this starting point, I’d like to suggest that we need some improvements to the EA UI which will allow us to go further:

• Implement a simple ‘merge’ function to move all the connectors from a back-level element to a new one. Saves me having to drop old + new onto the same diagram, with ALL their connected elements, and move the connectors one at a time from old to new.
• Better diagram filters to show/hide different versions more simply
• Associating the current ‘version’ text field with something more interesting – another EA element e.g. an Archimate Plateau, or some other project-related ‘thing’, so that we can find out ‘all things associated with version X.Y’ without having to start writing SQL
• Native EA support for the function that eaDocX lets us do already (as shown above): ‘show the clones for this element’, ‘show me what’s related to those clones’. These are now important functions, and shouldn’t need me to create a document to see them easily.

Conclusion

The V13 ‘time aware’ function is limited, but it is a start, and it does show the way to achieving what EA users have wanted for a long time – the ability to have multiple ‘versions’ of the same thing in a model at the same time.

This has many more implications for EA users, as it opens-up new ways of using EA. We can now allow teams to explore new ideas without messing-up the model for other uses, and keep track of those explorations using standard EA techniques.