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.
Sigh…
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.
Bah.
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 http://ow.ly/DFg6E
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.
Bah.
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).
Yep, understood. I was trying to be polite about TOGAF in at least some areas, is all.
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.
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.
Tom/Adrian,
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?
-Mike.
@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.
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.
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.
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.
Glad it’s been useful, Peo – many thanks!
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.
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? 🙁 🙂
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 https://www.linkedin.com/pulse/enterprise-architecture-maturity-michael-fulton?published=t 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.
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.
Welcome, everybody on this thread!
Let me brief; I’m not an expert, or acknowledged EA, TOGAF and any standards certified one either (this is my luck, I think :). I’m only a newborn on this field blessed with clear, critical thinking and a pragmatic stance. However, I’ve been dealing proactively with EA more than decade, its struggle and mess.
What I can feel about TOGAF: This is a mix of ‘framework’, ‘methodology’ as a kind of ‘standard’ (?), so widely coerced nowadays to the EA community what is very difficult to overcome. Even if that is not concluded to be mandatory having a certificate for getting an EA position, that is much times expected having at least knowledge about TOGAF. And sometimes that is also true, one can be only an acknowledged EA, if he/she has a TOGAF certification. But, I also think, not the certification important much rather how one can think, and able to oversee the things.
What I can see, agreeing with
@Mike: “Unfortunately, we seem to have few other options for the foundation on which to build a more professional approach to EA…Yes, there are many other frameworks as well as organizations dedicated to the “professionalization” of EA, but as far as I can see – I too – most of these are not that much different to TOGAF and none has really achieved the critical mass needed for success…”
Whether Open Group is best suited or credited for creating a workable, usable most common helping tool ( method, framework, even standard, and concrete software tool to handle it) practicing EA at least well, even if it is not professional, I cannot esteem.
What I can feel too, perhaps that is not the best way to openly refuse or concretely go against them, as Svytoslav Kotusev dare to heavily criticize TOGAF in his academical papers. Perhaps it can be better to persuade them to refine it being better practically usable, based on a critical mass already working in daily practice experiences. I don’t know how.. But I know ones who may be able…It depends on…Just enough mass and effort and considering worth… Perhaps :):):)
Yes, again, there are else worked out frameworks may be better than TOGAF e.g
1. PEAF what is trying to overcome TOGAF, and what have has already many followers, but, they created a such a bunch of ontology (they name that so, concretely) what really requires rewiring someones’ brain.
I also had the opportunity to look into
2. Enterprise Architecture frameworks critique by Adrian Grigoriu – issuu
https://issuu.com/grigoriu/docs/ea_frameworks, his
FFLV method
and FFLV framework
distinguished
(unfortunately the slides can not be downloaded and not so good readable at Issuu)
3. I also read and tied to put together Svytoslyav Kotusev frameworkless artifacts set and EA process conceptualization based on his huge research work
4. And have not read yet Tom’s metaframeworks.
What I can see, there are much of speech, tremendous readable information, material about EA, and surely very good or better experiments creating a generalized or single unified framework.
However, about the time and money: To put together a workable method, framework for one just got an EA job, against TOGAF, and or persuade his EA environment even the CIO using that rather it, requires tremendous time, almost so much reading than Togaf. Even invest money to buy the relevant books (the final cost may be almost so much spending for a TOGAF course and certification, which inevitable shorten the time as only reading it) and read more hundred or thousand of pages and evaluate them, meanwhile one is coerced to present workable solutions in a time win situation at his workplace.
I feel, it is impossible mission, at least for me.
(My problem is for example too, I can not read sequentially hundred of pages books, if I can not bind the reading to an actual task I’m focusing on. I lose the context or forget some minutes later what I had read. Perhaps, it is because my short time memory is able to retain the things in actual context dependency, and doesn’t deal with to store to the long time memory for later using only at least the pointers where to find when I’ve glanced over a reading. In exchange, I’m able to focus on at least 3-4 parallel threads, although keeping my attention only 1 at at time of moment. Why this is so, it is just another field of brain architecture 🙂
I feel much rather the problem is the clarification of the difference between what IS EA, and what does it mean practicing EAM.
TOGAF is absolutely a mix about them, although its seven partitions perhaps can describe that. I feel it is able to somehow cover the business and it operation continuum. Well or not, usable or not, that is an else question. However until doesn’t understood basically the difference between EA and EAM it is a complete mess, truly.
I see Achimate, as a kind of higher level conceptual framework, not only helping tool for modeling, and in my opinion, it is not exactly made for IT, e.g. solution architecture level modelling (even if due to its UML base, it can interconnect with tools what are better for that e.g. Sparx EA. Which is not so good for modelling higher level views and relationships). It is much rather for similarly as BPMN practice conceptualizes at least three levels of modelling. Achimate is relatively much simpler to understand, and also is a thinking tool and a visualizing possibility of the layers, aspects as artifacts, behavior of elements and also using views as an architectural process.
That is Tom’s another post, but, let me react to that here.
Whether there is a need for BDAT or not? I think the Business, Information (Data, Application), Technology domains segmentation and their transparency are needed. How about the granularity and the visualization help, what is the best tool for it just again an another question.
For example there is SAMU, what is a (System Architecture
Management Utility) very good for creating interconnected views about the domain layers, and also very good for a kind of repository metamodel establishment what can involve even projects, organization levels responsible for projects, (aka has an ability for portfolio management, service management, because if the metamodel is well established and also we have good queries we can see the relationships). Also may be recorded requirements and glued into projects and relevant responsible segments of the organization, even policies.This tool is not for development help and deployment.
And there are yet the measurements cockpit for decision making. Just another tool for help.
I think we need more severe tools to help visualizing our works, and a tremendous both technical an non technical knowledge communicating with the involved stakeholders, how to establish workable meta model repositories what views and artifacts help best their work.
And I also feel, it may be very vary depending on the given enterprise culture, people, skills, business it operations, habits, goals inside outside environments drivers, customers so I don’t esteem whether it would be enough a generalized metamodel or not. The reference frameworks perhaps can give a crest frame.
Yes maybe there is a complex tool what fit all of our needs, but that surely reachable at vast cost.
So what about the best usable framework? I think, the first should be clarifying what we need to know meaning EA, and EAM.
I found a relatively simple written and good description here, and almost everything (reading the follow up links) what can be enough to realize sketchy about the big business-it operation picture for a new born EA.
https://cio-wiki.org/wiki/Enterprise_Architecture_Management_(EAM)
Thank you for reading my long comment.
I hope I could also give something 🙂
Cheers, Valeria
Hi Valeria – many thanks for the long comment! – a very good summary. 🙂
(“I hope I could also give something”, you say – you just have, right here! 🙂 – that critique above is useful just in itself.)
A few quick responses:
On other frameworks: If you like Kevin Smith’s PEAF, I’d strongly recommend taking the time to explore his POET framework, on ‘transformation of transformation’. For mainstream, I’d recommend also to take a look at Frameworx (for the telecoms industry) and TRAK (for rail-transport and systems-engineering generally). Also a very strong recommend to look at Milan Guenter’s Enterprise Design framework and the large Intersection conference/community that’s built up around it, and also Annika Klyver and Cecilia Nordén’s Wintergatan/Milky Way framework, derived in part from their involvement in the Enterprise Design community.
On metaframeworks: One example is in the post above 🙂 – it’s the right-hand side of that comparison-graphic. A metaframework is just a framework for building frameworks: in this case, TOGAF, on the left-hand side of that graphic, can be understood as one of a near-infinity of possible instantiations of the metaframework on the right. There’s more on this in the post ‘Metaframeworks in practice’ blog-series that followed that post.
On usable frameworks/metaframeworks for whole-enterprise architecture, see the blog-series summarised in the post ‘Towards a whole-enterprise architecture standard: Summary‘.
(The reason why we need whole-enterprise architecture is that there’s a lot more to an enterprise than just its IT: building off the BDAT-stack is not enough! All of those other themes you listed need to be in there, and more: stakeholders, culture, people, skills, customers, environment, as you say, and also all of the cross-cutting qualitative themes such as security, privacy, sustainability, safety, business-ethics and many, many more. The IT-architecture may not be easy at times, but it’s actually the easy part of the architecture!)
You ask, “So what about the best usable framework?”. The short-answer it ‘It depends…’ 🙂 That’s one of the reasons why TOGAF has been so problematic: it purports to be ‘The Standard’, but it’s so specific to and skewed towards IT that it’s largely unusable for anything else, and is so incomplete anyway (as Open Group themselves will sometimes admit) that it really should not be described described as ‘a standard’. In short, a classic example of “one size fits none”. To me, the usual best answer is to find what frameworks exist for your own industry, and use those as a base to customise a purpose-built framework for your own organisation, with hooks outward wherever possible to other standards.
The one thing that puts TOGAF above the rest of that 1990s-onward cohort of frameworks is that it has a defined method: there isn’t one in any of the other frameworks from that period (DoDAF, TEAF, FEAF, eTOM/SID and suchlike). The catch is that the TOGAF-ADM is bloated, cumbersome, very much ‘fat Waterfall’, and rigidly hardwired for IT-infrastructure (a fact all too evident up until version 8.1, and merely concealed in later versions). Yet we need a governance-method to guide the architecture through all of the details and pitfalls of an architecture-framework. In essence, the TOGAF-ADM is a sort-of rework of the classic Deming-style PDCA (Plan/Do/Check/Act) loop, which might work if there weren’t so many gaps in that rework (as described in the post above). For some years I pushed for a more complete rework based in part on PDCA, but also on the classic Tuckman ‘Group Dynamics’ model (Forming, Storming, Norming etc), and even more on the classic Chinese ‘wu xing or ‘Five Elements’ – for example, see the post ‘Towards a whole-enterprise architecture standard – 3: Method. Unfortunately even that rework turned out to be ‘too complicated’ for many people’s tastes, and a further attempt to simplify it (see ‘Methods for whole-enterprise architecture – Keep it simple‘) fell into an awkward space of being perhaps simple enough but now too abstract. It took us another two years of hard work to simplify it down even further, as the ‘Context, Scope, Plan, Action, Review’ sequence in ‘Change-mapping‘ – which does at last seem to hit the sweet-spot of simplicity and usability, and can also work with any EA-framework that we might need to use. It’s still early days on that one, though: we’ wait and see, I guess?
Hope that’s useful, anyway, and thanks again for your comments.
Best regards
– tom g.
Dear Tom!
My honest thanks for your spending time reading and answering to my really long comment, and also for listening to me anyway! This in itself gives me very good feeling. 🙂
In general, I agree with you, and with those who have been spending very much time to clarify both EA, and EAM practice, and have been trying to put together a usable framework.
I will glance over the above links you’ve just suggested to read.
As shortly as I can, and to be honest, I’ve never read TOGAF, (owing to I’d mentioned in my prev. comment my brain working habit 🙂 at least glanced over documents what tried giving a summary about it. I will read those passages what are needed at a coming time. So, I do not feel entitling myself taking any strong critics either about TOGAF or Open Group authenticity. What I can also see, one personally may become an Open Group member, if the organization employing one has been their already acknowledged member, and give a recommendation of their employee becoming a member, too.
Let me expose my present personal situation, and I think, this may be also a general daily case when someone is trying to get an EA position, or try to change its employment because the very inconvenience of his expectation and experiences about EA role, tasks, and anyway all is running on this field.
When one (as me) have just enough time yet (due to a just unemployment) and ambition, to look around, and deepen my/one’s understanding by reading and gathering forward looking best materials – that is really a good way for personal development. But, the real questions come after or perhaps in some extent may be forethought;
(I’m presently at a 2.rounds interview meeting with the person entitled IT director of the company. I could suppose from the offered written EA position responsibilities and requirements, when I’d applied, there might be an already setup of a kind of EAM practice at this company. However, at the first interview, I could clearly guess, probably they are in a maturity step1, or at best in between step2. Unfortunately, only an already employed EA was present on the interview, who did not say anything concrete what have been happening there, but only tried to check up me, and asked me – Whether that will be enough for me only to model and doing system integration? I obviously said yes, due to I need a workplace..However I’m very curious to speak with the CIO(?) or IT director to get more, why they need for a second, EA or perhaps EA staff, and what about his understanding about EA-EAM.)
Yes, one may be set up by his thinking toward and innovative stance persuading his ‘new’ or actual environment doing a change, or even to introduce something new (using a better framework, thinking on else way) against the wrongly done mess, or yet not having any EAM establishment.
So, because of I’ve been only too, in between state of my own understanding and clear seeing the EA-EAM matters, looking for a better and practically usable way what to do, and perhaps offer to ones, for which scrutiny I have presently enough time yet. But, almost sure it won’t be so much if I get the employment. Thus, I need for a ‘strategy’ whether what worth to do, how much time can be invested for toward learning and persuading ones, so on….
The first problem what I can see;
1. As far as very shortly I could give my stance about what makes an EA to be an EA in our LinkedIn conversation;
If there is not a proper Cxx level understanding (meaning the CIO himself doesn’t understand clearly why he wants establishing an EAM practice, what he wants about making and employing EAs, or what about his thinking EA-EAM matters anyway) very likely this EA role or practice will not be much as a very developed BA, or a little more to be a universal solution-software- at best all domains architect role, who can probably oversee the mess and try to do something, what expected to be based on TOGAF, because they are coerced to do that or doesn’t know else frameworks.
So the first is, for a person who has a truly EA vein, to check up what are in the CIO/CTO/IT/director’s head. Me needs to think first with the CIO’s head, so called. And I have to be very polite not to know much than he has, if that is the case, at least very politely correct the mess if there is, and check up too, how he is open for something new. Whether he has a business oriented or IT oriented stance, why he thinks the TOGAF can be used etc. What about business value, their business models, business-it strategy, the technical landscape, and what are the intents/purposes, goals, drivers.. etc. What about the digital transformation, cloud platform initiation, microservices, agile things, devops..so far.
(I see few chance to clear all from 2.rounds interview with him)
2. I guess also, if they are in maturity step 1 that is better, to try to persuade them choosing an else possible framework.
But again – your mantra comes 🙂 – I don’t know even yet myself either, it also depends on my own clear seeing and gathering more knowledge, evaluating the possibilities getting a confidence in one of them. In the meantime probably I need taking such works in parallel what are on their course at this company..so all also depends on my time, and whether it worth to take a such a big effort or leave it being only my passion and contribution to that community who are trying to do this step forward if my time allows.
So, Tom, I will be and remaining on this way surely, but the daily TRUTH and ‘Story’, and reality just is, what is.
Kind regards, and thanks for all! I’ve really enjoyed our conversation, and hoped remaining in contact further.
Valeria
Hi Tom!
I’d like adding some reactions ..
1. PEAF: I’ve not registered myself yet, to read Kevin Smith’s PEAF, material in depth. (It is needed for reaching the full material in pdf form). At first glancing the free web based books, the whole continuum of his ontology seemed me very difficult to read and follow and put together. Although, it got my interest, but the web site structure and look and readability was a bit distracting, so I was a bit disappointed. I reckon to register perhaps later.
2. I’m sympathizing with Adrian Grigoriu
The FFLV-GODS Enterprise Architecture framework
https://it.toolbox.com/blogs/adriangrigoriu/the-fflv-gods-enterprise-architecture-framework-032712
I like the ” comparison with the human body anatomy and physiology descrptions …Body parts are Functions, body flows (end to end vital processes) are business Flows and the nervous or blood system… look like EA Views.
It may be closer to my present thinking…
But, the essential slides can not be downloaded.. for better reading … and again
READING THE BOOKS..and tremendous BOOKS…(what is not my strongest capability, I have no capacity for that, not because of the money consideration)
So it may be promising, however…
Both of above do not try to openly go against TOGAF, somehow they are trying integrate something from it and to overcome the its flaws…
See Grigoriu comment above: .. 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.”
3. At first sight your right-side TOGAF alterations may be better, (But perhaps – because of I’m a tiny so to be simple – I little bit change the LETTERS order too as what context comes first, however in your wide scale following explanation I lost the focus 🙂
Let me a bit disagree in that the TOGAF suggest to be strongly IT centric, (at least, it does not come from the graphic, perhaps from the whole TOGAF book, what I haven’t read fully, as I said), and I think, it depends on too, how ones apprehend, and what they keep important to see into this graphics …
And as I wrote in my previous comment, that is for example the question of how about the modelling views levels, and used tools? How can be the business and IT matter interconnectedness to make them visualizable, at which granularity. But the modelling only a one side of the coin.
May be if we can see an EAM practice similar to as a Business process model we can get a clearer view.
As per my theoretical understanding: the method is a description how to do something particular, a framework can be a collection of reusable components with which variable using something could be built based on a particular method how to.
The meta framework can be a kind of variable premade frameworks collection based on also variable meta-method set for many particular things. Thus, creating framework(s) from premade frameworks using a chosen premade method for a particular thing, or even chosen from more methods creating one particular framework or several frameworks.
Do you mean this? What do you think?
I will read toward your links, as how my time allows. I do not want taking any evaluation until haven’t at least glanced over 🙂
Cheers,
Valeria