How IT-centrism creeps into enterprise-architecture

A kind of follow-up to the previous post ‘IT-oriented versus IT-centric‘, this one starts from a Tweet from the Open Group’s official TOGAF Twitter-account:

  • togaf_r: TOGAF Resource: The TOGAF 9.1 changes overview and 6 other slide decks are now at (free PDF) #ogsfo

The link points to the Open Group’s ‘public resources’ website for TOGAF (The Open Group Architecture Framework), which includes the respective slidedecks.

One of those slidedecks is ‘TOGAF Version 9.1 Management Overview‘ [PDF] – which turns out to be an interesting illustration of exactly how IT-centrism creeps into enterprise-architecture…

We’ll start with slide 18 (lower part of p.9):

What is an Enterprise?
• A collection of organizations that share a common set of goals
– Government agency
– Part of a corporation
– Corporation
• Large corporations may comprise multiple enterprises
• May be an “extended enterprise” including partners, suppliers and customers

They don’t give the source for that definition, but it’s one I’ve seen elsewhere – I think it’s used in FEAF, for example. Importantly, this definition explicitly does not regard ‘organisation’ and ‘enterprise’ as synonyms. In my view it doesn’t go far enough in that separation, but at least it’s clear that there is a difference, and that ‘the enterprise’ often extends well beyond the boundaries of ‘the organisation’. In short, so far so good.

Next, look at slide 19 (upper part of p.10):

What is an Architecture?
• An Architecture is the fundamental organization of something, embodied in:
– its components,
– their relationships to each other and the environment,
– and the principles governing its design and evolution.

As they say on the slide, that definition is adapted from ANSI/IEEE Standard 1471-2000, another well-known and much-used reference. Again, so far so good.

But note what happens in slide 20 (lower part of p.10), which purports to bring together those previous two definitions:

What is Enterprise Architecture?
Enterprise Architecture is:
• The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model. [MIT Center for Information Systems Research]
• A conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives. []

Which for me brings up an instant response of  “Huh? Now wait a minute?”… The SearchCIO definition would make reasonable sense if it wasn’t arbitrarily constrained only to the view of the organisation – not the enterprise, as per that previous definition of ‘enterprise’. And in the MIT definition it’s constrained even further, with an unexplained emphasis on IT-infrastructure and “integration and standardization” – which doesn’t make sense at all.

One slide further on, and without any explanation or justification, we’re suddenly down in classic TOGAF territory, where the foundation for everything is IT-infrastructure, and where ‘Business Architecture’ is ‘anything not-IT that might affect IT’. Oops…

And by the time we get to slide 22 (lower part of p.11), we’re presented with this:

Why Enterprise Architecture?
• Effective management and exploitation of information through IT is key to business success
• Good information management = competitive advantage
• Current IT systems do not really meet the needs of business
– Fragmented, duplicated
– Poorly understood
– Not responsive to change
• Investment in Information Technology
– Focussed on system maintenance
– Tactical developments rather than a strategic plan

All I can say to that is “You what???”… To be blunt, what has any of this got to do with enterprise-architecture, in terms of the definitions of either ‘enterprise’ or ‘architecture’ above? “Some but not much”, is the short answer. To illustrate the point, let’s deconstruct some of those assertions above:

—  “Effective management and exploitation of information through IT is key to business success” – is it? Can you prove this? Given this arbitrary assertion about the importance of IT, can you show the connection – if any – to either ‘enterprise’ or ‘architecture’? And what do you mean by ‘IT’ anyway?

— “Good information management = competitive advantage” – possibly. But what about government and other organisations for whom ‘competitive advantage’ has little or no priority or point? And what about all the other non-IT issues – such as respect and trust – that might have far greater impacts on ‘competitive advantage’?

— “Current IT systems do not really meet the needs of business” – so what? The same is true of many other business-systems, such as the structure and design of core business models – which, architecturally speaking, would usually need to come before any fix-up of outdated IT-systems.

— “Investment in Information Technology [maintenance focus, tactical]” – again, yes, we know, but so what? The same is likely to be true about almost every other aspect of the enterprise – especially in multi-partner enterprises.

So let’s again be blunt about this: that slide above is best dismissed as mere marketing-puff – a sales pitch for large consultancies who want to sell ‘IT-rationalisation’ programmes to clean up the IT-mess that in all probability they themselves had created in the first place… In practice, there’s so much that’s missing from that ‘Why Enterprise Architecture?’ – such arbitrary and unjustifiable constraints on scope – that it really is all but meaningless. It describes only a tiny subset of the actual scope of ‘the architecture of the enterprise’, but somehow seems to purport that this is the whole. Which would be laughable if it wasn’t such a bad joke – or such a destructive one.

In other words, somewhere between slide 19 and slide 22, we’ve gone from enterprise and business, to a largely-spurious attempt at business-justification for one specific subset of enterprise IT-architecture. The remainder of ‘the architecture of the enterprise’ – especially about anything not-IT – has been erased from the story.

Which is why the TOGAF-style EA story just does not make sense to anyone who’s not already embedded and wedded to an IT-centric view of the world.

If you want to see how and why enterprise-architecture is still such a darned hard ‘sell’ to just about anyone in business, all you need to do is read that ‘Management Overview’. And quietly weep…

Surely by now we can do better than this? Please?

6 Comments on “How IT-centrism creeps into enterprise-architecture

  1. Tom, do you think most TOGAF practioners/”marketeers” are doing or talking about Infrastructure Architecture? Especially because you tweeted:

    RT @Dave_van_Gelder: Why is EA constantly related to IT and CIO’s? #ogSFO >my point exactly, Dave… see

    To which I reacted with:

    @tetradian @Dave_van_Gelder #ogSFO Perhaps because The Open Group’s EA = Infrastructure Architecture?

    My question to you at this point is: How does the The Open Group’s vision of the “Boundaryless Information Flow™” (a shorthand representation of “access to integrated information to support business process improvements” represents a desired state of an enterprise’s infrastructure and is specific to the business needs of the organization.) fits in your view of Enterprise Architecture?
    (because to me it fits rather well (or maybe even exactly) with my definition of Infrastructure Architecture…)

    I asked this question also through this tweet to Stuart (and you):
    @ArtBourbon @tetradian Please help me realign my view on Infrastructure & #entarch by answering my question at

    You may answer it here or on my site, whatever you feel is more appropriate…

  2. @Tom: “How IT-centrism creeps into enterprise-architecture”

    Yep – Well done for exposing this in very direct and constructive way.

    All it needs is for TOG to amend the slides – 10 minutes? But I wonder how long it will take – if ever!

    Ho Hum. You and I and the others in the minority will continue to expose this information (for we are architects after all and thats what architects do).

    NOW – something profound just hit me……

    It is very very very interesting in that what is happening here is exactly the same type of thing that happens in organisations which is one of the fundamental problems that EA (well PEAF does!) addresses…. That of governance upwards…

    It’s like people working at the project level seeing the strategy above them being fatally flawed but not having the influence to get that message up to the strategy level to change it.

    We (you me and the rest of the minority) are the people working at the project level (outside TOG as individuals) seeing the strategy above them (as defined by all TOG members) being fatally flawed but we do not having the influence to get that message up to the strategy level to change it – TOG.

    In projects., “proper” EA Governance (as defined in PEAF) – allows this to happen by exposing the Enterprise Debt being created and providing that information up to the strategy level for appropriate decisions to be made – at that level. But that only works if the bounding organisation has already changed to allow that to happen. EA allows us to make those changes.

    Regarding TOG and their “view” of EA we will never get them to change and listen to what we are saying because TOG first needs to change to allow that to happen.

    Now, after elation at finding a profound correlation, I’m depressed. It’s the same depression (aka frustration) felt by massive numbers of people working in projects all over the world – knowing something is wrong (with the system – system being he system of change they work within) but not being in a position to change it, and being ignored by those that are in a position to change it (indeed that is their duty and job but they do not realise it)

    The people that can see the problem (and therefore the solution) have no power to implements it.

    The people that do have the power to implement the changes cannot see the problem – Indeed seem to actively ignore the problem – are therefore are not interested in the solution.

    This is the fundamental cultural problem that “proper” EA addresses….

    People “at the top” (management) not only “should” listen to people “below them” (workers), they should actively seek out their views. It should be their duty.

    People “at the bottom” (workers) should not only be encouraged to expose problems to people at the top” (Managers) they should be mandated to do so. It should be their duty.

    This is the classic cultural change that Deming (and the Japanese) were talking about, and it is why I see Deming so useful for EA. (Deming = Quality of Operational efficiency. EA = Quality of Transformational Efficiency – see the “Demming and TQM vs Zachman (et al) and EA. Two sides of the same coin?” discussion on linkedin at

    So. The question is how do we apply EA to TOG to transform it into and organisation that treats the input of one voice with a massively important message with the same importance as inputs from large commercial organisations (e.g. consultancies) ??????

    If TOG cannot apply “true” EA to itself, how can people treat them as leaders in the field???

    How can we get TOG to eat it’s own dog food???

  3. @Kevin: “How can we get TOG to eat it’s own dog food???”

    To correct myself!……

    The problem is in the work that needs to happen BEFORE TOGAF. That is where PEAF fits.

    So we cannot say “How can we get TOG to eat it’s own dog food???” because the food it needs to eat is not in TOGAF!

    It would be more correct to say “How can we get TOG to eat (aka apply) PEAF to itself”

    And we all know the answer to that question!

    I suspect it would be less difficult to perform nano-engineering using a planet!

Leave a Reply

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