I believe complexity is a powerful weapon that when used properly can be transformational to IT and to the business.

Complexity in and of itself doesn't create cost, unless you've made a complex device to perform what a more simple device can do just as well. An example of unnecessary complexity might be combining an Ohm meter with a screw driver. You can do it. It will be more complex and it will cost more, but does the complexity actually buy you anything? Even if the Ohm meter did buy you something, you now have to worry about replacing an Ohm meter when you break the tip on the screw driver or vice versa. I would argue this is unnecessary complexity. 

On the other hand building complexity into IT solutions like VMware’s vSphere solution makes tremendous sense to me. In a traditional non-virtualized environment each of your operating systems were running just fine, and the servers generally did the job they were supposed to, so superficially you might believe that this "traditional" environment is less complex than a virtualized one. However, in many cases I believe we could successfully argue that the traditional environment was more complex, but for reasons many of us might not consider.

The following are a few thoughts on complexity in the traditional IT infrastructure environment:  

• Fewer systems per FTE, which in turn leads to more training costs, higher overhead for staffing and more complexity in your response to growth or problems in the environment.
• Lack of a common framework for working on all the systems. Lack of a framework means you're introducing complexity into how you patch the systems, perform upgrades or plan for replacement because they’re all one-offs.
• Each of your hardware platforms are unique and as such require special software or knowledge to maintain them effectively.  You could reduce this headache by building complexity into the purchasing process and attempting to stick with one vendor and maintain a minimum number of platform varieties, but you still have complexity. Inevitably you run into the application provider that says they need a specific platform and now your purchasing scheme and hardware standards are shot to hell. Worse yet, what happens with you buy another company.
• Creating failover and fast recovery for your applications and servers means buying highly complex tools that have to be added to your environment. Each of these tools is meant for specific operating systems and or hardware platforms. In many cases you would need 3 or 4 independent tools to protect one application environment.

Now think about how complexity might play in a "virtualized" IT environment in the same situations as the above examples:

• You now have a single interface into your application and server environments. There is significant complexity in the tool, but the great thing is that the operator doesn't need to know exactly how the system does a specific task s/he only needs to understand that the task is performed appropriately and safely. Your administrator can now handle anywhere from 5 - 10X the number of systems s/he could handle in the legacy environment.
• Having a single interface and infrastructure framework for your environment means that you can begin to forget what type of server you're using and focus more attention on delivering new value, reducing cost, increasing efficiency and improving application performance. Yes this virtual infrastructure is complex, but not to the operator, in fact it's the opposite. Now you've driven out complexity relative to buying hardware and determining how it should be integrated or how you need to manage its lifecycle. You've also removed the need for staff to be trained on a variety of hardware platform architectures. When a patch is released it can be tested and applied in minutes rather than days. If there’s a firmware update you can migrate machines to a different platform and apply the patch with no business interruption.
• Failover and or fast recovery using a tool like VMware’s SRM is now as simple as point and click! No longer do you need to manually manage complex strategies and processes for different tools and hardware platforms. In this case the system (virtual platform) does most of the work for you. Instead of spending hundreds of thousands or even millions on multiple unique tools to solve a single problem you now have a single fully integrated tool that solves the majority of your needs.

Another Great Complexity Example – The Network

The network is a great example of “hidden” complexity. Today the average network administrator can plug in a switch to another switch and then plug devices into the new switch and expect that in most cases the network will work. Imagine if before he could get the server to talk to the switch he had to create a new address from scratch or spell out the switch port in the server’s network interface card. The fact is networks have been hiding complexity for years, but they still have a long way to go. When you can log into a console and use your mouse pointer to drag a server into a network or resource pool and have the appropriate network security and routing policies applied, you’ll be getting close to IT nirvana. Although you might disappoint the hardcore network administrator who was hoping to spend some late nights and weekends tweaking the environment.

There's no doubt that complexity has it's issues, but I think the most important questions aren’t whether it's "complex" but whether it successfully solves a business requirement and or hides complexity under the covers. In other words “it should be so complex, that any dummy could use it”.

Many of us shy away from buying something new and complex, because it seems safer to buy the same for less. I've talked to many an IT leader who when presented with an opportunity to do things the way they always have for 50% less vs. saving only 25% and doing twice as much, have often times picked doing things the way they always have so they could "save" more. This "savings first" mentality creates significant risk for the business and the IT organization. These risks include an inability to respond quickly to business needs, staff that aren't trained for the correct technologies, and the potential need to do major rip and replace projects of people and solutions. This issue of “cost first” and “risk aversion” is a roadblock to technology adoption across the industry.

So, I guess what I'm trying to say is that there are times when you can have complexity for complexity's sake and there are other times when you can buy complexity to solve problems that you otherwise wouldn't have been able to address. In the later case the only factor that determines whether it's more "expensive" is whether or not it's the right solution and it’s implemented effectively. I'll offer one more example of booking travel in an attempt to further simplify the message. Today your travel arrangements are done using complex software, over a complex network, on computers with complex operating systems all running in a complex data center, but is all this complexity more expensive that each of use driving from place to place trying to find and schedule our next vacation? What about the savings in carbon emissions?

Finally, my answer to the question “Does Complexity Cost More” is “no, unless you’re doing something wrong”. Real cost does not have to be higher just because the system is more complex.