Enterprise architecture as language

Each enterprise has its own distinct language. More to the point, the enterprise-architecture is a language.

I probably need to take a step or two back at this point…

For quite some while I’ve been using the metaphor of ‘hologram’ to describe how we collect and store and describe information about the enterprise. Once we’ve done the essential foundation-work that describes the fundamental frame of the hologram, every item of work that we do will add to the detail. And since everything is connected to everything else, this means that any piece of work – always done to tackle a specific business-problem – will also add a little more detail that could well connect with everywhere.

This contrasts with the more photograph-like Zachman school, where we’re supposed to document everything ‘in excruciating detail’ before we can usefully do anything. The problem with the ‘photograph’ approach is that it’s not only insanely expensive – in every sense – but it’s often out of date barely before we’ve even started.

So while struggling to get by in Brazil with my still very-limited Portuguese, it struck me that the way we’re likely to learn a language is also much like a hologram.

Most people won’t try to learn a language ‘photograph-style’, learning every scrap of grammar and the entire dictionary before we start. That’ll take far more time than we’re likely to have to spare, and if nothing else, we probably won’t get much of a clue of pronunciation or real-world usage – which in many languages is very different from the ‘by the book’ official version.

We also probably won’t do very well if we try to go only via the phrase-book route. That tends to provide tiny fragments that should be technically correct, but there’s nothing to link them together – a bit like cutting up a photograph, in fact.

Instead, our best option is to pick up the core basics of the grammar and flow, and then do a version of the phrase-book approach that does link each of those items into that core framework. We tackle a key ‘business-problem’ – how to buy a ticket, how to order a coffee, what to do in the airport, how to greet a colleague. In the process we learn essential vocabulary, the ‘things’ of the language: please, thank-you, excuse me, sorry, and various key ‘gotchas’ – such as the Portuguese word puxe, pronounced ‘push’, which means ‘pull’…

Each new item links quietly to everything else, each tiny fragment building up more detail that helps to make sense elsewhere in the language. Sometimes we’ll do a specific ‘project’ to cover an entire area – working our way through past and future tenses, perhaps, or key irregular verbs. Yet slowly, slowly, the bare skeleton of the language fills itself out, until quite suddenly we realise that we recognise much or even most of what’s going on around us.

So too the enterprise-architecture. If we go the classic Zachman-style route, we’ll spend so much time trying to define everything that we’re unlikely ever to get properly started. If we go the classic IT-centric route, we tackle small fragments – mostly IT, of course – that have no effective connection with anything else, and eventually descends to an unused piece of shelfware, like a forgotten phrase-book from a long-past foreign holiday. But if we start with the core skeleton of the ‘hologram’ – particularly the vision and values, the entities that define the enterprise – we have enough framework that any work on any subsequent ‘business-question’ helps to build more detail of the whole.

The past is a foreign country: they do things differently there. Yet the same is true of each enterprise: each is its own country, with its own structures, its own quirks, its own idioms and inflections. I’ve suggested before that the enterprise is a story; it seems it’s its own language too.

A possibly-useful metaphor to ponder, perhaps?

7 Comments on “Enterprise architecture as language

  1. Hi Tom, very nice metaphor.

    You start to talk an idiom very well at the point you don’t have to translate words anymore, you just talk according the context. Everything become natural and easy. IT should be like that into an EA context, like the air we breathe, like a very well known language we speak.

    Best regards my friend,

    Roberto

  2. I agree. Working with any social structure is like raising a child, and all of us who have children knows that there is no school to make you a perfect parent. Only a wide range of experiences across all of life can give you insight to raise a reasonably complete child. I’m raising three children and let me tell you what works on one child is a complete mess on the next one. I’m coaching a couple of larger organizations EA teams and it is the same with them. What works on one team makes the other team go off the grid.

    Enterprise IT Architecture is not a social system and you can be very successful using methods and classifications based on TOGAF 9, Zachman Framework and other such frameworks.

    Enterprise Architecture covers the social parts and there you have to rely more on situational understanding to be successful.

    Keep up the good work Tom.

    /JD

  3. Lovely metaphor, especially as I am working abroad and I am challenged everyday with a foreign language:) Reading this post left in me the same feeling which I get when we manage to deliver approximately useful input/deliverable which the other side understands enough to start talking to us (unlike the situation when we deliver precisely irrelevant deliverable). It’s the same as if I manage to squeeze out of me approximately correct sentence of which the essence is understood and brings me to the desired result. I think I am gonna use this metaphor more often, thanks Tom.

  4. Tom nice metaphor. I hadn’t thought about the hologram analogy. I use the phrase, “I want the Monet not a photograph.” Of course that breaks down because you have to be a creative genius to produce a Monet, while anyone with a camera can snap a pic.
    As I think further maybe the analogy is a good one. Anyone can record masses of detail, it takes more skill to create the associatiins and links that give value to the evolving picture.

    Chris.

  5. “The problem with the ‘photograph’ approach is that it’s not only insanely expensive – in every sense – but it’s often out of date barely before we’ve even started.”

    Thanks Tom

  6. Well done Tom…again. You can go a level deeper…different departments in an organization in an enterprise speaks different languages too. Every piece of your Enterprise framework has usuable information…a language which helps others in the whole of enterprise to communicate with each other.

Leave a Reply to Jörgen Dahlberg Cancel reply

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

*