Read Blog Post

Read Blog Post

Contributed on March 8, 2017

1.6K

1.1K

The bucket-list – next steps

Blog: Tom Graves / Tetradian

Frameworks, tools and so on. All the stuff that’s in the bucket-list.

There’s a right way to do it.

There’s a wrong way to do it.

(There’s also an all-too-common incompetent way to do it – throw together a mish-mash of half-baked ideas, give it a fancy label such as ‘Bimetallic’ or the like, make it proprietary, and then market the heck out of it as ‘The Solution To Everything!’. But we’ll ignore that for now, anyway.)

It’s probably simplest to view this in terms of the distinct mindsets in Rogers et al’s model of the technology-adoption lifecycle:

(For this, we only need to consider the first three stages: Innovators, Early-Adopters and Early-Majority. Late-Majority pick up something new only when everyone else is already doing; and Laggards will cling on to whatever they already have until it’s so broken that it almost falls apart into dust.)

The right way to do it is the way that people like Alex Osterwalder (Business Model Canvas, Value Proposition Canvas etc) and Nigel Green (VPEC-T, Found In Design etc) have done it:

• develop an initial idea
• Innovation stage:
  • build a small community to refine, sanity-test and simplify for Innovator use – develop the potential, but keep the hype at bay
  • work with that community to test in real-world Innovator practice
  • collate all of the feedback from that small community to decide whether to proceed to Early-Adopter stage
• Early-Adopter stage:
  • develop a more usable version of the idea for Early-Adopters
  • build a broader community to refine and simplify again for Early-Adopter use
  • work with that broader community to test in real-world Early-Adopter practice
  • collate all of the feedback from that broader community to decide whether to proceed the Early-Majority stage
• Early-Majority stage:
  • develop a more polished version of the idea for Early-Majority
  • work with mainstream marketers etc to launch out to broader market
  • ride the keynote / consult / train / publish cycle to monetise and to grow broader reputation
  • collate all of the feedback to guide development of the next follow-on idea
• rinse and repeat

Or, as Nigel Green puts it, experiment, include, listen to feedback, and evolve – all the way to the Early Majority and beyond.

It takes a minimum of around 3-5 years to go through that cycle with a single useful tool, from initial idea to profitable-for-all roll-out and initial adoption with the Early Majority. (Once it reaches that stage, it largely looks after itself.)

The wrong way to do it is the way that I’ve done it:

• develop an initial idea
• work alone to refine, sanity-test and simplify for Innovator use
• throw it out to the nearby Innovator community, with no means to check if anyone has caught it, or to gather feedback on practice
• rinse and repeat, without ever really getting beyond the Innovator stage on anything

Otherwise known as ‘idea-hamsters’… – spinning round and round on the ideas-wheel, doing little to no immediately-usable work, and burning out at the end with almost nothing to show for it…

That’s me.

But that’s also a lot of us: enterprise-architecture is full of people who’ve made the same mistake as the one I’ve done as per above. Very few of us have done it the right way; amongst those of us who’ve developed our own ideas, tools and techniques, almost all of us have done it the wrong way.

Sitting in the bucket-list is a complete suite of tools that, for high-level overview at least, can be used to cover pretty much the entirety of any enterprise-architecture context, at any scope and scale. But it’s all been done the wrong way – it’s there, it works, but for most people it’s too incomplete and unpolished to be usable in the ways that they need. Cleaning up all of that, all the way up to the shiny-polished-and-immediately-usable level that the Early Majority mindset needs, would take something like 50-100 person-years; whereas at my current age of 65, I have maybe 5-10 years left in which I would be able to do it – and there’s a lot of other things I also need to do in what little time I have left. (At last having something resembling ‘a life’ would be good, for starters… )

In short, there’s a problem there…

And again, it ain’t just me. Sure, I’ve been one of the more prolific in the EA-space; but counting just the people I know across ‘the trade’ who are coming up to or beyond so-called ‘retirement-age’, I can see at least a thousand person-years of clean-up that’s needed, to rescue really good ideas that will be valuable for the next generation(s) of enterprise-architects. We need to do that, urgently, before those ideas and experiences are lost forever. And we need to keep doing it, and keep doing it, as part of every aspect of our work.

The point here is that this idea-to-use problem is always going to be endemic in ‘the EA trade’.

By the nature of the work, most of us don’t really get into our full stride until late-career – usually our late-40s or 50s at the earliest.

By the nature of the work, we tend to be ‘loners’ – there aren’t many of us, and we do work that few people will understand.

By the nature of the work, innovators will always at first be misunderstood – and yeah, that hurts, especially when our work means we’re always a decade or more ahead of the mainstream.

By the nature of the work, much of what we do is context-specific and unique – which, yeah, is yet another common source of misunderstanding, even within the EA community itself. (Definitional-fights on LinkedIn, anyone? )

By the nature of the work, much of what we do is abstract, to connect things that are context-specific and unique – but thence needs adaptation to apply to anything that’s context-specific and unique, which is uncomfortable for those who want and need prepackaged step-by-step instructions.

The point here is that this idea-to-use problem is always going to be endemic in ‘the EA trade’.

In which case, we need to stop pretending that the idea-to-use problem doesn’t exist.

In which case, as a community, we need systematic processes and repositories to help idea-to-use and idea-sharing across the EA community.

Which don’t exist.

And it’s probable that none of the existing bodies will help us resolve this. For example, Open Group is an IT-standards body – not an EA-practice body. Sure, they’ve carried much of the can for us, for too long: but it’s unfair and unwise to expect them even to be able to do much more than they have – particularly as we necessarily move further and further beyond an IT-centric scope.

Yes, the standards-bodies can help, in the standards aspects of our work – no doubt about that.

But what we need now is a EA-practice body. – the equivalent of a standards-body, but focussed not solely on the ‘samenesses’ of standards, but focussed more on the ‘uniquenesses’ of practice.

Which doesn’t yet exist.

But without it, we’re about to lose tens, hundreds, thousands of really useful tools, techniques and more, and thousands upon thousands of years of irreplaceable experience.

So what do we do about this, as a community?

To be honest, I don’t know – and as I warned in the follow-up to the ‘bucket-list’ post, right now I’m personally almost too burned-out to care. And unfortunately it’ll still take me some months at least to get the other side of it – I know all too well how burn-out goes, from a lot of painful past experience.

I do know, though, that other people do care about this, a lot. I’ve had some very good conversations on this, in the past few weeks. That’s heartening.

Yet we need to get beyond just talking about it. We need real action, fast, to save what we can, and make sure nothing else is lost.

I’m the wrong person to do that: it’s not just the burn-out, it’s much more that I have the wrong mindset. I believe I’m a fairly good innovator, but I’m not good at all at the follow-on clean-up that makes tools useful. To make things work well, I need help on that – a lot of us do.

Yet it’s only going to happen if we come together as a community – an EA-practice community – to help each other make it all happen.

In short, apply architecture to our own work too.

So what part can you play in helping this happen, for all of us?

Over to you…