How do we do roadmapping in enterprise-architecture – developing the plan for change, and keeping to that change? How do we adjust to changes in the change itself?
A great session on this last week at Vlerick Business School, in Brussels. (And many thanks too to Bjorn Cumps and Stijn Viaene for inviting me to take part, and to Wouter Depoorte – aka The Beard – for his flow of tweets on the day.)
To me, probably the single most important theme was one that came up in one of Wouter’s tweets:
- DepoWo: “Roadmap is nothing, roadmapping is everything” – @tetradian on #entarch
It kinda needs a bit of context, of course, but what I meant by that was similar to the crucial difference between a single ‘the plan’, versus the capability to do planning – and create any required plan. Likewise the crucial difference between trying to identify ‘the future’ – in essence, a failed exercise even before it starts, almost by definition – versus futures, the capability to explore multiple-futures and to develop strategies and tactics dynamically, on-the-fly, to work with any future, ‘foreseeable’ or not. Hence, here, the distinction between ‘the roadmap’, versus the capability to do roadmapping, restructuring so as to be able to change course dynamically yet still with consistent overall guidance and intent. That’s really the point here.
The two sessions before mine – on roadmapping for long-term ICT change, by Leo Siegers at ING, and a very nice ‘greenfield-EA’ case-study by Pascal Dussart at Loqutus – both illustrated that point about ‘roadmapping, not roadmap’ really well.
In some ways Pascal had the easier example to work on, precisely because it was a ‘greenfield’ project with almost no legacy to deal with. Given my own interests in ‘EA beyond IT’, it was also especially interesting to me in that, yes, it covered a lot more than just the IT, in this case in a hazardous-waste recycling operation that’s undergoing rapid expansion Europe-wide – and hence a lot of cross-cultural issues where translation needs to go quite a long way beyond just the usual difficulties about natural-language. By contrast, Leo’s example was much larger, and over a much longer time-span, measured in decades: yes, it’s a bank, hence primarily about IT-systems, in terms of its direct content, but also a lot of useful and practical experience and advice about the human aspects as well.
(I won’t comment any further on those two sessions, other than that I liked them both a lot: very useful. If you want to see the respective slidedecks, contact Leo or Pascal direct, or via Bjorn Cumps at Vlerick Business School.)
For my own session, Bjorn had given me a long list of topics that he knew were of concern to many of the participants: and yes, I made the classic mistake of trying to cover as many of them as possible… – not a good idea! Nevertheless, there was quite a lot in there that was useful, and it did include some real case-studies, as requested, together with brief practice-interludes. For what it’s worth, here’s the structure that I used for the session, with the titles for the respective practice-pieces shown in (brackets and italics):
- The challenge: Realising the architecture (As-Is Change)
- The usual approach… (As-Is Process for Roadmapping)
- What’s really going on? (Factors in change)
- Interdependency: Using a maturity-model (Maturity-models)
- Interdependency: Using a clustering-model (Clustering)
- Interdependency: Backbone and edge (Stability)
- Interdependency: Pace-layering and change (Change)
- Planning for uncertainty and complexity (Complexity)
- Budgeting: Using a ‘decision-dartboard’ (Budgeting)
- People: Guiding change (People)
- People: Building the story (Change-story)
Yeah, way too much. And then I compounded the error by leaving in enough detail for people to argue and discuss about – particularly in the section on using maturity-models – such that by the time I was just past the one-third point in the slidedeck I’d already used up two-thirds of the allotted time, and was forced to blast my way through the remainder at somewhat of a breakneck pace. Again not a good idea… – but it all seemed to work out well enough, if perhaps leaving the participants with rather too much of a feeling of far-too-rushed. Oh well.
Much of it was adapted and expanded from existing slidedecks that touch in various ways on roadmapping and the like. If you’re interesting in following up a bit more on some of those themes above, here are some of my sources that I’d used:
- Using a maturity-model: slidedeck ‘Stepping-stone of enterprise-architecture: Process and practice in the real enterprise‘
- Using a clustering-model: slidedeck ‘Unpacking TOGAF’s ‘Phase B’: Business Transformation, Business Architecture and Business Buy-In‘
- Backbone and edge: slidedeck ‘Backbone and edge – architecting the balance between continuity and change‘
- Complexity: slidedeck ‘The dung-beetle’s tale: systems-thinking, complexity and the real-world‘
- Decision-dartboard: posts ‘SCAN as ‘decision-dartboard’‘ and ‘SCAN – some recent notes‘
- People: slidedeck ‘Where do people fit within enterprise-architecture?‘
- Story: slidedecks ‘The enterprise is a story‘ and ‘Staging the story: a people-oriented view of enterprise-architecture‘
The three case-studies that I used as illustrations were the old Australia Post example (which, almost a decade later, is to me still one of the best for whole-of-enterprise EA-modelling), Kai Schlüter‘s brilliant ‘decision-dartboard’, and a truly excellent ‘change-story’ map from Ondrej Gálik. (Ondrej asked me to suggest an EA conference where he could present that change-story: so if you’re running a conference on EA or business-transformation, and you want a good case-study for your participants to play with, get in touch with him as soon as possible! )
For completeness, here are the tweets from Wouter and others that came up during and after the session:
- DepoWo: “Roadmap is nothing, roadmapping is everything.” – @tetradian on #EntArch
- LoQutus_be: Center for Excellence in #EntArch at @Vlerick today about roadmapping with presentations from @LoQutus_be, @tetradian and @INGBelgie
- DepoWo: “#EntArch is more about people problems than it is about technology problems.” Thank you, @tetradian, can’t be stated enough!
- BjornCumps: @DepoWo Agree! But also not only about problems. Opportunities at least as important. People create opportunities. Models can’t.
- DepoWo: @BjornCumps Sure! In my lingo problem = opportunity, always!
- tetradian: @DepoWo: “In my lingo problem = opportunity, always! ” – yes, in yin/yang relation – is why I use term ‘context-space’
- DepoWo: “Defining the ideal is hard, but then making it real, that is the really hard part in #EntArch.” – @tetradian
- DepoWo: “1st of all, get to know your business. Then clean up the mess!” – @tetradian Because you can’t build on unstable foundations. #EntArch
- DepoWo: “Don’t forget you need to deal with the real world.” – @tetradian And real world doesn’t necessary match well with your #EntArch models.
- DepoWo: “A spectrum of services implies a spectrum of governance: governance of governance itself!” – @tetradian. Okay, NOW I’m really scared!
- tetradian: @DepoWo: “‘governance of governance itself!’ – Okay, NOW I’m really scared!” – try metagovernance or metametaframeworks? #entarch
- DepoWo: “It’s only a failure if you fail to learn from it.” – @tetradian Thanks, Tom, I’m gonna quote you on that one!
- DepoWo: “Yes, control is an illusion, but influence is not!” – @tetradian Why #EntArch is a people business, not a technology business.
And the slidedeck itself, now up on Slideshare:
(Note that the slidedeck is slightly different from the one I showed at Vlerick – mainly in that I’ve removed the detail-slides from the maturity-model section, that caused us to slow down too much, and miss the point that that section was only meant to be about the use of maturity-models in general in EA-roadmapping, not the details of that specific maturity-model!)
Hope it’s useful, anyway: comments, anyone, perhaps?