Is more intelligence in the network a good thing?

Opinion
Dec 11, 20073 mins

* The need for advanced troubleshooting skills

IT organizations are constantly being bombarded by vendors trying to convince them that networks need to become more intelligent. We believe that it certainly can make sense to put more intelligence in the network but we also believe that as is so often the case, the devil is in the details. In the next two newsletters we will highlight how one IT organization approaches the task of adding intelligence to the network.

To put this into perspective, at the October Interop conference in New York Jim moderated a panel entitled, “Adding More Intelligence to the Network.” The premise of the panel was that over the last few years, a wide array of functionality has been added to the network including firewalls, load balancers, as well as devices that perform compression, caching and TCP optimization. The panelists were then asked to answer questions such as how much intelligence belongs in the network and what are the technical and organizational implications of putting more intelligence in the network.

Pete Hughes, manager with KPMG’s Information Technology Services organization presented an enterprise perspective on this topic. In his presentation, Hughes described an IT environment of increasing complexity where clear trade-offs between business value and operational complexity could be assessed and advanced troubleshooting skills were becoming increasingly important to support the infrastructure within the enterprise. This caught our interest because we have written in the past about the role of troubleshooting in IT organizations.

After the conference in New York we asked Hughes two simple questions: Why was he drawn to this topic and how should the decision to add intelligence to the network be made?

Hughes explained, “The debate about what intelligence to add to the network is not new and I have spent a large part of my career involved in just such discussions. When I joined the telephone company as a young engineer over 20 years ago, some people were still troubled by the FCC’s Carterphone decision from almost 20 years earlier that first allowed customers to attach devices to the network that were not owned by the telephone company. The debate between PBXs (with intelligence located in the enterprise) vs. Centrex (with the intelligence located in the carrier’s network) continued. Later in the 1990s when I represented the telephone companies before state and federal regulators, questions as to what features (intelligence in the network) the telephone companies should be allowed to provide, how they could be competitive with enterprise based solutions and how to bring regulation in line with market and technology forces created reams of filings before various regulatory agencies.”

Hughes added: “As both a consultant to external companies and a manager focused on internal enterprise needs, I have seen the balance that needs to be struck between deploying new technologies that can provide significant business value vs. the challenges associated with supporting this increasingly complex infrastructure. The list of network capabilities is constantly increasing and along with variations in location of this functionality (e.g., client vs. network, enterprise vs. carrier, consolidation vs. distribution) and the complexities the interactions between all of these capabilities entails has produced an environment rich in opportunities for confusion as well as extensive and advanced troubleshooting. But anyone who has any sense of a historical perspective can also see the immense value that has been created for our businesses. Their ability to deliver to multiple customer segments in a rapid fashion has clearly been enabled by these technological advances.”

In the next newsletter, Hughes continues his discussion on the topic of adding intelligence to an enterprise network.

Jim has a broad background in the IT industry. This includes serving as a software engineer, an engineering manager for high-speed data services for a major network service provider, a product manager for network hardware, a network manager at two Fortune 500 companies, and the principal of a consulting organization. In addition, Jim has created software tools for designing customer networks for a major network service provider and directed and performed market research at a major industry analyst firm. Jim’s current interests include both cloud networking and application and service delivery. Jim has a Ph.D. in Mathematics from Boston University.

More from this author