A Tale of Two CIOs—How Would You Enable Business Agility?

Sometimes a story paints a thousand pictures…

A number of CIOs and their lead architects met to discuss their respective businesses and compare notes. They represented a group of loosely confederated international companies in the telecom sector. Each business operated in a different country. Though they were in the same general business domain, they differed in important ways, including business strategy and planning, markets and customer segments, regulatory environments, business age and maturity, product mix, and information systems requirements. I was privileged to attend.

During the course of the meeting, each CIO presented the state of their overall business, the issues their IT group was facing, and their plans for addressing those issues.

One of the first to present was the CIO from the oldest and most mature of the represented companies. He was a seasoned IT veteran with a depth of wisdom that comes from many battles. He had a large IT group with a sizeable budget.

He talked at length about his situation. His CEO demanded ever-greater business agility, yet IT was filled with legacy systems that were highly resistant to change. His budget seemed to shrink every year and he struggled with the never-ending battle to keep pace with technologies that changed faster than he could retool and retrain his staff. His systems were routinely called on to perform tasks they were not designed for and could not do, given their hardcoded business rules, inflexible integrations, and locked-in vendor relationships. His enterprise application vendors were not sufficiently responsive to his requests for changes. A merger had just been completed and he was faced with a huge consolidation project. A major outsourcing effort seemed to produce more problems than solutions.

Together, these IT issues were preventing the business from achieving its goals. With a recent shift in the parent company’s strategic goals, demand for updated systems only increased, and IT’s inflexible systems stood in the way of the business.

His group had its hands full just keeping the lights on. Demands for strategic change and consolidation were overwhelming, and they saw no clear way to be successful. They responded in the only way they knew how—by simply rolling up their sleeves and giving the best effort possible under the circumstances. This would take heroic efforts under less than ideal conditions, which would reduce job satisfaction for the staff and make retention of critical individuals more difficult.

Of course, most readers will recognize this scenario. The systems that IT creates to solve business problems all too often contribute to, or even becomethe next round of problems the business must solve.

The story continues…

On the second day of the meeting, another of the CIOs gave an overview of his IT situation. This CIO represented … the newest and least mature of the companies present, in business for less than a year. The CIO was young and energetic but with neither a background in IT nor much technology training. His entire staff consisted of about a dozen programmers, and his budget was similarly small.

He exuded entrepreneurial fervor and an unrelenting “get ‘er done” mentality. His solution to every problem was to customize open source software for his specific business needs, handcrafting whatever was needed as inexpensively as possible. As the company grew, IT would simply grow its budget and hire more developers to meet the growing need. He presented no overarching vision or plan. Everything was tactical and reactive. There was no plan to purchase any vendor-produced applications to support operations.

The contrast between these two CIOs could not have been more striking. The question seemed obvious, so I asked the second CIO, “After hearing the issues that your colleague is facing, what will you do differently now, so that you are not in his unenviable position a few years from now?” As a hint, I suggested that his answer should cover business strategy, IT strategy, system design, integration, solution flexibility, staff skillsets, and possible skills shortages. Quite a lot to think about when in startup mode, to be sure, but critically important nonetheless. His focus was maximizing present day, startup agility without regard for future agility. He was minimizing present day costs with little regard for future costs. He was building IT solutions, and an IT culture, that simply couldn’t be sustained over the long haul.

As he pondered a response to my question, he hemmed, he hawed, he mumbled a few platitudes, and it became apparent that this question had simply never crossed his mind. With a bit of encouragement, he agreed to talk with the first CIO to learn how they got into trouble, and to discuss what he might do differently to avoid the same fate.

This meeting was a beautifully encapsulated microcosm of the differing approaches to IT strategy across the business lifecycle, and illustrates the ways in which the pressures on early stage IT groups drive them toward decisions that can easily trap both them and their business partners later on.

(Excerpted from Breaking Through the Agility Barrier—Creating Information Systems that Accelerate Business Evolution, by Steve Laufmann, ©2015, used with permission.)

CIO #1 had systems that couldn’t adapt to changing business needs. With no systems to adapt (yet), CIO #2 was in danger of building brand new systems that couldn’t be adapted to future business needs.

Is it possible to do better? IT architects have long complained about being called into service way too late in the systems lifecycle of a company. But some argue that the issues that plagued CIO #1 are a natural outcome of the process of building a business, and are therefore inevitable.

An Enterprise Architect might assert that without appropriate architecture there is little hope of a better outcome. But withsuitable architecture, applied early and consistently through the business lifecycle, most of the problems facing CIO #1 could have been minimized, and perhaps some could have been avoided altogether.

Jason Bloomberg talked about this issue in what I consider to be one of his all-time best posts, Why Nobody is Doing Enterprise Architecture. Though I don’t entirely agree with his conclusions (read his post to see the humor in that), he makes a few essential points about when and how to apply architecture in the early phases of a new business.

I’ll argue, in a series of upcoming articles, that there isa better way. And it doesn’t take as much additional work as most people fear.

But let me put the question to you: