Speaking to a client a couple of weeks ago, I came across a modelling idea so simple, and so useful, I’m kicking myself from not thinking of it years ago.
They called them ‘NODs’ – Notice Of Decision.
The idea is as straightforward as possible.
They make a decision, then they write it down. What’s the decision, why was it made, and by whom. That’s it.
Ok, so they also link the decision ‘thing’ in their model to the stuff which is affected by the decision. For example, the decision to ‘make all widgets blue’ would be linked-up the the ‘Widget’ idea in a Domain Model, and the the Configure Widget process, which is might be where the Widgets get made blue.
So, many years from now, when some newbie modeller has to idea of making all the blue Widgets go red, they can find the Widgets idea, follow the link back to the decision, and maybe, just maybe, pause before they undo what’s gone before.
For Sparx Enterprise Architect users, I’ve use a ‘Decision’ element. This is normally used in flowcharts, but to use anything else would be misleading, so I used the ‘Info View’ facility in 12.1, and give it a ‘NOD’ stereotype, just I remember that this shouldn’t be used like other decisions.
And I also hooked it up to the process and the Domain Model class with simple ‘Dependency’ connectors, since they are available on all menus.