The IT Dilemma—Irresistible Forces vs. Immovable Objects

A large service company was facing severe competitive challenges. Customers demanded better access to more services for less cost. Competitors were drawing customers away in droves. The CEO defined a few key initiatives that would determine whether the business would survive. One initiative was to reduce customer service intervals from more than a day to less than two hours. After much study, only one practicable solution could be found. However, it would cost tens of millions of dollars and take multiple years to achieve—much more than the company could afford and well beyond the business’s current horizon.

The problem? The underlying information systems were simply not designed for the functions they were being asked to perform. Basic business assumptions were hardcoded deep in vendor silos and could not be modified within the needed time or cost constraints.

The CEO was forced to modify his business strategy and find other ways to address sagging customer satisfaction.

In this case competitive advantage was lost because of IT’s inability to modify critical legacy systems. No CIO wants to be in the position of telling the CEO that a competitive differentiator cannot be accomplished because IT’s systems were poorly designed or thoughtlessly implemented.

IT leaders all too often find themselves caught between forces intent on tearing them apart—forces that seem universally present, recurring, and largely beyond their control:

1. Demand for greater agility. Change happens, so the business demands improved solution agility, rapid turnaround on new functional capabilities, and increased adaptability and flexibility in their systems.

2. Increasing cost pressures. The business demands lower IT costs, often by fiat—by simply shrinking IT’s budget.

3. Rapidly changing technologies. There always seems to be some “new and improved” technology promising whatever it is that IT needs—the technology du jour. IT leaders must make sense of the fluid world of emerging (and many times reconstituted) technologies, understanding whether (and how) each can help, together with the time and cost to deploy.

4. Arcane and inflexible legacy systems. Every IT group has some (often large) number of systems in production—legacy systems, by definition. Each incorporates assumptions, technologies, environments, business rules, and platforms based on what was known or relevant at some point in the past. Some may be as much as 30 or 40 years old, especially in industries that were early adopters of computing technology from the 1960s through the 1980s, like banking, insurance, and telecommunications. These are notoriously tough to adapt to new business needs.

Business demands for agility and emerging technologies drive IT to change as quickly as possible, while cost pressures and legacy systems work powerfully against IT change of any kind or scope.

Cost pressures and business agility are business driven, while changing technologies and legacy systems are IT driven.

In some all-too-real sense these comprise the IT version of Irresistible Forces and Immovable Objects, with IT leaders caught in the middle—expected to work magic while feeling a bit like their feet are encased in concrete blocks and their arms attached to rockets—a condition which inevitably leads to some unpleasant days.

How can we move the immovable while (at least temporarily) resisting the irresistible?

There are two core issues. First, systems must be specifically designed to enable rapid change. This requires a modular approach to constructing and defining systems, rather than merely defining APIs. While this is not rocket science (OK, bad joke), many IT groups pay only lip service to this principle, so fail to truly understand and apply it consistently.

Second, modular systems can only work as well as the technologies and processes that integrate and coordinate the modules. This is where most of the complexity lies. Nearly all of today’s hot, new, technologies du jour address coordination issues in some way. And, of course, some work better than others.

I’ll address these issues in upcoming posts.