At Integrated EA conference
Spent part of this week at the Integrated Enterprise Architecture conference in London. And for me, it was a real refreshing change from the usual banks / insurance / finance / tax focus of most of what passes for ‘enterprise’-architecture these days. Instead of the (literally) imaginary world of money and information, almost all of the players at this conference were dealing directly with the hard end of Reality Department: air-traffic, rail, military logistics and the like. In other words, the architecture of the real.
And it showed. Almost the first slide in the first presentation, on defence information, from Air Commodore Mark Neal, talked about people, processes and technology – and mentioned, almost as an aside, that yes, there was some IT in there too. Again, very different from most of the other conferences I’ve been to, where in most cases IT was seemingly touted as the beginning and end and sole centre of everything.
I won’t attempt to cover everything from there – if you’re interested, look at the conference programme, then search the Twitter-hashtag #iea2011, which summarises most of it (courtesy of a veritable army of Tweeters, especially the indefatigable Robert Damashek). Highlights for me included the presentation on supporting Op Herrick (the British contingent in Afghanistan) – IT in a context where cooler-fans get filled-up with dust and sand within days, where the data-centre can catch fire just from the heat (let alone stray rocket-propelled grenades), where you can’t just nip out to Best Buy to replace a broken part because the nearest one’s several thousand miles away, the cabling is lashed together onto an old oil-drum because that’s all you have, and if anything does break there’s a high chance that someone will die. By comparison, the common complaints of the usual Cloud crew – who worry about how a momentary glitch might create a momentary dip in someone’s share-price – seem very petty indeed…
That emphasis on the real continued through into the civilian presentations too – such as the two on enterprise-architecture for rail (a hat-tip here to Nic Plum and the TRAK crew, who’ve done a brilliant job on ‘de-miltarising’ MoDAF for civil engineering), and the one from NATS on upgrading the European and worldwide air-traffic control systems (which need to take into account all air users, including airline, general-aviation, military, weather-balloons and other UAVs, and even large-wildlife). These are all ‘mission-critical systems’: in most cases, they can’t ever be switched-off for an upgrade – and again, if anyone gets anything wrong, a lot of people may die. Not trivial.
One annoyance was a presentation purporting to compare the relative maturity of EA in the defence and financial-services sectors: fair enough in principle, but in practice, to my mind, seemed downright misleading. At first glance, according to the slides, the financial-services industry seems much more mature in its EA – and I could see that quite a few of the defence crew were seriously demoralised by that. But it wasn’t a like-for-like comparison – not at all. The financial-services architecture he described was, in essence, not enterprise-architecture at all, but the classic IT-is-the-centre-of-the-world self-referential subset – which can only be made to seem like real-world sense because the business of that business mostly revolves around information. As soon as we move outside of that IT-centric / information-centric space, the real enterprise-architectures of most financial-services organisations are very immature indeed – which is precisely what lead to the current financial-crisis, and will do so again and again until the fundamental flaws in those architectures are addressed.
And consider too the relative complexity of each. A typical financial-service company delivers:
There’ll typically be some mix of banking, finance and insurance, but in essence they’re just minor variants on the same general theme. And if something goes wrong, the buck can usually be passed on to the customers or the shareholders without anyone being the wiser. But a defence-materiel organisation will typically run the equivalent of:
- a finance company
- a trucking company
- a shipping company
- a construction company (and a destruction company too 🙂 )
- a wholesale store
- an airline
- a travel-agency
- a catering company
- a hospital system
- a police organisation
…and much, much more – usually in far-flung, inhospitable places, and sometimes being shot at as well. In short, a the equivalent of a huge industrial conglomerate – but one in which all of the disparate parts and disparate cultures must mesh, or else, again, people will die. And all of this takes place under intense public scrutiny, much of it mindlessly mistaken or misleading (or highly politicised, which comes to much the same thing 🙂 ). Given the circumstances, I’m amazed that any of it works at all: so in practice, although the architecture is a long way from what we consider as mature, it’s a lot more mature than the mess that underlies most financial-services organisations.
In short, comparing real-EA in one context with the relatively-trivial EITA in another is not a fair comparison at all. Oh well.
My own presentation was perhaps a bit sideways from all of that. I’d mistakenly assumed that the conference was going to be the usual IT-dominated / IT-centric version of ‘enterprise’-architecture, so I’d focussed on showing examples of how the architecture of the enterprise extends a long way beyond IT, and the EA lessons-learned from those practical real-world examples. Here it is, anyway:
Despite being somewhat sideways, it seemed to go down well: for example, quite a few people picked up on the theme that the concept or role of ‘Enemy’ is much more blurred than it used to be, and of viewing Enemy as ‘anti-client’ (rather than, bizarrely, ‘customer’) within the overall enterprise. The relationship of organisation versus enterprise went down well, too: quite a few folks commented on that in subsequent presentations – which was kinda gratifying. 🙂
In all, a great conference – one I’d strongly recommend in future for anyone involved in real enterprise-architectures. And many thanks too to Ian Bailey and Penny Creed for their hard work in organising and hosting the overall show.
These are great signs! Thanks for sharing. I’m thrilled about the opening comment by “Air Commodore Mark Neal, talked about people, processes and technology – and mentioned, almost as an aside, that yes, there was some IT in there too.” Great stuff!
Sounds like a great conference, and I wish I’d been there.
I completely agree with your criticism of the finance sector. The management of complexity and requisite variety in the finance sector seems pretty limited compared to those sectors that actually create value, and I have long been sceptical of the a-licking flattery of the finance sector in certain quarters. You may remember IBM’s claim that “the banking and insurance industries lead in the maturity of their SOA deployments”. Or that it was a bank that won the SOA Consortium Case Study Contest. I’m sorry, but I can’t see much evidence of the superior maturity of the finance sector even if we are only talking about EITA.
Just a minor correction – TRAK isn’t about civil engineering, it’s centred on ‘System’ (in the solution). This might be a combination of human resource, software and physical or indeed other systems. It isn’t, despite the name which reflects the origin, tied to rail, civil engineering or any domain – it’s a general purpose framework. A system doesn’t know what domain it’s in so why should the AF care?
I would have liked to be there – it’s always worth going.
Best also to use the http://trak.sf.net link for TRAK since there are warnings posted on Wikipedia that TRAK isn’t considered to be notable and the Wikipedia article is liable to deletion at any point.
The trouble with not mandating TRAK use as has happened with the DoD/DODAF and the MoD/MODAF is that it’s much harder to establish where and who might be using TRAK. People tend not to tell you.
“A system doesn’t know what domain it’s in so why should the AF care?” – very good point…
(Have just posted that as a Tweet on your behalf: “Why generic #entarch frameworks: “A system doesn’t know what domain it’s in so why should the AF care?” (Nic Plum, TRAK) http://trak.sf.net “)
Recommended link duly noted – though we do need to do something about stabilising the Wikipedia article… don’t know how to do that, unfortunately. Perhaps get Mike Brownsword / Joe Silmon to reference their Integrated EA presentation in the Wikipedia article, as that’s a publicly-described application of TRAK by someone other than yourself?
Pat, Richard – many thanks for comments. I strongly agree, of course – as should be obvious from what I’d written above. 🙂