Tom Graves / Tetradian

This one extends the models-for-enterprise-architecture theme from the previous post. Although for me this theme goes back a long way, the start-point here was a Tweet from Dutch EA consultant Martin van den Berg (@bergmart) that triggered off a veritable flurry of replies:

• bergmart: I’m more and more convinced that it should be forbidden to show ArchiMate diagrams to business management #entarch #bizarch
• EAatWork: @bergmart why should it be forbidden to show archimate diagrams to business management?
• blomr: @bergmart @eaatwork Depends on level/type of business management + depends on complexity of the diagram(amount of (different) objects&rel’s)
• ArchiTool: @bergmart I’m intrigued to know why. Are they infrastructure models?
• bergmart: @ArchiTool I’m not talking about infrastructure models but business / information models
• ArchiTool: @bergmart @EAatWork Then maybe break them down into smaller focussed viewpoints?
• bergmart: I think we need to find other ways. Business Model Canvas is a much friendlier way or use the operating model stuff of Ross
• ArchiTool: @bergmart Right. Higher levels. And ArchiMate could be used in addition for more detail if needed? // Hmm….Business Model Canvas in Archi? Development of the Sketch View? #archimate #bmc
• bergmart: @ArchiTool Yes, in the architecture & engineering communities
• ArchiTool: @tetradian Synchronicity is nudging me toward possible Bus Model Canvas & Ent Canvas implementation in Archi. Reading up on it now…
• tetradian: @ArchiTool aiming to have 2 new posts for you soon: models as anchors for discussion/decision-records; roles of tools in toolset-spectrum
• tetradian: @bergmart ‘don’t show Archimate diags to biz mgmt’ – in my experience showing them BPMN diagrams is an even worse idea…
• bergmart: @tetradian Can imagine!
• EAatWork: @bergmart too complex from a modelling language point of view (archimate) or too complex because the diagrams are too complex?
• bergmart: @EAatWork Both
• EAatWork: @bergmart  I think that the concepts are ok but the  different relation types are causing the confusion (look all similar) for bizz mgmt
• tetradian: @bergmart @EAatWork with BPMN diags, prob was need to translate from abstract to concrete – so overlay Archimate rigour w visual images?
• ArchiTool: @bergmart But with Business Model Canvas approach maybe managers are concerned with $$$$$$ rather than architecture and internal workings?
• ceri: @tetradian @bergmart To quote @wilm on Tuesday “never ever show the entire model to ANYONE, only the view that is relevant to them” #jiscfsd
• bergmart: @EAatWork Yes, the arrows are the main problem. The concepts are ok.
• bergmart: @ArchiTool Nice  with Business Model Canvas is the combination of $$$$ with coherency.

As mentioned in that back-and-forth above, I’ve had painful first-hand experience of what happens when we show ‘formal’-type EA diagrams to executives, as described in this quoted from my book Real Enterprise-Architecture:

In our first attempt to show the true value of [a proposed] logistics early-warning system, we made the mistake of showing the process-flows [to the executive] in the form of a Business Process Modelling Notation diagram. BPMN is great for the formal modelling rigour needed by software engineers, but not for a board-level presentation: the blank stares and silence from round the table sent us away in shame.

For the next meeting, we redrew the diagram, with the exact same process-flows, but replacing the bland BPMN boxes with clip-art pictures of trucks, conveyor-belts, fork-lifts, sorting-machines, delivery staff. This time it clearly made sense: we gained our go-ahead.

These senior people weren’t ‘stupid’: when we explained it in their own terms, they understood straight away what we were aiming to do. The problem before was that they didn’t have time to learn an abstract language and translate it back into their concrete world. As architects, we did need that level of abstraction: but it was also our responsibility to each audience to do the translation from the abstract into the everyday.

This is going to be a long one… sorry…

Read more…

Over the past few weeks and months I’ve been hammering away at ideas for metamodels (or metametamodels) for enterprise architecture, with the longer-term aim of triggering development of an Open Source-style enterprise architecture toolset. So I’ve taken some time off in the past week to sit down and document where it’s got to so far. The result is now up on one of my ‘spare’ wikis under the ‘OpenFutures’ banner – see http://ea.openfutures.org/OsEATools .

The section on metametamodel design, starting at http://ea.openfutures.org/MetaModel , will, I admit, probably only make sense to a few dozen people in the whole world at best (if anyone… ). Reason is not only that it’s horribly technical and applicable to a very specific field of interest, but it’s also too incomplete to be usable as-is, it’s in text form only when it urgently needs some descriptive graphics (my apologies, but I couldn’t find any way to do them…), it assumes an underlying layer (OMG MOF) that relatively few people would know, and it is, well, still a Tom-tangle of useful ideas and probably-impenetrable assumptions… Oh well. But it’s there, anyway.

The ‘examples‘ section, starting at http://ea.openfutures.org/MetaExamples , is probably (possibly?) a bit more accessible, since in effect it focusses on how to make Zachman usable with real whole-of-enterprise variants of better-known metamodels such as ArchiMate and TOGAF. Mapping ArchiMate and the new TOGAF 9 ‘Content Metamodel’ helps to highlight what’s missing from those metamodels, and what the impacts are as we move out from a simplistic IT-centric ‘enterprise architecture’ to a true whole-of-enterprise scope; it also highlights what needs to be in scope as we move out from clean-up and strategy (steps 2 and 3 in the “Doing Enterprise Architecture” sequence – the only types of architecture work covered in TOGAF) and start to tackle real-world real-time constraints (step 4) and the real ‘nasties’ such as social-complexity ‘wicked-problems’ (step 5) and beyond. The aim in particular is to identify ‘substitutability’ – what can be substituted for what else, in architectural redesign for the enterprise.

As I say, it’s there for anyone who wants to peruse it (though if you’re working for a commercial organisation, please note the ‘legal bit‘ about copyright and the rest – this is intended as a shared Open Source resource, not merely yet another item for profit-based organisations to steal, as has happened to me too often in the past… ).

Comments / suggestions / ideas most welcome, in an Open Source-type spirit. If you want to comment directly on that site, please ask for a username / password (email me, or post a comment here with your [hidden] email); otherwise just post comments to this post.

Many thanks, all.