Digital Transformation: There is no target picture

Traditional IT projects work by taking something from the current state to a reasonable known future state. Much effort goes into defining the future state well, so IT can deliver accordingly. Once delivered, we like to keep things in the future state for a good while as that's how the project generates the ROI (Return on Investment) projected in the up-front business case. A majority of IT management's time is spent with such projections and calculations as the IT delivery is usually outsourced.

When such organizations take an aim at digital transformation, they are naturally inclined to follow the same process. The process may not be perfect, but it's worked well enough for them and digital transformation is a difficult endeavor anyway, so better not to change the process at the same time. Hence, you end up with a "change project" or "change program" (if more money is on the table) that'll take the organization from today's state into one that's ready for the digital world.

Digital Transformation: Preparing for Constant Change

Sadly, this approach badly misses the whole point of digital transformation. Yes, we do know several elements of what "being digital" looks like: companies that do well in the digital world are customer-centric, highly automated, aren't afraid of failure, etc. Understanding these aspects is already better than simply putting more pressure on the organization to move faster, but it still assumes there's a specific target picture you are aiming for.

Unlike the traditional IT world, digital companies aren't looking to optimize existing processes -- they chart new territory, meaning they need to be able to course-correct as they discover what works and what doesn't. Digital transformation therefore isn't about reaching a specific target state ("B" in the diagram above), but about permanently increasing the rate of change in the organization, so it can deal with the fact that there is no well-defined target picture.

I observed an organization demanding a "digital architecture blueprint" that was meant to last for 5 years. The contradiction in such a plan is easy to unearth by conducting the thought experiment that you would have defined this architecture 5 years ago: even if you had done a great job, and you were totally super-bleeding edge, you might have included Docker containers, but your strategy would have likely ignored container orchestration and be devoid of Kubernetes, the de-facto container orchestrator. There would be no sign of TensorFlow and most other machine learning tools. There likely wouldn't be a hybrid cloud strategy based on open source run-time abstractions. Whether we like it or not, IT plans don't last 5 years anymore unless they are so high level that they are meaningless (yes, there'll be some new stuff, some legacy, and some data analytics).

Should we wait until it all settles down?

In an executive discussion, IT managers of a traditional organization voiced their frustration with the high rate of change in cloud technologies. One thought would be to wait until things slow down a bit in order to be able to make longer-lasting investment decisions. I consider this a very dangerous position. I don't think a traditional business has to be on the very bleeding edge, so you can be a fast follower that avoids a few swings in the technology evolution. For example, you might have been able to save yourself from evaluating multiple container orchestrators if you waited a year or so until it became clear that Kubernetes was the winner. But to expect that things will slow down is bound to be a losing proposition. If anything we have seen the pace of innovation pick up in recent years: machine learning is a great example that moved from science fiction into main stream within just a few years.

The only viable answer is to shape your IT organization and technology stack in such a way that it can deal with change more easily and cheaply. That's what digital transformation is about.

Want more?

You can read more of my thoughts on architecture and transformation in my book:

• E-book at https://leanpub.com/37things
• Hardcopy at Amazon