YEAH!

Hans Voss :
The problem with using LEGO to describe an EA is that the LEGO blocks will always fit nicely together. Whereas in a real world IT Architecture things usually don’t fit that well.

Is that really a problem given the EA context? Seems to me it would be very interesting to see how different stakeholders try to fit pieces together. It ought to make for an interesting discussion about both existing and to-be processes and systems.

Bit sad really that most of the discussion (on Twitter) revolved around whether Lego was capable of expressing an enterprise architecture or not. Would have been much more interesting to discuss how it would be different, better and/or worse.

“Since we decided a few weeks ago to adopt the leaf as legal tender, we have, of course, all become immensely rich. But we have also, run into a small inflation problem on account of the high level of leaf availability, which means that, I gather, the current going rate has something like three deciduous forests buying one ship’s peanut. So in order to obviate this problem, and effectively revaluate the leaf, we are about to embark on a massive defoliation campaign, and … er, burn down all the forests. I think you’ll all agree that’s a sensible move under the circumstances”

Nic Plum :

Yes, it arose from the depths .. what some of us call “engineering”. I realise it’s a dirty word and I should crawl back into the dark but TRAK is very much something that arose from the pragmatic needs of those on the floor plate – Colin and I were having to deliver other tasks for the ongoing development whilst doing the TRAK definition. It therefore has been developed to meet the needs we had.

Strongly agree with you there: this sounds very similar to what we went through with Australia Post (where again the need for the models arose primarily from the ‘mail network’ – i.e. trucks and depots and sorting-machines and manual processes and the like), and with Telstra (which likewise started from engineering rather than IT). In fact in both cases our main problem was to keep the IT-folks reined-in and to not assume that the world began and ended with IT… In one of those two examples we ended up taking over the ‘enterprise’-architecture unit and allowed most of them to return to a new IT-architecture unit where they could remain within their comfort-zone; in the other case the IT-centric ‘enterprise’-architecture unit pretty much imploded into increasingly-futile ‘analysis-paralysis’, spiralled into irrelevance, was disbanded, and was not replaced. In both cases we ended up using the term ‘Business Transformation’ to hide the fact that what we were really doing was a true whole-of-enterprise architecture.

Nic Plum :

Tom G :
There’s all the work (and rigour/discipline) in comparing as-was / as-is / to-be, deriving options, dealing with bottom-up real-world constraints, assisting in implementation-time trade-offs and so on.

Tom, there are a number of things here and, I suspect, again a difference in emphasis or possibly scope.

I fear we may be talking somewhat at cross-purposes here: I’m talking about the actual process used to develop the architecture itself – in other words, the equivalent of the TOGAF ADM – whereas you seem to be talking about how process is described within the TRAK metamodel/model, which is not the same. Creating views is only a small part of the architecture-process: there’s a vast amount of one-on-one or small-group discussions and the like with the various stakeholders and change-managers and project-developers and so on, all of which – for governance purposes, if nothing else – need to be understood and tracked as part of the architecture-process. But never mind, I think it’s fairly clear from your description what the practical process will be.

Again, strongly agree about ‘just-enough’ for modelling of views and requirements etc. There are time when we do need to go right down into Zachman’s ‘excruciating detail’, but it’s usually better if that fine-detail is held in some other toolset that’s more explicitly built for the purpose (such as DOORS, as you say, or the UML tools or process-modelling tools. What we do need to be able to do in the architecture-tools and/or models, is maintain a link or reference to those more-detailed models in the other toolsets – which is where wiki-type cross-reference protocols become really useful.

Another metaphor I use a lot is the comparison between photograph and holograph. If we cut up a photograph, we end up with a kind of jigsaw puzzle of very small pieces, each in very fine detail, but with nothing to link them together. If we add more detail in one place, it only applies and adds richness to that one place – it doesn’t help us much to make sense of anywhere else. But if we cut up a holograph, every one of those tiny fragments contains a picture of the whole – but in less detail. Each time we add a bit more detail in one place, it adds to the richness of every other view. The conventional metamodels and toolsets – such as Zachman, and the ‘EA’ toolsets that were derived from software-development tools – all emphasise a ‘photograph’-type concept: a swathe of fragmentary views, each of varying granularity, layering and depth of detail, yet with nothing much that would link them together. The upcoming generation of metamodels and tools, fortunately, seem to be much more oriented towards connection – such as the Archimate metamodel, for example, or what you’ve been doing here.

What we really need, as you say, is something that will help us navigate around the holograph, and orient ourselves within it, whilst always helping us to make sense of the integration across the layers and intersections and interdependencies of systems. That’s why I really like what I’ve seen so far of TRAK.

I still haven’t yet had a chance to burrow deep into the TRAK documentation and wiki – but am very much looking forward to doing so, and would certainly like to keep in touch with you on that.