Technology-adoption, technology-evolution and lifecycle-management

What’s the difference between technology-adoption, technology-evolution and lifecycle-management? That’s a question that’s come up recently for me, in part as a follow-up to my recent post ‘Technology-adoption, Wardley-maps and Bimodal-IT‘.

The key point here is that, to explain the underlying problems with Gartner’s notion of ‘Bimodal-IT’, I’d used a crossmap between the classic Rogers technology-adoption lifecycle and Simon Wardley‘s concept of ‘Pioneers, Settlers and Town-Planners‘ [PST]. Wardley tweeted back that whilst he agreed with how I’d described the crucial intermediating role of the Settlers, he insisted that PST was about technology-evolution, not technology-adoption. In his own terms he’s obviously right, of course – it’s his model, after all! But yeah, it got me thinking again…

Probably best to backtrack a bit here?

First, we need to understand the term ‘technology’ in its broadest sense: not just some physical machine or IT-box, but all the processes, skills and the rest that are needed to make those machines and boxes not only work, but be useful in their working.

Given that, then the starting-point for that previous post was – as above – Rogers’ five-step technology-adoption lifecycle:

• Innovators: creating new ideas, materials, processes and more
• Early Adopters: applying new ideas in real-world practice, improving them iteratively
• Early Majority: working with ‘new’ ideas etc that seem to be already proven in real-world practice
• Late Majority: apply new ideas etc only when they’re fully established and routine
• Laggards: apply new ideas etc only when ‘forced’ to do so – such as when the old ones cease to be available any more

I’d then applied a crossmap to a left-right flipped version of the SCAN frame, to link that sequence to the transitions from uncertainty to certainty, or unorder to order:

And I noted that we can also crossmap this to Gartner’s Hype Cycle and Geoffrey Moore’s ‘the Chasm‘, which shows how the former in effect creates the latter:

From there, I’d picked up on the PST model:

Which is described in depth in a whole swathe of posts by Simon Wardley, such as:

• ‘Pioneers, Settlers and Town-Planners‘
• ‘An Introduction to Wardley (Value-Chain) Mapping‘
• ‘Stopping Self Harm In Corporate IT‘
• ‘Bimodal IT – the new old hotness‘

(Whilst I was writing this post, marketing-writer Seth Godin came up with his own separate take on the same kind of theme: ‘Scientist, Engineer and Operations-Manager‘ – it’s well worth a look. In relation to that, there’s also the swamp–metaphor with its sequence of Artist → Technologist → Scientist → Believer, that maps to the classic development-sequence of idea → hypothesis → theory → law – though note that the Scientist-mode there is aligned more with so-called ‘scientific-management‘ and the like. But I digress…)

In Wardley’s models, the PST relationships are about how to handle technology-evolution – the way in which the implementations of a given technology tend to evolve over time from initial genesis, to custom-built in-house, to off-the shelf or rented product, to outsourced commodity or service. To support a strategy, we need the right mix of Pioneers, Settlers and Town-Planners, guiding and governing the usage of the full set of technologies in use within that strategy and value-chain, and passing each technology from one to the next as the strategy and technologies themselves evolve over time.

Wardley summarises the respective PST responsibilities, skillsets and relationships in visual form as follows:

Yet to me that set of descriptions also matches very well with the technology-lifecycle – the changes in the nature and usage of a technology over time. (Note that it’s not an ‘either/or’ here – evolution or lifecycle – but more two different views into the same dynamically-changing context-space.)

As I see it, we do need to make a couple of tweaks to the original PST model to make it match up well with lifecycle-management:

• Town-Planners gets split into two distinct roles – Town-Planners and Exploiters
• we need an additional distinct role for Stayers to manage end-of-lifecycle activities.

(By the way, I’m not saying that Wardley’s PST model is somehow ‘wrong’, or even incomplete as such. Given the strategy-focus of the original PST model, the Exploiters wouldn’t be visible at that level, because they’re more about operations than strategy; and the Stayers only become visible when we explore the technology-lifecycle as a whole.)

This gives us an extended-PST as follows:

• Pioneers: invention and innovation, finding the novel and the new – guided by vision, purpose, principles
• Settlers: refining the novel and the new to something real, usable and practical – guided by patterns and guidelines
• Town-Planners: fine-adjustment to specific context – guided by algorithms and analysis
• Exploiters: operation at maximum efficiency – guided by rules and work-instructions
• Stayers: retention and re-use after main production ends – again guided by vision, purpose, principles

(Pioneers and Stayers have quite a lot in common, as we’ll see again in a moment.)

I’d then used that extended-PST structure as the basis for some further crossmaps, first with the Rogers technology-adoption sequence:

And with the Gartner ‘Hype-Cycle’ sequence and Geoffrey Moore’s ‘the Chasm’, as per that earlier crossmap above:

Yet as we explore the crossmaps in more depth, other features of the lifecycle come to light. One is that even though the link from Stayers back to Pioneers is often far from obvious, it’s still a definite cycle, as we can also see in a SCAN crossmap:

(Note that the usual SCAN layout is again here flipped left-to-right, for compatibility with the Rogers sequence.)

Or rather, there are several cycles or feedback-loops that may take place. The forward-going part of each loop is much as described in Wardley’s ‘steals from‘ path in his summary above, with each phase or role re-using ideas, experiences and guidance from the previous stage: for example, Exploiters use the rules and work-instructions developed by the Town-Planners. For the return part of the cycle, there’s some feedback and re-use from Town-Planners and Exploiters back to Pioneers – as in Wardley’s ‘uses components from‘ return-path – but it’s perhaps less pronounced than as shown in Wardley’s diagram. Instead, the main return-loops are probably from Settlers to Pioneers (maybe no surprise there, since both operate within the same somewhat-unordered space), and also, if perhaps in more subtle form, from Stayers back to Pioneers:

The reasons behind all of these differences become clear when we do a further crossmap around cost versus return for the respective activity. For the central sections of the lifecycle – Early-Majority / Town-Planners, and Late-Majority / Exploiters – the returns should generally exceed the direct costs: in other words, those activities are likely to be ‘profitable’, in the mainstream sense of the term. The further our technology is from the centre of that lifecycle, though, the costs rise and the immediate returns fall, until at each of the extremes we’re right out at the ‘bleeding edge’ – the deep uncertainty of initial innovation, or the huge costs of maintaining fragile ‘legacy’-technologies well beyond their ‘use-by’ date:

It’s perhaps most in that sense that the two ‘bleeding edges’ have so much in common: the Pioneers are exploring the new, whilst the Stayers are re-exploring the old. The passion that drives people to invent – ‘scratching an itch’, to use Richard Stallman’s famous phrase – is very similar to that which drives people to rebuild classic cars, to maintain rare-breeds of animals and plants, to recreate historical costumes and events, or to rediscover the virtues of vinyl or photographic film.

Some people might deride the Stayers as out-of-date, as Luddites and suchlike: but perhaps they’re worthy of more respect than they’re often given, because once a technology is fully lost, it usually becomes very hard to recreate it from scratch. And some old technologies have forgotten properties that may be much more valuable than we realise: for example, magnetic-core memory and valve-based logic might well seem laughably beyond its ‘use-by’ date – but they can survive electromagnetic pulses and solar-flares much better than most modern-day electronics, and hence have real value in certain emergency-services contexts. In short, don’t be so quick to laugh about the old – no matter how old it may be…

Another parallel is that Pioneers and Stayers tend to have much broader time-horizons than the others – though the Stayers tend to extend their view as much to the past as to the future. Relative to the future, the respective time-horizons follow a very similar curve to the cost/return curve, with the Town-Planners and, especially, the Exploiters tending far more towards short-termism than the rest:

For the Exploiters, a stronger emphasis on the short-term is actually what we want: if we allow the focus to stray too far away from the Now, everything slows down, and cost/benefit balance may well shift back into unprofitability. Yet it does all need to be in balance, and – as in the diagram above – there needs to be explicit planning for acquisition and implementation of any new technology, and proper preparation for sunset and end-of-life, providing clear and managed transitions throughout the whole technology-lifecycle.

We can also crossmap those extended-PST phases to the phases of the fractal Five Element whole-enterprise architecture cycle:

The above is what happens when we have the full cycle in balance: in particular, the Exploiters exploit the respective technology in a way that creates the greatest return, yet also fully in context of the larger picture.

Consider, though, what happens instead when connection to the longer-term is lost, in a push to grab the maximum profit in the short-term, regardless of the consequences in the longer-term:

What happens is that the whole technology-adoption cycle takes on a different and more literally exploitative shape:

First, the respective organisation abandons any attempt at doing its own innovation – usually on the basis that it’s too difficult and too expensive, with no immediate returns. Instead, all of that is reframed as Somebody Else’s Problem, and is outsourced, usually as ‘meme-copying‘ or ‘solutioneering’ via some big-consultancy or other large provider of pseudo-certainty: “our clients demand a future that is fully proven”, as one large-firm consultant put it.

(Worryingly, from some vendors, the prior roles and contributions of other Pioneers and Settlers are often ignored, or even actively denied: Wardley’s metaphor of ‘stealing’ from earlier stages can sometimes take on an all-too-literal meaning here…)

The active Town-Planner role is replaced by the largely-passive Buyer, whose sole aim is to outsource all responsibility, strategy and thought. But without any internal means of access to the inventiveness of the Pioneers, or the careful realism of the Settlers, this creates a dangerous dependence on external providers – a dependence that, to be blunt, too often resembles the poisonous relationship between drug-pusher and ‘user’. Even at best, the Buyer is often like a kid let loose in a toy-store, rushing endlessly from one ill-thought-through management-fad to the next, in a feverishly hype-fuelled yet inherently-futile quest for the One True Solution That Will Finally Fix Everything And Enforce Competitive Advantage Forever.

(Kinda sad to watch, really – especially as the ones most often falling for this mess are supposed to be the adults in the room, the array of Chief This-That-And-The-Other Officer for the respective organisations. Oh well…)

Which brings us to the Exploiters – who, in this scenario, are required to take on whatever the Buyers give them, and then all-too-literally exploit and exploit, ‘sweating the assets’ with the maximum ‘efficiency’ and speed, regardless of any damage doing so may cause (and which, again, is deemed to be Somebody Else’s Problem). Short-term profit is all that matters – no focus on anything else, or often even any awareness of anything else.

And there is no end-of-life planning. Instead, once the technology breaks down beyond the reach of a quick-and-dirty repair, it is simply abandoned, and replaced by the next shiny new toy. In effect, it becomes ‘anti-property‘ that somehow, once again, is magically reframed as Somebody Else’s Problem. Or, in this case, as a challenge for the respective Stayers, who salvage whatever they can from the wreckage. Even so, the overall costs of repair and recovery can often far exceed the gains that were made by the Buyer/Exploiter pairing – as can be seen all too graphically, for example, in the environmental-disaster-zones that surround so many former mines and their abandoned ghost-towns.

Not exactly a happy scenario, this one, but still depressingly common in business and elsewhere – especially where parasites and predators rule the show. Not A Good Idea…?

Implications for enterprise-architecture

The key point here is that technology-adoption is only viable in context of the whole technology-lifecycle: not the dysfunctional Buyer/Exploiter pairing, but the full set of Pioneers, Settlers, Town-Planners, Exploiters and Stayers for the respective technology.

In practice, this means that for each technology in use, or intended for use, within the organisation – whether in strategy, business-model, operating-model or beyond – we need the full skillsets for each of those roles, accessible either somewhere within the organisation, or elsewhere in the broader shared-enterprise. This doesn’t mean that we have to have all of those skills, present at all times: what it does mean is that we need to know where to find those skills, and to maintain enough skills and knowledge in-house to be able to make full sense of each technology and its needs. Architecturally speaking, over-reliance on external ‘solution’-providers is a recipe for organisational-suicide.

Hence, for an architecture-roadmap or suchlike, we need to map out not just the technologies in use, but the full set of skillsets and knowledge required for development, pre-use validation, implementation, operation and end-of-life closure for each technology. (Often these will require systematic attention to ‘architecting the shadows‘, at both ends of the technology-adoption lifecycle.) It’s only when all of those are properly covered, somewhere within the roadmap, that we would have a viable architecture, and hence a viable business-model and/or operating-model.

As usual, the greatest architecture-challenges are likely not to be in the technical domains, but in the human ones – in particular, in the politics of strategy-development. Even at the enterprise-architecture level, few architects get the opportunity to define an organisation’s strategy – but we still remain responsible for making sure that it works. We need to find ways to influence our strategy stakeholders, to ensure that the full technology-lifecycle is properly covered in each case. For example, we need to make it clear that many classic business-models could be made to seem ‘viable’ and profitable only by ignoring a whole swathe of externalities – and with the onset of much greater enforcement of transparency in business, government and elsewhere, pushing those impacts back onto their creators, the apparent profitability of a dysfunctional business-model can evaporate overnight. In a full whole-of-enterprise architecture, there is no such thing as ‘Somebody Else’s Problem’ – and until this fact fully sinks in, the hidden risks for strategy can be very high indeed.

For architects, probably the hardest task of all will be to dissuade executives and others from falling into the Buyer/Exploiter trap. That trap can be very profitable, in the short-term, for outsiders – particularly vendors and some types of shareholder – but it has a high risk of becoming very expensive indeed for the organisation itself. Given the huge pressures that push everyone towards simplistic ‘solutions’ that don’t and can’t work – especially over the longer term – then yes, this one’s never going to be easy: but we do need to fight against it as best we can. A proper understanding of the real technology-lifecycle, as above, should probably help in that.

Enough on this for now, I guess: over to you for comments and suchlike, perhaps?