point
Menu
Magazines
Browse by year:
Systems Complexity Quandary
V. Anantakrishnan
Tuesday, September 30, 2003
IN A JANUARY 2003 SURVEY OF ABOUT 500 IT executives polled by the Ziff Davis publications, almost one in two agreed on one thing-that their IT systems architecture is more complex than necessary.

Managing applications at this high level of complexity cost them an average of 29 percent of their IT budgets. Is your enterprise systems architecture too complex? Place the drawing of a Rube Goldberg invention on one side, and your systems architecture diagram next to it. If you notice a striking similarity, be afraid, very afraid!

System complexity has a way of sneaking up into your architecture very innocently, and before you know, you would be lording over islands of automation that have nothing in common with each other.

Defining Complexity
Defining complexity may be harder than it seems, especially given the fact that no one deliberately introduces complexity into a system. Like fat buildup that clogs arteries, system complexity just builds up over time.

Complexity is when your enterprise has sixteen different database management systems serving a dozen-odd application. It is compounded when these applications are accessed via two dozen user-interfaces including four different versions of Windows, Macs, and PDAs. It gets further complicated when these communicate using various protocols. The worst part of it all is that all of these could be serving a single business process.

Examples of such complex systems abound. Ahead of simplifying and integrating their Human Resources systems, Novell's information support services team identified 19 different applications just to serve their hiring process. Shell Oil Co. had 85 different ERP systems, each implementation customized to fit a specific business requirement. Before paring down considerably, IBM had 100 different desktop configurations, 55 data centers, and 31 different network service providers. In all these cases, it didn't take long for mind-numbing complexity to bog down efficiency and to negate any effort by the companies to achieve productivity gains.

Companies seldom start out on a project with the intention of creating a complex architecture. However, over time, as process modifications are implemented into the system by creating stopgap solutions that circumvent architectural principles, islands of incompatible applications and heterogeneous databases begin to proliferate. The end result is a potpourri of protocols, applications, and databases that contribute to redundancy without adding real value. Complexity, not to mention chaos, is usually the ultimate result of such haphazard and shortsighted growth.

Cost of Complexity
The obvious cost of complexity is the heavy strain it places on the IT budget. In the past couple of years, Accenture has observed that some companies spend around 70 to 80 percent of their IT budgets on “lights-on” systems alone. This leaves precious little to spend on technology projects that implement new business initiatives which could help the company expand into new and more lucrative markets, or to adapt to ever-changing business trends.

Apart from the financial ramifications, a host of other drawbacks only serve to highlight the counter-productive nature of complexity.

Besides adding millions to annual operating costs, system complexity bogs down efficiency. It defeats all that is to be gained by standardization. It hinders scalability. It inhibits flexibility and the organization's ability to quickly react to new business requirements, which ultimately adversely affects time to market.

As market conditions change, if IT systems do not support the business' need to react with agility in introducing new products, then it stands the risk of not being viewed as an enabler (hence an ally) of business.


The Path to Simplicity
Eliminating complexity isn't necessarily 'dumbing down' the enterprise architecture. It simply means system optimization and standardization at an enterprise level, in an effort to arrive at a streamlined architecture that is robust, scalable, and easily manageable. It means building complex solutions using simple components.

Albert Einstein is known to have remarked “Everything should be made as simple as possible, but not simpler.” While there is no standard blueprint that systems architects can follow in order to simplify complex architectures, adhering to a few thumb rules while designing new systems could go a long way in eliminating unnecessary complexity.

• Standardize - Never miss an opportunity to design and build around a few set standards, be it database management systems, operating systems, or communication protocols. Watch out for 'quick-hit' solutions built around non-standard components. They may come back to haunt you at the most inopportune moment.

• Integrate - Take time to view how a proposed system enhancement affects other downstream and upstream systems. The most sophisticated solution within a single subsystem may not be the most optimum solution when the entire enterprise architecture is taken into consideration.

• Minimize - Strip away anything and everything that does not add real value to the solution. If a notoriously inefficient piece of software is employed to deliver a trivial piece of business functionality, it is going to make the entire system look bad.

• Prioritize - Prioritize discretionary spending (and infrastructure spending) with an eye on their impact on future system scalability and adaptability. Don't contribute to the proliferation of highly disparate systems that do not integrate well with existing infrastructure.

• Leverage - Capitalize on what is already in place. If it is not a better mousetrap, don't buy it. Reuse and reduce.

• Educate - Preach (and practice) building systems, even complex systems, with homogeneous components.
Once the idea takes root, it could turn into a self-perpetuating discipline.

The Challenges
As long as the temptation exists to indiscriminately expand into new technology solutions (based on unproven claims from the vendor), the battle against complexity will never be over. The challenges are twofold. In designing new systems, the challenge is to not view the architecture in vacuum. View it in the context of the entire enterprise architecture. On the other hand, in retrofitting existing systems the challenge is to not give in to implementing quick and easy fixes that may only be temporary solutions.

From Here to Utility
The disadvantages that come with system complexity far outweigh any of its advantages. “Custom-built” may be a swank adjective when describing cars and homes, but when it comes to IT systems architectures, standardization rules. In the long run, server consolidation and system standardization are but two pit stops in the industry's march toward 'Utility Computing.' With virtually every major technology vendor gearing up to offer solutions for on-demand computing, it's time for companies to simplify their architecture if they intend to capitalize on that trend. Otherwise, their IT systems will simply become an albatross around their neck.

Twitter
Share on LinkedIn
facebook