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.

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”.miracle2

He expanded. “We’ve haven’t started modelling yet, but this is what we need the tool to contain.”.

Wow. So he’s about to start out doing what has to be the hardest bit of modelling there is – capturing all that’s interesting about a large organisation – and he already knows exactly what information he’ll be capturing, and how it will be organised.

We chatted for a while, gave him some brochures, and wished him well.

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.

We had a great workshop, designing the meta-model. There were 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. 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.

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.

About the Author Ian Mitchell

Ian Mitchell is a business analyst and software developer. He's been using UML since before it was UML, and has managed teams of BAs all over the place. He also teaches UML and BPMN, and writes the eaDocX document generator for the Sparx EA tool.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s