Link: http://weblog.tetradian.com/2013/11/12/saving-ea-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 regulation, high transaction-load, high 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?
