Abstruse arguments on EA frameworks

Been having a long interaction on Twitter over the last couple of days with Jon H Ayre (otherwise known as ‘The Enterprising Architect’, @EnterprisingA) and others, about enterprise-architecture frameworks.

(If you’re not interested in enterprise-architecture, probably best to skip this one, as it’s gonna be long; otherwise click on the ‘More info…’ link.)

The starting-point was a post by Jon about the next part in his ‘EA Quick-Start Guide‘:

EnterprisingA: Have just posted Part 3 “Getting Down to Business” of my quick start guide to EA focusing on the Business Architecture http://bit.ly/4UKiCM

The key image of the framework (which I emphasise is ยฉ Jon H Ayre) is this:

EA Business Layer (c) Jon H Ayre

EA Business Layer (c) Jon H Ayre

And the previous two parts to the series are (Part 1) ‘How to set up an EA practice‘ and (Part 2) ‘The big picture‘.

I like Jon’s work a lot, so duly re-Tweeted Jon’s announcement, but added the comment:

<is for IT-centric ‘#entarch’, but still definitely useful

Which kind of triggered off quite a storm of back-and-forth Tweets:

  • EnterprisingA: @tetradian It is not IT arch. Doesn’t even mention it! It is business arch successfully used by bus
  • tetradian: @EnterprisingA to me, anything that uses the structure ‘Business’, ‘Application’, ‘Infrastructure’ is an IT-centric arch // Real *enterprise* architecture starts several steps beyond org; some activities may not touch IT (‘Solutions’, ‘Data’) at all // You have one of the best descriptions for IT-centric architecture, but it doesn’t go far enough for *enterprise* architecture // Crucially, your frame barely touches the people-space – knowledge & information vs data, manual-processes vs IT-apps, etc
  • EnterprisingA: @tetradian Forget you ever heard of IT then read my guide again. E.g. Trucks are infrastructure. Paper ledgers are applications // There are solutions without IT and data without IT. These are english words borrowed by it. // [If] all you expect to see is IT then that is what you’ll see. But i didn’t mention it.
  • tetradian: @EnterprisingA yes, agree re truck=infrastructure, but when would you hear of a paper ledger described as an ‘app’? also where are people?? // …so yes, I take your point, but it still seems a bit of a stretch, and nothing like explicit enough. For me, anyway. ๐Ÿ™‚ // point is about language used – non-presence does not help, we need to be explicit (apols for being a pain on this, BTW)
  • EnterprisingA: The problem is not the words. The problem is that IT think they only apply to IT. When i talk to business they don’t see IT. // If i ask someone to describe their solution and they only tell about IT parts is it my fault or theirs?
  • tetradian: given the huge predominance of the (erroneous) belief that EA=IT, we do need to be explicit each time we use the term // ..so yes, it’s their ‘fault’ in failing to grasp that EA > IT, but also our fault if we make it easy for them do it! ๐Ÿ™‚
  • richardveryard: @EnterprisingA @tetradian All descriptions are incomplete. We tell a story based on what we judge relevant to a particular context.
  • EnterprisingA: @tetradian Point taken. I will amend my guide to include regular reminders that my model is not referring to IT but the full scope of ea.
  • tetradian: @EnterprisingA Great! – apologies for having been such a pain, the aim was to make a (very) good model even better – hope it’s helped?
  • leodesousa: @tetradian @EnterprisingA been following your conversation … good discussion. Highlights the challenges we have as EA’s about defns
  • pauljansen: @tetradian @EnterprisingA Great exchange! Reminding us Information (only) is the meaning the receiver gives to a message.
  • EnterprisingA: @tetradian It did help. Appreciate the feedback. It’s a challenge getting IT to accept the wider use of some words so clarity will help // The people are in various places in the model, but for starters in the Services and Organisation models (the people are the org) // The Application layer was the only name on the grid I had issues with but couldn’t find a better one (given its pre-IT meaning)

And there it settled down for the night. This morning I duly re-read the article with a lot more care, and also taking care to expand away from any implicit but unintended IT-centrism. But I had to admit it still didn’t work for me.

The problem is that it’s actually very close to Zachman’s very first model, which Zachman himself very quickly realised was too limited: a simple structure with three columns ‘What’, ‘How’, and ‘Where’. These columns are almost identical with Jon’s ‘Knowledge’, ‘Behaviour’ and ‘Structure’ respectively. There’s an even closer map to Archimate, whose columns are ‘Information’, ‘Behaviour’ and ‘Structure’, with the layers ‘Business’, ‘Application’ and ‘Technology’ – just about the only difference being that Archimate is still noticeably IT-centric whereas Jon emphasises that the framework needs to extend IT. Which is fine if all you’re doing is a conventional TOGAF-style architecture, which regards the business as ‘the enterprise’, and makes a whole load of assumptions about events, people, and the all-important ‘why’ for the business itself. So, perhaps unwisely, I said so: which triggered off another even larger flurry of Tweets:

  • tetradian: r @EnterprisingA reviewing your model again http://bit.ly/5fVaqu , it does align very well with Archimate http://bit.ly/7wYASP … // …but it provides no space for what I’ve found utterly essential for all #entarch: the question ‘Why?’ // r @EnterprisingA Without a rigorous, insistent emphasis on ‘Why’, we’re likely to build an #entarch that is efficient but useless // r @EnterprisingA The question ‘Why’ must extend far beyond the org, to describe the context in which the business and its #entarch exist
  • enectoux: @EnterprisingA @tetradian instead of asking for solution directly. Try to express your need.
  • EnterprisingA: @tetradian Archimate aligns with TOGAF & my model to an extent as they all share some common wisdom (with variations) p.s. I like Archimate // The “why” is required to support the influencing and comms activities but is not part of the core model (which gives the answer). // Rigorously and insistently focusing on “why” can happen without it having to end up as part of the resulting model.ย  // Just because there isn’t a box called “why” and a box called “who” doesn’t mean they aren’t embedded in the models.
  • richardveryard: @EnterprisingA @tetradian “WHY” can be outside the model only if we assume a single centralized “FOR WHOM”. (viz homogeneous enterprise).
  • tetradian: r @EnterprisingA: agree re Archimate, disagree strongly re ‘Why’ – architecture will fail if ‘Why’ is only implicit, esp. at Vision level // If ‘Why’ and Who’ (and ‘When’, and RV’s ‘For Whom’) are not explicit right from the start, where are they in the models?
  • tetradian: @richardveryard @EnterprisingA emphasis on ‘For Whom’? – we would then need to ask ‘*why* for whom?’ – ‘why’ needs primacy! ๐Ÿ™‚
  • EnterprisingA: @tetradian Architecture is one piece of the jigsaw, not whole shooting match. For context read http://bit.ly/186KOb & http://bit.ly/soIrc // @tetradian I feel (perhaps wrongly) that you are assuming the Architecture World Domination position (I am not a fan of this position).
  • richardveryard: @EnterprisingA I think you are being unfair to @tetradian . It is plurality of stakeholder and actor that forces these things to be explicit
  • tetradian: r @EnterprisingA in http://bit.ly/186KOb you say arch-skeleton must be broad, yet here you’re artificially narrowing it – why?
  • EnterprisingA: @tetradian In my Bus layer “Organisation” model shows who, when, where and for what purpose. “Service” model shows what and for whom. // My Infrastructure layer shows with what and how. My app layer shows in what order/sequence and for what purpose.
  • tetradian: r @EnterprisingA http://bit.ly/4UKiCM is a great frame for TOGAF/Archimate detail, but does not provide space for Enterprise-level ‘Why’ … // …Enterprise ‘Why’ etc is not ‘ArchWorldDomination’, but skeleton/frame large enough to describe business *context* …ย  // …TOGAF etc fail as EA models where they fail to provide space for enterprise context (3 or more layers beyond ‘Business’) //ย  …all of What/Who/Why etc (see http://bit.ly/NZYS3 ) need to be explicit right out to all Enterprise layers
  • EnterprisingA: @tetradian Agree absolutely; we need to ask “why”, but we are discussing where it goes in the model and in what form.
  • EnterprisingA: @tetradian Broad yes, answer yes, working’s out/reasoning? Not necessarily – depends on environment and context. // Perhaps an example of what you consider to be “why” is required for clarity? It is possible we are agreeing without realising. // An example would help as I believe I have that covered but might be misunderstanding what you are saying
  • tetradian: r @EnterprisingA examples see slidedecks ‘Vision Role Mission Goal’ http://bit.ly/13xBGd and ‘What Is An Enterprise’ http://bit.ly/8wWNSq .. // ..just about *none* of these are covered in your Business-layer descriptions for Services, Organisation or Information // Remember we’re only talking about the skeleton/frame here – reality is that the frame will never be fully populated.. // ..arch-frame *must* cover whole-Enterprise scope, or architecture will fail wherever it makes assumptions across boundary
  • EnterprisingA: @tetradian Then either I have not been clear enough in my descriptions or the detail has not yet been documented in my series of articles // For fear of becoming repetetive, and example of your choosing would help, and then I can explain where it fits?
  • tetradian: @EnterprisingA prime example: Enterprise vision/values vs org/business vision/values, and interactions between: where is that in model? // next example: anchoring between market, business-model (#bmgen http://bit.ly/OzZh0) and Business-layer services // Lower-level example: distinction b/w function & capability in services (are merged in IT-services, but separate in manual)
  • EnterprisingA: @tetradian Once more I agree (as I do with most of what you are saying) but IMO this is covered by my model.
  • tetradian: @EnterprisingA *where* is it “covered by my model”??? – at present it’s all implicit, and does not cover enterprise-beyond-org at all
  • EnterprisingA: @tetradian Too general for me still (sorry) – a specific example of two such interacting visions?
  • tetradian: r @EnterprisingA conflicting visions/values (real from current client): business profit vs clients refusing to be source for that profit! // unify via shared vision of ‘managing risk/opportunity’ (otherwise loss of trust/reputation – real issue for my client) // Need to carry links to that unifying vision right down into lowest-level details of architecture, as stable ‘guiding-star’
  • EnterprisingA: @tetradian If I understand your example, covered in linkage between the Service model (in bus layer) and Capability model (in App layer)ย  // I’m still laying out the approach at the moment. There is more depth to come, but I am laying out the broad model at the moment.
  • tetradian: r @EnterprisingA if you leave it until the links b/w Service and Capability, you’ve left it far too late – must be in from the very start
  • EnterprisingA: @tetradian I agree with your last 5 tweets and I hold that this is covered by my model (and I wouldn’t suggest leaving the links til last)
  • tetradian: @EnterprisingA great! (still disagree slightly, but what the heck! ๐Ÿ™‚ ) – apols again for pushing so hard, your model is worth the effort
  • enectoux: @tetradian Guys. I tried hard, but it’s a bit hard to follow you conversation. Too much ideas & misunderstanding at the same timeโ€ฆ // Right.This is basis. Now challenge is to describe it through the right model & translate it to make it understandable by business // Get down to the atom level: business object.
  • enectoux: @tetradian I guess you are speaking of goal model. Still unsure to understand you right.
  • tetradian: @enectoux apologies for long/too-detailed conversation – there were (are) some fundamental differences there in #entarch philosophy // Agree “get down to the atom level”, but business object applies only at business layer – other layers have other atomic objects // “I guess you are speaking of a goal model” – goal is the lowest layer, but also goes up above e.g. Business Motivation Model

There we’ve left it for now. I’m still far from happy: at least it is a model that understands some of the world beyond IT, but to me it doesn’t go anything like far enough – as I said in the Tweets, there’s no real space for events, for people, or for ‘why’, nor any real means to handle physical objects (as in Archimate and BPMN, we’re sort supposed magically to realise that it’s an analogue of ‘Knowledge’, and we can put it in there). Yet I have to admit that it probably is the level of simplicity that newcomers to the field will need: what worries me is that they’ll get used to that simplicity, and think that that ‘is’ EA, when in reality the picture needs to be a lot bigger, and should really have been that larger scope right from the start.

Enough – this is a long enough post already! But it did at least seem worthwhile keeping of a record of the conversation, anyway.

Tagged with: , , , ,
5 comments on “Abstruse arguments on EA frameworks
  1. A good summing up of the conversation (it felt so much more confused while we were having it, but makes more sense read as a single flow). Thank you for the summary. Your conclusion leads me to believe that our apparant disagreement arises from the fact the the structure of my model looks similar to TOGAF and Archimate, and it is therefore easy to assume that the content of each model is similarly limited and tunnel visioned. I would stress that it isn’t, and there is much more in each model than might at first be thought. I am only on step 3 of the guide, and as it is a quick start/beginners guide, I am trying to start simply and build from there.

    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

    • Tom G says:

      Hi Jon

      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?

  2. enectoux says:

    Hello Tom,

    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

    • Tom G says:

      Hi 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!

  3. enectoux says:

    Hi Tom,

    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 :o)
    BR
    Emeric

Leave a Reply

Your email address will not be published. Required fields are marked *

*