Toward a Definition

By Terry Kirkpatrick  |  Posted 02-01-2003 Print Email

Toward a Definition

What is complexity? It has many strands, some technical, some organizational. On one level it is the sheer number and variety of devices and people using them. Consider the financial services industry: In 1996, a major bank's 30,000 ATM machines might have been considered a really large online environment, says IBM's Ganek. "Six years later, big banks have Internet services accessible by anybody in the world," he says. "They have 10 million, 20 million, 100 million users. At first, ATMs all looked alike and had a limited set of functions. Today these banks' networks are accessed by notebook computers, desktops, eight different versions of Windows, Macs, PDAs, smart cards. That's a much more complex environment to support. And the scale: We've got customers that have 30,000 servers—more servers today than they had PCs six years ago."

Yet it is more than the number of boxes that proliferated as IT moved out of the glass house. "The problem is the number of point-to-point connections between systems," says André LeClerc, a software developer and IT architecture consultant at the Cutter Consortium. "How many times does a large enterprise have to interface with its legacy systems? That's the measure of complexity. Take an order-processing system. How many groups in the company have to register orders? How many systems do they go through to process an order? And then, when you expose that to the Internet, how many touch points are there from customer to information? There's been logarithmic growth in these connections."

Complexity lurks in the layers of heterogeneous platforms and applications that came with client/server networks and Internet computing. "You have the network layer, which involves your WAN, LAN and PCs," says Dick LeFave, CIO of Nextel Communications Inc., the wireless phone company. "You've got the middleware layer, where you're handling a variety of protocols. You've got the application layer and the database layer." All these layers must work with each other seamlessly to enable seemingly routine processes. "We're talking about technology layers that are five to 10 times more complex than they were 10 years ago."

Moreover, islands of expertise have grown up in IT shops around each of those layers. Back in 1997, financial services giant Wachovia Corp., with $5.3 billion in revenues at the time, had a problem with its new browser application for corporate customer access. Chris Edden, then a senior vice president and group manager of commercial services in the IT department, quickly put together a team of experts to fix it. Edden gathered his troops in a windowless room in the bank's operations center in Winston-Salem, N.C. Among the dozen people were experts in applications, telephony, security, mainframes, desktops, middleware, databases and computer operations. After three hours and as many pots of coffee, they isolated the problem: a piece of transaction software had failed. It took just 15 minutes to fix.

What the incident highlighted for Edden is that each IT discipline tries to maximize its contribution by offering the most sophisticated solution, regardless of the impact on everything else. The CIO has to see the big picture and manage all these disciplines as a unified service. "The trick for the CIO is, how do you take these centers of excellence and associate them to create a solution?" Edden says. "It wasn't always an issue, but the organization is a much more complex system now."

Perhaps the most useful definition comes from Bob Reinhold, vice president and head of Americas Technology Consulting Services for Cap Gemini Ernst & Young: "I see complexity as the non-value-added redundancy across all the dimensions of your applications or infrastructure or data store. Having multiple ways of delivering a service without a good reason for them introduces a complexity that doesn't add value to your organization." Reinhold is careful to distinguish between good and bad redundancy—between redundancy that might assure a zero-tolerance transaction system, for instance, or necessary business continuity. As for the rest, "the fact that you have multiple hammers doesn't necessarily mean you're redundant. And the fact that you've got 12 hammers doesn't mean you are overly complex. But if you have seven of the same kind, you might be overly complex." And each of those hammers costs money and time to maintain.



 

Submit a Comment

Loading Comments...
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date