Two becomes Three
I’ve spent the last few weeks revisiting the 2-speed IT paper that we (Atos Consulting) produced in 2014 and correlating it to how we work now within Worldline – in essence, bringing it to life in the way in which we all work.
As a reminder, 2-speed IT, written around the same time as Gartner’s bimodal IT, highlighted the emerging and growing gap between traditional IT application and operations thinking (often the realm of the IT Director and CIO) and digital (“what would the web do” - WWWD) speed thinking (often as illustrated through marketing/CX related activities or business adoption of SaaS). The challenge in that paper was to highlight the different mindset, techniques and methods, best or next practices, that were likely to be relevant in optimising Operational Speed or effectively executing Digital Speed.
Wind the clock forward to 2016 and I think the graph above holds remarkably true. We’ve seen the continued acceleration and adoption of Digital across all market sectors, and at the same time we know that not everything – and certainly not everybody – can be Digital Speed. Operational Speed is causing increased frustration though where the pace of change and evolution of legacy, monolithic applications continues to frustrate those who need to respond quickly to evolving needs in their business. ‘Acceptable disappointment’ has become ‘Unacceptable disappointment’, which has highlighted the criticality of being able to ‘cross the chasm’ – to at least find a route to drive a better pace of change, even if fusing the mindsets of both.
This is the core point of my article. As we drive change in our business (and I don’t think for a moment we are unique), I see three distinct activities – three speeds of IT if you will.
As we’ve always said, driving change and application development from a digital mindset – WWWD. With no legacy to adopt, this is about the creation of new products, applications and services at pace and with agility - born digital, utilising commodity services wherever possible and only considering an agile development approach and iterative release cycles. We could point to solutions that we are currently building consuming Redshift and AWS, or another with Financial Force, or another using open-source hardware components as part of IoT related Connected solution. I’ve seen this accelerate too in industry, with more organisations buying in (recruited or contracted) Digital development capability (Product Directors, sprint teams) with backgrounds baked in web and mobile rather than traditional corporate or IT services background.
The challenge set in 2014 was to get Operational Speed ‘fit for purpose’. To drive the reliability, availability, accessibility, velocity ever higher – but recognising that those applications or infrastructures will by their nature never be Digital Speed. Whether regulation, compliance or complexity, these are the typically back-office services that may well run for years to come much as they do today, requiring feeding and watering, occasional tech refresh and sometime wrap (integration to Digital Speed front office).
To be clear, Operational Speed can include the transition to a cloud based infrastructure – private or public. Simply introducing a technology associated with Digital does not mean that it becomes Digital, unless it can also be proven to demonstrate the behaviours associated with Digital – pace, agility, iterative and more.
Perhaps in 2014, we would have positioned this as part of Operational Speed, but in execution terms, for me it is distinct. It is undoubtedly a transition state – a bridge that allows us to cross the chasm between Operational Speed and Digital Speed that allows us to deliver tangible benefits usually associated with Digital Speed – specifically pace.
To illustrate it I’d like to highlight the work done in the past few years by our Customer Information Systems team that deliver solutions into UK rail stations. They had a respected but legacy, proven technology – using Visual COBOL, Visual Basic – that typically had six monthly release cycles. Without changing technologies, they changed the delivery approach and ways of working – introducing git, agile and Kanban – resulting in what is now two weekly release cycles and a much faster time to market for change. This has recently been recognised through them being shortlisted for an innovation award for their work delivering a train graphic showing reservation levels, train formation and location of on-board facilities for Virgin– because of the impact of pace & velocity in quickly delivering CX functionality that improved flow through stations.
In essence, I see Operational Speed’s ‘getting fit for purpose’ as about utilising technology solutions to improve performance, improve reliability, to lessen the gap of supply to demand.
I see Bridging Speed as the adoption of a Digital mindset to the way in which teams work – the fusion of legacy and digital that drives accelerated release cycles, faster time to market (for change), improved ability to close the gap of supply to demand. As a transition state, I would also expect the more Digital astute teams that emerge to drive that change further, ultimately themselves becoming Digital Speed - learning not only new ways of working, but new technologies that allow them to evolve to full Digital Speed themselves.
Operational Speed and Bridging Speed are about existing applications and services – whatever infrastructure it happens to run on today or tomorrow. New products – surely you would start Digital Speed. Why replicate the legacies of the past? In execution terms, there is a world of difference between evolution of an existing product and creation of a new one – it’s like installing a new kitchen rather than building a new house.
Bridging Speed will give Operational teams more experience – more tools – in their kit bag that gives them a better chance to build the house most effectively next time.
I’m conscious that in proposing three speeds, it is purely a personal opinion informed by my personal journey from CDO to COO, from strategizing to executing that strategy. There are other views out there, four-speed IT and our CTO even suggests perhaps five. I’m particularly interested to hear other experiences from other industries and other technology providers as to how 2-speed IT (or bimodal IT) is working in practice for you.