Strategies for Dealing With IT Complexity

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.

"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 Andre 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.

Page Break

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.

Page Break

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 fulfils 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 clamouring for their own unique variants of, say, customer information. And that adds complexity.

With the architectural groundwork established, Motorola uses modelling 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.

Page Break

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.

In ING's approach, complexity factors are fundamental to the joint business-IT decision-making process, not only alerting business to the price to be paid for its requests, but also helping IT avoid overcomplicating what it delivers.

Page Break

Third Cure: Default to Simplicity

"It's harder to do simple, but it's better to do simple," says Accenture's Modruson, because the more difficult task of simplifying the design up front results in easier implementation down the road.

In 2005, Motorola's Morrison says, she had 60 customer data models. That made application and business process integration extremely difficult. Then the business requested an accounts receivable project, and Morrison used it as a driver to simplify those 60 data models. "We established a global common customer master data model; we didn't make it optional. All projects now use it as a blueprint," she says. "The result is we now work on one customer master; we modify and maintain one, as opposed to a mountain of them. It's just a massive reduction in work and overhead, and an improvement in agility."

It's easy to end up with unnecessary complexity due to technological and business-process diversity, notes Fifth Third Bancorp CIO Raymond Dury. "Each additional technology wasn't a tipping point; it was just one more thing. But at some point you realize you've reached a tipping point where simplifying is a benefit."

"Mature companies need disciplined teams and change controls to minimize the risk [of increasing complexity]. That's why they've failed in the past; they don't look at the lifecycle," says Wal-Mart's Ford. "All of a sudden, they hit the wall."

But driving to simplicity can be tricky. It's hard to get resources to revamp older systems or to pay for the initial architectural efforts. And the work can take years. "It can't take too long; otherwise people will seek exceptions. So you need to get resources fast," Morrison warns. Some of those resources need to come from your internal savings, some in the form of business investments. Internal savings typically come from two areas: efficiencies and vendor management.

CIOs can achieve efficiencies -- and reduce IT complexity along with costs -- through a variety of complementary tactics, including disciplined data management, employing change-control techniques to their application development and integration efforts, using Six Sigma techniques for post-deployment defect management, increasing automation, deploying cost-savings technologies such as virtualization, outsourcing some technologies, "ruthlessly" standardizing (using Accenture's Modruson's adverb), consolidating duplicate technologies and retiring older systems. "When you do things rationally, you can actually cut the budget," says Special Olympics' Mendes, as he discovered when, as CIO of PBS a few years ago, he cut the interconnection asked from the federal government from $177 million to $120 million while, he says, introducing new technology that substantially improved services.

The key area to focus on internally is your data architecture, says Motorola's Morrison. "If you focus on master data -- customer, pricing, bills of materials and so on -- and get those very defined, the number of applications you have will become less of a complexity problem," she maintains. That's because much of the integration effort across applications involves managing all the point-to-point data transformations when applications interact. Having a consistent data architecture eliminates much of that effort by allowing one to use repeatable processes at the integration layer. That results in both immediate and long-term savings that can help the CIO make other efficiency and simplification investments.

Two approaches to achieving savings and simplification -- technology consolidation and retirement -- can be tricky, notes Peter Ruggerello, VP of applications development of pharmaceutical distributor AmerisourceBergen, because there are often undocumented dependencies between what you want to keep and what you want to get rid of. A classic example is that "a customer order entry system is being retired and you find that a job to receive EDI [electronic data interchange] orders was using the same subsystem to validate data received before it was passed on to a new process in the back-end order-entry systems," he says.

That's no reason to shy away from getting rid of technologies that are no longer needed, but it does require mapping dependencies -- and keeping the map updated -- so you can remove the older technologies more efficiently when the time comes, Ruggerello suggests.

Accenture spent quite a bit of effort when in 2004 it replaced 450 financial applications with a single SAP ERP instance, and migrated 277 of its 280 business applications to a single platform. More recently, the consultancy undertook the same consolidation effort with its recruiting systems, replacing 46 with one. "Today, we have a theory of one: We have just one of anything," Modruson says.

"Even though it was hard to get there, what we have today is a lot better," says Modruson. The cost of IT as a percentage of net revenue has been cut in half, he notes, with a "significant" portion coming from reduced complexity.

Paradoxically, achieving savings through consolidation isn't achieved merely by consolidating. "You can take 30 inefficient data centres and create three inefficient data centres from them," warns ING's Vincent. "What takes the most time [to do it right] is figuring out what your target is. Only with that in place can you optimize the operations," he says. It's the Goldilocks principle of determining what's just right, being just as simple as you need to be.

The easily appreciated benefits of consolidation include reducing license costs (by reducing the number of licenses you need) and personnel (by having fewer data centre managers). But these savings are finite. Once you achieve them, you're done. You can accomplish more by, for example, moving to different types of servers or adopting new approaches such as virtualization. But these require thinking first about what the future needs of your organization are likely to be and how changes to your processes might anticipate them, or at least not get in the way, Vincent says.

Savings through vendor management typically come as a result of consolidation, Fifth Third's Dury notes. The basic equation, he says, is simple: "If you'll share these efficiencies with us, you'll get more of our business." Savings -- and simplifications -- can also come from educating your vendors about your architecture, says ING's Vincent, "so they don't bring incompatible products to the table." Another way to use your vendors to reduce complexity is to challenge each one to identify two existing products that you can eliminate by buying their one, says Gartner's McDonald.

Such internal improvements cannot be undertaken just for IT's sake. The real goal remains serving business's changing needs by having a responsive, flexible technology base.

Page Break

Fourth Cure: Continuous Improvement Required

It can be tempting to try to buy your way out of complexity by outsourcing as much of your IT as you can get away with or by adopting big-ticket platforms from any one of a hundred vendors that will swear they can solve all your problems.

"We went ERP in 2000. It simplified our landscape by getting rid of legacy systems. We cleared out the old and brought in the new," recalls Anthony Bosco, CIO of engineering and facilities management firm Day & Zimmermann. Bosco believes that having a fairly closed technology system or platform encourages simplicity because it discourages the addition of single-point technologies.

However, enterprises have multiple needs, which means they will need multiple systems. And when adding technologies is necessary, you get added complexity, Bosco concedes, especially where they duplicate some of each other's processes. "It worked for a while," he adds, but the complexity started creeping back as the business's new needs required new technologies not anticipated by the ERP developers. "The ERP systems of today are the legacy of tomorrow," Bosco sums up. He's handling this conundrum by tying each platform to a specific set of business needs, such as ERP for financial management and e-commerce for online transactions. He enforces a disciplined set of links among them to prevent complexity caused by use of duplicate processes.

A seductively easy fix for complexity is to hand over your technology to someone else. That's a bad idea, says Bernard "Bud" Mathaisel, CIO of software outsourcing provider Achievo. When a company is stable, says Mathaisel, it's more efficient and costs less to manage well-designed key infrastructure, such as data centres, in-house. Outsourcing makes sense when a company is in transition, such as during a merger, or in a period of high growth, and you don't have the human or management resources available. "That's worth the premium cost," he says.

Outsourcing, unfortunately, may not reduce complexity so much as shift it, notes John Baschab, president of management services at consultancy Technisource: "Outsourcing turns a technical challenge into a management one."

And outsourcing per se won't fix overly complex subsystems. Sounding an ironic note, Ramesh Dorairaj, head of application management services at Mindtree Consulting, says that "offshoring merely arbitrages inefficiency at a lower cost."

Some organizations follow a cyclical approach to dealing with complexity. Every five years or so, they embark on a simplification effort to reset the technology base to something that can be used as a platform for future growth. In theory, this can work, especially for industries that have boom-and-bust cycles; the bust times are when you can make the investments for the next boom period. But this approach has three flaws, says Daryl Plummer, chief of research for emerging trends and process management at Gartner. One is that enterprises rarely invest when times are tight. Two is that it requires a large shift in skills and priorities that's hard for people to handle. Three is that waiting lets the problem fester, leading to workarounds by impatient users that will contribute to complexity down the road.

"Occasionally, the window for big-project change does exist -- maybe 5 percent of the time," says Mathaisel. "Take advantage of it when you can. But 95 percent of the time you're really talking about incremental change. You do what you can today and deal with the rest on a later cycle."

There's also bigger risk for large-scale retrofits embarked on during down times, warns Wal-Mart's Ford. It's precisely during the tough times that the business comes to IT for help. So counting on simplifying your technology environment then is probably not realistic.

The best approach is to make the work of simplification ongoing, says Dow's Murrell. "Look in every area to see what's redundant," he recommends. That doesn't necessarily mean doing anything to simplify the technology cans you've opened. "You may make a decision to leave the worms in there due to the cost or the delay to value," Murrell says. But you should document what could have been simplified and why you didn't make the effort, so the next time that particular can is opened it'll be easier to determine if that's the right time to get rid of the worms.

Ultimately, says TD Banknorth's Petrey, you need to reduce complexity in the legacy technology you're not retiring. "If you don't," he says ominously, "the consequences to your business will come at a point not of your choosing.

"It's not a sexy thing to do," he continues, "and the business doesn't see the value in it, but if you let it go, you'll end up with complexity and fragility." Not a good combination.

Staging simplification efforts over time is a critical strategy for success, argues ING's Vincent: "Take bite-sized, digestible chunks; otherwise, you'll choke. Replace a brick at a time, not a whole building."

Page Break

The Highest Complexity Factor: Your Job

It may seem as if the complexity burden has become too great to bear. But CIOs have been there before, says Accenture's Modruson, and not only have they survived, they've thrived: "In the 1980s, everyone stitched together networks from multiple technologies. Things have gotten better as technology complexities have collapsed."

For example, CIOs used to worry about what network technology to choose; now it's all IP-based and no longer something on which CIOs need to focus. Similarly, server technologies have collapsed into a few well-known quantities that CIOs can rely on. "These are standard platforms I don't have to worry about," says Special Olympics' Mendes. "I can target business value instead."

"A decade ago, we moved to new technologies quickly because the old ones weren't so good. But now we can be more measured because what is now the old stuff does work," Modruson says.

What's changed is that the complexity has migrated. As parts of the IT environment became standardized, such as networks, other issues replaced it, such as securing porous enterprise boundaries and managing massive data sets in a world where budgeting for downtime for maintenance and backup is simply not acceptable to the business. And emerging process-management approaches such as service-oriented architecture that promise to reduce the complexity of application integration and development introduce complexities elsewhere, such as in change management and testing, notes TD Banknorth's Petrey.

A more fundamental shift has been away from a focus on infrastructure technologies to technologies that deliver business processes. The IT infrastructure continues to pose its own complexity challenges, but it's now just table stakes -- part of the CIO job -- and why business needs CIOs who are both business- and process-oriented.

CIOs must play at several levels simultaneously, addressing both business and IT needs, keeping the systems running while ensuring that their technology strategy supports business operations, promotes innovation and provides competitive advantage in a changing environment, says Michael Farber, a vice president at consultancy Booz Allen Hamilton. "It's a 3-D chess board," he notes.

At most companies, "the CIO ends up at the tail end of things," stuck with complexities caused by others, says Dave Zink, client executive at consultancy EquaTerra and former CIO of CBS. "But when companies have elevated the CIO to the right level, they are less likely to have complexity."

Assuming they have a CIO who can play a mean game of 3-D chess.