I cannot say more than I agree to 500% on what you say.

PS: I said “You should be respectfull to this at the same time and not forget it either.” I meant: “WE should be respectfull to this at the same time and not forget it either.” Since I put myself in the “same bag” so to say. The WHY is the pre-requisite to any EA approach. If we skip it, then we end-up into a trap which I call: do architecture for architecture, which is useless…

Thank you for sharing your thoughts. I hope will be able to continue such discussion around a beer soon )
BR
Emeric

I’m glad the summary was useful – it helped me too.

Yes, Twitter-debates can be difficult to follow because of the scrambled timeline, but I’ll admit that in my limited experience of Wave I almost prefer Twitter. (Trying to use Wave on a netbook is not a fun experience – it may be better on a decent-sized screen.)

And yes, you’re right, I’ve been pushing so hard against the ‘EA=IT’ bandwagon for so long that it may well seem I’m anti-IT. I’m not: I’ve ‘done my time’ in IT (more than thirty years of it, now). And I’m well aware that (to paraphrase Andrew McAfee on Enterprise 2.0), EA is “not not about the technology”. It’s just that I’m acutely aware of IT’s limitations, of which many practitioners seem not to be aware. (One example: “modern business cannot run without IT!”, I’m told – but in many disaster-recovery scenarios it must run without its IT, or the business is dead…). If we look at failed implementations of BPR, for example, we see that the most common causes of failure were:

1. - failing to take enough (or any) account of the human factors
2. - an assumption that any IT-based process was necessarily better than a manual one
3. - replicating only the simple parts of a manual process by IT and forgetting the rest, failing either to rethink the process and/or to provide any manual override for unhandled exceptions (true complexity)

In other words, the potential gains of BPR were frequently destroyed by inappropriate IT-centrism (usually as a result of vendor-hype, but that’s another story). Other than in certain special and extremely expensive cases, IT can only handle simple rules or analytics – it cannot do decision-making in true complexity or true chaos (one-of-a-kind). It can of course provide decision-support in the latter contexts, but there must be a skilled human-in-the-loop in those processes. So a key part of EA is in identifying what decision-making requirements apply in each context (rule-based, analytic, guideline/heuristic and/or principle-based), and ensure that appropriate techniques and technologies are used in each case. IT provides one very important class of techniques and technologies: all I’m saying is that it is essential to understand that it’s not the only one!

We also need to be wary of another lethal trap for EA, namely business-centrism. The organisation is not the whole of the enterprise: in reality, the organisation exists and operates within an entire ecosystem of ‘the enterprise’ (at least three steps ‘above’ the organisation), which itself is part of a wider ecosystem that impacts upon but may have little direct interaction with the enterprise. If our EA does not have a solid awareness of the enterprise-ecosystem and the broader ecosystem, we will have little or no understanding of the real drivers for the business – the ‘why’ that underpins the business-architecture, and thence the information-architecture, infrastructure-architecture, process-architecture, security-architecture and so on. That’s why I push so strongly for the importance of vision, values and principles – because those are how the business connects with its wider ecosystem, and in turn define the meaning of ‘return on investment’ and the like. (Very important to recognise that monetary-return is only one of many possible value-metrics impacting the enterprise, for example.)

Better stop there, but I hope the above comments help to clarify my position. And thanks again!

Thank you for the summary! It makes this whole converstation so much clearer to me now. It really deserved to have such sum-up.

I realize by reading it that some of my comments may look odd, due to the followed time line. This is where google Wave should help a lot for such discussion, by linking the right comments to the right statement. Next time maybe ;o)

So, even if I fully agree with Jon and many more (like JP Morgenthal & others…) regarding the need to underline that EA is NOT about IT. We also need to be fair and not forget that IT is there to support business too. So even if EA is not about IT, IT is a part of EA. You should be respectfull to this at the same time and not forget it either.

BR
Emeric

Many thanks indeed for the comments, and for the gentlemanly fashion in which you engaged in that discussion!

I did indeed re-read it all with awareness that it was intended as a generic model rather than the ‘classic’ IT-centric one, and also that it’s aimed at beginners. Taken in that sense, it does work very well – it’s simple enough to be easily understood, and it does cover most of the basics. I’m glad that you say you’re going to re-work it to emphasise that it’s not IT-centric, because the field has so ‘poisoned’ by blinkered IT-centrism that that point does unfortunately need to be hammered home at every opportunity.

I like the cross-map with Archimate, and I do think it would be valuable to emphasise this, not least because AM is so good at emphasising the links *between* the boxes rather than focussing solely on the boxes themselves.

My main remaining concerns are about what happens with human-based services (because there ‘function’ and ‘capability’ are strongly separated – rather than merged, as in IT or machines – and are also much more fluid), and also how to link with the enterprise *beyond* the limits of the organisation (because business-centric architectures are almost worse than IT-centric ones, in the long run). But those are themes to discuss later, perhaps? – although they’re critically important to the architecture, they may be too abstract for a very-first ‘EA Quick Start’.

Thanks again, anyway – and continue the discussion at a later date, perhaps?

I will move onto worked examples once I have the overall model described, and I believe this will bring out the true richness of the model.

This is the model I use successfully, and much of my work is in the business domain and not IT centric.

I would also stress that the model has no assumptions whatsoever as to the existence of IT. The model can be used to demonstrate the architecture of a completely non-IT based business, and all layers and models play a part in this. There is no model in my grid that exists to support IT solutions. However in the modern world it is difficult to create an end-to-end solution that does not involve IT elements at some point in the journey.

The discussion has been hugely useful, and I will use it to guide my future posting of the remaining parts of the guide.

A final point – View my model with an open mind – pretend you have never heard of IT and pretend you have never heard of TOGAF, and then you can consider the models in their true form (rather than constrained by the limitations of these areas). I use english words and their original meaning is always meant (rather than the borrowed IT or TOGAF meaning).

Regards
Jon Ayre
The Enterprising Architect