At Gartner EA 2016

Somewhat to my surprise, via a much-appreciated invitation from Lucy Jones and her colleagues at Gartner’s events-team, I found myself at the Gartner EA Summit conference in London last week. Interesting…

Okay, yes, I’ll have to admit to still feeling somewhat ambivalent about the engagement in the EA-field of Gartner and the other big-consultancies – much as I feel about the Open Group’s involvement in enterprise-architecture, for that matter, and for much the same reasons. And as a professional futurist, I really, really dislike the endless streams of ‘predictions’ that come out of Gartner in particular – it’s just not a valid futures-technique at all…

But that said, I have a deep respect for a fair few of the Gartner consultants, whom I regard as real colleagues, genuine leaders in their respective fields – and at the conference I did have the privilege to meet up with some of them, such as Mike Walker (aka ‘Mike The Architect‘) and Emeric Nectoux. Mike’s introductory session, ‘Business-Outcome-Driven EA; A quantum leap in delivering value‘, on the first day, was one of the highlights of the whole conference for me, with much of the content very close to my opinion and my heart:

  • “Stop trying to force-fit EA to an industry framework” – a particular reference to the limitations of TOGAF and the like, which to my mind are now no longer fit-for-purpose for almost any form of enterprise-architecture
  • “Start with the highest-priority outcomes” – because that’s crucial to engaging stakeholders in the architecture
  • “Just enough deliverables” – a specific-case of the underlying guideline about ‘Just Enough Detail
  • “Choose the right diagnostic tools” – enterprise-architects need a broad toolkit
  • “Ensure program outputs are actionable” – delivering identifiable business-value, and avoiding the ‘ivory-tower syndrome’ so endemic in ‘classic’-EA
  • “Measure impact, not activity” – we need to demonstrate that we deliver business-value

In the past, Gartner and the other big-consultancies had actively promoted the mainstream ‘enterprise’-architecture frameworks such as TOGAF, DoDAF, FEAF and the like; then when they finally realised that predefined frameworks simply don’t work well in inherently-unique contexts, they shifted to a stronger emphasis on predefined processes. But they’ve now at last started to recognise that the real problem in EA is not about frameworks or processes, but about the impracticality of ‘predefined’ – and also that whilst it’s ‘not not about technology’ (to quote Andrew McAfee), the real key to an enterprise-architecture that actually works is always within the people.

Hence, as Mike said in the session, the real work of enterprise-architects, with a steadily-widening range of stakeholders, “takes place over cups of coffee” – or anywhere that “takes them out of their environment and into somewhere more relaxed”. Mike warned that it typically takes “at least two to three such meetups to get beyond symptoms, to the real issues beyond”. And the most important thing to ask is “Why? – tell me more…” – and listen, listen carefully, for what’s really being said, beneath the surface.

One more comment from Mike, about prepackaged frameworks and processes, is likewise crucial here: “‘How do we tailor?’ is my most important question”, he said. He’s right: although there’s no doubt that we do need some kind of consistency at the metaframework level, the framework or process still must always be adapted to the specific needs of the respective context. Yet none of the existing mainstream frameworks describe how to do this: the nearest we have are some thin platitudes in TOGAF, without the practical detail that we need. It’s a fundamental gap that we definitely need to fill…

I’m perhaps so (over?)-focussed at present on that last theme of ‘How do we tailor?’, that Mike’s session turned out to be the only one I managed to get in the whole conference. I’d say that was a significant mistake on my part, as I missed out on what look to have been some really good sessions, such as Brian Burke’s ‘The Digital Humanist: Shifting to a human-centric architecture‘, Marcus Blosch’s ‘Architecting the Business Ecosystem‘, and Frank Buytendijk’s ‘Digital Ethics: When saying “I’m sorry” is not enough‘. Oh well: another time, maybe?

Instead of going to sessions, like a sensible conference-attendee would, I spent almost the entirety of the conference on the toolset-vendors’ show-floor, worrying (and no doubt worrying others…) about this:

If you haven’t seen this before, in other posts here, it’s a visual mapping of tools and toolsets to the development-process described by Damien Newman’s ‘the Squiggle‘. And the point is that virtually all of our current supposed ‘EA’-tools focus only on the easy, stable, design-oriented part at the far end of the development-process – the red dots on the graphic above. No doubt that the tools we have are often very good at what they do: some impressive modelling of IT-landscapes, for example – much of it automated, some even in near-real-time – and very good visual-modelling and simulation and the like.

(One catch is that, for most of those tools, the user-interfaces and user-experience are such that they can really only be used by lengthily-trained professionals, not everyday business-folk – which makes stakeholder engagement kinda hard. And even when we can get other people engaged in the modelling, most of the modelling-notations are still so complex and so ‘technical’ that, by the time we’ve actually managed to make a model that complies to all of the myriad of modelling-rules, it’s so hard to change anything that we’re likely to stick with the first design we create – which is exactly what not to do in architecture-development. Awkward…)

And whilst those tools are usually good for solution-architecture, often all the way out to a whole-of-enterprise scope, that’s not the same as enterprise-architecture – the literal ‘the architecture of the enterprise itself‘. In effect, much as Mike Walker implied in his session, solution-architecture focusses on a more easily-definable How and With-What, whereas enterprise-architecture must necessarily face the far more ‘messy’ Why and Who, at the front-end of the Squiggle. Yet at present, the so-called ‘enterprise-architecture’ tools give us almost no support for that latter need at all: instead, we’re forced to make do with whiteboards, pen-and-paper, web-browsers and the ubiquitous ‘EVP’ (Excel, Powerpoint, Visio) – the green dots on the Squiggle – with occasional help from more versatile tools such as Evernote, OneNote and concept-mappers such as CMAPTools – represented the amber dots in the graphic above. The catch there is that almost none of these tools connect with each other, either consistently or at all, and the current ‘EA’-tools give little to no support for import, export, or, especially, round-trip with those ‘messy’-end tools – which again tends to drive us in a one-way flow towards the trap of premature-design.

So that was my main focus for those two days at the Gartner EA conference: try to engage the various toolset-vendors there in the need to support enterprise-architects throughout the whole of the Squiggle, rather than merely the ‘easy’ design- and maintenance-mapping at the very far end. Some of them didn’t get the message at all: one woman, for example, insisted that it had to be simple, because that was what was easiest to implement and to sell – an unfortunate example of completely missing the point, that the real-world, for our work as EAs, actually is messy and complex, and that it’s generally best to work with the real-world rather than delude ourselves and others into thinking that’s it’s simpler than it actually is… But most vendors, I’m glad to say, did take it as a serious concern, a challenge that they do indeed need to address. Interesting discussions, and definitely with some hopeful outcomes. It may take a while for those outcomes to come through as new features in those EA-toolsets, but Watch This Space, perhaps?

Once again, many thanks to the Gartner crew for having me there – very much appreciated.

Comments, anyone?

8 Comments on “At Gartner EA 2016

  1. Oh how I wish I was there. It sounds so promising. It almost makes me want to jump back into the entarch world. Can you get the transcripts from the other sessions you couldn’t attend?

    Skip vendors. They will catch up as corps accept the holistic approach.

    • Thanks for this, Pat (and apologies for the delay in reply).

      I probably could get the transcripts, but it’s rather moved away from that time. And as usual, I’m in the middle of yet another rethink about what I’m doing – which this time will likely move further away from the corporate world, and more towards NGOs, government and the like (and other places where I can actually be of some use to the world… :wry-grin: )

  2. Maybe we should just stick to pen and paper? Marler and white board? Lego blocks maybe?

    I’m wondering what the essential requirements are for this kind of tool… A repeatable dump of our thinking?

    Love this article Tom. And fully agree on the Gartner guys! Top notch!

    • Thanks, Davey. The key point, perhaps, is that right now the whiteboard and the like are usually the best tools for this early-stage work: the catch is that if/when we need to revisit a ‘finished’ design, the original trail that led us there is long since gone… That’s really where the requirements are: in effect, to make the support for the Squiggle into a loop, rather than (as at present) always a one-way process.

  3. I’m with you Tom on several issues:
    – Gartner still has this irritating hype-based ‘future prediction’ stuff, the presentations are all about selling ‘certainty’, and I’m still not over the ‘shill’ aspect they had for a long time (and in part maybe still have, but I haven’t investigated deeply). But they also have quite a few top notch people these days, not just the silly pundits of the past. I find talking with people from Gartner for Professionals generally worthwhile.
    – High-priority outcomes, certainly, but as long as high-priority doesn’t equate to ‘quick wins’ and pure short-termism and priority includes the difficult improvements you have to make that do not look like improvements to the ‘outside’. From there also comes a bit of reluctance from my side about the Squiggle that you like so much. Prototyping is not always a usable step, for instance, often only for parts of the issue. And it does look a bit like another type of waterfall.
    And we do agree (and Gartner now agrees too) that EA frameworks generally have shot past their mark in several ways, based as they are on assumptions that in complex and unpredictable reality do not hold. Still, there often is some value there too.

    • Thanks, Gerben. Agree that Gartner has “quite a few top notch people these days” – Bard Papegaaij is one that immediately comes to mind, for example.

      On “as long as high-priority doesn’t equate to ‘quick wins’ and pure short-termism” – to me there’s nothing wrong with ‘quick wins’, in fact we’d generally need at least some of them in order to establish credibility. The problem comes, as you say, when the focus is only on “‘quick wins’ and pure short-termism”. If that happens, we’re in trouble…

      That’s why, to me, the first and utterly-essential stage for enterprise-architecture is not to go rushing off to tidy up the IT-estate, but sit back back for a brief moment and establish the big-picture. Once that is established, then all future work can, should and must be aware of that big-picture, so that even the smallest ‘quick win’ can then be in-context-of that big-picture. Without that, then yes, we fall back into “pure short-termism” again – which, as we both know, is Not A Good Idea…

      On the Squiggle, the trick is in the reframe. If we think of the Squiggle as a single-layer, single-pass project, then yes, we’re straight back into Waterfall territory again – the only gain is that it’s Waterfall with a bit more awareness and honesty about early-stage ‘messiness’. But if we reframe the Squiggle as a depiction of a single iteration within a fractal, recursive, fully context-aware loop, then no, that’s a lot more than mere Waterfall – more agile (in every sense of the word), more self-adaptive, and a lot richer, too. (Don’t agonise too much about that label of ‘Prototyping’ – remember that a ‘prototype’ could be anything at all, include a thought-experiment carried out just on a whiteboard.)

      On “Still, there often is some value there too” – yes, strong agree on that – and it’s a point that’s too often forgotten in the endless hype-fuelled hunt for The Shiny New Next Thing. For example, yes, I rant rather too often about the inadequacies of TOGAF and the like – but if you’re facing a clean-up of a classic big-IT estate in a large organisation, then TOGAF 8 is probably still the best place to start. Everything has its value: the point is to recognise where that value resides, and make best and appropriate use of whatever it is that we have in our respective toolkits.

    • Many thanks, Rebel! As I’ve just said above, to Gerben, we do need to ensure that those ‘high-priority outcomes’ are always in context of the big-picture – but yes, it’s always the best way to engage stakeholders in the architecture. The trick that follows is to then get those stakeholders to recognise that architecture is actually and always their responsibility – not solely the responsibility of the people with ‘Architect’ in their job-title… 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *