The one big change in IT

A chat with IT consultant and former InfoWorlder Bob Lewis leads to a couple of entertaining revelations

The one big change in IT
Thinkstock

Recently I got a call from Bob Lewis, who several years ago abandoned his regular gig writing InfoWorld's Advice Line and running an independent consultancy in favor of a full-time job as a senior business/IT management consultant at Dell Digital Business Consulting. I recognized Bob's tone from past calls -- he'd had some sort of revelation. "Do you realize," he said, "that over just the past three years IT has pretty much been stood on its head?"

I knew this would lead to a long conversation I couldn't afford at the moment, but I asked Bob what he was talking about anyway. To minimize the damage, I wondered whether he could boil it down to the one most significant change.

He didn't hesitate: "The biggest change in IT is the shift from cost reduction to revenue enhancement."

Say what? What Bob meant was that, in the past, the CIO's mission was to make IT leaner and more efficient, with a focus on streamlining inward-facing applications and business processes. Today, IT focuses more on outward-facing systems intended to gain new customers, retain existing ones, and extract more revenue from them through web or mobile applications and predictive analytics (along with better use of existing CRM systems). This, incidentally, is Bob's definition of the hackneyed phrase "digital transformation."

Bob sees devops playing a key role in this pursuit. Among devops' impacts is that it calls for a major reassessment of ITIL. As Bob describes it:

ITIL was for IT's industrial age, when it was all about cost reduction and risk avoidance. With devops, deployments are small enough that each individual deployment has very low risk and very easy recovery, especially when you layer in containerization. That means you can get rid of a lot of the bureaucratic superstructure IT created to prevent calamities from happening.

Yet Bob does not believe the devops hammer should be used on anything that looks remotely like a nail. Accounting systems, supply chain management systems, warehouse management systems, and so on do not benefit from the constant modification enabled by devops. Those are bound by precise, interlocking processes along with granular permissions and regulations. Here, continuous change invites disaster of the type that ITIL-huggers and OCM (organizational change management) proponents fear most.

In the end, it's not merely technology that separates "legacy systems" from modern, agile, cloudy systems. Different requirements demand different processes.

That said, Bob sees one aspect of devops that belongs everywhere. Devops replaces formal handoffs between independent departments with informal collaborations, a modality that belongs everywhere in the enterprise.

Not that there isn't a long way to go. Bob still encounters siloed organizations that steadfastly stand in the way of any IT productivity whatsoever. In one enterprise, for example, IT needed four months to provision a virtual server:

They didn't have a process. What they had was a series of request forms. Every request form sat in a queue until the group in question was ready to work on it. Then they popped it off the queue and delivered whatever they were supposed to deliver. Nobody owned queue time. By the time they were all done it took 120 days instead of 10 seconds to provision a virtual server.

It's hard for those of us immersed in the world of devops and agile and CICD to imagine such places still exist, yet Bob says he sees this sort of mind-numbing bureaucracy in the majority of enterprises where he consults.

However, he doesn't let the cool kids off the hook, either. No one can afford to brag about effective measures of success in IT:

Look at how scrum, the best-developed branch of agile, measures things. It's throughput. It's how many user story points the team can deliver in a sprint. What businesses care about much more is the cycle time from when a business manager with the authority to make a request says, "I need something," to when the business change happens that the software is built to support. But there's nothing in any of these techniques to measure cycle time in any way, shape, or form.

After many decades of technology "transforming" business one way or another, we're still groping for ways to comprehend the dynamics of the whole. Figuring that out has always been Bob's calling. When pressed, he even resists viewing modern systems of engagement as distinct from legacy systems of record. "The externally facing systems are making promises that your internal systems have to keep," he says. "They're not really separable."

In Silicon Valley, it's easy to get caught up in the latest brilliant idea even when it directly contradicts the last brilliant idea. A little reality check from Bob, who I think by now really has seen it all, provided a long view I'd been missing for a while.

In the end, I had to wing it through the meeting I was supposed to have been preparing for while I talked to Bob instead. But a couple of embarrassing moments aside, it turned out OK. Catching up with Bob was worth it.

Copyright © 2016 IDG Communications, Inc.