Explaining EA Sparx Systems to non-modellers

Over the holidays, in between soaking up some rays and watching the sun go down over the ocean, I got around to reading some of those books that have been on the ‘must read’ list for months.

And even talked to the family for a change. One conversation started with ‘Dad – what do you actually DO‘.

This is a tough question when your life is spent manipulating ideas around a screen, and trying to understand how businesses want to work. All a bit abstract.

After a few false starts, I finally hit on ‘Model Driven Analysis’ as the shortest way to explain what I do. I tried googling the expression, and it doesn’t seem to exist anywhere as a ‘thing’, so, you heard it here first.

What I do, and what maybe you do as well, is Model Driven Analysis, and this is what I think it means:

1. We capture what we’re trying to think about in a rigorous form. Our ideas may start out as a Mind Map, but the blobs on the picture get quickly morphed into more definite things: Risks or Requirements, Domain concepts or processes, States or Business Functions, not just paragraphs of text.
   So no Blob and Stick diagrams, and no more Visio.
2. We put those ‘things’ into some kind of tool. This is essential. What we’re grappling with here are problems which larger than will fit into a single head, so we out-source the remembering to a computer *.
3. We think hard about the relationships between the ‘things’. Just like the WWW, it’s the links which provide the richness. So a Business Goal and a User Story are interesting ‘things’, but if we connect them together by saying ‘this User Story contributes to the achievement of the business goal, we start to add more value to the problem.
4.  We use the modelled ideas, and the tool where they sit to help us to do a better job of analyzing. This is why it’s called Model Driven Analysis .
   For example:
   • “This User Story doesn’t connect back to any project objectives? What’s it doing in scope?”
   • “Why do we have a stakeholder who does’t appear to be responsible for any Requirements? Did we miss something?”
   • “Have we implemented all the local security requirements somewhere in the solution?”
5. We treat the model as an important organisational asset. Over time, the model will contain more and more knowledge about how and why our organisation works. And we’ll have spent thousands or millions of (£/$/€) creating it, so we’d better look after it, and make sure it gets used by every project, but also stays consistent and useful.

These five ideas are what I think are the essentials of Model Driven Analysis. More to follow on this, but as nobody else seems to have used the term, I thought I’d put my towel onto the metaphorical sun-lounger, before someone else does.

(* the idea of ‘outsourcing the remembering came from a holiday reading book ‘The Organised Mind’)