Brocade did an interesting paper on the topic of digital transformation, something you’ll recall was also a fixture of the Netcracker launch of its Agile Virtualization Platform. Reading it, it occurred to me that the concept of “digital transformation” is widely accepted and not usefully defined. That was one of my conclusions on the Netcracker report that also used the term, you’ll recall, and it’s clearly demonstrated in the Brocade survey. It also occurred to me that some statistical market research I did several years ago might point to a definition, and perhaps even a path forward to achieving the goal.
The Brocade paper documents a global survey that, to me, shows IT organizations groping with the critical question of relevance. They’re facing budget constraints, “shadow IT” and other things that demonstrate that line departments and senior management want something from IT, something that IT can’t deliver. Is that something “digital transformation?” Perhaps it is, if we define the concept appropriately.
Facts and industry history might be a good place to start our quest. What I found in my research is that the rate of change in IT spending relative to changes in GDP over the last 50 years, when graphed, form a sine wave. If you then lay in key IT innovations along the timeline, you see that the peaks of the wave (when IT spending grows faster than GDP) came when a paradigm shift in IT opened new benefit sources for exploitation. The curve then rose for four to eight years as businesses absorbed the benefits of the new paradigm, then dipped down as things fell into cost consolidation when all the gains had been realized. Then they picked back up again in the next cycle. There were three major IT cycles prior to about the year 2000. There have been none since.
I thought when I uncovered this relationship that we were now awaiting the next cycle, a cycle that would reignite benefit-driven IT. I realize now that’s not the answer. What we’re looking for is an agile IT model that doesn’t demand big technical paradigm shifts at all. Every year, we get more invested in technology, and cyclical transformations that involve new computing models (minicomputers, PCs) are simply not practical. What’s needed from “digital transformation” is a restructuring of IT to allow it to couple continuously with business operations through all the twists and turns. Four or eight-year realization? Forget it. Digital transformation has to facilitate almost instant adaptation, and then re-adaptation. Nothing singular and simple is going to generate it. It’s a whole new IT and networking model.
That starts at the top. If you want “digital transformation” you have to transform the relationship between applications and the business, which starts by redefining how you conceptualize the role of applications in supporting workers. In the past, we’ve used software to create a framework for production, and built human processes to fit the software model. That’s why the advent of minicomputers and personal computers and online services have been transformative—they let us build the IT model “closer” to the worker.
The line departments think this “framework” has become a cage, though. Because software processes are highly integrated with each other and increasingly just touch the worker through a GUI, they aren’t particularly responsive to changes or opportunities that demand a more fundamental shift. We can see this in the way businesses struggle to support mobile work. Mobile-worker productivity support is effectively contextual, personalized, IT. That eliminates an application-driven flow in favor of linking IT support to worker-recognized events.
It’s not happening today. In my most recent exchange with enterprises, I found that almost three out of four said their mobile strategy was to make their applications work on a mobile device. It should have been focused on defining the right information relationship to support a mobile worker. But how? By making applications completely event-driven.
Making something event-driven means taking the workflow structure out of applications, and instead looking at any activity as a series of events or “happenings” that suggest their own process support tasks at the application level. This, you’ll undoubtedly recognize, is an enterprise version of the event-driven OSS/BSS trend in the operator space. The realization of digital transformation must be to first create an event-driven software structure, then create an agile platform to host it, and finally to create a set of network services that properly connect it.
Microservices, meaning small functional atoms that use web-like (“RESTful”) interfaces to obtain the data they operate on, are generally considered to be the key to making OSS/BSS event-driven and that’s also true for enterprise software. However, it’s not a simple matter to change software to create microservices. Many software components are “stateful” meaning that they store data across multiple interactions, and that forces them to be used in a flow-driven rather than event-driven way. However, it’s almost certain that microservices would be the first step in supporting a realistic model for digital transformation.
Underneath this first step there are a few things that could be done at the developer level. One is the embodied, in Java, as the Open Services Gateway Initiative, or OSGi. OSGi lets components be developed and deployed either as locally connected pieces of something or as distributed elements. If you were to develop all software components using OSGi principles (in whatever language you like), you could host stuff where it makes sense, meaning either as network-connected or locally bound processes. This is critical because you can’t build efficient software by putting every little function on the network as a separate microservice, but what can be made network-hosted and what for efficiency reasons has to be local would vary depending on the specifics of the application.
Another essential transformation in software development is functional programming. Functional programming basically means that software elements (“functions” in development terms) take all their arguments from the thing that invoked them and deliver all their results back the same way. Everything is “passed” explicitly, which means you don’t collect stuff internally and can’t accidentally become stateful. Microsoft and Oracle (with C# and Java 8, respectively) support this today. Functional programs could easily be shifted from internally connected to network-connected, and they’re also much more easily adapted to changing business conditions.
Hosting this framework is what justifies containers versus virtual machines. The more you componentize and microservicize something, the more inefficient it is to host a dedicated version of OS and middleware for every software instance you deploy. In fact, in this framework it’s really important to understand the transit delay budget for a given worker’s support and then distribute the components to insure that you can meet it. Data center design and connection is paramount, and data center interconnect is a close second. Networking has to create and preserve a distributed and yet responsive virtual platform to run our agile microservices.
All of these technical shifts are recognized today. Most developers know about OSGi and functional programming. Everyone knows about containers and microservices. What seems to be lacking is an architecture, or even a philosophy, that connects them all. Could it be that the concept of digital transformation is shrouded in definitional shadows at the high level, and obscured by technical specialization below? The pieces of digital transformation are all laid out before us, but “us” is organizationally divided and unaware of the high-level goal. That’s why we can’t even define what “digital transformation” means.
Knowledge is power, they say, but only if it’s a precursor to an informed decision. Surveys can tell us there isn’t a consensus on digital transformation today, but since there isn’t one to know, we can’t survey to find it. I think event-driven, agile, IT that supports rather than defines work is what digital transformation has to be.
Presuming my definition here is the right one, it’s a compelling goal but it has to be justified for each company by a business case and not just by consensus, and that business case has to be decomposed into specific steps that can approved and adopted. Surveys show commitment and confusion, but confusion has to be resolved if investment is to come. Now that we know the buyers want something, we have to define and then take the appropriate steps. If Netcracker or Brocade (or Cisco, Dell, IBM, HPE, Microsoft, Oracle, Red Hat…) can create that chain from concept to benefits to technology steps, then they’ve started the march along the path to digital transformation, to their benefit and ultimately to the benefit of the industry.