I was looking at a little diagram which showed the relationship between an Activity (from the Process world) and a Use Case (from the systems world).
But compare this diagram with this one:
I agree, the two diagrams look the same. And it may be a ‘feature’ of the Sparx EA modelling tool I’m using, but it turned out that the second diagram was different from the first. The modeller had used a different way to create the connection. It was an Archimate ‘Realization’, which the tool had modelled as a <<Archimate_Realization>>Dependency, and decided to helpfully draw as a normal-looking Realization.
OK, so not the finest hour for the tool concerned, and I totally understand how the modellers did different things. But what to do about it?
The diagrams look fine, so the documents will probably look OK, deliverables delivered, everybody wins.
Except for the Modeller-Who- is- Yet- To- Come.
The person who, in a couple of years time wants to make use of this bit of modelling, looks at the diagrams and thinks they have a consistent ,and starts work. Only later do they find that the model isn’t consistent.
Did the original author mean something different when they modelled these two ideas? or are they accidentally different underneath, but really the same.
So the usefulness of the model is reduced. And because if there is one weird bit like this, there are probably more, they won’t trust the model in quite the same way any more. And the basis for re-use is TRUST. If future users don’t trust what we produce, then they probably won’t re-use it, and we might as well have crayoned our diagrams in Visio.
So spending some time looking more deeply into our models, and making sure they don’t just LOOK right but they ARE right is time well spent. Because there are wider considerations than today’s diagrams and tomorrow’s deliverables. There’s the integrity of the model, and its utility as a re-usable organisational asset. Because we’re bothered about that too.