The Art and Science of Network Consolidation

Various strategies for consolidating data centers, and even certain types of distributed processing systems, have been thoroughly tried, tested, and documented. But when it comes to integrating networks, particularly heterogeneous networks, discussions regarding techniques and best practices for managing the consolidation process have been limited.

Solid asset and people management processes make it relatively simple to establish the cost of two separate and different network environments. And, given necessary and accurate data, one can estimate the personnel, equipment, and transport requirements of operating a combined, homogeneous network on an ongoing basis.

However, the process of executing the transition from two networks to one consolidated system raises some thorny questions. How much should the integration cost? How long should it take? How can the two businesses served by the two networks minimize disruption during the consolidation? What criteria should be applied to determining which staff members and skill sets remain?

Approaches to Consolidation

There are three basic approaches to consolidation.

Maintain diverse environments while consolidating personnel. Under this approach, headcount is usually slightly reduced, particularly at the trouble desk. However, transport costs either remain constant or increase slightly due to topographical change, while equipment costs are unaffected. Meanwhile, a contentious management fray ensues over which network is the “right” one to support business growth. Both networks also compete for resources and the debate takes on religious overtones as each side views the outcome as a matter of survival.

Select a single pre-existing network and expand it to provide networking services for the consolidated users. This approach is most commonly seen in consolidations of financial institutions, and is the most disruptive to both end users and personnel. The debate over which network architecture or processes to adapt is rarely based on merit, and is usually won by the acquiring party in the consolidation. As a result, a sub-optimal network is likely to result.

Chaos and Paralysis

Unfortunately, when it comes to network consolidation, these two most common practices tend to be the worst practices – and even some very large and otherwise sagacious businesses are guilty of applying them.

In many instances, companies justify an acquisition or internal integration based upon a “projected” (MBA speak for “I guess”) savings, to be achieved in year one, with little or no prior planning. The two operating groups are thrown together in the spirit of, “May the best man win.”

The result is chaos, organizational upheaval, or paralysis. Users experience a sudden inflexibility coupled with a decline in service quality. One large, US financial institution suffered a very significant loss of market share and of capital following a poorly planned consolidation.

A Third Way

There is a third approach to consolidation that, generally speaking, yields optimal results.

Hybridization involves a conscious review of architecture, products, and processes, often mediated by a neutral third party with both technical knowledge and practical experience. Under this approach, a going-forward, strategically optimum architecture is selected, along with best practices employed by both parties. Importantly, the review can result in the selection of a third architecture or vendor – in other words, an approach different from the one currently employed by either party. For example, the consolidation process may be an appropriate time to convert two different private line architectures to a common VPN architecture.

A successful hybridization must be preceded by a careful unit cost analysis of each of the existing environments, as well as any third architecture that may be considered.

The best practices to be employed in the operation of the target environment must be established. These can vary depending on business requirements and the architecture deployed. For example, the type of rigid change control required by an SNA or many SNA-derivative architectures is inappropriate for an IP network and can be downright counterproductive. On the other hand, the security management challenge presented by an IP network – particularly one which interfaces to the public Ethernet – is very different from that posed by more traditional, SNA-derivative networks. Once the appropriate architecture is selected, cost targets based on detailed cost data of actual operation of that architecture must be defined.

The next step is to develop and cost an appropriate and detailed evolution plan – one that considers contingencies and potential trouble areas. The plan must specifically identify all of the application dependencies involved – since some applications are highly transport sensitive – and define a back-down plan for each program step. For example, the evolution from private line or high capacity frame relay to an IPVPN or a wireless network may be incompatible with the latency requirements of some applications, and will result not only in user dissatisfaction but in buffer overflows and application time-outs, often causing the application to fail. Thus, even though small-scale testing of applications may have preceded network conversion, a plan must be in place for backing down from any conversion step and returning to the prior configuration should the system perform poorly under real-life loading conditions.

After this planning process (of 30 to 90 days) has been accomplished, an organization can with reasonable certainty develop a financial scenario for a successful transition – a transition in which delays, cost overruns, and service disruptions are minimized, and a foundation is established to provide effective and efficient support of evolving business requirements.

Carl Pitasi is a Compass senior consultant specializing in network and telecom issues. He is based in Oak Brook, IL.