Digital transformation, aka DX, is hot -- and if you're not doing it, your company will die and you will lose your CIO or IT leadership job. You'll -- shudder -- be disrupted! Or fail the wrong side of the Innovator's Dilemma. That's the message over the last few months from consultants, pundits, and of course vendors.
But wait -- wasn't digital transformation hot in the late 1990s and again in the mid-2000s? Indeed it was. It's hot again, mainly for the wrong reasons. That is, vendors want you to buy stuff because IT has been cutting back.
There is a very good reason to invest in digital transformation. But it's not the digital transformation you're usually sold.
First, here's a typical definition of digital transformation that means the same things consultants and vendors have been saying for years: keep up with new technologies, and use them -- only the technologies have changed:
Digital transformation is the application of digital technologies to fundamentally impact all aspects of business and society.
If your company has not been applying digital technologies over the last 40 years, you don't exist. The time-share, mainframe, departmental computing, client-server, PC, ERP, Internet, cloud, and mobile eras are all old news today. You already use some of these, of course. If anything, most of these eras coexist in your technology stack.
But the adoption of these technologies doesn't mean you're digitally transformed, even if you are digitized. Most of these technologies have been applied to existing processes: to digitize or computerize those processes, mainly for efficiency. Paper forms became electronic forms, cash became bits, paper documents became PDFs and HTML pages, sales transaction logs and invoices became sales-force automation and ERP. The underlying nature, at least to start, was the same, but now digital only.
An ugly word is at the root of digital transformation
What should digital transformation mean? The key is in an ugly word that "transformation" weakly implies: "fungibility."
Fungibility means the ability for something to be changed. That's not the same as the ability to change something; fungibility is an intrinsic characteristic, not a force imposed by an external source. Transformation is the act of making substantive change; fungibility is the intrinsic ability to be substantively changed.
Some digital transformation proponents have long recognized that digital transformation is more than digitization. They start with that definition I quoted, but continue along these lines, which comes from Isaac Sacolick, global CIO and a managing director at Greenwich Associates, an advisory services to the financial services industry, whom I've long known from joint conference work.
Digitally transformed businesses typically develop an ecosystem that blur the lines between supply chain, partner, customer, crowd, and employee and both strategy and execution are heavily influenced by this ecosystem.
When I put the "fungibility" notion to Dion Hinchcliffe, a technologist strategist well known for his focus on social technology and more recently digital transformation, he agreed it was core to real digital transformation:
I think you're on the right track. Digitization was "paving the cowpath," using digital tools to automate and improve the existing way of working without really altering it fundamentally or playing the new rules of the game. Transformation is a more caterpillar to butterfly process, moving gracefully from one way of working to an entirely new one, replacing corporate body parts and ways of functioning completely in some cases to capture far more value than was possible using low-scale, low-leverage legacy business.
If you look to past eras' books on digital transformation, you'll also see this fungibility notion, even if the term is not used. However, most people stopped at the digitization part of the definition and missed the transformation part.
Put digital transformation into practice
What does that mean in practice? It means you design items, so they can easily change; much of IT's digitization work has been to prevent change. There have been good reasons for that: You want honest, verifiable finances, orders, deliveries, payments, access logs, employment validation, and so on. ERP, CRM, MRP, SFA, and the late-1990s enterprise systems are systems of records, and their state needs to be assured. For security, identity is similarly something that needs to not be fungible.
But once you've digitized your products -- music, books, articles, order-taking services, courses, investment vehicles, social networks, and so on -- you've left the real world and entered a virtual one, à la "The Matrix." These products need not be strict analogs to their real-world forebears, and in fact seem to gain more value and engagement when they are not. The more fungible you make them, the more engaging they become.
That's been the case in the media industry, and it's the impetus for the augmented-reality and virtual-reality crazes now under way. It's what makes social networks so different from live ones like clubs. It's why all those disintermediation systems, from Uber to Amazon, have rocked the economics of their forebears -- fundamentally, the underlying systems don't care if they're matching people with restaurants, drives, storefronts, or dates; they can even mix those up in a way a traditional sales channel cannot. It promises to do the same for health care, research, and facilities management.
But digital transformation is about more than digital products and services; it's also about the processes that create, enable, manage, and deliver them. That's where IT comes in. Processes and the underlying technologies should be fungible as well. Not all processes and technologies, of course -- we still need reliable systems of records -- but more than most companies now have.
Perhaps an easier way to swallow this concept is by thinking of it as easy adaptability. Take the usual Exchange deployment at a company: It works reliably as long as everyone uses the same system, meaning Windows PCs and Microsoft clients. Yet the world is not so standardized or rigidly deployed; it's full of Macs, iPads, iPhones, and Android devices that support some Exchange capabilities through both Microsoft and native clients. Those people can't participate easily or at all because the platform is not designed to adapt to changing clients.
A digital transformation approach to the Exchange processes and technology around meetings, collaboration, and messaging would be based on common protocols and local rendering. A new device or OS or client could then join the party without IT or user work.
That's a very small example. Imagine it applied to security: Instead of hard-wiring already-known threat responses in appliances and software, use techniques like machine learning to adapt not only the responses but the underlying threat models along with the changing threats. It's easier said than done, I know.
The next step is that the technology systems themselves are fungible. Every IT organization has many layers of "transformative" technology in place that has turned into legacy technology. Wouldn't it better if the platforms themselves could easily adapt to support the evolving products and processes you have? Right now, you have to add new layers of technologies for the new and different stuff, and figure out how to integrate, isolate, or retire the old stuff -- and it's usually a complex mix of all three.
Tactical approaches to digital transformation
Strategy is well and good, but it's fundamentally meaningless if you can't execute on it. There's no silver bullet to becoming digitally transformed -- by definition, it's an ongoing process -- but you can take advantage of certain tactics. They too will change over time, with today's innovations becoming tomorrow's legacy. It's better to do that than to stick with yesterday's legacy.
A tactical approach to digital transformation centers on using new tools and related processes to get better results. Those new tools are based on new or reworked ideas, so they're not a direct substitution for the tools you already have.
For example, agile programming -- when done right -- broke from the waterfall model's assumption that you could predefine the whole application, then have coders execute it. That might work for software whose functionality is static, but not for applications that are meant to engage with people under variable circumstances.
Microservices and containers like Docker both are forms of the "leave the monolith behind" approach, this time for code segments that can be easily created, destroyed, and changed -- without a central, managed library at the center as in the end days of service-oriented architecture where complexities like CMDB that resulted when old-school IT thinking were imposed. MBaaS is a more centrally controlled variation of this notion for mobile services.
Think differently
Those are a few examples of emerging tactical technologies that help you think different about how to deliver the processes and products you deploy technology to do. What's key is that they make you think differently, as the Internet, cloud computing, and mobile computing have done.
Thinking differently is perhaps the most important ingredient in digital transformation, in fact. If you keep thinking the same, all that new technology will be used to do more of the same. That's the opposite of transformation.