[I won't name the airline here: they probably did a better job than most, under the circumstances, and it certainly wasn't bad enough to blame or shame. In any case, I want to focus on the overall theme here rather than a single incident.]

And we wait. After perhaps twenty minutes past our scheduled departure, a call from the cockpit: there’s a problem with the cargo-door, haven’t been able to fix it, engineers are on their way, apologies for the delay.

Twenty minutes later, with the clunking and clanking still going on below, I’m doing that calculation so common amongst experienced air-travellers: is my connection still possible? I can probably still make it across the terminal, but will my luggage make it too? Another polite apology from the flight-deck, but no actual news. And whatever they say, it’s not looking good.

An hour goes past. Still belted into our seats. Can perhaps just make that connection if we leave now. Another announcement: but it’s not the one I’d been hoping for… “first class and business class passengers can leave the plane and wait in our airline lounge; other passengers please wait here while we serve you a meal”. The meal, when it eventually arrives, consists of, uh, one plastic cup-a-soup. While another hour drifted away into nowhere. Like the flight, which is clearly going nowhere.

Another hour. “All passengers please disembark: please take all your belongings, we’ll call you when you can board again.” As we leave, it’s clear that the first-class and business-class passengers didn’t take their carry-on junk with them when they left earlier: it’s going to be chaos for them if we have to change planes. No information; no warnings about what to do with boarding-cards or the like. Three harassed staff at the gate, trying to field impossible queries in half a dozen different languages; no-one knows in any detail what’s going on, no suggestions on what to do about a myriad of by-now-lost connections other than the all-too-obvious platitudes of “we’ll sort it out later”.

Another hour, spent anxiously around the gate. At least the children are having fun, running up and down on the somewhat bouncy travelator. And then, suddenly, an announcement over the general system: plane’s fixed, please hurry up, we’re boarding now. The usual airline complaints about lost passengers – as if it’s the passengers’ fault that there’s a delay. No time to check boarding-cards, it seems – and a fair few passengers have left them on the plane anyway. But everyone’s in, seemingly on record time: and five hours after scheduled departure, and with somewhat of a struggle to find a slot in the lengthy queue for take-off, we’re finally on our way. Hooray.

A tedious seven hours later, we arrive at the airline’s hub. The only passengers who aren’t going to be affected by the delay are the relatively few who live here, and the fewer still who’d want to stay here: just about every onward connection will have been blown. Still, the airline’s ground-staff will have had almost twelve hours to plan for this: we’ll get it sorted out somehow. We decant from the plane into an almost empty airport, well after midnight, in fairly optimistic mood.

Which doesn’t last long. No plan, no information, no nothing. A chaos of queues at the transit desk. Nothing happens, very slowly. One lucky soul eventually rushes away to catch one momentary slot. The line beside collectively groan when it becomes clear that there’s no possible flight to their destination for at least another day, and so many of them that it might take two or three days at least to find enough slots.

My name is called, followed by those of several others. In some confusion, I make my way forward to the desk – and am angrily challenged by the woman already there, whose name hadn’t been called – how come I’d been picked instead of her? I try to explain that I’m just following instructions, like everyone else, that it’s the airline’s choice, not mine, it’s not something I’ve done to her at all: slowly, slowly, she subsides, still simmering. Turns out that we’d been picked out to catch a flight that we’d already missed anyway. Another woman next to me had been given one of her boarding passes for a connection that now no longer exists. No-one seems to know what’s going on; perhaps least of all the ground-staff who are trying to sort out the mess.

Another hour of tired confusion, frazzled ground-staff, yet tempers still holding fairly well all round. No more connections for anyone today, but they do manage to assign hotels for everyone, with pick-up times and boarding-passes and coaches to take us to bed. At last.

Except the hotel doesn’t know we’re coming: no-one had told the reception-desk, at any rate. It’s gone 4am before we all manage to get that one sorted out and into bed. For a 6am wake-up to call to warn the people waiting for me at the other end that I won’t be there for another full day.

Where, eventually, we do indeed arrive. And my luggage, too. Wow. Amazing. Feels like a real bonus after all that struggle.

Looking back with an enterprise-architect’s eye, what are the lessons-learned here?

The incident itself was ‘just one of those things’: someone had been a bit too rough with the cargo-door, bent something just that bit too much out of shape. All fixed: it just takes time. Except time was what we didn’t have. For which we can’t blame the airline, or the airport, or anyone, really. Just one of those things.

What wasn’t good was the availability or use of information. The ground-staff where we started didn’t know what was going on. Which was why the passengers didn’t know what was going on. Which was why no-one could make any alternate plans, beyond perhaps passing on a warning to others further down the line. The screw-up over the non-’meal’ was just a minor annoyance, really: a few people kicked up a minor fuss, but there wasn’t much point – because if everything’s run on a just-in-time model, there ain’t much redundancy anywhere in the system to cover anything like that.

Beyond the departure itself, the use of available information seemed even worse. The ground-staff at the hub should have known we were going to be late, and that connections would have been lost: they should, at the very least, had had the whole of our flight-time – seven hours or so – to prepare for alternatives. But amazingly, no-one seems to have had thought fit to warn them. Hence a lot of chaotic make-it-up-on-the-spot – not just for the passengers, but for all their separate checked-baggage too. Not the ground-staff’s fault, really, that so much of it was such a mess – they did remarkably well, under the circumstances. Likewise the hotel-staff, when we all arrived in the middle of the night, apparently without warning. But none of that chaos should have happened at all – if the airline and others had made proper use of their information. Which they didn’t. Which to me, frankly, seems bizarre – but there ’tis…

Yet all of this was just one flight, with one well-rated airline. What happens when the whole airport is out of action? Or the whole transport network? An entire city, or an entire region? That’s when we most need the information-exchange to work. But instead, we see all too well the gaps in information…

What are the most common complaints these days in any kind of disruption? “They didn’t tell us anything.” “We had no way to find out what was going on.” Endless variations on the same theme: no information, or information not where it’s needed, or not available in a form that can be used. Which, even for the IT-centric of ‘enterprise’-architecture, should tell us straight away that there’s a real information-issue there that can probably only be addressed with any success via a whole-of-enterprise approach. And in each case the enterprise-in-scope needs to be larger than the organisation-in-scope.

To resolve each of those various problems on our flight, the information-scope was larger than the flight itself:

• the initial attempt to repair the cargo-door was not via airline staff but the airport ground-crew
• the damaged door needed attention from aircraft-engineers assigned to the airport by the aircraft manufacturer
• the flight-delay required rescheduling for ground-control at the airport and for air-traffic control once in the air
• the airline ground-staff at the departure-airport needed to consider the impact of the delayed flight at the arrival-airport
• rescheduling before and on arrival needed real-time knowledge of other flights across the system, in some cases including other airlines’ flights, and links to the airport baggage-handling system to re-assign and/or hold checked baggage
• overnight stays (a legal responsibility of the airline) required links to hotel-availability information, and also coach and driver information to transfer stranded passengers to and from the hotels
• few if any of the stranded transit-passengers had visas for that country, so the off-airport overnight-stop needed passport-information links to immigration

Not much of which, it’s clear, worked particularly well – because if it had, we wouldn’t have experienced anything like the mess that we did.

(It definitely helped that immigration there were very laid-back about it all, though, compared to the the seemingly-insane rules and regulations of so many other ‘security’-obsessed countries these days: for example, why on earth does a transit-passenger from London to Mexico need a full [expensive] US visa and full immigration clearance just to pass through the sealed international-transit section of Dallas airport…??? No idea what would happen for those rare stranded-passengers whose countries or passports were incompatible: probably the only option would be to be locked up in a cell somewhere until their onward flight became available?)

All of those are large enough enterprise-architecture problems. But take the scale up a few notches, to the kind of issues that we’ve seen so often over the past few years:

• an airline goes broke, stranding its passengers in random places across the globe: what information is needed to find them all, identify their needs (not just food and shelter, but medical and much else besides), assign the appropriate priorities, get them all to their required or alternate destinations as soon as possible
• there’s a fire at a fuel depot, blocking the usual fuel supply-chain to the airport: what information do you need to get to airlines, to their passengers, to air-traffic control?
• there’s a failure in the baggage-handling system: what information do you need in order to reunite the right passengers with their own baggage – and only their own baggage – when all the electronic records have been lost?
• heavy snow closes the airport for several days: what information do you need to share with other modes of transport – rail, road, even by sea – in order to get the passengers moving onward? what information do they need in order to make the right choices? and how do you get that information to them in the most effective way?

On the surface, there are simple answers to all of those questions. But in practice, with present-day enterprise-architectures – few of which extend beyond the nominal scope of a single organisation – many of the essential links are fragile at best, or missing entirely. And the closer each system and sub-system moves to maximum ‘efficiency’, the less room there is for manoeuvre: Heathrow Airport, for example, at present often operates at or above 95% of its theoretical capacity, with each aircraft similarly close to its maximum load – hence even a single day of closure could take more than a month to clear if no other alternative transport-options exist. In essence, to make the system seem to work, we rely on people to take up the slack – abandoning their journeys, making alternate arrangements, whatever. Which kind of defeats the whole object of the extended-enterprise, namely to make it easy and convenient and reliable for people to travel as they need…

So in these days of obsessing over ‘efficiency’ and the like, how do we get back to enterprise-architecture – an architecture that provides proper support for the enterprise in context? What we’ve seen for information above applies to all other aspects of each enterprise: assets, people, process and everything else. So what do we need for the enterprise? How do we enable the requisite redundancy and resilience in the enterprise, to emphasise overall effectiveness rather than mere local ‘efficiency’? For that matter, what is ‘the enterprise’ in scope in each case – not just the organisation itself, but the broader context within which the organisation exists? How do we deliver on the real promise of enterprise-architecture, that “things work better when they work together”?

Happy Travels? Or unHappy Chaos? An interesting yet all too real challenge here for enterprise-architects and enterprise-architecture…

In the Information Age, the phrase was “Content is King”. While that may still be true, in the Shift Age, “Context is King”

Yet whilst that also “may still be true”, it doesn’t go anything like far enough. At the very least, we need to add ‘connections’ to that list, and probably ‘purpose’ as well – and, perhaps most important, the integration that links all of those dimensions together.

(Oh dear, yet another one that’s getting a bit long, and probably a bit too abstract too. Mainly enterprise-architecture and the like, so click on the ‘Read more…’ link if that’s of interest to you.)

Compare this to the well-worn sequence ‘Data, Information, Knowledge, Wisdom’. These are usually described in terms of a stack:

• Data is content : the equivalent of a physical asset
• Information is Data + context : the ‘context’ for data usually being described as metadata, or ‘information about information’
• Knowledge is Information + connections : the ‘connections’ for information usually being described in terms of a set of defined relations between data- and/or metadata-items, in a schema or taxonomy
• Wisdom is Knowledge + purpose : the ‘purpose’ for knowledge usually being described in terms of values or principles that underpin some kind of formal or informal ontology

In some ways, though, it’s more useful to describe these as locations or regions within a four-dimensional space laid as a tetradian, the internal axes of a tetrahedron:

It’s actually a better fit, though, if we return to the more generic ‘content, context’ and so on:

The point here is that we can choose to focus on any one of these at any given time – hence we might shift our attention from content to context, for example, as David Houle suggests. But all of them are equally valid – none of the dimensions is inherently more important than any of the others.

And in practice none of them makes sense in isolation from the others. For example, as again David Houle implies, great emphasis was placed on content during the ‘Information Age’. To be more precise, the emphasis was placed on virtual-content, or data – often there was nothing like enough ‘information-about-information’ to give the content any meaning, which is why in recent times there’sbeen  a strong re-emphasis on metadata to give the data its context. Yet that too is incomplete: information only becomes knowledge when we can connect to other items of information; and so on.

Hence data-management, information-management, knowledge-management – all of them recognised disciplines in present-day business. But what about ‘wisdom management’? The answer is that that exists too, though rarely with that title: we see it in the vast storehouse of stories, proverbs, advisory anecdotes and cautionary tales that embody the painfully-accumulated wisdom of the organisation. And taken on their own, in isolation, even ‘wisdoms’ may make little sense: without a context to anchor it, content to embody it, and connections to link it into the real world, even the greatest wisdom becomes little more than a empty proverb, a pointless ‘moral of the story’ without a story to bring it to life.

Yet one of the most important parts of this is that we need something to link each of these dimensions into a unified whole: a systematic process of integration, passing attention from one dimension to the next, and ensuring that each dimension has sufficient ‘time in the spotlight’ that it never fully fades from our awareness. That way we would avoid misleading labels like ‘The Information Age’ or ‘The Connection Age’, that over-emphasise a single dimension, and instead have what we might call ‘The Integration Age’. (I’d avoid calling it ‘The Integral Age’, to avoid associations with the mad millennial aspirations of Ken Wilber and the like…) Everything links together with everything else, in every dimension.

That perhaps sounds a bit abstract, but another way to look at it is with yet another set of labels, that bring it back down to more concrete realms:

This is one of the underlying frames that I use to categorise implementation-’segments’ in my extended-Zachman taxonomy/framework for whole-of-enterprise architecture. (This dimension-set – physical, relational, virtual, and aspirational - is also the same as the ‘Four Elements’ of classical Western philosophy – Earth, Water, Air, and Fire – which these days are better understood as the four distinct states of matter – solid, liquid, gas and plasma.)

The physical dimension is about tangible ‘things’, physical assets, physical locations, and functions that act upon those things. Our economic models are all actually based on the ‘alienable’ nature of physical things: if I give it to you, I no longer have it, hence I would need to be ‘compensated’ for its loss.

The virtual or ‘conceptual’ dimension we see most often as data and the like – an organisation’s ‘virtual assets’ – but also virtual locations such as IP addresses and phone-numbers, and functions that act on those. (An ‘Information Age’ would place a probably excessive emphasis on this dimension – which is exactly what we’ve seen in the past few decades.) The crucial distinction between physical and virtual assets is that the latter are ‘non-alienable’: if I give it to you, I still have it – hence the literal meaning of the phrase ‘information wants to be free’, which is actually nothing about price at all. Most ‘intellectual-property’ economics somehow assumes that virtual-assets can be withheld in the same way as physical assets: since this can’t work, by the nature of information, we’re forced into a chaotic mess of ‘digital rights management’ and the like, to try to force virtual-assets into a physical-asset-like frame. Which, unsurprisingly, doesn’t work very well… though what to do about that is a subject for a separate post!

The relational dimension is in part about people – hence its classical description as the ‘emotional’ dimension – but is actually more about connections and relationships in general, between people, between things, between ideas, from anything to anything else. Crucially, a connection exists between two other entities: if either side drops the connection, it ceases to exist. Current economics again tries to treat connections as if they’re physical objects – most notoriously in the often well-meant but lethally destructive phrase “our people are our greatest asset” – which again is a common cause of architectural failure.

The aspirational dimension is always about purpose, expressed in real-world forms as morale, vision, values, brands and the like. In effect, this is a kind of one-way connection from a source to a target that may be either real or abstract.  (To avoid some seriously murky waters of teleology and the like, it’s wisest to assume in enterprise-architecture that the ‘source’ in this context is always a real person – usually as individuals, though sometimes as a collective, such as in the phrase “the vision of the organisation is…”.) The source has an active commitment towards the target, but the commitment does not need to be reciprocal (as it it is in the relational dimension), and in some cases may not actually exist – for example, a ‘vision’ is about an imagined future rather than a present reality. Current economics even attempts to treat this as if it is physical, such as in monetary valuations of brands; trying to do so is seriously insane, in a very literal sense, but there ’tis…

The dimensions are also recursive, looping back on themselves and each other. For example, data are the ‘things’ or content of the virtual dimension; metadata or information-about-information provide the data with its virtual context; relational connections link the data into useful knowledge, either in a personal sense, or within some kind of schema; whilst the purpose to which we apply all of this is what gives it its meaning.

That’s still somewhat abstract; but in the real world, most things are explicit composites of two or more of these dimension, and implicitly are probably composites of all of them. For example, a network node has both a physical and a virtual location, and is represented by something that is physical (a server, or router or whatever) and that also has – or should have – a purpose within at least one schema of the network and its business role. A business role represents a place in a relational schema -such as  the dreaded ‘org-chart’ – a real person, a physical and/or virtual location and some kind of business purpose. The dimensions interweave, are made real in many different ways, but it’s a still a useful way to categorise what’s going on in an architectural context.

Content, context, connections, purpose; often as expressed as physical, virtual, relational and aspirational dimensions. We can choose to focus our attention on any one of these at any time – an emphasis which may lead us in turn to useful abstractions such as ‘The Information Age’ or ‘The Connection Age’. Hence, again in turn, may give us the feeling that that ‘content is king’, or context’ – yet which in reality is only an artefact of our choice to focus on that specific dimension or domain.

So as architects, we must remember that all these dimensions of reality are always present in everything, everywhere, everywhen. Nothing exists in isolation from anything else, hence we always need to hold a view of the whole system in mind whenever we work on any one of its supposed parts. We forget that fact at our peril!