At Gartner EA 2016
Blog: Tom Graves / Tetradian
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.