At Integrated-EA 2016

Always enlivening and enlightening, and working with what is perhaps still the closest we’ll see so far to a real ‘the architecture of the enterprise’, the Defence-oriented Integrated-EA conference in London in early March is one of the regular highlights of my professional year. So what did it serve up for us this year?

A mixed bag as always, is probably the real answer.

There were the usual ‘progress reports’ on some key long-term themes, with updates to frameworks (MoDAF and NAF), standards for modelling (UPDM), whole-of-Europe air-traffic control (CESAR / NATS), and a couple of others.

There were a handful of more-than-overt sales-pitches from vendors, about which, uh, perhaps the least said the better?

And there were some odd surprises. For example, one presentation, almost all the way through, had seemed like the most tedious reprise of a kind of entry-level ‘Waterfall-101’ – in other words, exactly what most of us these days would recommend not to do. But right at the end, it suddenly became clear that they were struggling with a context so antediluvian, and so poorly-managed in an architecture sense, that in their case even to achieve a consistent Waterfall-101 was actually a huge improvement – and, given their circumstances, really was an impressive piece of work. A sobering reminder for the rest of us…

Yet the big surprise for me, perhaps, was how much I enjoyed the first-day sessions on security. Normally it’s a topic that bores me to tears – especially when the IT-obsessives get started on their own rigidly IT-centric view of it. But here it was very different, and was perhaps best typified by a session by ‘Helen’ from CESG, the information-assurance section of GCHQ – the UK’s equivalent of the US NSA. Her section at CESG explicitly describes security as a socio-technical concern, not merely a technical one (hooray!). And, much as in my own work on EA, they insist that we need to ensure that security is embedded right into the core of everything (“baked into the design”, as she put it), and is also everyone’s – the specialists are still needed to help at times, but are there as a support-service, not as an afterthought with sole responsibility for sorting out the mess.

Some good stuff too from Michael Brunton-Spall, lead security-architect for GDS (UK Government Digital Service) – dressed in jeans and black t-shirt, he described himself as “I’m the most scary public-servant!”. Again, a lot of emphasis on the human aspects of security: “individuals are not interchangeable resources”, he said – to which I would strongly agree. He also warned of a common absurdity in government and elsewhere, that the security-policy document is classified at a higher level than the development-team are allowed to read – and hence making the policy itself irrelevant. If we want to improve security, then we need to make sure that everyone on the team has a solid understanding of risk [and opportunity too, I would add] – and designing our systems overall such that choosing the secure method is always the easiest option for people to use.

(The one point where I did disagree with him was around one key aspect of Agile-style development, where he argued that Mean Time To Recovery is more important than Mean Time Between Failure. It’s true that he’s probably right about that for the the context of what GDS mainly deals with – the front-facing IT-specific side of routine delivery of routine government services. But his advice there is not right for contexts where resources are not easy to replace – such as in most military or other high-risk contexts – or wherever people are involved: as he himself said, “individuals are not ‘interchangeable resources'”, and should not be casually broken in Agile-style experiments!)

His point about making the secure method the easiest to use was hammered home in a different and broader sense, in another discussion that came up during the panel-session on security. Someone asked whether these concerns were specific to security, or would apply across architecture in general. One of the panel replied that “It’s not only for security – technology is changing really fast, and our role is to help people keep up”. But again, that’s not specific to technology, but to the sociotechnical system as a whole: one bleak example from another panel-member was the comment that “we didn’t have enough body-armour in Iraq because the [inventory-management] system was too cumbersome, so people didn’t use it” – with literally lethal consequences…

For me, the other highlight of the conference was Steve Winter’s session on “The Drones Are Coming: future enterprise-architectures for Unmanned Aircraft Systems [UAS]”. Current approaches to air-traffic control [ATC] are, literally, about control – and it depends, entirely, upon all players in controlled-airspace being willing to submit to a system and discipline of centralised routing, guidance and control. At present the system works so well, even under the huge load of commercial and private aviation, that the few significant problem-areas are mostly natural-hazards such as storms and large birds. The catch, though, is that as the amount of air-traffic increases, the risks of collisions increase exponentially – and as drones come into the picture, the current model of air-traffic control is rapidly becoming unsustainable.

How unsustainable? The US currently sees up into the tens of thousands of flights each day – and whilst the current ATC system can cope with that, it’s definitely under strain. UAS are definitely going to make that problem exponentially worse, in timescales that the ATC industry is not equipped to cope with at all. For example, this Christmas, in the US alone, some 300,000 UAS were registered with the Federal Aviation Authority [FAA] – increasing the potential air-traffic by a factor of ten. But we know that at least 700,000 UAS were bought in the US in that period, which means more than half of the potential UAS traffic is not registered at all – and ATC has no idea where that potential traffic is, and probably no certain means to find out. And although, yes, many of those UAS are tiny, they still represent a serious risk: modern jet engines can swallow smaller birds without too much trouble, but the hard metal and plastics of a modern hobby-UAS would be a very different story. Higher-end hobbyist-UAS are certainly capable of flying up to controlled-airspace levels: and even at lower levels they can and do represent a serious hazard to ‘normal’ aircraft, such as in firefighting, or on take-off or approach. As Steve Winter said, “this is not a solved problem” – and one we definitely need to face.

But is it our problem, as enterprise-architects? One conference-participant thought not: “Why is this enterprise-architecture, rather than programme-management?” he asked. Steve Winter’s response was that “it’s not a programme, it a huge super-enterprise” – the outcome will probably be legislation and regulation, but it’s still an architectural concern. I’d strongly with him on that: that it’s literally ‘the architecture of the enterprise’ that matters here – not merely the internal architecture of one specific organisation within that shared-enterprise.

One wag immediately responded with “Will this lead to super-enterprise architects?” – but actually, the real answer is yes. Or, rather, that that’s what enterprise-architecture literally means: the architecture of the [shared]-enterprise. After all, both FAA and NATS (UK ATC) are ‘super-organisations’ that cover the scope of that type of ‘super-enterprise’ of air-traffic-as-a-whole – and if there’s an enterprise of any scope, there need to be enterprise-architects to address the architectural concerns of and within that scope. Kinda important that we don’t forget that point, and allow our work to be trapped into a too-parochial view?

And yes, I did my regular ‘Gravesyard Slot’ at the end of the conference – kind of ‘comedy-act to end the show’, but also to send people homeward with some ideas to think about too. For what it’s worth, here’s the slidedeck from that session – this time on the factors that drive towards fragmentation of an architecture, and the disciplines that we need to counter against them:

Share And Enjoy, perhaps?

Anyway, over to you for comments, if you wish.