Strategies for Dealing With IT Complexity

Every innovation, every business process improvement, comes with an IT complexity tax that must be paid by CIOs in time, money and sweat. Here are strategies to mitigate the increasing complexity of IT as it enables new business.

It’s called Moore’s Flaw, the flip side of the famous axiom that has driven the furious pace of IT innovation for several decades.

Moore’s Law (in one of its many formulations) states that computing capability increases 1 percent per week. Moore’s Flaw posits that keeping up with this flood tide of innovation quickly becomes too difficult (and too costly) for anyone to manage.

More on CIO.com

Consumer Tech: The New Complexity Add

Reduce IT Complexity, Costs with Consolidation

Managing IT Complexity: Survival Techniques

“IT complexity acts as a significant tax on IT value,” says Bob Zukis, a partner at PricewaterhouseCoopers. It’s those organizations that “have managed complexity out of their environments that are reaping the value from their IT spends.”

Even more important, businesses that successfully address complexity can be more agile because their systems don’t get in the way of business process change.

“When you reduce complexity, you increase your ability to implement new solutions,” says André Mendes, CIO of the Special Olympics.

“Complexity leads to brittleness and high costs,” notes Frank Modruson, CIO of Accenture. “But if you get your technology cleaner, you can serve the business more easily.”

Today, all CIOs are standing in the path of a fire hose spewing complexity.

And many are getting soaked.

The Complexity Add

Within IT, factors that increase complexity include outsourcing management, the adoption of Web and consumer technologies, support for mobile workforces, developing and managing technology architectures and governance for those workforces, and ensuring security in a distributed environment.

Outside of IT’s direct control, complexity is increased by the requirements of compliance, the need to support global business, and the speed and depth of access to information demanded by your customers and your partners.

CIOs can—with difficulty—handle these challenges individually, one at a time. But in the real world CIOs face many, if not all, of these challenges, all at once, over and over. “That’s why you need a strategy to keep complexity out of the environment, not just have knee-jerk responses,” Modruson says.

The challenge of complexity is exacerbated by the fact that many organizations have technology systems that have been built up over time or acquired through acquisitions or complicated by many waves of vendor consolidation. For these companies, moving forward requires an almost archaeological effort to unearth, understand and work with all these layers of sedimentary technology. This digging causes the delays that frustrate business executives and CIOs alike whenever change or progress is needed, says Mark McDonald, group vice president for Gartner executive programs.

Worse, fundamental changes in business are making the complexity challenges harder than ever. “I don’t see an end to complexity. Technology continues to change, and business demand for services continues to increase,” says Wal-Mart CIO Rollin Ford. This means that even CIOs who are good at managing complexity can never, ever rest. And those who are not good at it are at risk of allowing their organizations to fall behind.

Some CIOs have figured out ways to escape the complexity trap. They reduce complexity where possible; they live with what remains; they still invest in new technologies that can lead to business success. But there’s no silver bullet. You can’t buy simplicity. And you can’t hand off the problem to a service provider. No one lives in the complexity space; no one has a packaged solution to the complexity problem. The truth is that you need a strategy that reduces complexity, and you need the tactical ability to implement that strategy up and down your organization.

Although there’s no single formula that will work for everyone, IT leaders and consultants have identified four broad principles for reducing complexity:

First, make process central to your IT organization’s approach to technology.

Second, you need superior governance of both the technology infrastructure and the business-IT relationship.

Third, everything you do must have simplicity as the default expectation.

Fourth, your efforts must be ongoing. Complexity is not something you get rid of once and for all. It’s a battle you wage every day.

First Cure: Process-Driven Architecture

An architectural approach is essential to managing complexity, says Motorola CIO Patty Morrison, and you need one mapped to business objectives.

“You very, very much need to have an end-state architecture in place—a description of where you’re headed,” she says. That architecture cannot simply be for the IT infrastructure—the network, the data flow to and from the ERP systems, the security checkpoints, the application monitors, and so on. IT-oriented architectures tend not to take into account the flexibility needed to support changing business processes. Rather, Morrison says, the CIO’s architecture has to be driven first by key business processes.

Imagine what a failure a plane’s design would be if its creators didn’t take into account the fact that different customers may have different uses for the planes—some desiring multiple classes, some looking for different cargo-passenger ratios, some serving long-haul destinations and others short-haul. Ignoring those factors would result in a plane that flew but couldn’t adapt to its customers’ business needs. The seats might be movable but not the lighting—a seemingly minor detail, but one that might prevent airlines from configuring the seating to differentiate between first class and coach. In the same way, a business with a technology architecture that isn’t created in service of current and anticipated business needs will be limited in what it can do. Change will require expensive retrofitting of technology to handle what the architecture hasn’t anticipated.

At Motorola, Morrison ensures that her architecture accommodates and anticipates business goals by using business process management (BPM) principles and an enterprise reference architecture to define a common language for business and IT. The enterprise reference architecture is a broad set of blueprints that shows the business, operations and systems layers.

This approach also ensures that business-IT conversations don’t devolve into throwing requirements over the wall, an approach that usually adds complexity in two ways. One is that IT fulfills the business’s requirements outside the overall architecture, often leading to multiple ways of doing the same thing. These processes must then be reconciled, which frequently requires custom interfaces for other systems that no one (certainly not the business) realized would be affected. The other complexity add comes from IT’s interpretation of those over-the-wall requirements. It usually misses something, leading to multiple rounds of rework and patches that make the final system ever more complex. By contrast, the architecture-based approach at Motorola “creates a rich, interactive, high-quality conversation around real solutions, not abstracted requirements,” says Morrison.

But, she acknowledges, it’s not easy to achieve this state. It requires that business units think beyond their immediate needs and work with other units toward a common approach.

“The hardest thing for IT to do is to get business units to agree on a common way to do something,” says Morrison. That takes maturity in working across silos. Without it, business units end up clamoring for their own unique variants of, say, customer information. And that adds complexity.

With the architectural groundwork established, Motorola uses modeling tools first to design the desired business processes and then to simulate and test various technological approaches to delivering them. For example, Motorola used this approach to reduce part qualification cycle time—a process of evaluating which suppliers’ parts meet the quality, cost and other requirements for planned Motorola products—from 28 weeks to seven weeks in 2006 while improving visibility and controls over the process.

Having an enterprise reference architecture doesn’t mean an organization has an immutable plan. Because both business and technologies change, you can’t always have a multiyear plan for a specific result, says Mack Murrell, vice president of IS at Dow Chemical. For example, you shouldn’t develop a service technician scheduling system that depends on a specific wireless network, or is limited to servicing only the kinds of products you currently offer. Instead, “you want a set of options within your target,” he says.

For example, you would ensure the application is network-agnostic and supports both always-on connections and intermittent connections. You would not hard-code product specifications but would instead rely on a metadata approach that supports a range of possible product characteristics, and could support a variety of information types (say, video and PDF) even if they’re not needed today.

That requires an architecture that anticipates and enables change. To do this, Dow deconstructs its enterprise architecture into discrete subsets (such as purchasing, plant maintenance and pricing) and layers (such as business system, technical and products). Dow uses structured enterprise architecture methods and service-oriented architecture approaches to manage the subsets and the changing relationships among them within the overall architecture.

Dow has a group of IT and business staff whose job is to track these subsets and make sure they conform to the overall architecture—or adapt the architecture if that’s what’s needed.

Second Cure: Good Governance

Ironically, as Accenture CIO Modruson notes, “Complex things tend to be easier to design and deploy.” Many enterprises justify Rube Goldberg-type systems by saying they need them now and promising themselves that they’ll clean up the technology later. But “later never happens,” Modruson says dolefully. Strong central governance can prevent that “let the future worry about it” mentality. “Organizations that have effective IT governance by and large have lower levels of IT complexity,” notes Gartner’s McDonald.

That’s why CIOs and their business partners must have strong governance “about what really impacts our customer, with business a key part of that decision structure,” says Michael Vincent, CIO of global financial services provider ING.

Having that fundamental business understanding—and a common view of it in both business and technology leaderships—provides the CIO with the ability to make decisions that prevent unnecessary complexity and also enables him to more accurately assess the costs and benefits of any desired technology. It enables him, Vincent says, to figure in the impact of complexity not just on deployment but also on maintenance and integration, which consumes about 70 percent of IT’s budget. It also allows him to gauge how a technology will affect future changes to both the business and the IT infrastructure. “This customer focus helps show which requests are too complex for the value provided,” says Vincent.

Of course, CIOs are always under pressure to respond quickly to business’s urgent priorities, and an IT leader will inevitably need to make some complexity trade-offs for truly critical demands. But you can’t let that pressure subvert the principles of good governance.

“If we find ourselves living in a ‘get it done’ mode for extended periods, the red flag goes up,” says Wal-Mart’s Ford. By having a seat at the executive committee table, Ford can make sure the red flag is not ignored.

This joint IT-business approach to decision making should also extend to decisions on what technology products and services are purchased—even for technologies that the CIO is not directly responsible for managing, says John Petrey, CIO of financial services provider TD Banknorth.

“In some cases, a business unit might go out and contract for services such as Salesforce.com. That starts out as a silo with no messaging or integration with existing apps. But later, that messaging or integration becomes desirable and then the complexity factor for IT rises,” Petrey says. What seemed like an isolated technology ends up needing to connect to core systems, requiring retrofit work.

The CIO’s involvement in these outside-of-IT decisions can help ensure conformity to standards and architectures, says Petrey, reducing current or future complexity issues that could affect the business units, not just IT. “You want to look for the best fit to business needs and minimum complexity through the governance process,” he says.

When evaluating the complexity implications of any business or IT effort, CIOs will need to accept, in some cases, more complexity than is ideal because of the business benefit, says Vincent. For example, ING is buying various transaction systems in its fast-growing Asian operations to handle a surge in demand. And although ING is re-architecting some of its global systems for more common processes and technology, the Asia business can’t grow if it has to mark time while that effort is completed. Vincent knows he’ll need to rework the Asia operations eventually, but that will cost ING less than the revenues it might miss by waiting.

Understanding this trade-off up front ensures that the price of the complexity-add is apparent early on, preparing the ground for later investments that will be needed to clean things up.

1 2 Page 1
NEW! Download the State of the CIO 2017 report