Saving enterprise-architecture from itself – 4: Responsibility

Who defines the profession and disciplines for ‘the architecture of the enterprise’? Who is responsible for it, how, and why?

The focus in this part of the series is on a comment by Len Fehskens, on an earlier post about EA and certification.

As with the previous post, building on a comment by Sally Bean, I ought to give a bit of background here. Len Fehskens is another (now-former) ‘insider’-EAs, again, enormously experienced – far more so than I am. He comes from what’s very much a ‘big-IT’ background, but he’s also been one of the very few around the Open Group space who, right from start, has pushed for a much broader view of enterprise-architecture – not just broader than IT, but broader than the organisation too. He’s currently the Open Group’s ‘Vice President, Skills and Capabilities’.

Again, as with Sally Bean, he’s someone I deeply respect. We do, however, have a significant clash around the role that Open Group has played, and continues to play, in the development of enterprise-architecture as a discipline and profession – and that clash is very much in evidence in the comment we’ll focus on here:

Tom writes:

“if the Open Group’s arbitrarily-narrow concept of ‘enterprise-architecture’ does take hold”

What’s with the “if”? Once again you confuse cause and effect. The Open Group is its members. The Open Group staff, with very few exceptions, are not enterprise architects — they are facilitators, who provide support to The Open Group’s members, who in turn develop the standards published under The Open Group’s name.

This is indeed important: we need to draw a clear distinction here between ‘Open Group the organisation’ and ‘Open Group the member-community’, otherwise we’re going to end up going round in circles.

Exactly as Len indicates, The Open Group organisation (‘TOGO’) actually plays only quite a small role in these concerns around the nature of enterprise-architecture itself. In essence, they act as a coordinating body, not a decision-making body: there’s a big difference there, especially in terms of responsibilities. For example, TOGO has huge expertise in helping people create and run consortia of almost any type: but they themselves are not responsible for those consortia. The only thing I would scream at TOGO about – and I’ll admit I do perhaps do it too often – is the fundamentally-wrong idea of trying to use a crude machine-delivered multiple-choice exam to test for competence in skills-awareness (which is what still happens with the full TOGAF certification exam).

[I can understand the cost-imperatives around this, and the practicality-issues, but by definition it is not an appropriate way to test for skills-competence, and should not be used for that purpose – because it renders the entire certification-schema invalid. That’s not about enterprise-architecture as such, it applies across the board to testing for any type of skill – it’s a fundamental of pedagogy, not content. (I researched and wrote my Masters thesis on this, so I do know what I’m talking about here.) But I digress…]

By contrast, as Len implies, The Open Group membership (‘TOGM’) – the members of the Open Group Architecture Forum and suchlike – are the ones primarily responsible for this (to be blunt) disaster-area of what TOGAF (mis)describes as ‘enterprise’-architecture. But why? – why, and how, did they get it into such an inherently-dysfunctional mess? Where did they go so badly, ludicrously wrong? The answer, I’d suggest, in part lies in the structure of the Open Group itself – the relationship between TOGO and TOGM.

Despite its name, The Open Group is not particularly ‘open’ as such: in fact it’s what we would describe as a ‘pay for play’ member-organisation. This is so that TOGM can cover the costs of TOGO, whose coordination-services they (TOGM) rely on, in order to do their development of technical-standards and suchlike. But the membership-fees, and voting-rights in the various forums, are per-organisation – not per-person. And also there are various levels of ‘pay-for-play’, where paying a larger membership-fee entitles an organisation to acquire broader voting-rights in more standards-forums.

Again, it’s easy to see why and how this particular membership-model was adopted, and why and how it does deliver a lot of advantages for many of the players. But it also has subtle built-in problems too, and one is that, given a per-organisation model, the per-person membership fee is, by definition, inversely-proportional to organisation-size. The base-level membership-fee is a few thousand dollars a year, which is almost nothing, of course, to a company the size of IBM – but it’s definitely non-trivial to a small consultancy or an independent. (It’s why I’m not an Open Group member: I simply can’t afford it.)

So, almost by default, the whole structure is skewed towards large IT-organisations and large-company business-models – and that ‘reality-distortion field’ really shows through in every aspect of TOGAF, especially in versions 8 and 9. The results are exactly what we would expect, as per my ‘follow the money‘ post: TOGAF and, now, Archimate end up with structures that all too evidently cling to the past, riddled with circular-definitions, and geared to the way that big-IT companies do things, at a time when the old big-IT business-models are largely falling apart at seams. In short, not exactly helpful…

The Open Group’s member organizations’ representatives represent the conventional wisdom about enterprise architecture. They are not creating this conventional wisdom, they are codifying it.

Let’s be blunt, and reframe this in more honest fashion, but in a similar way: “The Open Group’s member organizations’ representatives represent the conventional lack of wisdom about enterprise-architecture“. There is no other honest way to put it – and it’s a direct outcome and consequence of that skewed ‘pay for play’ business-model and membership-model.

What is very clearly in evidence is that, yes, the members of the Architecture Forum and suchlike did indeed “codify… this conventional wisdom”. What they also clearly did not do was question the premises or assumptions on which that purported ‘wisdom’ was based. If they had – and if they’d looked at either the logical implications of the ever-expanding scope of TOGAF throughout its development-history, or the actual nature of the self-centric delusions that underpinned the ongoing wicked-problem of ‘business/IT-alignment’ – then it should have been obvious to them just how lacking in wisdom that ‘conventional-wisdom’ really was. But no, they didn’t: and as a result, we have in TOGAF – and, it should be said, also in most other ‘large-IT-organisation’-dominated frameworks in enterprise-architecture and elsewhere – a codified view of ‘the enterprise’ and its architectures that bears little to no connection with the realities of any real-world enterprise. And that is darn dangerous – for everyone involved.

Let’s explain this with an analogy.

Shift, for a moment, from the architecture of enterprises to the architecture of buildings.

And shift, for a moment, from the electronic to the mechanical; from the informational to the physical.

Imagine that there is a new technology that completely revolutionises the possibilities for buildings – in effect, the business-model for buildings.

That technology is called a ‘lift’, or an ‘elevator’. Before its invention, the height of buildings is – in practice – limited by how far people can (or will) climb on a regular basis. After its invention – well, the sky’s the limit! (Notice how the hyperbole starts to creep in, almost immediately…)

If we’re involved with elevators, well, that’s the centre of a whole new world! The centre of the building! – after all, the building is literally constructed around it! It enables everything: the building wouldn’t be possible without it! – the enterprise wouldn’t be possible without it!

(Which is arguably true, yes, though there are a lot of other technologies, materials-sciences, and much, much more, that go into making and using a building – and the building wouldn’t be possible without them, either. ‘Elevator-centric thinking’ can be not only a distraction here, but a potentially-dangerous one too.)

Within the elevator practitioner-community, all those hyperboles are such obvious truths that, surely, there’s no need to consider anything else! Yet anyone coming from outside, with experience of how buildings are used, would note that whilst, yes, the elevator is indeed a most efficient and effective way of moving people up and down the building, we’re going to need parallel alternatives such as a stairwell, for risk-management and the like – and also because experience shows that technologies do indeed break down from time to time. The elevator-practitioner community dismiss these as irrelevant – old-fashioned! the technology is perfect! – and so on, and so on…

(It’s in this sense that ‘anything-centrism’ can be lethal, and sometimes literally so. In this case, if there’s a critical problem, and the elevators don’t work, and there’s no alternative because the building-designers were caught up in ‘elevator-centric’ thinking, then people are going to die. In large numbers. Oops…)

Again, anyone outside is likely to have a broader picture, not just of how the elevator fits into the building, but of how the building works as a whole – and perhaps particularly in relation to the human element, and the enterprise that links the whole together, in which even the entire building is only one part.

Yet within the elevator practitioner-community, the only talk is of elevators! – and how important they are!

Slowly, an awareness develops in the elevator practitioner-community that, well, yes, actually, even elevators on their own can be problematic. Although elevators are essential! of course!, we can’t just have elevators being placed willy-nilly within the building, and their control-systems and wiring-infrastructures and cables clashing with each other: we kinda need to optimise the elevator-infrastructure! This is called ‘elevator-architecture’.

Then someone else says, wait a moment, we’re also doing this on a larger scale: let’s call this larger scale ‘enterprise-wide elevator-architecture’!

And then, for shorthand, within the community, ‘enterprise-wide elevator-architecture’ gets compressed to – yep – ‘enterprise-architecture’! But no-one stops to think that this shortened term might have other meanings, and that therefore there’s a risk of confusion or term-hijack here...

Over time, someone else says, we’re building elevators, hadn’t we better think also about how the elevators work? – the applications of moving people versus freight, and of speed versus volume, and the data that we could use to optimise how elevators go from floor to floor? So let’s add these as our ‘applications-architecture’ and ‘data-architecture’ – our ‘information-systems architecture’ – to our ‘enterprise-architecture’! Look, it has layers to the architecture, it really is an enterprise-architecture now!

And eventually it recurses up to the next level of scope: someone says, shouldn’t we also think about how the elevators are used, in the business of the building? Let’s call this the ‘business-architecture’ layer of our enterprise-architecture!

And because building elevators is big-business, and kinda complex too, a whole training-community develops around this ‘architecture of elevators’. Which they call ‘enterprise-architecture’, and teach everyone involved to call it ‘enterprise-architecture’. The architecture of elevators is enterprise-architecture! – everyone knows this! There’s now a lot of money tied up in this, and a lot of clout…

Yet finally, at long last, a few practitioners step out of the elevator, and instead of solely looking back at the elevator – because elevators are the centre of the world, everyone knows this! – they actually remember to also look outward, towards the real-world. And discover that, uh, oops, there’s kinda a very large number of people out here, doing a very large number of other things that are also just as important to the existence and operation of the enterprise.

And then, with some trepidation, they go back to the elevator-architecture practitioner-community and say, uh, hang on a minute, haven’t we, uh, perhaps been doing this the wrong way round…? Isn’t ‘enterprise’, uh, a bit bigger than elevators alone? Shouldn’t we, uh, look at this thing from a bigger picture?

But nope: no-one else in the elevator practitioner-community wants to listen – I mean, look, we now have twenty-seven thousand people certified as practitioners in enterprise-architecture! That’s what enterprise-architecture is!

At which point, those of us in the real-world start to shift from a pained sigh, to something more like wondering if there’s a way to superglue the damn doors on the elevator…

So if you want to blame someone for the conventional wisdom on enterprise architecture not corresponding to your vision of what it ought to be, blame the entire practitioner community, and the companies they work for, because that’s where its coming from.

I do.

Or rather, I don’t. I don’t ‘blame’, as such – there’s no point, and it doesn’t help. What I do note is what can only be described as an appalling dereliction of duty and responsibility, in almost any sense – perhaps particularly professional and ethical. Sadly, I don’t expect many – maybe any? – of the people involved to understand why I say this, or what the consequences of that dereliction will have been over the longer term. Oh well.

As a professional generalist for the whole of my working life, I’m painfully aware that myopia, self-importance and an often extraordinarily-arrogant self-centrism are characteristic to almost every specialist ‘profession’. Unfortunately, the IT-industry seems to have all of that in spades. Perhaps it’s linked to that age-old obsessional ‘need’ for ‘control’? Perhaps an escape from the need to deal with other people? Perhaps a deep-down insecurity? or maybe even an inherent tendency to drown in its own hype? I honestly don’t know. What I do know is that just about anything-IT tends to suffer from a serious inability to understand the world from any other perspective at all – or that, however impressive its technologies may be, IT itself is merely one aspect of a much more complex system, an ‘ecosystem of ecosystems’.

To continue that analogy above, what we have, right now, is a situation where the Elevator Engineering Institute is so enamoured of its own importance and its own concept of ‘enterprise architecture’ that it goes around to other folks such as the Institute of Architects and the Business Institute and the Architecture University to show them this ‘new profession of enterprise-architecture!’ – and then wonder why those professions kinda give them the cold shoulder. In the meanwhile, it turns out that big banks and insurance-companies and suchlike really like big buildings with big shiny elevators, so the elevator practitioner-community say, hey, look, we’ve got some real allies here with lots of financial clout behind them – we can use them to prove that our enterprise-architecture is the essential centre of business, for everyone! Look, we have twenty-seven thousand certified enterprise-architects! – sure, it’s only a five-day training course, but the Architects University’s five-year training course doesn’t teach anything more at all about elevators, so these are real enterprise architects!

Forgive me if I sigh in extreme frustration…?

Ask people what the most important book about enterprise architecture they have read is. A disproportionate number will cite Ross Weill and Robertson, “Enterprise Architecture as Strategy”. Guess what concept of enterprise architecture this book espouses. Did the authors get this concept from The Open Group? No. MIT Sloan CISR does empirical research — they got it from the practitioner community and their employers.

Yep. And if those people had actually read the darn book, they’d realise that it teaches a fundamentally-different model from that taught in TOGAF and its ilk. The EA As Strategy book is strongly IT-oriented, no doubt about that; but the TOGAF / Archimate axis is IT-centric – and that distinction is crucial. Even somewhat in the book, and much more so in person these days, Ross explicitly places enterprise-architecture at the CEO level – not somewhere way down below the CIO. Meanwhile, TOGAF places architecture-principles, for example, as a subset of IT-principles; and the Archimate standard starts off by defining enterprise-architecture as a subset of IT-architecture. (In the current TOGAF standard, oddly, there doesn’t seem to be any explicit definition of ‘enterprise-architecture’ at all – none in the ‘Definitions’ or ‘Supplementary-definitions’ sections, anyway.)

The fundamental flaw and failure of both TOGAF and Archimate is the ‘three architectures’ model: ‘[IT]-Infrastructure’, ‘Information-Systems’, and ‘Business’. These ‘architectures’ are explicitly defined as layers; and, to be blunt, the so-called Business-Architecture ‘layer’ is just a dumping-ground for ‘anything not-IT that might affect IT’ – a fact that should be painfully obvious to anyone who reads either of those standards with anything other than a rigidly IT-centric eye.

The consequences of that ‘three-architectures’ model are dire. To give just a few examples:

  • everything physical is assumed to be in the ‘Infrastructure’ layer, anything informational in the ‘Information-Systems’ layer, and anything human or purposive in the ‘Business’ layer – there is no means to describe the real-world orthogonality of those sets, such as information embedded in physical things, or as tacit-knowledge held by people
  • there is no means to describe any non-IT-based process – hence impossible to describe human-based processes substituting for IT-based ones during disaster-recover
  • there is no means to describe any non-IT technologies or physical facilities – hence no means to describe the physical context in which that IT-infrastructure exists
  • there is no means to describe anything that does not in some way directly interact with IT

Yeah, it really is that bad. And that fact should have been obvious to anyone in that practitioner-community, right from the beginning. What we’ve had instead is a massive proselytising of the pretence that these problems do not exist – which is, again, an appalling dereliction of responsibility.

(For what it’s worth, there’s a very easy fix to the TOGAF ADM to make it work for a real whole-of-enterprise architecture: see revised-ADM reference-sheet [PDF]. It’s a simple change that doesn’t alter the underlying PDCA-style structure of the ADM, and one that many of us had hoped would be taken up for TOGAF 9: but no, it succumbed to ‘follow the money’, and IT-centrism still rules the day – holding us back by at least another half-decade. Fixing the flaws in Archimate is harder, because they’re more deeply embedded in its underlying metamodel, but it is doable – see my post ‘Unravelling the anatomy of Archimate‘ for more detail on that.)

So stop blaming The Open Group as the source of all your angst. This isn’t because it’s wrong, it’s more importantly because it’s ineffective. The Open Group and TOGAF will not change their concept of enterprise architecture until the community as a whole does.

Point taken. Unfortunately, though, there are several reason why we do need to keep a focus firmly on the Open Group – although, as Len says, more on the practitioner-community than on the organisation itself. These reasons include:

— ADM as method: one of the problems arises because TOGAF is actually better than most so-called ‘frameworks’, in that it does include an explicit architecture-development method. That means that we can almost ignore many frameworks, because, without a method behind them, the damage they can do is inherently less. And because the ADM has fundamental flaws, as above, the more that method is adopted, the more serious the problems that it can create will become.

— Overall reach: the TOGAF / Archimate axis is almost unique in that it purports to be a generic framework for enterprise-architecture. Most others are more specific to a single domain (e.g. FEAF, TEAF, DoDAF/MoDAF/NAF) or industry (Frameworx, SCOR) or architecture-development task (PEAF). The result is that the potential for damage is much greater, because it can be (mis)applied in just about any domain, industry or task.

— Paradigm nexus: in lining themselves up with the Open Group, a lot of big-consultancies have all but abandoned their own frameworks, but have re-embedded that kind of ‘big-consultancy thinking’ into TOGAF instead – the influence of CapGemini’s IAF on the structure of TOGAF 9 being the obvious example here.

— IT-centrism (again): of the major frameworks, probably only the TOGAF / Archimate axis is now still so extreme in, yet so unaware of, its own deeply-embedded IT-centrism. Some others (Frameworx, Business Model Canvas) are probably too ‘management-centric’ or ‘business-centric’, in much the same way as TOGAF / Archimate are IT-centric – but they don’t claim to cover the whole enterprise-scope in quite the way that the latter do.

— Skewed focus: whenever we see ‘enterprise-architecture’ mentioned by the Open Group community and their ilk, the examples used are almost always ‘the usual suspects’: banking, finance, insurance, tax. In other words, information-oriented industries with high regulationhigh transaction-loadhigh repeatability and predefinable processes and ‘business-rules’ – all of which, unfortunately, makes it seem quite a good fit even for the most mistakenly IT-centric paradigm. We see these same examples touted time and time again – for example, take a look at the number of banks and other IT-oriented organisations in the programme for the current Open Group conference in Costa Rica. The ‘success’ in those domains is then used to support claims that the paradigm itself is ‘correct’ and applicable to all other business-domains – which it isn’t.

— Big-company clout: there are lot of large organisations either promoting and/or adopting the TOGAF / Archimate set. Many people would see this as a huge advantage; but if the framework is fundamentally-flawed – which, clearly, it is – then this ‘huge advantage’ inherently becomes a huge problem… and especially so when all of the inherent ‘follow the money’ problems also come into play.

— Training nexus: in some ways a corollary of all of the other points, there’s a huge sub-industry developed for TOGAF / Archimate training – with the result that not only are they churning out large numbers of ‘architects’ who are ‘certified’ in a framework that is, again, fundamentally-flawed, but also that there are huge vested-interests against fixing any of the problems. (The more cynical of us might note that the longer this mess goes on, and the more mis-trained ‘architects’ there are out there, the larger becomes the training-opportunity to fix up the mess…) The sheer numbers – ‘twenty-seven thousand certified architects!‘, Open Group announce with joy, whilst I just want to cry – in itself form a huge part of the problem. By comparison, for example, the most active MoDAF training seems to consist of Ian Bailey running an occasional one-day workshop in a back room at IMechE – which wouldn’t be a huge problem to fix even if it were wrong on the scale of TOGAF / Archimate (which it isn’t).

And for heaven’s sake, look at the dishonesty and irresponsibility in that comment above about “The Open Group and TOGAF will not change their concept of enterprise architecture until the community as a whole does”… You simply cannot claim ‘thought-leadership’ – as both sides of Open Group most definitely do – and then hide from responsibility with that old chestnut of “It’s not our fault, everyone else has to change first”. That’s not okay; that is just not okay… professional-irresponsibility in one of its worst possible forms.

Pi**ing on The Open Group is only going to get you branded as a crank by the greater community of enterprise architects who value what The Open Group provides because it corresponds to what they think they need, because it addresses what their employers want them to do.

Yep: I’m a crank – I’ll have to admit that, no doubt about it. As far as probably most people are concerned, that’s all that I am: more than a few of the Open Group folks dismissed right from the beginning as a harebrained crank – and kinda failed to notice that they themselves have consistently, if only eventually, proved that I was right about pretty much everything I’d said, time and time again over the intervening years.

And as I mentioned in the previous post, the reality is that it’s only the supposed ‘cranks’ and the ‘eccentrics’ who can get any change happening at all: everyone else is so stuck in circular-reasoning and self-centric ‘groupthink’ that they just can’t move, no matter how much they might want to.

So yeah, to quote a tweet by one of the Open Group staffers at their current conference in Costa Rica:

  • RT @stevenunn: #ogCOS Marcel Lopez: A successful project needs “parents” – otherwise noone takes responsibility for fixing things! #entarch @AssociationEA

If you think of the ongoing development of enterprise-architecture as a project (it’s a lot more, of course, but the metaphor will hold well enough for this), then think of me in turn as that perhaps kinda-annoying ‘parent’, nagging the perhaps still too self-oriented ‘children’ to grow their awareness of the wider world in which they live…

That’s the kind of ‘crank’ that I really am: all I’m doing is trying to get people to be more aware of and responsible about that wider world for enterprise-architecture. Quite often, I’d really like not to be doing this: heaven knows it’s not a good way to earn an income – not least because in many ways, my ‘business-model’ is more like that of an artist, funded not so much by clients as by ‘patrons’, and there ain’t many of those around… But someone has to do this – otherwise enterprise-architecture perhaps literally has no future.

And that does matter – a lot. Getting it right, right now, does matter – a lot. To quote another of those Costa Rica tweets:

  • RT @AssociationEA: Show of hands at #ogCOS shows a little under 50% of attendees are from IT department – bodes well for the future! #entarch @theopengroup

Yes, on the surface, it bodes really well for the future. But if the premier ‘enterprise’-architecture frameworks are, in essence, still little more than an IT-centric mess, then it bodes really badly for the future of enterprise-architecture – very badly indeed. That’s the choice we face here.

So what do we do about it? To be honest, I don’t know. (I have my own views, of course: but I certainly don’t have the whole picture, so it’s possible – probable? – that I may be just as wrong as everyone else I’ve critiqued here.) All I do know is some of the questions that we really need to ask, if we’re to move the enterprise-architecture disciplines forward into the future, and towards the real profession that I know so many truly do desire.

Hence a bit more exploration, in the final part in this series: see you there?

19 Comments on “Saving enterprise-architecture from itself – 4: Responsibility

  1. Hi Tom,

    Once again you are so spot on in making absolutely clear what the uneasiness I was having towards current E(it)A methods and frameworks. Heren in the Netherlands there is a ‘movement’ of thinkers on organisations that are bound together with the theme of ‘slow management’. Centre to their thinking is that current organisations are perfections of Taylor’s view on scientific management. However, with the introduction of web-technology and different needs of (at least some) of employees in how they work, Taylorism is becoming more and more a burden. When reading you’re article above, I immediately recognized that Taylorism is in fact the ‘elevator’ in current organisations and hence in current views of EA.

    • Many thanks for this, Bart – I’m delighted to hear I’m not the only ‘crank’ here…

      Now, if enough of us get together on this, enough to start pushing hard against this… – oh, call it what you will… – then perhaps we can bring enough pressure to bear to satisfy Len’s assertion above, that “The Open Group and TOGAF will not change their concept of enterprise architecture until the community as a whole does”…

      Will admit I get very, very tired of this at times, but we do somehow have to keep the pressure up on this, otherwise nothing will change. And that (‘no change’) really would be a non-recoverable disaster for enterprise-architecture – and possibly for a whole lot more as well…

      Thanks again, anyway.

  2. Tom accuses The Open Group staff of:

    “the fundamentally-wrong idea of trying to use a crude machine-delivered multiple-choice exam to test for competence in skills-awareness”

    Please cite for me anything from The Open Group literature that makes this assertion.

    The TOGAF certification is a test of knowledge, not of skills or competence, and The Open Group has never contended otherwise.


    • Following on from what’s happened in the meantime since we both wrote the above, I’m going to avoid as much of this as possible.

      There are just two comments I could add.

      The first is the difference between legalese – the fine-print on the legal document – and what is implied very strongly in action. I’ve no doubt that the legalese says that it’s a test of knowledge. That is not, however, what is said or, more important in practice, strongly implied, in virtually everything I’ve seen from the overall Open Group training-caucus (i.e. Open Group community overall, and TOGAF trainers in particular, and to a lesser extent the Open Group organisation itself).

      The second is just an application of a corollary of Beer’s ‘POSIWID’. When pretty much the entire ‘EA’-recruitment space asserts that TOGAF-certification is a test not merely of knowledge, but of competence, almost a ‘licence to practice’, then either Open Group has a major challenge on its hands to disabuse that entire industry of its damaging error, or else the Open Group is being somewhat disingenuous about what’s going on. I leave it to others to decide which of the two (or both, perhaps) that that really is.

      Either way, a machine-delivered multiple-choice exam should not be used as a test of purported skill and competence, or that may be interpreted by others as a test of skill or competence. There can be very significant risks for all involved – especially when such purported skills and competence are applied in subsequent practice. That’s a long-proven proven point in pedagogy that should not continue to be ignored.

    • The difference is that Jeanne Ross has acknowledged and addressed some of the more seriously-fundamental errors, such as (previously) placing EA solely under the CIO. TOGAF/Archimate still doesn’t – for example, architecture-principles as a subset of IT-principles.

  3. Tom writes:

    “And for heaven’s sake, look at the dishonesty and irresponsibility in that comment above about “The Open Group and TOGAF will not change their concept of enterprise architecture until the community as a whole does”

    Excuse me? This statement is dishonest and irresponsible?

    It is a simple statement of truth. How is making a truthful statement “hiding from responsibility”.

    And this attack is not directed at TOGAF or The Open Group, it’s directed at me personally, and I take it as such. You’re calling me an irresponsible liar.


    • I’ve apologised for this in person elsewhere, and in public on the subsequent post.

      In my defence, the phrase “dishonesty and irresponsibility” was meant to refer to the “will not change their concept of enterprise-architecture until the community as a whole does” – a point which I then expanded on in the subsequent text. But I can see how it could be interpreted instead as addressed personally to you (Len). All I can say is that that was not my intent, and, again, I apologise unreservedly for that.

  4. Hi Tom,

    It seems to me that you have clouded what could be two very important and useful posts by intertwining concerns.

    The first, is characterizing the responsibility space for
    i. helping to shape the EA field’s identity/self concept (
    and accompanying values/behaviors/practices/etc.) and
    ii. moving towards that self-concept (taking into account all the challenges and obstacles)

    The second is your frustration and needs. Which we do need to hear about, and do care about.

    I think that doing a better and more fair job of the first, would help resolve some of the tensions of the second. Alternately put, it would help you see more clearly what your role is and where and how to make your contribution.

    More explicitly. It felt to me like you were blaming The Open Group for driving an unhelpful characterization of EA to broad adoption. It also felt like you weren’t allowing that The Open Group is encumbered in a way that you are not. It has to develop consensus. And it’s member practitioners have to contend with the distance between where an organization is in mindset, responsibility/power structure, and much else that can put distance between practice and, arguably(given the pragmatic reality of many) an idealization of EA. And so forth.

    And that is precisely why you are important! You have more degrees of freedom. You can facilitate conversations that help draw the field into new conceptions of itself. Some organizations will want, and be in a position, to work at that frontier.

    Does that make sense in a helpful way?

    (Addressing part 4 and 5:) You have a role in this field, clearly. And some performance art to help the field reconceive itself in ways that make it more effective strategically, is a good thing. But if it comes across as too mixed in with your own specific set of personal concerns, the message gets confused and clouded.

    But that is how life is! And we who work as, or with, enterprise architects, had better be really good at receiving a mix of messages 🙂

    We need to do our part to ensure you feel valued — which includes earning a reasonable living, but also includes recognition that you do valuable work stimulating discussions of and helping to position EA and articulate its evolving identity/vision for/of itself (and hence what it _does_).

    And I sense that you were onto something with the responsibility question, but your discussion didn’t rise to its full potential due to being distracted.

    Goodness, I hope this helps. The intention is to express both value and encouragement, but in a practical way that says “here are some ideas” — maybe they are the wrong ones, but often that isn’t the point. Responding/reacting to wrong ideas can help pry loose the ideas that better fit your need and perspective. The important thing is that you want to!

    And we want you to want to! I need to remind people to buy your books! And we need to figure out what else to do, so you can work from a happy personal place — while still maintaining enough discontent to forge frontiers for us! 🙂

    • Ruth, many thanks of course. You and Dana have always been key guides for me in navigating this – and again I must be blunt – sheer mess that has been made of what enterprise-architecture could and should been.

      The mess really does need to be cleaned up – urgently, and quite possibly as a literal matter of survival. What’s clear is that I’m not the right person to do it: I’ve always been a John the Baptist kind of guy, I guess.

      Best leave it at that – but thanks again.

  5. Ah, well I know you have left the arena, but others may come to discuss…

    As I chatted about in a comment on the previous post.. the missing players here are higher education and government.

    The relationship between standardised bodies of knowledge for professions, and culturally stable problem domains, and the funding and conduct of peer-reviewed public research is critical.

    When Universities start treating enterprise architecture as a discipline, then a social knowledge-production architecture of a very impressive scale swings into play that puts industry consortia and the privatisation of knowledge and accreditation back in their appropriate junior-partner box.

    A lot of milage comes from practitioners working backwards from clinical problems and objectives. But there is some distance that can only be crossed by researchers pursuing evidence and testing theories where they lead.

    Alas – not until…

    • Ric: “the missing players here are higher education and government”

      And again, one of the key things you bring so brilliantly to this so-troubled domain is that wonderfully wry sense of yours – and, also your ability to strip things down their concise essence (an ability that, sadly, I most definitely lack… :wry-grin: )

      Once more, many thanks.

  6. I sympathise with Tom’s view.

    But on the “The Open Group and TOGAF will not change their concept of enterprise architecture until the community as a whole does”, I think that Len is right in that Open Group, as a company, plays an administrative rather than technical role in defining TOGAF. The member companies (representatives), that is the “community”, does that.

    Still, to be fair, the community is not the community of users at large but rather the community of member companies (representatives).

    As such Open Group as a company cannot change TOGAF, in theory.
    Still, while I was Chief Architect at TMForum, as a company, the intention was exactly that, to work across thematic member groups, find out the gaps and issues and supply, in agreement, an overall direction and roadmap for Frameworx (their framework) in order to render it more palatable and useful, as an EA framework, for the customers in the digital media industry at least.

    I did that but it didn’t work in the end but not because the direction was not sound or lacked agreement but because when egos flared and things got hot, as they do in case of critical change, the company management rather backed down and scaled down the role.

    TOGAF moves too slowly in who knows what direction while it becomes irrelevant. In the meantime, because of its clout, it hinders the development of other EA approaches.

    The problem is that TOGAF is driven by committee. One needs a strong chief architect to move things forward in the right direction.

    TOGAF, at first, must be made consistent, be trimmed and reorganised in essentials and separate good practices chapters. Then it must be supplemented with the missing parts. To speed up the process, it can adopt the goods from other approaches, with credits given, as with Archimate. After all, it is a public framework.

    Last but not least, it needs a roadmap, made public at that. So that the true community of users, rather than the members alone, know what to expect and be able to prepare, comment and contribute. For my part, I know little of what to expect from TOGAF.

    • Adrian – to a large extent, yes. But right now I’ve just given up: I’m not the right person to do much more on this, so best that I don’t – all I do is make things worse. Oh well. And again, apologies to all, I guess.

  7. Adrian Grigoriu asserts about TOGAF:

    “In the meantime, because of its clout, it hinders the development of other EA approaches.”

    Please provide an example of TOGAF preventing or hindering anyone from thinking differently about enterprise architecture.


  8. I was so excited by the question posed in “Saving enterprise-architecture from itself – 4: Responsibility”… Not the question “who is responsible for being stuck in a place that needs saving” but the questions that come up when we ask “who has responsibility for saving” — questions like “how does (more of) the field rise to the full promise of EA?”…

    And I am excited (and concerned) because Tom is one of the preeminent people who can make a difference because he asks, and gets us to ask, interesting/important/powerful questions like that! And his analysis is sharp (pointedly acute and accurate and smart and informed and more good things) — and impressively fast!

    • Ruth: “Not the question “who is responsible for being stuck in a place that needs saving” but the questions that come up when we ask “who has responsibility for saving” — questions like “how does (more of) the field rise to the full promise of EA?”…”

      Yes, exactly – in many ways finding the best way of (re)phrasing the questions is almost more important than the (current) ‘answers’.

      What’s become painfully clear over the past few days is that I’m not the right person to be asking questions in this specific space that calls itself ‘enterprise’-architecture. In many ways, all I’ve done is make things worse – for the incumbents, at least, and those who’ve been working right down in the practical roots of the field.

      Yes, I do need to continue asking questions, and perhaps occasionally some awkward questions too – sorry, that’s just who I am, it’s not intentional, it’s just the way it comes out sometimes, the way I seem to (fail to) interact with this world. What’s clear is that this isn’t an appropriate arena for me to ask questions any more. What an appropriate arena for me to do so – if any? – would be is far from clear to me at present, but no doubt I’ll find out. It tends to happen that way, eventually.

      Once again, many thanks.

  9. Len, you asked me to “provide an example of TOGAF preventing or hindering anyone from thinking differently about enterprise architecture”.

    Had you taken the time to properly read my statement, you would have realised that it is not about TOGAF hindering a different thinking, as you put it – in fact, it inadvertently stimulates that nowadays – but about hindering the take off and development of other approaches.

    The victims are the other frameworks, including mine, who have little chances to surface or survive in the market left. The big issue is though that, while TOGAF has established its strong EA monopoly, it doesn’t help much in the delivery of EA, at least in my view, holding it back as such.

    It also looks to me like TOGAF is at least ignoring if not competing with other approaches rather than collaborating or integrating the best of breed for the good of the enterprises world wide as I thought it is supposed to.

    TOGAF should be a method open to innovation, given its supposedly open membership, rather than a tool for milking the cash cow.

    People actually think that TOGAF must be right because it has so many brand names behind, because of its many followers in IT, because of its many vocal backers whose interests are intertwined with TOGAF, because it has the dominant training and certification market share, because it has its own conferences… and, not least, because so many employers demand it now choosing to trust it on faith, at their own peril.

    So much so that people gave up the last of critical thinking. They surrender to TOGAF. To no avail though since TOGAF is basically a rather generic solution architecture development process. You follow it, you end up with what your requirements stated in the first place rather than an EA. TOGAF does not even come with an EA definition… as already said and discovered myself at the training.

    I would have preferred you or anyone tell us about the TOGAF roadmap, is there any light at the end of the tunnel? So what happens behind the TOGAF curtains?!

Leave a Reply

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