Saving enterprise-architecture from itself – 1: Introduction

What’s wrong with enterprise-architecture? For that matter, what’s right with it? How can we do more of what’s right and less of what’s wrong? And what is the point of EA, anyway?

Following on from those posts on certification and EA, I want to do another brief series, way up at the big-picture level again, addressing the simple question of Why EA? In short, what’s it for? And once we’re clear on what it’s for, how well are we doing what’s for? How could we do it better?

What’s driving me, here, is a paraphrase of Russ Ackoff:

Doing the wrong thing better merely makes things worse

What worries me is that much of the current supposed ‘success’ in EA is actually just that: doing the wrong thing better. (And yes, sorry, but once again I am going to have to single out the TOGAF / Archimate axis here as a prime example of ‘doing the wrong thing’… or, more accurately, doing a different ‘right thing’ but making it lethally-wrong and lethally-dangerous by calling it something else that it isn’t.) Collectively, the better we get at doing the wrong thing, the more we’re making things worse – and yet we seem to have almost no way to see that we’re making things worse. Collectively, we’re so much blinded by our own so-called ‘success’ at the small-picture level that we’re failing to see that we’re at present setting ourselves up for a really primal failure at the big-picture scale. That’s the problem; that’s the tragedy here.

Seems to me that there’s an urgent need to save enterprise-architecture’ from its own mistaken ‘success’ – or, in short, saving enterprise-architecture from itself.

What I’ll do in this brief five-part series is as follows:

  • Part 1: Introduction: this post, setting the overall scene, about the basic need for an ‘architecture of the enterprise’
  • Part 2: Personal background: a bit about my own working-background, to explain why I interpret EA in the way that I do
  • Part 3: Sally’s comment: exploring a comment by Sally Bean on a previous post here, to see what’s missing from current EA
  • Part 4: Len’s comment: exploring a comment by Len Fehskens on the same post, to see how and why EA goes wrong
  • Part 5: What next?: given the gap between what EA should be doing, versus what it’s doing now, what can we do to correct our course?

But first, what’s the point of this, anyway? – this overall discipline of enterprise-architecture? For this, I’d suggest the following principles and ground-rules:

— ‘Enterprise architecture’ consists of two words – ‘enterprise‘, and ‘architecture‘ – in conjunction with each other. We clarity not only on each of those terms, but how they fit together.

— In essence, ‘enterprise‘ is just an idea, a desire, an intent, a vision, a promise – almost any of those terms will do. It’s a kind of ‘drive, with purpose’.

— Confusingly, the term ‘enterprise’ is also used for the practical expression of an enterprise in that sense above. In other words, not so much purpose on its own as, for example, an ‘ecosystem with purpose’ – a complex, adaptive, emergent ‘system’ with some form of implied or explicit collective-purpose.

— Even more confusingly, the term ‘enterprise’ is also often used for an organisation in context of an enterprise, in that sense above. In other words, a blurring-together of the ends represented by enterprise – the idea, the purpose, the drive – and a means (the organisation) through which some aspects of that enterprise can be achieved. Treating a means as an end in itself is rarely a good idea…

— In practice, every enterprise exists in context of, and often interacting with, many other enterprises.

— In essence, ‘architecture‘ is the practical expression of one very simple idea: things work better when they work together, on purpose.

— A core understanding of any real-world architecture, when viewed as a ‘system’, is that everything depends on everything else, and everything is in context of everything else.

— A direct corollary of this interdependency is that, for an an architecture, everything and nothing is ‘the centre’ of the architecture, all at the same time. The moment we make anything or any domain to be ‘the centre’ – with everything else always solely subservient or in context of that arbitrarily chosen ‘the centre’ – we set ourselves up for whole-of-system dysfunction or failure.

— In an architecture, all boundaries are ultimately artificial, arbitrary and potentially-problematic. (However, as in an ecosystem, boundaries are also where many of the most interesting things can happen…)

There’s plenty more we could add to those lists, but that’s probably enough to get started.

An enterprise-architecture brings all of these themes together, to combine together the story of the architecture with the structures of the architecture to do something that’s useful in practice.

We’d typically develop an architecture for an organisation about the enterprise within which that organisation operates. In order to create an ‘enterprise-story’ that meaningfully describes the organisation’s stakeholders, we’d typically describe an enterprise that’s some three or more steps in scope larger than the scope of the respective organisation:

And we’d also need to support multiple views into, within and around the organisation and enterprise – inside-in, inside-out, outside-in and outside-out:

We can choose to view and act on only a subset of that overall context-space – but we must never forget that it is only a subset, not the whole – and also that the boundaries for that subset, and the subset itself, are a choice, not a ‘fact’.

A practical example

As usual, that’s almost certainly too abstract on its own, so we’ll need a concrete example – in this case, an airport.

An airport exists in context of the enterprise of air-travel (people) and air-freight (things), which in turn are subsets of the broader enterprises of travel and freight.

The airport can be said to exist as a set of physical structures – terminals, hangars, runways, sensors, control-systems and much, much more – at an identifiable physical location. There are also mobile structures or entities – vehicles, aircraft and suchlike – that can move around within and/or across the boundaries of this physical ‘the airport’.

The airport is a node of and for a very wide variety of information-types and information-flows. In a sense, the airport ‘is’ information – though that’s definitely not all that it is.

The airport is a nexus for another very wide variety of people and people-relationships – travellers, employees of the airport itself, and employees and staff of many other organisations that intersect with the airport, such as delivery-drivers, bus-drivers, government, police, health and many more.

The airport is also a nexus for stories – for individual and collective purpose. A vast array of enterprise-stories intersect with, traverse through and, in some cases, terminate at the airport. (This is part of what makes the question ‘Who is the customer of the airport?’ very definitely non-trivial.) Some of these stories are in relation to the airport, but not necessarily associated directly with the airport itself – for example, as a symbol of civic or national pride, or as a focus for anticlients‘ disaffection.

Linking information and purpose, as money or finance, the airport is also an intersection for a vast array of financial concerns – the airport itself as a business, the airport as a place of business, the airport as a node in other businesses, the airport as both a source and sink for tax-revenue, and so on.

Aircraft fly in and out of the airport, in accordance with guidance from air-traffic control – which, by definition, operates at a larger scope than the airport itself. Much the same applies to land-vehicles moving in and out of the airport, although the guidance for that traffic is often more loosely controlled.

The airport has distinct zones (physical and otherwise), some of which require explicit management of boundaries – for example, the distinction between ‘air-side’ and ‘land-side’ within the airport terminals and out on the tarmac, or the operational boundary – and some of which are intentionally much more porous – for example, non-travellers on ‘land-side’ accompanying departing or arriving passengers, up to the ‘air-side’ boundary. Much the same applies to information-flows: cell-phones and public over-the-air data-links can be used almost anywhere, but monetary information-flows and much of the air-traffic-management information will be tightly constrained.

Also – and too often forgotten – the fact of the airport as a large and largely-open physical location means that there are many potential or actual intersections with wildlife. Rodents and network-cables are not a good mix; neither are large animals or large birds with aircraft, on the land or in the air respectively; insect-infestations can cause other nightmare problems, such as cockroaches in kitchens, or wasp-nests high up in the ceiling of an airport-terminal building.

And then – just to make things even more fun – there are other crucial factors over which we have no control at all, but which we must include in our architecture design. For the airport, the most obvious example is weather. How will you manage high winds, heavy rain, fog, ice, snow, sleet? You can stop aircraft taking off, if you have to, but aircraft have to land somehow… Technology can help with that – ILS, for example, Instrument Landing System – but what about aircraft that aren’t equipped with that technology? If you have hazardous conditions, what’s the impact for different sizes and types of aircraft? – a little two-seater general-aviation or a microlight is just as much ‘air-traffic’ as a 500-seater commercial airliner. And then there are other human factors outside our control: would-be terrorists, of course – everyone worries about those. But you also might have a disgruntled nearby resident with an anti-aircraft gun (real example: Germany) or an idiot with a shotgun, sitting in a garden-chair held aloft by balloons wandering into the airport flight-path (real example: also US) or a 40ft flying-pig balloon drifting loose on a calm day on the approach to the busiest airport in the world (thank you, Pink Floyd). Oh, and your everyday teenage idiot who thinks it’s fun to shine his $5 laser onto an airliner on final approach. (Yeah, I’ve personally been on the receiving end of that last one – literally blinding for a few seconds. So think about what it’s like for the flight-crew, in the last few seconds of finals – and what it could mean for the airport…)

All of this is within the scope of an overall enterprise-architecture for the airport: everything depends on everything else. And anyone working on any given subset of that architecture still needs always to be aware of that whole scope, and aware of the potential for interactions from elements conventionally described as ‘out-of-scope’ for their own selected sub-domain – otherwise there is significant risk of creating conditions for ‘unexpected’ failure.

Arbitrarily selecting one sub-domain within this overall context-space – information-systems and information-flows, for example – and myopically ignoring all other aspects of the enterprise, will cause failure within the overall enterprise. (That’s classic IT-centric ‘enterprise’-architecture in a nutshell…)

Arbitrarily privileging one sub-domain over all others within the shared-enterprise will cause dysfunctions, sometimes up to the level of total failure. Consider, for example, how ‘security’, in many different forms and senses, now forms a literal blockade in both directions on the boundaries between ‘air-side’ and ‘land-side’ – and, amongst other ‘unintended consequences’, often imposes huge delays onto the flows of passenger-traffic.

Arbitrarily privileging the interests of specific stakeholders over above those of others can cause not only flow-dysfunctions – as for ‘security’ above – but also can skew the entire design and operation of the airport such that other stakeholders can become deeply disaffected, and risk becoming active anticlients for the airport. For example, contrast London City Airport – where the whole focus is on passenger through-flow, and ‘check-in to departure’ time will often be a half-hour or less – with a large commercial airport such as London Heathrow or London Stansted – where the airport-terminal is in essence set up as a giant, mandatory, over-priced shopping-mall, and where the official ‘check-in to departure’ time is listed as three hours or more.

Yes, there’s a lot in there. (Ask Norman Foster, who designed the terminal-buildings for Stansted and Heathrow Terminal 5: but even he only did the architecture for the terminals, not the entire airport!) And yes, an enterprise-architect for the airport would need to be aware of all of that. Not necessarily design for it all – in fact it’s unlikely that any one person could design for it all. But be aware of it at all times, and take it into account at all times, a definite yes.

That’s enterprise-architecture.

By definition, that’s the necessary scope and nature of an enterprise-architecture – because it’s the literal architecture of the overall enterprise.

Anything less is not enterprise-architecture: it’s an arbitrary sub-domain pretending to be the whole, or deluding itself that it ‘is’ the whole – with potentially-disastrous consequences for the real enterprise-as-whole.

Describing as ‘enterprise-architecture’ something that is not the literal ‘architecture’ of the enterprise can be very dangerous indeed – in many, many different senses. For example, if anything goes wrong – if anything ‘unexpected’ happens – we won’t be able to understand why, or what to do about it, because we’d have arbitrarily dismissed as ‘out of scope’ everything that we’d actually need to know there. By definition, it’s the wrong thing to do, the wrong way to approach enterprise-architecture.

And yet that is exactly what is done within many current approaches to ‘enterprise’-architecture: they assert and insist that one subset ‘is’ the whole, and either myopically, or by deliberate intent, ignore all the rest. Yes, collectively we seem to be getting much better at doing what’s claimed to be ‘enterprise’-architecture: but it’s the wrong way to do it, we now know that it’s the wrong way to do it, and doing the wrong thing better merely makes things worse.

If our putative profession keeps on going much further in the direction that it’s headed now, the inevitable failures, at ever larger and larger scales, will bring the entire discipline of enterprise-architecture into such disrepute that it will, of necessity, die. And that won’t be a good outcome for anyone. Not for anyone at all.

That’s the real concern that’s at risk here.

And we’ll explore that more in the later parts of this series.

Over to you for any comments so far?

[Update (11Nov13) – I don’t like changing content once something’s published, but in this case I really did need to add, in the ‘airport’ example, the section on weather and other factors that are inherently ‘outside our control’.]

13 Comments on “Saving enterprise-architecture from itself – 1: Introduction

  1. Hi Tom, I feel that you are doing exactly the same as what you’re blaming TOGAF for. You claim that TOGAF is pushing their definition of enterprise (and enterprise architecture) on the rest of the world, well that’s exactly what you are doing with your definition of enterprise and thereby enterprise architecture.
    In my opinion, the scope of the enterprise (and thus enterprise architecture) depends on the “problem” you need to deal with. This means that it is OK to deliberately choose to keep it narrow in some cases (“put a domain in the center”), and sometimes you will have to look at the broader perspective (beyond the boundaries of the organisation). For me, this can all be EA.
    As a non-English speaker, I feel that your definition of enterprise is rather artificial, far away of common use of the word “enterprise” in the spoken language (at least in my opinion). You consider the environment to be part of the enterprise. Yes, the environment is also a system and yes it has an influence on the enterprise, but saying that it needs to be part of the enterprise goes too far for me. The environment is outside my locus of control and that’s why I prefer to keep it as an out-of-scope system my enterprise interfaces with (so it is definitely important to me), rather than making something that I cannot control part of my system. When a vulcano erupted in Iceland a few years ago, it had a big impact on my people and business around the world (no more flying in and out the whole continent for days); I don’t think many businesses considered this vulcano to be part of their enterprise architecture (though it is a fairly predicatable systems and it had impact on my organisation). For practical reasons, you cannot then leave parts out of scope (and yes some parts will prove to be more important than you initially thought). Nothing stops people to increase their scope when needed.
    But then again, this is just my view, and I’m not going to claim that this is the only correct view (as you tend to do with your definition). Depending on the context (the problem you’re facing), yours may be better than mine or even a smaller scope may be justified in some situations. Let me end with the wise words of Einstein: “Make things as simple as possible, but not simpler.”

    • @Christof: “As a non-English speaker, I feel that your definition of enterprise is rather artificial, far away of common use of the word “enterprise” in the spoken language (at least in my opinion).”

      I do accept that in part this is a language-problem: we haven’t as yet been able to find in Spanish or Portuguese any equivalent (at all – which is worrying) for the sense of ‘enterprise’ we’re using here.

      If say ‘we’ above because it’s not just me – there’s a lot of us having made this jump. That said, there’s a heck of a lot that’s holding us back – hence the point of this series.

      For more on why that usage of ‘enterprise’, see Jack Martin Leith’s post ‘What is an enterprise ecosystem, and why does it matter?’ ( http://www.jackmartinleith.com/enterprise-ecosystem/ ). He uses some of my material in places, but extends it, and in a way that’s much more clear and succinct than I’ve ever done.

      Hope this makes a bit more sense now?

      • Hi Tom,

        In Dutch the word for Enterprise is “onderneming” which has similar multiple definitions as the word enterprise in English. But the most commonly usage of the word “onderneming” is that of “bedrijf” which translates to “business” in English. So most/all people in the Netherlands use Enterprise Architecture as a definition for the whole architecture for a business. Business architecture is mostly used to define the architecture of the client facing side of the business and infrastructure architecture is commonly used to define the I(C)T of the business.

        Most enterprises/ondernemingen started architecture initiatives at infrastructure level before anybody had heared of TOGAF of Enterprise Architecture and those initiatives were often called ICT and later IT architecture or “working under architecture”.

        If I understand you correctly you are talking more about the Enterprise Ecosystem so in my opinion it would be wiser/less confusing to use the phrase Enterprise Ecosystem Architecture as the next logical step to take in architecture.

        • Peter – I take your point about the language-problem (again) – i.e. that we’re dealing with a concept that barely exists in many natural-languages (which is a huge problem just in itself).

          On the term ‘Enterprise Ecosystem Architecture’, yeah, again, I take your point. The catch is that ‘EEA’ would again be interpreted as a subdomain of EA – and correctly so, in the same sense as ‘Enterprise Business-Architecture’ (EBA) or ‘Enterprise IT-Architecture’ (EITA). Which, however, leaves ‘Enterprise Architecture’ still stuck as being misused as a term for IT-architecture. Which, in turn, would leave us with the ludicrous – and (once-again, for Len’s benefit), potentially-dangerous right up to the level of extinction-level lethality – situation that a very small subset of a context (i.e. EITA) is portrayed as the superset (EA), whereas the superset (your EEA) is portrayed as a minor subset of (in this case) IT.

          So, yeah, nice try, but unfortunately no cigar… 😐 As far as I can see, there is no way out of this mess but to somehow force the existing self-styled ‘EA’ community to stop misusing, in an utterly misleading way, a term that is not and should never been portrayed as theirs. An alternative term won’t do the job – especially when the respective terms imply the exact wrong relationships between subset and superset.

  2. Christof,
    I am afraid that when you state that “the scope of the enterprise (and thus enterprise architecture) depends on the “problem”” then you indeed define EA as a solution architecture.
    This is in fact quite common today. Many “EA architects” design and review solutions rather than modelling the architecture of the whole enterprise.

    EA is the big picture of the enterprise as the name says.
    In practice, EA is the integrated view of all the various architectures with different scopes you were, in fact, rightly talking about.

    But the EA is about the whole while you are focusing on the parts that make the EA, in isolation.

    The EA architect is primarily concerned with the design of the whole enterprise representation and the integration of the EA parts into the whole.

    The solution architect is concerned with the architecture of a part.

    An enterprise where the parts are designed bottom-up, without the big picture of EA, would end up with duplications, multiple technologies for the same function… This is exactly what EA aims to avoid.
    The problem with EA today is that architects do not use a proper EA framework that help them design the parts in the context of the whole EA. Check FFLV-GODS for that.

    • Christof: strong agree with Adrian when he says that putting up arbitrary boundaries on scope in effect drops the ‘enterprise’-architecture back to an artificially-constrained solution-architecture.

      @Christof: ” The environment is outside my locus of control and that’s why I prefer to keep it as an out-of-scope system my enterprise interfaces with (so it is definitely important to me), rather than making something that I cannot control part of my system.”

      Sure it’s not in your control: that’s the whole point. That’s precisely why your architecture needs to be aware of it, and design resilience and/or antifragility for it, rather than simply playing ostrich and pretending it doesn’t exist.

      If you want a real-life example, compare the various companies who had data-centres sited in New York, just prior to Hurricane Sandy. Some had understood the risks of issues such as climate-change, and had explicitly factored in contingency-plans, roll-backs and system-redundancies. They survived, in some cases with barely a hiccup. Quite a few of those who didn’t bother to think about such things that were ‘outside of their control’ – because they were ‘outside of scope’ – didn’t survive. Your choice?

  3. Excellent post Tom. I am not sure it will change anything but you introduction is succinct and totally on the mark, IMHO. It all adds to the voices of the crowd (that is beginning to get louder) that the Emperor has no clothes on. (Or rather the emperor does have some new clothes but they are a boiler suit rather than a regal coat of state)

    @Christof – You speak of putting a domain on EA – can you not see the absurdity of that statement? the E puts the domain on A. If you want to add a sub-domain to it then you need to add that domain to the acronym too which then means you are not talking about EA anymore.

  4. “And yes, sorry, but once again I am going to have to single out the TOGAF / Archimate axis here as a prime example of ‘doing the wrong thing’… or, more accurately, doing a different ‘right thing’ but making it lethally-wrong and lethally-dangerous by calling it something else that it isn’t”

    “Lethally”? Really, “lethally”?

    I offer for your consideration, two children’s tales: “Chicken Little (Henny Penny)” and “The boy who cried wolf”.

    At worst, a good name for a useful concept (“enterprise architecture”) has been hijacked.

    We’ll just have to find another name for our concept and sell it to a world that, to be honest, right now just doesn’t seem to want what we’re selling.

    len.

    • Yes, Len, I do mean ‘lethally’.

      Real example? Healthcare ‘architectures’ that are so IT-centric that they are a direct contributing-factor to the mess we have (in the UK) with things like the Mid-Stafford hospital management-failures. (Several hundred deaths, and still counting, in that one example alone – and it’s becoming clear that there are dozens of others. Thousands of lives lost there, Len – thousands of lives.) Or just take a look at the fiasco of the US healthcare.gov website – the chance of that fundamentally-flawed architecture costing lives is extremely high. (The whole ‘architecture of the enterprise’, that is – including the quagmire of procurement-processes that drove the whole mess.)

      Real example? The failures at Chernobyl and Fukushima, driven directly by a failure to ‘connect the dots’ across the whole system – in other words, a failed ‘architecture of the enterprise’. (The IT-architectures were probably fine in both cases – but the disconnect across the whole all but guaranteed systemic failure and significant loss of life and livelihood in both cases.)

      Real example? IT-centric ‘architectures’ for robotics-development – primarily in the US, unfortunately – for fully-autonomous live-weapons drones: no human-in-the-loop, explicitly by design, so as to bypass the ‘nuisance’ of the laws of war.

      Need I add any more examples? – there are thousands of them.

      An enterprise-architecture that does not explicitly start from the human domain – not the IT-domain – will inevitably become lethal. In some examples, potentially extinction-level lethal.

      And no, that ain’t no ‘Chicken Little’, thank you very much… Nor is it ‘crying wolf’…

      Please, Len, think, dammit, think – you’re not stupid, no way, but you’re thinking way, way, way too small a scale here, way too narrow a scope. Which is exactly the damn problem we’re trying to resolve – or that I’m at least trying to address here. Are you? At all? Or just happily assuming it doesn’t exist and/or doesn’t matter? Because that’s what it sounds like right now. Especially when you, of all people, sink to petty putdowns like ‘Chicken Little’ and ‘Crying ‘wolf”…

      And it’s a problem that’s made harder and harder every day as a result of what you so carelessly dismiss as ‘just a term-hijack’. Have you never looked at the real-world of term-hijacks? – especially in life-critical areas? Have you never heard of the (now) none-too-fictitious NewSpeak, and its implications of explicitly blocking the ability to express fundamental concepts?

      Sigh… sigh indeed…

      “We’ll just have to find another name for our concept and sell it to a world that, to be honest, right now just doesn’t seem to want what we’re selling.”

      Now that’s a fairy-tale, all right…

      I’m painfully aware that right now no-one wants what we’re ‘selling’ (your term, not mine). There’s a huge ‘anti-want’ for what we’re ‘selling’: no doubt about that at all. There happens, however, to be a huge need for it, an unbelievably huge need for it – ask any climate-scientist, for example, any resources-geologist who’s watching how soon we start running out of economy-critical resources, or any futurist who can see further than about five years ahead. If we wait around until someone at last wants to ‘buy’ before getting started on this, it’s gonna be way, way too late…

      Can you not see that? Can you not see that, given the timescales and the literally global scale of the problem, it’s urgent that we get properly moving on this right now?

      In a sense, it’s easy for me: I have maybe ten years left, twenty at the absolute most, so the chance of my still being alive when the shit fully hits the fan is remote, if not laughable. Same for you, probably. But there’s no doubt in hell that’s coming: it shouldn’t take a decent enterprise-architect long to work that one out. And I’m not going to go down in history as one of the people who didn’t give a shit about future generations, at a time when it really mattered, and we had some chance of helping to make that not-too-far-in-the-future mess at the least survivable for those who live then, and maybe even thrivable. Are you going to go down as one who couldn’t give a shit about the future? – because that’s what it’s sounding like right now.

      So go ahead: put me down if you want, mock me if you want. As you’ll remember well, lots of people in EA did just that seven years ago, when they all mocked me for saying that EA needed to more fully about business-architecture, as something more than just ‘anything not-IT that might affect IT’. Turned out to be right, didn’t I? So consider carefully the possibility that I might just be right about this too? – and that, whilst in the past the myopic stupidity of so much self-styled ‘enterprise’-architecture merely killed companies (which it did – as you well know), there are serious risks that the same myopic stupidity could well kill us all.

      So go ahead: mock, belittle, all the rest. You’ll have plenty of company in doing so, I’m well aware of that. But perhaps consider too that there might be real consequences of doing so, for a lot more than just you and me?

      Your choice.

      • Scratched a sore spot, did I?

        You completely missed my point Tom.

        I absolutely agree with you that were we able to do “real” enterprise architecture well, the world would be a much better place.

        But blaming the currently shortsighted conventional wisdom on enterprise architecture (and more specifically, TOGAF and Archimate) for the terrible tragedies you enumerate won’t help. That’s my point. Worse, they make you sound like a nutcase, and if people were to take you seriously, would lead to utterly unrealistic expectations for the efficacy of a profession that does not yet exist.

        You don’t deserve to be written off as a nutcase.

        But lack of foresight, failure to consider the big picture, bad implementations, etc., all seem to be part of the “human condition”. If you get sick and don’t go to a doctor, is it the medical profession’s fault? We as a species have a predisposition to “everything will be all right”, “maybe it will go away”, “it can’t be that bad”, “it’s a conspiracy” thinking.

        You finish up your rant with:

        “Turned out to be right, didn’t I?”

        Yes, you and lot of the rest of us as well.

        “So consider carefully the possibility that I might just be right about this too?”

        You’re right that the need certainly exists. I think you’re wrong about the causal relationships, and I think this will lead you to invest a lot of energy nonproductively.

        “there are serious risks that the same myopic stupidity could well kill us all.”

        That “myopic stupidity” is not the sole province of enterprise architecture. And enterprise architecture as currently practiced is certainly not its cause. Again, you’ve got it backwards. EA is the way it is because we as a species have a predisposition towards myopic stupidity, towards oversimplification, towards solving the easy problems even when they’re not the problems we really have.

        But we do, slowly, painfully, make progress. We make progress by looking at the real causes, not straw men.

        len.

        • Lest you forget that I have for years shared your concern (if less hysterically) about the IT-centricity of the conventional wisdom on EA, I quote myself from a recent LinkedIn discussion:

          Here is what I see as the problem. In conventional English, the compound noun “enterprise architecture” would be expected to mean something like “the architecture of an enterprise”, or “architecture in the enterprise context”. Every other instance of a compound noun comprising the word “architecture” and a qualifier conforms to this expectation.

          By far the vast majority of people who call themselves enterprise architects violate this convention. What they actually do is something that would more accurately (i.e., be in accordance with the expectations engendered by the conventional interpretation of compound nouns in English) be called “business-value directed commercial business organization information systems design”. Calling something by the name of the (in this case much) larger class within which it is contained is an instance of synecdoche, which is a figure of speech.

          So, the name of this emerging profession is either a rhetorical gesture that is inherently misleading and self-aggrandizing, or, less charitably, it is an outright lie.

          Some of us are not comfortable with this as the initial premise of an emerging profession, especially one that we believe has enormous potential to facilitate all forms of human endeavor.

          len.

          • Mmmm, I could wish for a little more cordiality from this exchange – but it is interesting to read.

            Some thoughts…. relevant to the professionalisation of EA but I declare no attempt at a coherent argument or system of proposition.

            ———-

            Enterprise Architecture – as Len so clearly indicated – incorporates the idea of intentional structure – things built deliberately to an end. But – and I find this but to be quite a doozy – all the ‘big guns’ of the EA world seemed to have excised the verb ‘design’ from their discourse. They will reach for ‘engineering’ – and of course risk being referred to a ‘dagnamned EITA’. Mostly though they seem to want to go with the empty, circular neologism ‘architecting’.

            ———–

            The fraught interplay between the general and specific has a pattern in those activities that have been professionalised. It is easy to be specific about what a profession does – where lies its bailiwick so to speak. And it is easy to describe the general problem to which the specific skills and knowledge of a profession are addressed. I have said it before – while there is a long and winding road to the professionalisation of EA, we are not there yet until we reach the day when it can be described to an average middle-schooler – without having to explain our vocabulary. As I can currently to with, doctor, teacher, pilot, electrician, accountant, banker, soldier… etc. We are not there yet.

            ———–

            The Open Group – sorry Len (though I kind of expect you are quite aware of this) – is a transitional player in the professionalism of EA. The real tipping point is when Higher Education (HE) and relevant government (gov) bodies come to the party.

            HE – though usually in partnership with industry and professional bodies – still does the work of standardising, developing, and transmitting the bodies of knowledge and skills required for established professions. And gov provides a quality control mechanism – again often in partnership with industry and HE – through licensing mechanisms.

            Of course there isn’t a clean division between job titles and professions – it is something of a continuum – but dismissing disingenuous ‘slippery-slope’ rebuttals there is a clear difference of professionalisation between a surgeon, a taxi-driver (well maybe less a London black-cab operator), and a shop assistant.

            Here in Melbourne Keith Frampton was a bit of a visionary, setting up what I think was the second HE degree (post grad) in EA – in the world. Industry-consortia associations, training and accreditation is really important. And the Open Group, CEAP, and others are doing what needs to be done – with the exception of attempting to commodify and privatise accreditation – that’s stop gap and ‘sub-optimal’.

            If HE institutions around the world start delivering EA courses – it will be very interesting to see out of which discipline and which faculties/schools they come. A review of Computer Science at my own university predicts the partitioning of traditional IT education much the same way that business schools started to classify Marketing, Finance, etc as different professional streams in commerce and began to structure knowledge – and research and teaching and professional development – accordingly. Our report predicted IT it will be Engineering, Operations, Service Delivery, and Governance (in which EA was grouped, along with contract management).

            Yes HE is undergoing its own structural upheaval – but it will remain for some time the arbiter of professional accreditation and the standardisation bodies of knowledge. Industry just doesn’t have the social infrastructure to compete with HE.

            ———

            There are two aspects of the ‘what is EA’ conversation that oft times become hopelessly muddled..

            1) What is the object of EA – what does it do, what problems does it solve that are definitive of EA as a profession. That is – what value does an EA bring that a BA or a PM or any other profession / role can’t.

            2) What is the techne of EA – what is the knowledge, techniques, methods, that constitute the toolset of a working EA.

            They are related of course. To my mind – though some would argue – Zachman and TOGAF are clearly situated in the domain of large scale (and really, in-house, bespoke) IT development problems. They provide a methodology for getting systems designed and built.

            The profusion of ‘canvas’ approaches shows, not an attempt to address any methodological problems with TOGAF for example, but rather an attempt to reframe the problem and direct the definition of EA as a profession to a different problem domain.

            The mammoth discussion currently on LinkedIn about whether Archimate should include a ‘capability’ element or not is merely an expression of this struggle over turf that has been going on for some years now.

            I should say I don’t want to imply it is an arbitrary or rancorous struggle for control of the term Enterprise Architecture. Each side has a clear and rationally arguable view about why and where the value of EA rests. But they are to a very real extent irreconcilable.

            ———-

            My take….

            Tom is right – it is absurd to think one can design a system without reference to the context that gives it meaning. Doing the wrong thing better does make things worse.

            Len is right – attacking IT-centricity is a straw-man argument.

            But… the more integrated organisations are into, well, communication networks at base I guess, the more arbitrary is the conceptual divide between ‘business systems’ and ‘IT system’.

            If EA is going to be anything – IMHO (and I definitely mean the H) – it will be because it develops techniques and approaches that don’t split business design from information system design. It will stop talking about ‘alignment’ – which embeds the difference in the analysis.

            It certainly will stop attempting to arrogate to itself a business-strategy role that will remain with ownership and executive management. And it will not treat everything problem in its domain as something that can be modelled using a formal language.

            It will knuckle down to the problems of complexity, the behaviour of systems, and the visibility of cause and effect, and of course reducing the cost and risk of novelty. (And, I hope, stop waffling on in neologisms and cliches that represent little more than wishes).

  5. Tom

    Yes – all activity systems have structure and behaviour. EA typifies and systematises those for a given business system. EA is based on general system theory, set theory and type theory. Try the “System Theory” page at avancier.co.uk.

    And aren’t you (like TOGAF and ArchiMate) confusing EA with SA? Try “What is EA? BA? SA?” at avancier.co.uk for ways to distinguish them.

Leave a Reply to Tom G Cancel reply

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

*