At Integrated-EA 2014

Always an interesting event, this one: Integrated-EA, the annual Defence-oriented enterprise-architecture conference in London that’s been a favourite part of my calendar for some years now.

This time I was only able to go to the second day – I won’t bother to go into the reasons why – but even in this abbreviated form it was definitely worthwhile. Here were some of the highlights for me:

— PRINCE vs PRANCE: I can’t quite remember when this came up, but in effect it was a theme that came through quite often, around the constraints of how projects are done in the Defence space (and government in general).

The usual approach is built around PRINCE2, or PRojects IN Controlled Environments, with a waterfall-type sequence of ‘gateways’ and other control-points throughout the whole project. Which is fine, except for the blunt fact that no project exists in a ‘controlled environment’: ‘hope and wish and pray it would be something resembling a controlled environment’, maybe, but never actually so in the real world. Oh well, nice idea… but that’s one of the core reasons why things so often go so disastrously wrong, or just plain don’t work at the end of the process.

The supposed alternative is some variant of ‘agile’ – which usually works even less well, because too often it’s used as an excuse to try to avoid any kind of discipline at all. In other words, ‘kiddies’-anarchy’ – with exactly the (lack of) quality of results we’d expect from that kind of shambles.

So it struck us – ‘us’ being various folks in various conversations there – that what’s needed is not some shining PRINCE to ‘take control’, but something more like PRANCE: PRojects in Ambiguous Non-Controllable Environments. But how would we create such a standard? How would we make it work, in real-world practice? Any suggestions on that, anyone?

— The baleful influence of big-contracts: One of the purported reasons for the necessity of PRINCE2 is the even worse shambles of the procurement-process – and especially so for the kind of huge multi-billion-pound contracts that perhaps too often come up in the Defence context. To put it at its perhaps most polite, everyone seems to be avoiding the fact that these are not ‘controlled environments’ – in fact by their nature cannot be ‘controlled’ – but are required to pretend that it is ‘controllable’. And, as a result, each of the players is trying to handball as much of the uncertainties as possible onto each of the other players. Oops…

Much of which shambolic mess ultimately has its roots in the money-system, and the possession-economy in general – which doesn’t work, and never has, but again, almost all of the players desperately want to believe that it does, because every interaction is based on the assumption and assertion that it does. Oops…

Which, in that sense, at least, is nobody’s fault as such: but if we’re going to have any chance of a finding a viable way out of these endless messes, we’ll first need to face up to the fact that it doesn’t work. Which is not going to be easy. Hmm…

— Information-assurance and other ‘non-functionals’: One of the best sessions came from three folks (no names given, of course) from CESG, the information-assurance arm of GCHQ. They made the interesting point that the breaking of the Enigma cypher and subsequent reading of supposedly-secure communications is a classic example of an information-assurance failure – from the German military’s perspective, that is. Given that – so they told us – some 93% of large organisations have had some kind of significant security-breach, and 86% of small- to medium-sized ones, then building good information-assurance is kinda important…

Probably what was most refreshing about the talk was its realism – the kind of challenges that enterprise-architects face every day. The ‘bolt-on’ approach to security – exactly as for a ‘bolt-on’ approach to enterprise-architecture – just doesn’t work. Yet neither does any kind of rigid attempt at enforcement, because that just puts people off – almost invariably making things worse (or, in this context, more risky). The challenge is to get the right ‘just enough’: “there are many ‘wrong-answers’, but no one ‘right-answer’ either”. And whilst, in principle, most of it is quite simple, yet, as they wisely put it, ‘simple’ does not necessarily mean ‘easy’!

Often one of the hardest challenges – something that, again, we see all too often in enterprise-architecture – is dissuading people from taking fundamentally-invalid approaches to the ‘non-functionals’: “how do you place metrics on things that can’t really be measured?” The danger there is people wanting the easy ‘out’ of a box to tick, rather than engaging with the actual need. One tactic suggested was to flip the perspective the other way round: “we want to avoid an insecure architecture – so what does ‘insecure’ look like?”

A related theme was around risk-appetite: since risk will always exist, how much risk would be acceptable for the given opportunity and need? “Seniors often need help in understanding their risk-appetite”, said the speaker; “the stakeholders themselves need to be responsible and accountable for risk” – so we need to help them get there.

The necessary blurriness of boundaries was another core concern. We need to understand our environment and its boundaries: “clean boundaries are a luxury – they’re no longer a given”. It’s more useful to focus on the security-domain rather than the security-boundary. And in any case, mechanisms to enforce boundaries don’t really help if there’s not enough clarity on what the boundaries should be, and why.

And finally, a reminder of the need to understand trust in the context: who or what is being trusted, why, what for, all in relation to the value of the respective asset and the implications of its damage or loss. “10% of the worst security-breaches”, warned the speaker, “were from deliberate attack by people who had valid authority to access the systems”. And above all, we need to understand the human component in all of these scenarios – and not merely rely on technology-oriented ‘solutions’.

— A question of purpose: Trust was a theme that came up again – for me at least – in a talk from Joint Forces Command (tagline: “Joint Warfare: United We Conquer”). I don’t really have anything to say about the talk itself – it was interesting, but seemed somewhat specific to that context only. Yet what it triggered off for me was a need for much more clarity about the overall vision for Defence: or, to put it bluntly, to ask some fairly deep questions about what it is that we want Defence to defend us against – and hence the architectures that we need so as to support that actual purpose.

I’m not being ‘anti-militarist’ here (or ‘pro-militarist’, for that matter): it’s just that it strikes me that the insistent emphasis on warfighting may be missing the point more than somewhat in the present-day – or, more accurately, be of way too narrow a focus, much like IT-centrism is for enterprise-architecture. Okay, I can understand that if we’re going to indulge in sabre-rattling, we need metaphoric sabres to rattle – and if someone calls our bluff, those sabres had darn well better work. Yet most of the Defence focus still seems to be back in the kind of warfighting from the old Victorian age of ‘imperial powers’ still playing some variant of The Great Game – nation-state against nation-state, preferably in some other people’s backyard. But nation-against-nation is by no means the only concern for ‘defence of the nation’, in its most literal sense.

Sure, that classic kind of nation-state threat still exists: and although, for Britain, the last major event was around the Falklands/Malvinas, almost a third of a century ago, there are still present-day rumblings around ancient cross-nation grievance-points such as Gibraltar. Right now, the South China Seas are a dangerous multi-nation flashpoint; likewise, as I write this, the Crimean peninsula. Yet, for most nations now, most of the current military concerns are with non-state actors – the kind of home-grown insurgencies and suchlike for which tanks and heavy artillery are more likely to be a hindrance than a help. And it also seems to me that, increasingly, we’re going to need far better defence against non-human actors: climate-change, for example, or the very real risk of global pandemics against humans, animals, people or environment – against which a tank or battle-cruiser is almost exactly the wrong kind of weapon.

We might argue about the causes of climate-change, but there’s no doubt at all that climate-change itself is real, and becoming ever more extreme: hence, for the literal ‘defence of the realm’, we’re going to need soldiers and suchlike who are at least as skilled at toting sandbags and pop-up flood-barriers as they are with toting a gun. Present-day soldiers are trained in techniques for managing biological-attack: we’re going to need those skills, at scale, when we next get hit by foot-and-mouth disease, let alone anything more virulent than that. And again, increasing climate-stress and suchlike means increasingly likelihood of ever-worse disasters abroad as well as here: deployments of nominal military-assets on disaster-relief – such as, most recently, the Philippines after Typhoon Haiyan – are likely to become increasingly common. In which, exactly as for warfighting, the assets deployed had better be able to work for that purpose.

Which is why, once again, getting better clarity on the real enterprise-vision – in this case, for ‘Defence’ in its broadest sense – would seem kinda important for the architectures that support that enterprise?

— The dubious joys of standards-development: Back down to earth, there were several sessions that gave kind of ‘status-reports’ on the current state of play with various architecture-standards in the Defence context – and the huge challenges of creating common standards across often very-different nations and cultures. For example, as one speaker put it, there’s been “a long game of leapfrog” between DoDAF (US), MoDAF (UK), NAF (NATO and others), DNDAF (Canada) and suchlike, with each standard building on the lessons-learned from other standards’ revisions and updates, but seemingly never getting a chance for them all to line up with each other – which they sorely need.

One very good point is that – unlike TOGAF, FEAF, Archimate and suchlike – all of these standards are built on a concept of ‘systems’ that isn’t solely IT-centric: “it’s always included people, right from the start”. The catch, then, is the need to design an approach that explicitly allows for difference and disagreement between nations – about terminology and suchlike – and that, where necessary, supports national versions of standards, whilst still being ‘standard’ enough to enable the required interoperability. As per that earlier speaker, in principle, it’s really simple: but ‘simple’ ain’t the same as ‘easy’…

The main thrust at present is to unify all of the differing frameworks around the NAF (NATO Architecture Framework) core: take a look at NAFDocs.org to see how that’s progressing. To me it looks a good direction to be heading, anyway.

— The ‘Gravesyard slot’: There’s a kind of tradition now that I do the last slot at this conference, as a kind of ‘comedy-act’ to end the show. Because of this, I always aim to do something that’s a bit left-of-field and thought-provoking, yet also fast-paced and fun.

The conference-theme this year was about complexity, so I gave myself the working-title of ‘The dung-beetle’s tale: systems-thinking, complexity and the real-world’. I’d have to say that it soon became one of those “it was a good idea at the time…” items: I’d long had a clear idea for the dung-beetle part – about interdependency, as in my post ‘Dependency and resilience in enterprise-architecture models‘ – but it proved incredibly hard to find the right kind of story to make it all work…

The breakthrough came when I found a new way to describe part of the SCAN sensemaking / decision-making framework, specifically the edge-transitions between each of the ‘domains’:

I’ll describe that reframing of the edge-transitions in another post, but for here it provided the anchor for a ‘journey’-type story for the dung-beetle, that would also link in well with the theme of complexity. After that, well, it was just the, uh, usual multi-day trawl through Flickr and elsewhere for suitable images, and a lot of rethinking and restructuring of the whole lot into a workable story. A presentation may be over and done with in thirty minutes, but for the kind of slidedecks I do, that can easily translate into almost as many days of darned hard slog to make it all work – but it’s fun to do, too, no doubt about that! 🙂

In the end, it’s turned out into something of a monster-slidedeck – 197 slides, in fact. It’s for a Defence context, of course, so it has somewhat more of a military flavour and military-type in-jokes than I would likely use elsewhere. Even so, I think it’d still work well for just about any type of audience – though you’d be the judge of that, I guess? Anyway, here it is:

Share And Enjoy, perhaps? Hope it’s useful, anyways.

(And thanks again to Ian Bailey and Penny Creed for all their work in putting on yet another excellent conference!)