Digital Transformation: Behind the Scenes

In prior posts I have talked about the macro-economic drivers behind the digital transformation that has changed, is changing, or will soon change every sector of the global economy. The slide below gives a quick synopsis of the changes afoot:

It is important to recognize that the new era does not obsolete the prior era but rather builds on top of it. That is, there is still deep value to be gained from investing on the left-hand side of this diagram. The point is, however, that we have had a lot of success in releasing the trapped value there, whereas the right-hand side is more of a green field, with tons of trapped value that has not even been touched. For that reason, budget allocation is shifting from the left to the right to capitalize on the opportunity of capturing low-hanging fruit.

That budget today is focused primarily on generating and deploying systems of engagement to take friction out of everyday interactions among consumers, customers, vendors, and partners, with the added benefit of teeing up data feeds for a coming wave of systems of intelligence. What is not being sufficiently acknowledged, on the other hand, is the concomitant revolution in systems support that digital transformation demands. This “behind the scenes” work comes to the fore only at the worst possible times, when an outage brings down a mission-critical system, or a breach exposes mission-critical data. This tends to ignite a round of “who is to blame?” the answer to which, if we are to be honest with ourselves, is almost always “the system.” People are part of the system, and indeed often the part that makes the most mistakes, but that is better treated as a systemic problem than a personnel problem.

The chart below sketches out the kind of systemic response I believe IT organizations need to put in place in order to support digital transformation while at the same time keeping the core enterprise up and running:

Again, the list on the left is mission-critical and must not be left behind. But also, once again, the current action is on the right, in part because it is so new, in part because it is so disruptive. So, let’s walk through what the key changes entail:

• Born in the cloud, not in the data center. Support operations used to be contained within the on-premise systems run in enterprise data centers. But with digital transformation, they are spread out across the data center, the cloud, and a myriad of mobile devices connected by another myriad of public and private networks. It is a fundamentally different terrain, and it calls for fundamentally different strategic orientation.
• Customer systems of engagement, not standard systems of record. These are much more varied and volatile, with uncertain provenance, and undocumented support protocols. In a better controlled world, you would never have released them this early or with this little testing, but competition being what it is, you either have to get on this bus now or be left behind. This puts a new kind of pressure on support, one that traditional systems were never designed to bear.
• Focus on convenience and ease of use, not security and reliability. It is not that we don’t want and need enterprise systems to be secure and reliable. It’s that consumer computing has “gifted us” with a no-cost, low-latency messaging fabric made up of public clouds and privately owned smart phones—all very wonderful in itself, but when interfaced with enterprise systems, chock full of security and reliability vulnerabilities. Unfortunately, these vulnerabilities are the price of poker—if we want to play, we have to accept them as part of the game. We cannot use our traditional approaches to design them out because those approaches also design out convenience and ease of use, as anyone who has been held hostage by the practice of passwords can testify.
• Consumer apps, not ISV SaaS applications. The latter are driven by business rules to which enterprise users must conform. The former are driven by the user’s individual mindset and mandate, deployed with neither training nor manuals, dependent upon leveraging operating conventions popularized by widely deployed consumer apps like Facebook, Google, and the like. The guardrails, in other words, are both low and intermittent, an invitation to serious accidents which, unsurprisingly, are persistently recurrent.
• Incident response, not technical support. Here lies the fundamental change that digital transformation is driving behind the scenes. The unit of focus is not the bug but rather the incident. That’s because incident extends the reach of the support obligation beyond the IT systems into the realm of customer experience. Here time to respond combined with transparent communication take precedence over closing the case. Yes, we still have to close the case, but no, that is not the highest priority. How the customer experiences the incident and our response to it is the main event. 
• Empower the people, not empower the system. Incident response is an inherently people-centric activity, at least until such time as machine learning, artificial intelligence, and real-time correction can be put in place. Given all the novelty entailed by digital transformation, we cannot expect much of this relief any time soon. So, informing and mobilizing the right people with the right tools and access to the right data is core to this new paradigm.
• Agile, not ITIL. Now, to be sure, over time ITIL needs to incorporate Agile, and these two disciplines synthesized into a comprehensive support capability for digitally transformed enterprises. But for the foreseeable future, as we saw with application development in the transition from the waterfall to the agile paradigm, the mindset behind each discipline is so different, the leadership has to come from different backgrounds. The job of the disruptor is to break the new ground as creatively as possible given its “clean sheet” advantages. The job of the incumbent is to catch up as quickly as possible.

The key point is that both these playbooks are mandatory, and neither gets veto power over the other. Each, in other words, operates from its own zone, abiding by that zone’s metrics, and respecting the fact that the other discipline operates in a different zone, measured by a different set of metrics. 

That’s what I think. What do you think?

Follow Geoff on LinkedIn | Geoffrey Moore Mailing List

__________________________________________________________________________

Geoffrey Moore | Zone to Win | Geoffrey Moore Twitter | Geoffrey Moore YouTube