Process model deliverables from models you can trust.

Last week I found myself in a heated discussion about diagrams and deliverables. I was told that the most important thing for a modeller is the deliverables they create for their project. As for how you get there – it doesn’t really matter that much.

And viewed from a certain angle, that’s right. Modellers are employed by projects to produce stuff, not to create useless abstractions. So long as the project is getting what it needs, does it really matter how modellers got them there?

Well, I think it does matter, and I have an example.

Simplest Diagram

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.

The Future

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 are consistent ,and starts work. Only later do they find that they aren’t.

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.