Spot the difference

“How do I loathe thee, TOGAF? Let me count the ways…”

In case anyone thinks that I’m just ‘TOGAF-bashing’ for the sake of it, I do believe that TOGAF has genuine value for what it was originally designed to do, namely architecture of enterprise-wide IT-infrastructure.

TOGAF 8.1 was actually pretty good at that, though by 2009 it was an urgent need of an update. Yet as I wrote back in February 2009, after the TOGAF 9 launch, to me TOGAF 9 represented a huge missed-opportunity, a disastrous hubris-laden wrong-turn. There were two choices: either stay with IT-architecture, and really develop the meta-architectures so as to make it self-updating to each change in technology (which was well within Open Group’s capabilities and remit); or go all-out to support a true ‘architecture of the enterprise’ (which, as an IT-standards body, Open Group was perhaps not well placed to do). In the end, they chose the worst of both worlds: a vaguely-revamped static framework that couldn’t keep pace with technological change, and that retained the inherently IT-centric ‘BDAT-stack’ yet also pretended that it would still work beyond IT (which, by definition, it can’t).

To be blunt, the current version of TOGAF looks like, and is, a classic example of a framework cobbled together out of disparate parts by a 200+ person committee. There are some excellent bits in it – my favourite is probably Bob Weisman’s work on capability-architectures – but overall it’s best described as a bloated, hugely-oversized, often-misleading, largely unusable mess. Even the ADM is a badly-reworked PDCA loop, with a misleadlingly-constrained ‘Act’ phase (ADM Phases B/C/D) and virtually no ‘Check’ phase (no ‘benefits-realisation’ or ‘lessons-learned’ in ADM Phases H/A).

Whilst TOGAF 8.1 was an IT-architecture framework that was good at what it did but needed some updating, TOGAF 9 and 9.1 are less-complete IT-architecture frameworks that are desperately pretending to be more than they are, and in practice are just-about usable only for the kind of now quite old big-IT that’s still in use only a specific subset of industries such as banking, insurance, finance and tax. There’s almost nothing in there that will help much, if at all, with mobile or social or internet-of-things or embedded health-technologies or ‘human apps’ such as Amazon’s ‘Mechanical Turk‘, or even key aspects of IT-disaster-recovery, because those are all contexts in which the human is deeply interwoven with the physical-machine is deeply-interwoven with the IT-technical is deeply interwoven with enterprise-purpose – whereas TOGAF and Archimate and the like only tackle the IT, leaving everything else as a supposedly all-but-irrelevant afterthought, a Somebody Else’s Problem.

The catch is that, as enterprise-architects, we are that ‘Somebody Else’: it’s our Problem. And we need real usable tools and frameworks to help us with that problem. Yet despite its vaunted claims to the contrary, TOGAF 9.1 is most definitely not one of them: it’s unsuited for the purpose, right down to the deepest roots of its internal architecture. But because it sits there like a dog-in-the-manger, hogging almost the entirety of that space, we’re stuck: none of us can move forward until we have some means to fix the resultant TOGAF-driven IT-centric mess.


To illustrate the point, let’s start with the centrepiece for TOGAF, the ADM (Architecture Development Method), and play a quick game of ‘Spot The Difference. Before we do that, let’s first have a quick check of the criteria for a framework that could actually work at a true whole-of-enterprise scope:

  • It needs to be able to cover any scope and context, consistent yet self-adapting to all those different contexts.
  • It needs to be able to work on any subsets of the overall scope, whilst still retaining full connection to that overall scope.
  • It needs to be able to work with and develop for often-extreme uncertainty.
  • It needs to support the full range from big-picture to detail-level, and from vision and strategy to implementation and operation.
  • It needs to support continuous-learning and continuous improvement.
  • In a business-sense, it needs to support real business-value.

Given that list, let’s play Spot The Difference on the TOGAF ADM, versus an alternate methodology that follows what, on the surface, might seem to be the same structure:

(Click on the graphic to expand it, if need be.)

No doubt you’ve noticed all of the differences. But have you noticed why the differences exist, and what they imply in practice?

The graphic on the left side of that ‘Spot The Difference’ summarises a method – the standard TOGAF9 ADM. And as a method, it’s optimised for use in precisely one type of context – a specific form of IT-architecture – and in practice is too constrained to do almost anything else:

Implicit from the arrows on the graphic is that it is possible to use it in a non-linear way – though this is barely described in the documentation, with no actual instructions on how to do it.

The graphic on the right side of that ‘Spot The Difference’ summarises a metamethod. And as a metamethod, it can be used either as-is, or in a self-adapting way to create context-specific methods for any type of scope and context – including (if with some twists) the TOGAF ADM itself:

(Note that it’s not that there’s no scope in Phases B, C and D, or that the scope is always an impossible ‘The Everything’ – but rather than the respective scope for the iteration is identified and defined in Phase A. That means that we can work on any scope, including subsets, supersets or intersecting-sets of the current scope, recursively, yet still do so in way that is clearly identifiable and appropriately-constrained for the current iteration.)

Implicit from the arrows on the graphic is that it can likewise be used in a non-linear way – but also fully-recursive, via the ‘any scope, any scale’ structure of Phases A to D.

(To be pedantic, that graphic on the right is itself an instance of a metametamethod for continuous-change and continuous-improvement. of which, for example, PDCA, OODA and the classic Tuckman ‘Group Dynamics’ project-cycle are other instances.)

Nothing much wrong with having a method like that of the ADM, that only works well with one type of scope and context, of course – as long as that scope and context are all it’d be used for.

The catch is that, courtesy of the hype-machine that is behind TOGAF these days, the graphic on the left is insistently marketed and ‘sold’ as if it’s the graphic on the right – as if the tiny subset of scope that the TOGAF ADM can cover is all that anyone would ever need in enterprise-architecture. Which it isn’t.

Which, since TOGAF can’t actually handle anything more than a very narrow type of scope – because that scope is hardwired right into its very structure – makes life very difficult indeed for those of us who do work at wider scopes and the rest of that list of criteria near the start of this post, and have to spend inordinate effort tidying up the TOGAF-created mess.


But as enterprise-architects, that’s just the start of our TOGAF-created woes… Here are a few more:

Pseudo-‘non-proprietary’ versus real non-proprietary

Proprietary frameworks are bad news all round: that’s all that need be said on that.

Open Group do claim that TOGAF is ‘non-proprietary’. Yet I’d put quotes around that assertion, because calling TOGAF a ‘non-proprietary framework’ really is a stretch too far: it may be true that we might not have to pay to, uh, look at it, but that’s about it. ‘Freemium’, just possibly: but the kind of ‘freemium’ that we can’t act do anything useful with unless we pony-up on the in-app purchases…

That’s because TOGAF itself is too incomplete to use ‘as-is’: there are key chunks missing, which means that it is, in effect, misleadingly useless, giving the impression of usability without actually providing it – kind of like a car that looks all shiny and new and ready to go but with key less-visible components like the drive-shaft and the steering-rods somehow just not there. In fact on its own, ‘out of the box’, the only people who could use TOGAF are those who already know enough real-world EA to be able to do without it – so the whole thing is all a bit moot anyway.

To make this ‘standard’ ‘non-proprietary’ framework usable in real-world practice, there’s a sizeable training-industry, all of it licensed at a fee to Open Group, and at serious cost to participants: back-of-the-envelope calculation suggests mid- to high tens of millions of dollars so far, and rising. And then there’s the ‘certification’: tested by multiple-choice exam – exactly how not to do skills-evaluation – and again a ‘nice little earner’, currently in the low tens of millions of dollars. ‘Non-proprietary’? Marketing hype-machine, yes, but ‘non-proprietary’ in any real sense of the word? – I think not…

True non-proprietary frameworks for EA do indeed exist: Kevin Smith’s PEAF and POET pairing is one that comes immediately to mind. Milan Guenther’s book ‘Intersection‘, on enterprise design, and Marlies Steenbergen and Martin Van Den Berg’s ‘Building An Enterprise Architecture Practice‘, on the DyA framework, are a lot more complete and usable than TOGAF, and also both come close to true non-proprietary, too: to get the full detail you’d have to buy the book, but that’s all.

To me the ideal would be some form of open-source architecture-framework – but it still doesn’t seem to be happening in any workable form as yet. Oh well.

Enterprise-as-scope versus enterprise-as-domain

This is probably the single most misleading mistake in the whole of TOGAF, yet in some ways one of the hardest to see: conflating ‘enterprise’ as a scope, with ‘enterprise’ as a domain in its own right.

In its Introduction, the TOGAF specification does define ‘enterprise’ in several ways: an organisation, a consortium of organisations, and so on. But what it doesn’t do is say – anywhere, as far as I can tell – that this is merely the scope of interest, to which all of the following specification would apply. It’s IT-architecture at an enterprise-wide scale, yes – but that’s not the same as ‘enterprise-architecture’, the literal ‘architecture of the enterprise’, where the enterprise itself is the domain of interest.

As described in the post ‘Organisation and enterprise‘, the scope we actually need to explore – the respective ‘enterprise’ – for any given architecture is at least two to three steps larger than the main scope of interest. At a whole-of-organisation level, for example, the respective ‘enterprise’ that we’d need to explore stretches way out beyond even the organisation’s business-market:

Yet TOGAF strongly implies, throughout the specification, that the organisation itself is ‘the enterprise’, the ultimate boundary of any architecture. As described in that ‘Organisation and enterprise’ post, this has serious consequences if we try to apply it at a business-architecture level, and often below that level as well.

That one double-error of conflation – perpetrated and perpetuated throughout the entire specification – leaves the framework wide-open to risk of perpetrating really serious term-hijacks, in which a tiny subset of a scope pretends to be the whole, blocking out the view of anything other than itself. Which is precisely what we see next, with the bewretched ‘BDAT-stack’…

BDAT-stack versus real-world

Like Archimate, which in essence follows the same pattern, TOGAF purports that the entirety of an enterprise-architecture can be split into exactly three sub-architectures:

  • Business Architecture
  • Information-Systems Architecture
  • Technology Architecture

In TOGAF itself, Information-Systems Architecture may optionally be split into Data-Architecture and Applications-Architecture – hence the respective initials that give us that acronym ‘BDAT’, ‘Business, Data, Applications, Technology’.

Looking closer at the specification, it quickly becomes clear that each of these ‘architectures’ revolves entirely around what we might call ‘big-IT’ – the kind of systems run by an ‘IT Department’ of a large organisation of perhaps half a decade ago. It’s really obvious, for example, that the supposed ‘Business Architecture’ is barely about business at all, but could instead be summarised by the phrase ‘anything not-IT that might affect IT’.

The BDAT-stack is actually quite a good description of what’s needed for a big-IT infrastructure-architecture, where – in terms of that ‘enterprise’ model just above – ‘Information-Systems Architecture’ is the metaphoric equivalent of ‘suppliers and customers’, and ‘Business Architecture’ is the metaphoric equivalent of the ‘market’-space for that big-IT. But we need to realise that that ‘enterprise’-model won’t work upside-down:  looking ‘up’ the stack is like looking upward from the bottom of a well, but looking ‘down’ the stack needs to take into account the whole context – of which the well itself is only one small part. Given that in most large-organisations their big-IT accounts for less than 10% of overall spend – and often a lot less than that – then it should be clear trying to claim as ‘enterprise-architecture’ an architectural model that can at best only describe perhaps one-tenth of the organisation’s concerns is somewhere between laughable and downright dangerous.

Let’s be blunt about this: the real world contains a lot more than just big-IT. Which means, also bluntly, that the ‘BDAT’ stack – fundamental to both TOGAF and Archimate, and the basis for Phases B, C and D in the TOGAF ADM – is misleadingly unusable for anything beyond IT-infrastructure architecture. Its descriptions even of Information-Systems Architecture, let alone Business-Architecture, are too incomplete and too misleading to be used for anything more than that.

TOGAF metamodel versus real-world

There’s quite a nice metamodel in TOGAF 9, and nicely extended in TOGAF 9.1. It’s a very nice summary of the entities needed to describe a big-IT infrastructure and its business-context. But that is all that it can or should be used for: period. It’s usable solely for a very small subset of the enterprise: yet what we need – even for a real IT-architecture – must, by definition, be able to describe anything in that real-world enterprise. Which, unfortunately, the TOGAF metamodel actively prevents us from being able to do.

If you doubt this, try using the TOGAF metamodel to describe any whole-of-context business concern such as security or disaster-recovery, in which human activities and mechanical structures are necessarily ‘equal-citizens’ alongside the IT-based apps. Try using it to describe the relationships between information about a parcel, versus the parcel itself, in a logistics context where something’s gone missing. Try using it to describe the whole context for mobile, social, programmable-hardware, an assembly-line, even a data-centre – let alone anything that centres more around physical-machines or people. It doesn’t work: many if not most of the entities we need simply don’t exist in the metamodel – and its arbitrary, unexamined assumptions just get in the way.

In other words, it’s yet another darned term-hijack. Frustrating, to say the least…

Predictable-world versus complex-world

The BDAT-stack and the TOGAF metamodel lead inevitably towards an IT-centric architecture. Which is fine, of course, in those specific cases where the IT is the centre of concern – but a huge problem when it isn’t.

One of the more subtle dangers of IT-centrism – or anything-centrism, actually – is that it tries to remake the world into its own image, constraining our view of that wider world. In the case of IT-centrism, the only world it can handle is one that is built around predictable rules and algorithms – a world of order, as indicated on the left-hand side of the SCAN frame:

The real-world, however, always includes ambiguities, uncertainties and other forms of unorder. Which means that a framework that barely acknowledges even the existence of such things – let alone their real-world prevalence – is inevitably going to be deeply misleading.

More than that, on its own IT can only handle tame-problems – problems with a definite true/false answer. The reality, though, is that the real-world consists primarily of ‘wild-problems‘ – of which seemingly-‘tame’ problems are merely an often-illusory subset, subject to ‘variety-weather‘, ‘requisite-fuzziness‘ and similar deep-uncertainties:

IT is great for mass-sameness, of course. The catch is that the very characteristics that make it great for mass-sameness are those that make it often deeply-unsuited to mass-uniqueness – which, in reality, resides right at the core of many industries and domains, such as healthcare, customer-service, retail, marketing, sales, agriculture and information-search. The inherent IT-centrism of TOGAF and the like is really unhelpful whenever we need to develop enterprise-architectures for such domains.

Predefined reference-architectures versus how to create a reference-architecture

Yet another frustration: reference-architectures. At present, the two TOGAF reference-frameworks – TRM and IIIRM – are both so long out-of-date that at one Open Group conference, Allen Brown himself recommended that they should be dropped.

But rather than a mere replacement reference-architecture that will likewise go out of date in a couple of years at most, what we most need instead is advice on how to create and maintain a reference-architecture – perhaps using the existing TRM and IIIRM as worked-examples. We also need such reference-architectures to explain their respective ‘It depends‘ constraints and variances – at least to the level of the MoSCoW set, as a minimum.

Yet there’s still almost nothing at all on that in the so-called ‘standard’. Bah.

Apprentice-level versus journeyman-level

This is another subtle one, though in part it follows directly from the IT-centrism problems above. More specifically, though, it’s about where TOGAF and, in particular, TOGAF training sit on the skills-development spectrum:

Where it sits is primarily at the earlier stages of the Apprentice phase, where the learner is just starting to move out of ‘follow-the-instructions’, and move ‘upward’ into the first levels of the theory behind those instructions. Yet the focus is still on rote-learning, ‘by the book’: it’s all theory, there’s no requirement for real-world practice.

And without that grounding in practice, there’s a huge, huge risk of ‘illusory superiority‘ – delusions of assumed competence that just does not exist in reality. The danger – and I’ve seen it displayed way too often, on LinkedIn and elsewhere – is that ‘newbie’ TOGAF trainees have just enough knowledge to get into serious trouble, and nothing like enough knowledge to be able to get out of that trouble on their own, yet believe that they alone know everything about enterprise-architecture. In too many cases, the only way to bring such people out of their over-certainties, and on towards the journeyman-level skills that they need for real-world enterprise-architecture, is to get them to unlearn every scrap of what they’ve learnt on their TOGAF course, and start again from scratch. A heck of a waste of effort all round… and a huge frustration in dealing with wave after wave of – let’s be blunt – idiots who think they know everything about enterprise-architecture solely because they have a TOGAF certification to wave around. Sigh…

Rote-learning certification versus skills-certification

Certification, ah, certification… probably the biggest bugbear about TOGAF that most of us have in enterprise-architecture, bluntly.

The TOGAF certification comes in two parts: Level 1 (Foundation) and Level 2 (Certified). In essence, Level 1 tests whether the candidate knows the terminology; Level 2 tests knowledge of the full specification.

Both of them are only at a rote-learning level: they can’t be more than that, because a TOGAF training-course is only a few days’-worth at most. There’s no skills-test at all – and the whole thing is tested via machine-based multiple-choice exam, which is exactly how not to test for skills-knowledge.

Given – as above – that several key parts of the TOGAF specification are not merely incomplete but just plain wrong, then all that ‘certification’ means is that someone has read wrong material well enough to pass a multiple-choice exam that has no connection whatsoever to any real-world context.

(Yes, I do know that Open Group’s ‘Open-CA’ certification does require real-world knowledge. TOGAF certification doesn’t: it solely tests rote-knowledge of the book itself, not real-world knowledge – in fact answering the test-questions correctly in terms of real-world practice will often incur a penalty on the test-score. Sigh…)

So in effect, TOGAF certification tests whether you’ve learnt the content of the book, which itself doesn’t connect much or, in some areas, at all, with real-world practice – in other words, not far off a work of wistful fiction. And, starting from that already largely-fictional story, it then demands true/false answers for decision-contexts that in real-world practice are always riddled with ‘It depends’ contextualities. In what possible way could anyone claim that that would be anything other than meaningless, or worse?

Yet various folks still seem kinda uncomfortable about that kind of interpretation:

The certification itself, like any certification, can’t mean any more than that [someone has been tested for rote-knowledge], and doesn’t purport to.

Correct that it can’t mean any more than that, and certainly that it shouldn’t. But given that just about every lazy darn recruiter uses the TOGAF ‘certification’ as a tick-the-box test not just of purported knowledge but of competence and skill, and that Open Group and, even more, its trainer-community actively promote it as such, we know that that assertion that “doesn’t purport to” is just not true. It’s arguable that the implications of that fact are primarily Open Group’s problem, not ours – but I really do wish that they’d do something more useful about it than merely trying to silence the critiques and pretend that the problem doesn’t exist…

Instead, if perhaps unsurprisingly, Open Group seem very happy about TOGAF certification, as evidenced in this Tweet from a few days ago:

  • TOGAF 9 Certification News: Total passes 37,000. Level 1=11445, Level 2=25878

And yet I don’t know whether to celebrate on their behalf, or weep for the rest of us. The latter, mostly… This supposed success of TOGAF in the marketplace is actually a ‘success’ that, as we can see from all of the above, is built on exactly how not to do ‘the architecture of the enterprise’ – which means that the real mess is getting worse with every passing day. For everyone’s sake, it really is time that all of us should call a halt on the TOGAF hype-machine, and put that bewretched ‘EA’-framework back into the IT-only box where it does and must belong.

Okay, you might think that a lot of those complaints above might seem a bit extreme: TOGAF does have some value, after all, if only for some specific types of IT-architecture. As one participant in a LinkedIn thread commented:

lets not throw the baby out with the bathwater

Yet for ‘the architecture of the enterprise’, turns out there is no baby in the TOGAF bathwater – just a rubber duck, a worn-out blob of soap, and a couple of mismatched socks left over from last week’s washing. Nothing much that’s worth keeping, anyway.

Storm in a bathtub, mostly. But with a lot of money riding on it, hence a lot of dollar-laden delusions too.

Why do I loathe thee, TOGAF? Let me count the ways…” Well, that’s some of the ways and whys, anyway.


Posted in Business, Complexity / Structure, Enterprise architecture Tagged with: , ,
14 comments on “Spot the difference
  1. Peter Bakker says:

    As an expert in IT-centrism (working more than 25 years in the IT infrastructure business now) I must disagree!

    IMHO the BDAT-stack, TOGAF and especially ArchiMate are not very useful (understatement) for IT-infrastructures because they don’t follow the “Use real-world rules about how things relate to each other to improve efficiency. Use knowledge to eliminate the mundane and speed critical decisions. Pay attention to the details” principle (from the BIG BIM, litte bim book).

  2. Tom,
    TOGAF establishes many unemployable practices that leave the trainee and practitioner bewildered in practice.

    Take for instance:
    1. the requirements bubble at the centre of ADM makes no sense.
    It is the strategy not the requirements that drive the enterprise transformation and target EA.
    Requirements are collected only for solutions architectures. Imagine the mound of requirements collected for the whole enterprise.

    2. It is the enterprise vision in the preparatory phase rather than architecture vision because the latter may only result later after the gap analysis and modeling anyhow.

    3. No clear target architecture specification phase

    4. Requests for architecture work that nobody asks for and ever asked for in reality

    And many other issues such as you exposed plus limited number of views specified, the contradictions in fundamental terms within, the lack of consistency…, the mere size, the incomplete metamodel that does not align with Archimate’s…

    But if you dare state today that TOGAF has fundamental flaws you experience the wrath of the TOGAF community because you affect their credibility.
    I hope that TOGAF community is open enough to discuss an objective opinion rather than ignore it, keep a moody silence or execute the messenger.

    It is high time that professionals with reputation in the field do something for this discipline that is besieged by unprofessionals, faux frameworks, trainings, certifications that take advantage of the EA confusion.

    • Tom G says:

      Agreed. No doubt some people would say that my work is ‘faux frameworks’, too. 😐 But yes, we do need to do something concrete about it, rather than solely complain about the many ‘failings’ of TOGAF when people try to use it outside of the domains for which it was originally intended.

  3. Mike Glendinning says:


    yes, indeed TOGAF is basically “junk”, as I have been telling clients for many years, often to their surprise.

    Unfortunately, we seem to have few other options for the foundation on which to build a more professional approach to EA and to drive out the imposters and charlatans.

    Yes, there are many other frameworks as well as organisations dedicated to the “professionalization” of EA, but as far as I can see most of these are not that much different to TOGAF and none has really achieved the critical mass needed for success.

    I have serious doubts whether the Open Group is the best organisation to create and manage an EA framework, but to their credit they have managed to create a fairly successful market around TOGAF training and accreditation.

    The sad fact is, being TOGAF certified is just about the only way an individual can mark themselves out today as being a professional enterprise architect. Because of the shortcomings of TOGAF, this is both meaningless and dangerous. Moreover, it creates a serious problem for the industry as well as those of us who really practice EA!

    So what to do? I don’t know. Stop calling what we do EA and distance ourselves from things like TOGAF, perhaps? Try and force the Open Group into relinquishing control of TOGAF and allow it to be updated by real practitioners? Endorse some other framework and/or organisation? Start something entirely new?

    None of the options seem particularly appealing to me right now. What do you think?


    • Tom G says:

      @Mike: “Unfortunately, we seem to have few other options for the foundation on which to build a more professional approach to EA and to drive out the imposters and charlatans.”

      Agreed, the lack of options is indeed a real problem. (Though as I’ve just said to Adrian above, no doubt a lot of people would lump me too in amongst those “impostors and charlatans”. 😐 )

      @Mike: “I have serious doubts whether the Open Group is the best organisation to create and manage an EA framework…”

      I have no doubts at all that Open Group are a suitable organisation to create an enterprise-IT-architecture framework; but as an IT-standards body I’d have to say they’re almost inherently unsuited to create an enterprise-architecture framework. Unfortunately they don’t seem too good at understanding that rather crucial difference…

      @Mike: “…but to their credit they have managed to create a fairly successful market around TOGAF training and accreditation.”

      Unfortunately it’s not “to their credit” if what they’re marketing turns out in practice – which is the case – to be fundamentally both the wrong thing to do for EA, and the wrong way to test and accredit it…

      @Mike: “Moreover, it creates a serious problem for the industry as well as those of us who really practice EA!”

      Strong agree there: it’s a huge problem. The more ‘successful’ that Open Group is in marketing TOGAF ‘as’ enterprise-architecture, the more damage they cause the entire discipline and industry.

      @Mike: “Try and force the Open Group into relinquishing control of TOGAF and allow it to be updated by real practitioners?”

      That’s one option that we definitely can’t have, for the simple reason that TOGAF is, literally, ‘The Open Group Architecture Framework’ – it belongs always to the Open Group, by definition.

      @Mike: “None of the options seem particularly appealing to me right now”

      I’ll agree there: I must admit I feel more than a bit stuck about this. Open Group were one of the few that had (and have) the ability to manage a wildly-disparate community and get a framework out of it that’s at least useful for something: they’ve badly mislabelled and mismarketed TOGAF, but it does at least exist, and yes, they do indeed deserve credit for that. For the rest of us, often the best we seem to be able to do is indulge in endless and pointless bickering-matches on LinkedIn, and get nothing useful out of any of it at all. Kinda dispiriting, really… Oh well.

      • Mike Glendinning says:

        I note also that the BCS is holding a debate on “professionalism [and accountability] for IT architects” in London on 24 November. I’m not convinced this is the right organisation for EA any more than the Open Group, but I am intrigued as to what they might have to say on the matter. A similar credibility problem exists in the pure IT and solution architecture space.

  4. Mike and Tom, I concur.

    I also believe that an organization to sponsor an independent harmonisation effort in the EA domain would be welcome.

    Rather than starting from scratch the effort should be directed to analysing existing EA approaches, objectively, by a selected expert group.

    They should produce according to a set list of deliverables, such as modeling framework, metamodel, process… paying due credits to sources.
    The result would be a best of breed EA approach. It can be ten pages long rather than 800+.

    Their work should be transparent and open to public input afterwards.
    The problem is what “independent” organization would embark in this risky endeavour where results are not guaranteed but costs are.
    Perhaps an EA tool maker or a government.

    It would have been the task of a group like Open Group but they will, most probably, continue to defend TOGAF because it pays the bills.
    Perhaps a competing association that deals in business , process or organization architectures rather than IT.

  5. Peo Ekström says:

    Thank you for an excellent post.
    In my profession (x.kind-of-architect) at a global fashion retailer I tend to reason about these concepts as contexts, interactions (man/machine, machine/machine, man/man) and sustainability (where we handle all our constraints of resources, capacities, knowledge etc. e.g. stuff that can be scarce and/or abundant). If I do it well the earning may come as confidence in form of decisions that can make things happen.

  6. gctwnl says:

    Tom, you’re openly saying a couple of things I am often thinking.

    Consider the difference between the BPMN and UML licenses and the TOGAF and ArchiMate licenses. This also hinders proliferation of the standards. I have no problem with having to pay to use something, but the $2500/year minimum excludes all but the companies that have turned exploiting it commercially into a walled garden. $250/year for an individual/small company, I would find appropriate to support the development of the ArchiMate standard and be able to use it commercially. Anyway, having to pay to use it commercially means that as far as I’m concerned the TOG standards are not `open’ (like UML and BPMN) and TOG is indeed more a `collusion of companies’.

    TOGAF and ArchiMate are indeed IT-centric. For TOGAF, that seems to be a bigger problem to me than for ArchiMate (as ArchiMate can be easily combined with other ‘languages’, whereas TOGAF is supposed to be all-encompassing for EA governance.

    But TOGAF has bigger problems than being IT-centric. Its biggest problem is being a fat waterfall. You’re change of scope focus is fine, but the other problem remains.

    • Tom G says:

      Gerben, very strong agree on the ‘fat waterfall’ problem (or rather, that fat-waterfall is the only option available).

      I obviously didn’t have enough space to explain it properly, but the metamethod (the right-hand side of the ‘Spot The Difference’ is explicitly designed to work not just with any scope, but any scale as well. In practice, we were able to get even a formal version of that cycle down to well under an hour, and an informal one could literally take seconds, used just as a checklist.

      The trick is to remember that it’s recursive, and as with all architecture, to keep aware at all times of ‘It Depends…’ and ‘Just Enough Detail’. The former guides the scope for each iteration, the latter guides the scale; and we use the expanded function of that central repository – either metaphoric, and/or literal, in the form of some toolset – to maintain the continuity to keep everything linked together across all of iterations and recursions. There’s a lot more detail on how this all works in practice in my books ‘Bridging The Silos‘ and ‘Doing Enterprise-Architecture‘, but there’s also a two-page summary in the ‘methodology reference-sheet‘ attached to ‘Bridging The Silos’. (That’s a free-download, of course.)

      I’d also like to throw in a bit of flag-waving here on your behalf, because you’re most definitely the ‘go-to person’ for anything Archimate: in your ‘Mastering Archimate‘ books, you’ve shown how to push even the present overly-constrained Archimate right to its limits, on huge real-world systems and architectures. By comparison, I’m just a probably-not-humble-enough theorist and toolmaker stuck out somewhere in the back of beyond. If I do get it wrong in terms of Archimate, please do feel free to correct me? – though preferably not with too many nails in those hob-nailed boots? 🙁 🙂

  7. Michael Fulton says:

    This is a really nice article and should be required reading for EA that have been in the job for 3 years or more. It should also be required reading for every member of the Open Group Architecture Forum, the folks who manage TOGAF.

    I agree with some of your points and disagree with some of your points. But my most fundamental disagreement is with how to use TOGAF. I firmly believe that TOGAF is an excellent approach to help someone transition into Architecture, whether it be from App Dev, Operations, Business Analysis or wherever. It provides a great foundation for architecture work. But to your point, it really needs some thought and supplements to allow it to continue to work in the more mature individual or organization. For those folks, Architecture can and should be much more.

    When I talk to people about EA and EA maturity, I use a four step model as outlined at In this context, I believe TOGAF is helpful for Levels 1 and 2 and I believe needs a lot of additional supplement for Levels 3 and 4. Tom, based on the conversation, you may be almost exclusively working at level 4, which is likely why you see TOGAF the way you do.

    • Tom G says:

      Thanks for the kind comments there, Michael – much appreciated!

      I agree that TOGAF is a good approach “to help someone transition into Architecture”, if they’re coming from an IT-oriented background (e.g. as per the ‘Level 1’ in your maturity-model), and also if there’s a broader framework also already in place that appropriately positions TOGAF within the broader EA context. The catch, of course, is that TOGAF frequently pretends to already be a complete description of that broader context – which it isn’t it.

      (The distinction that we need is clear, I hope, in the text above: that what’s needed for EA is a metaframework, whereas TOGAF+ADM is a hard-wired framework that is merely one possible instantiation from that metaframework.)

      I’ll reply to your maturity-model on LinkedIn: the point I think you’re still missing is that every one of your examples in that maturity-model is IT-centric. (If you don’t believe me, go look at your diagram again: Levels 1-3 are explicitly stated as being based on and/or derived from and/or delivering exclusively to some aspect of the IT-oriented domains.)

      In that sense, yes, I can see that you’d probably interpret my work as being “almost exclusively working at Level 4” – because that’s the only place that your current model allows for anything non-IT to be architected. In other words, the same misframing as in TOGAF itself, where ‘Business Architecture’ is in essence just a random grab-bag for ‘anything not-IT that might affect IT’.

      Instead, the way I view EA – and it’s based the work we did at Australia Post and elsewhere, a decade and more ago – is that, for example, there’s no such role as an IT Solution Architect: instead, the Solution Architect covers the whole of the solution, fully cross-domain – IT, people, process, machines, physical facilities, legal, compliance, training, lifecycles, whatever. Breaking the solution up into IT versus not-IT, and keeping everything partitioned along silo-boundaries, will all but guarantee a failed architecture for that solution: Not A Good Idea…?

      The same, about the need to break free from IT-centric assumptions, applies onward and upward through your maturity-model, from Level 1 through Level 4. (And beyond, by the way – there’s at least one more level needed to complete your maturity-model structure.)

      Happy to talk about this further offline, if you wish.

Leave a Reply

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