On EA tools and paper trials

Starting point for this thread was my comment that though I agreed with Michael Ellyett that some kind of repository-based toolset was essential for enterprise-architecture, it was also necessary to trial it on paper first. Michael disagreed:

I don’t think the issue is modelling per se. It is knowledge management – and the knowledge can and should be used to form models (because they can provide insight into to particular problems).

[Another long post – better chuck in a ‘More’ link here:]

Exactly: the real role of EA is decision-support, of which IT design (which too many still think is the only role of EA) is merely one minor subset.

The feasibility of “trialing” depends what you mean by “trial”. If you mean “a test of the efficacy, safety, etc, of a new product,…” [Chambers]. Then no trialing is not feasible or useful i.e. it will at best produce erroneous results (which is what happens with EA today). Trial it on paper – is like a bit like trying to trial World-Wide-Web on paper (blogs, google etc.). The experience is enabled by the mechanism and without the mechanism the experience can’t actually be experienced. Part of the experience is the ease of use, the cost of use, the ease of producing the results etc.. [snip of example] It is inconcievable to me that modelling domain with a far more complex frameworks, 50-ish primitives, and many different audiences – can be trialed on paper.

Good point, and good example, but that isn’t quite what I meant – of which more below. One more comment from Michael

If one means “… ;examination, sometimes merely formal, of a candidate;…; a piece used as a test; …” [Chambers] then one could test in the abstract (as one may tests OO design using CRC cards). Then that is possible as an intellectual exercise – but the impediments to EA are not its theory so much as the practicality of its application – and these paper based trials won’t provide any insights into these things – i.e. effort, cost, time etc. What is more all empirical evidence suggests paper based approaches fail.

Sure, but what I’m arguing for as “a paper trial” might seem at first to be “an intellectual exercise”, but it’s much more about getting the thinking straight, because the subtle assumptions of the toolset itself can easily get in the way. It’s the same problem as trying to redesign a business-process: people’s past experience of the process becomes ‘the only way it can be done’ – and we have to get past those assumptions before we can even start.

To give just one simple EA-toolset example, most toolsets use BPMN for process-modelling: which is fine, except that BPMN assumes that the only objects are data, and the only functions are IT-based – so there’s no way to model something as basic as getting a signature on a form. (Holocentric‘s Role Based Modelling does allow us to do this, by the way.) In one of my previous gigs, the quality-management team deliberately trialled their processes on paper, using paper forms – and only after they’d proven the processes in that way, ironing out the workflows, did they then port it onto the IT-based knowledge-sharing system. It’s the same here: what we need to trial are the overall EA processes – the meta-processes, if you like – in order to select an EA toolset that provides the best fit. Otherwise we’ll end up with the predefined processes from the toolset, without any real understanding of what emphases and trade-offs have been made in their design, or how (or even why) to create work-arounds to resolve the toolset’s limitations in our own environment. (Says he, from painful experience from trying to use a horribly IT-centric toolset in two separate and very different non-IT-centric organisations… 🙁 )

I feel strongly about this because I spent a year looking at frameworks and methods – and reading all the EA literature – and I felt grossly misled when I eventually concluded – that all these EA people should have said – “Oh, and by the way you can’t do it on paper, and you need a meta-modeller to effectively enable it”.

Yeah, agreed about the frustration, and the essential nature of a visual toolset. But actually Michael’s last and almost throw-away comment is actually the most important of the lot: “you need a meta-modeller to effectively enable it”.

This is the whole point of what I’m on about here, with rethinking Zachman and the like. In its original form, Zachman is an incomplete and somewhat muddled taxonomy that is frequently misunderstood and misused as a kind of base-level solutions-framework – and a hopelessly inadequate one at that, even within present-day IT (such as for presentation-layer design, as Michael points out), but especially as we start to move beyond the constraints of the IT-centric world. Each organisation is different: each organisation needs its own meta-model, its own taxonomy. This can be based on an existing meta-model: but it’s very rare that we can use an existing meta-model direct. So the first requirement for the first usage of an EA tool is that it supports that meta-model development. Pretty well every toolset does now at least make it possible to do some kind of amendment of the meta-model: but in most cases, to say that it supports it – makes meta-modelling easy, as a core activity – would be somewhat over generous… 🙁 Sure, meta-modelling is not easy: but it would help if the toolsets didn’t make it a damn sight harder than it needs to be…

So what I’m on about here is creating a taxonomy that actually works: real primitives that cover the whole of the enterprise scope. Which, yes, means something that’s way, way too abstract for direct business use – at least a couple of layers down even from the meta-model – but which provides a solid, stable foundation for meta-model design, which in turn provides a stable foundation for business-level ‘primitives’ and business-oriented perspectives and so on.

I know I’m being a bit obsessive about this. But it’s only when we’ve got that sorted out – the root-level taxonomy, the real primitives – that we can start developing something that we can use. Otherwise when we try to do real enterprise-level architecture, we’re stuck with whatever a poorly-scoped, IT-centric EA toolset will give us. And frankly, by comparison, struggling with paper is sometimes a better bet… ::wrygrin::