Where is the information when we need it?
We boarded the plane, settled down in our seats, to await pushback from the gate – the usual ‘hurry up and wait’ of everyday air-travel. Seemed to take a bit longer than usual, though. Strange clonks and thumps from beneath my seat, down below in the cargo bay. We wait, and we wait.
[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…
Very illustrative article! You perfectly underline (again) the necessity for a qualitatively new view on the world.
Organisations no longer rule ‘their’ world (they never did, but it often looked like it). Every organisation lives in a context (organisations always did), a context that is loaded with dynamics nowadays: nothing stays the same for long anymore. Therefore an organisation no longer lives all by itself (it never did), but becomes more and more interdependent with all of its surroundings. A broader view emerges as a necessity: the enterprise view.
Now have a look at information. As organisations no longer rule their world because of increased dynamics… how about the information that organisations are dealing with? Information appears to very much live in contexts as well. As the context (enterprise) more and more ‘defines’ the organisation… context also more and more defines the meaning of information.
Enterprised organisations therefore need contextualised information in order to be able to seamlessly (i.e. meaningfully) collaborate – in ‘normal’ operations, but even in all kinds of unusual situations! For that’s what we’re all headed for: increasing numbers of unexpected, unusual situations. Having information contextualised enables us to quickly and perfectly meet the various and varying enterprised organisations demands.
For an enterprised organisation shared and trustworthy meaning of contextualised information becomes more important than each organisation having information sets of your own (loaded with duplicates, inconsistencies etc).
In my presentation “infOrch” – available on SlideShare (http://www.slideshare.net/hjvantil/information-orchestration) I point out a way to create such an information architecture fitting enterprise architectures.
Many thanks, Jan.
“As the context (enterprise) more and more ‘defines’ the organisation… context also more and more defines the meaning of information.” – very strongly agree.
Thanks for the pointer to your presentation “infOrch” – very interesting pattern for managing the technical aspects at an enterprise level.
Yet those technical issues to resolve the information-sharing problems are only one side of the story. In my own practice, what concerns me more are the political issues, because to resolve these we need, as you put it above, “a qualitatively new view on the world”.
In the past, we’ve made each system appear to work by concentrating all attention at the unit-level (the organisation) and ignoring the system-level issues as far as practicable: there was usually enough spare capacity in system-inefficiencies to take up the slack when required. Most of the legal and other structures were likewise focussed at the unit-level (corporate ownership, corporate profits, corporate taxation), and likewise many of the legal models (such as bankruptcy laws and the key concept of corporate ‘limited liability’) enabled organisations to privatise the opportunities and the profits but socialise the risk. As a result, many current business-models and the like depend entirely on the ‘right’ to externalise costs and socialise risk: and it’s going to be a very, very hard job to change that.
Yet change it we must, because collectively we need our systems to run at much higher efficiencies than in the past, because key resources (fuel, key materials, airports slots, etc) are becoming more scarce just at the time when usage is increasing. And politically the ‘right’ to externalise/socialise costs (such as via pollution or bankruptcy or mass ‘human inconvenience’) is being challenged with increasing intensity, not just by activist groups but by mainstream politicians and even within business itself.
To make it work, we do need to respect that every one of those necessary changes is laden with political challenges. None of those issues listed above is solely a technical problem that could be resolved by a technology-solution (such as infOrch) on its own: the technology itself is “necessary but not sufficient”. Some of these issues are being addressed in a more systemic way: for example, higher efficiencies in utilisation of aircraft capacity and airport slots are enabled by code-share agreements, which represent a kind of ‘virtualisation’ of physical air-transport. Information-standards and other standards are absolutely crucial in this: yet each standard requires that each of the players surrender some aspect of their autonomy for the common good – and how far can each player go before they lose their identity and autonomy entirely? There’s a real challenge there.
And what happens when – as in that example above – the only available seats to move stranded passengers onward to their destination are on a rival airline with no code-share agreement? At present the ‘solution’ is to force the passengers to take up the slack: in other words, wait, and wait, often at their own expense, until the source airline deigns to sort out its own mess. Which brings not just the airline into disrepute, but with it the entire industry (and the overall enterprise of air-travel, in this case): which, in the long-term especially, is probably not a good idea for any of the players in that enterprise…
Which is why they need to work together. And which is where a whole-of-enterprise architecture comes into the picture, because its raison-d’etre is on that one core idea that “things work better when they work together”. Yet let’s not be under any illusions about this: yes, it’s true that new technologies, and new uses for existing technologies, will play an important part in this – but the real challenges, as always, will be in getting all those different players to talk with each other, and find common cause in what they do.
Thanks again, anyway.
Thank you, Tom, for the trouble you took to study infOrmation Orchestration and to reply to my comments on your article Where is the information when we need it?
Indeed, “the real challenges, as always, will be in getting all those different players to talk with each other, and find common cause in what they do.”
In my mind “all those different players” include first and foremost human beings (e.g. stranded passengers). For its natural persons that need to interoperate (using information) in the first place – whether it is on their own behalf or on the behalf of a legal person they somehow relate to. I created a presentation on Human Interoperability to stress the importance of human interoperability in addition to technical interoperability (which is “necessary but not sufficient”).
In my mind “find[ing] common cause in what they do” nowadays has an enormous and dominant (much more than most of us realise) informational aspect. Informationally speaking… any person (natural as well as legal) becomes more and more a participant in information traffic. Information traffic in which all participants obey the same information infrastructural rules and share the same information infrastructure in order to keep traffic-as-a-whole smoothly going. Just like normal traffic: that powerful infrastructure ‘simply’ is there to serve us all in various and varying ways (but wasn’t developed to serve any one of us specifically).
Right now every organisation has its own set of isolated rules and its own set of isolated information. We keep missing common informational cause. Most organisations are rather obsessed with themselves. For that reason they are not able to see/appreciate the enterprise they’re really in and the enormous possibilities/advantages that enterprise has in store for them. We interface (to bridge separateness) rather than that we participate (to acknowledge interdependency). We act as if we’re independent, but we really are interdependent (always have been). Even with respect to information we act ‘rather’ untrue to our true nature.
The information making up the information infrastructure is valuable to all participants in e.g. the air-travel enterprise (and industry). However, there is no need to value it as strictly competitive information. The specific way any participant combines information present in the information infrastructure together with private information determines a participants true competitiveness.
infOrch (as a technicality) is very, very much powered by the infrastructural organisation of information in the {i}’s. That organisation, in turn, controls the organisation of the services… in turn controls the organisation of the information orchestrators
The most important standard is the standard that standardises meaning of information. That standard starts with the organisation of information in the {i}’s – it ends in the information orchestrator where meaning is situationally established from information in the {i}’s. Indeed, “each standard requires that each of the players surrender some aspect of their autonomy”. They have to devalue information isolation (autarky) and trade it in for enterprised, infrastructuralised trustworthy, meaningful information.
“And what happens when – as in that example above – the only available seats to move stranded passengers onward to their destination are on a rival airline with no code-share agreement?” Well, such a situation is no longer a problem. From the available infrastructural information a (fairly autonomous – now) passenger decides for himself whether he is going to wait… he is booking a seat elsewhere… etc. Wouldn’t that be, in the long term especially, a brilliant idea – to the benefit of all relevant players?
Again Jan, many thanks for great points.
Three comments:
Your infOrch model summarises well how to handle the purely technical aspects of managing and sharing the explicit (machine-storable data) component of information. Yet the explicit data forms only one part of the whole – hence the common distinctions between data-management, information-management and knowledge-management. What we need in these contexts is a combination of information (contextualised data) and knowledge (information interpreted through personal experience and judgement: hence whilst the technical aspects are indeed crucially important, they need to be understood as “necessary but not sufficient” – we need orchestration of the system as a whole, and as a system, not just orchestration of the information.
“The most important standard is the standard that standardises meaning of information”: well, yes, that would indeed be wonderful, if we had any possibility to achieve such a standard – which, to be blunt, in practice we don’t. At the individual level, the whole point of ‘meaning’ is that it’s personal – that to a significant extent the definition of self is bound up with personal definitions of meaning. As you say, there’s a trade-off between autarky and collective-meaning – but each person makes it in their own way, and as architects we must never delude ourselves into thinking that that trade-off does not exist, that we can somehow always impose our preferred meanings on others. If we make it useful or worthwhile for others to choose to use our recommended meanings, they’re likely to do so, within that context at least: but that’s about the best that we’re going to get, in terms of standards. To a system-designer who needs certainty in order to make IT-style true/false logic work, this kind of uncertainty is frustrating in the extreme – but unfortunately that is the way the human world works, and as architects we need to design for that fact, rather than fighting in futility against it, or, worse, pretending that that fact does not exist.
“Well, such a situation is no longer a problem. From the available infrastructural information a passenger decides for himself whether he is going to wait… he is booking a seat elsewhere… etc”. Yes, it would indeed be a brilliant idea – if the availability of information was the only factor. (Making all appropriate information available in an accessible form is definitely a brilliant idea, and one I’m likewise arguing for above – though you’ve gone a lot further than I have on how to make that ‘brilliant idea’ a practical reality.) The point is that there’s a lot more involved than just the information: for example, “he is booking a seat elsewhere” involves serious costs that would be borne by the passenger, not the airline that was unable to get him there. (This is another example of ‘externalised costs’, by the way – and why airlines and others are so fond of simple-looking contracts that have interestingly one-sided liability-clauses buried deep within the small-print… 🙁 ) We need open information, to enable the choices and make the options and trade-offs visible and viable; but there’s a heck of a lot more that’s needed to get the system as a whole to work for all of the parties involved – and it’s the system-as-a-whole that is our actual concern as enterprise-architects.
Each of the players in this extended-enterprise has their own perspective, their own meaning. Most usually we’ll be developing an architecture for a single player, such as an airline or an airport or the air-traffic control. The airline will likely be in direct competition with others; the airport in less direct competition, more in the sense that cities are in competition with each other; whilst air-traffic control, almost by definition, needs to be a near-monopoly for any given region. Yet the player that’s most often forgotten is the one for whom the overall extended-enterprise actually exists – the passenger. From that perspective, the experience needs as seamless as possible: to paraphrase Chris Potts, the best way to understand the system as a whole is that passengers don’t so much appear in the various other players’ processes, as that the extended-enterprise of ‘air-travel’ appears in their experiences.
So the information-failures I described above are not so much about information as such, but much more about boundary-problems and political-problems (jurisdiction, competition, identity, responsibility etc) in the structure and flow of the extended-enterprise. Whilst, yes, we do need to do a much better job of handling the information, the place we actually need to work most – and perhaps where we most often need to start – is with the politics and the people. To quote Gerry Weinberg, whatever it looks like, no matter how ‘technical’, ultimately it’s always a ‘people-problem’. I guess that’s what I’m really trying to say here.
Tom,
How did we ever manage to get our traffic system-as-a-whole (A Valued Infrastructure!) to work the way it works right now? Bike, Car, Train, Plane, Ship, …, all kinds of Hubs, …, Traffic rules, …, Support (e.g. petrol stations, repair, police, …) – all material as well as immaterial ‘things’ belonging to that system-as-a-whole. Where did we start? Well, we (just) started! At several points, at various paces, with varying enthusiasm and success.
What would be the most impacting starting point in our information age? In our information society? In a society in which information is ubiquitous as well as hard to make meaningfully available (your question: Where is the information when we need it?) to any and all? What point would Christopher Alexander advise us to start with; see his The Nature Of Order? I’d say: meaningful information for any and all participants in information traffic. Any (part of an) organisation is part of an (ultimately the) encompassing system (enterprise), in which it acts as an interdependent participant in information traffic. (Informationally speaking, nowadays the organisation is largely… irrelevant).
In order to accomplish that (= meaningful information for any and all participants in information traffic), we have to organise our information in an infrastructural fashion in order to be able to situationally provide the intended meaning of information. Why? That’s simply because of the specifics of human nature: meaning always comes situationally (in time and space) into existence within a single human mind. Therefore contemporary technical information systems need to supply humans with contextual information (not only with information). For only the supply of contextual information enables the receiver of that information to construct the intended meaning (of the sender).
So…, indeed, I fully agree, “we need orchestration of the system as a whole, and as a system, not just orchestration of the information.” And the best current starting point to accomplish that… is, in my mind, to get ourselves a robust infrastructural information base from which it is most easy to situationally construct intended meaning in order to be able to perform the intended (system) behaviour. That’s why I stated that the most important standard is the standard that standardises meaning of information. And that’s very good news for the system-designer (and his true/false logic worldview): for meaning is situationally truly fixed! And, yes, it is very well possible to reach such a standard. Just Start! Start modelling your information infrastructurally. Start constructin your information base as far as its really relevant right now. Start constructing your orchestrators based on that (and let others construct other orchestrators that meet their needs).
You state that “[t]he point is that there’s a lot more involved than just the information: for example, ‘he is booking a seat elsewhere’ involves serious costs that would be borne by the passenger, not the airline that was unable to get him there. (This is another example of ‘externalised costs’, by the way – and why airlines and others are so fond of simple-looking contracts that have interestingly one-sided liability-clauses buried deep within the small-print… )”. Well…. Is that true? From the old perspective: yes. But… don’t you think that infrastructurally organised information changes our world significantly? Of course booking a seat elsewhere involves serious costs. The passenger will notice now. But the airline(s) too. And the room for an airline (for any company, any government, any civilian) to externalise costs (and to socialise risk) will quickly drop. Don’t you think?
“Each of the players in this extended-enterprise has their own perspective, their own meaning.” I agree; that’s human – that’s true to our nature. Let’s not change that! “Most usually we’ll be developing an architecture for a single player, such as an airline or an airport or the air-traffic control.” We should immediately stop with that! Now we develop information infrastructural architectures. Yesterday’s ‘autonomous’ players become tomorrow’s interdependent participants in information traffic. “The airline will likely be in direct competition with others; the airport in less direct competition, more in the sense that cities are in competition with each other; whilst air-traffic control, almost by definition, needs to be a near-monopoly for any given region.” As I said: they all become participants in information traffic. Competition will be ‘done’ at other levels now. Most of the infrastructuralised information becomes equally available to all relevant participants in information traffic. “Yet the player that’s most often forgotten is the one for whom the overall extended-enterprise actually exists – the passenger.” Yes, sigh, even the passengers individually become full participants in information traffic. The organisation no longer gets defined by itself, but by its surroundings (the passengers, the enterprise). “From that perspective, the experience needs as seamless as possible: to paraphrase Chris Potts, the best way to understand the system as a whole is that passengers don’t so much appear in the various other players’ processes, as that the extended-enterprise of ‘air-travel’ appears in their experiences.” Any natural/legal person becomes his own situational process. Process? What process! Any natural/legal person becomes a participant in information traffic (it gets boring; sorry; it’s only a new world view).
“So the information-failures I described above are not so much about information as such, but much more about boundary-problems and political-problems (jurisdiction, competition, identity, responsibility etc) in the structure and flow of the extended-enterprise.” The nature of the boundary-problems will change… completely as a consequence of infrastructuralising information. Boundary? What boundary! Even the nature of the political-problems will change as a consequence of infrastructuralising information. Following Christopher Alexander’s advise: first act on the most impacting problem… see how the world changes… then determine the next most impacting problem… etc.
Indeed, I agree, “ultimately it’s always a ‘people-problem’”. And people ‘work’ on information (since time immemorial). On signs that enter their individual minds through senses. Signs that get interpreted in there using earlier interpretations from earlier signs. It’s information that gets humans in formation; differences that make a/the difference (Bateson). I really think that Alexander would advise us to start with meaningful information for any and all participants in information traffic.
Jan, “starting with meaningful information for any and all participants in information traffic” would indeed mean that the starting point for all such endeavours has to be human-centric Information Architecture from a User Experience point of view. Not technology, not data, even not business are the starting points, but people and their information needs.
In consequence, that means that Enterprise Architecture endeavours have to start by using User Research techniques (Contextual Enquiry etc.) to translate this to “future architecture results” from the point of view of different roles in the extended enterprise, and then make this tangible by demonstrating the impact of this proposed change (for example using a dashboard for the destination airport crew).
Do you agree?
Milan