I’m currently working with a client who is capturing a load of project knowledge into a single (EA) repository, pulling the skills & wisdom of 20-30 IT experts into one place.
Before they started doing this, they split up the problem into bits, so that each modeller could work semi-independently of the others, and not have everyone trip over everyone else. And this worked well for quite a while. They even had a small part of the model for obviously re-usable stuff, such as master lists of Actors and Components.
Now they are starting to put the bits together, and some other problems are emerging. To help them to make their model more consistent, and easier for other people to understand and re-use, I’ve been creating a family of tools & techniques to help them.
We’ve chosen to put the errors in the model into two broad categories:
- “Mechanical” errors, which can be fixed by applying some simple (ish) rules, with minimal human involvement and bags of automation. Mechanical errors are self-defining: they are the kinds of errors which can be found by mechanical means.
- “Content” errors, are where, even though the ‘mechanics’ are correct, the model is still wrong. These can’t be fixed – or even detected – by mechanical means. Another human needs to look at the content and think hard.
The remainder of this post is about the mechanical errors, and talks about using some new techniques we’ve used to find and fix the problems for users of Sparx Enterprise Architect.