Advice for the new modeller #3 – Fixing your meta-model

At a recent conference on Enterprise Architecture, we met a surprising number of people who said ‘I’ve just been made the Enterprise Architect for my Enterprise. What should I do?”

These were people who looked genuinely worried, and quite right too. It’s a big job to give to someone who doesn’t know what it is. We had a steady stream of these people through the day. I wish we’d been selling counselling and not software tools.

But in the middle of all these struggling EAs was a real treat. A very smart gentleman who said – ‘I have a my Enterprise Architect Metamodel, now I need a tool to implement it”.

I’d happily bet the farm that his meta model now isn’t the one he showed us. The idea that such a complicated thing as a EA MM can be designed in advance is pure hubris.

I know this, because I fell into this bear trap.

Long ago, we had a great workshop, designing a meta-model for a project. We had modelling experts, domain experts, and even a Project manager to keep it all real. And at the end we had a MM which we all agreed would capture the essence of what we needed to model. Now just go away and populate it.

I was SO confident we’d nailed it – after all, it wasn’t the first time we’d thought about this – that I offered to customise our chosen tool to implement the MM. With Sparx EA, this is fiddly, but fairly straightforward. So a spent a couple days organising a set of diagrams, toolboxes and stereotype definitions, and it all went into an ‘MDG” file which was in effect our own modelling language. A “Meta-model in a box”.

Our team of 5 then started modelling.

We had a team stand-up every week to start with. Things were developing fast. We were discovering all kinds of new stuff about the domain, so sharing was essential. but the MM didn’t quite keep up. We needed new stereotypes, new kinds of links, and even new kinds of diagram, almost weekly. So I spent hours each week re-designing the MDG –  which contained all these new ideas – and re-releasing it to the team. This went on for about 2 months, after which I finally got tired of endless re-writes, and we decided as a team that whilst we’d DOCUMENT our MM, we’d wait until it stabilised before we committed it to code.

And finally it did stabilise. Right before the modelling was complete.

The Lesson

Don’t fix on you MM too early. And by ‘too early’ I mean before you’ve done at least one full project with a stable MM. And even then, only commit to code those bits of the MM which you haven’t changed for AGES. Keep rest as documented standards which need to be manually applied (or, if suitable tooling is available, applied in a way which you can change quickly)

If you’re on your first project – like our smart friend – then by all means document what you think your MM will be, but be prepared to change it rapidly as your model unfolds, and don’t commit it to code.