Bringing two networks together is not always a simple matter. There are many ways that can go wrong technically and most of these can be traced back to applications. But there is also the non-technical side where projects can go seriously awry. The cultural side of a network merger, for instance, can play havoc and the user community can quite easily get up in arms about relatively minor matters if not dealt with correctly.
“Merging two networks often comes about from merging two companies, IT teams and network tools,” said Stephen Brown, product marketing manager at Network Instruments. “In this case, it’s important to think of the bigger picture.”
But even it is two departments being integrated, he believes it is still more than bringing together applications and networks. Before you begin to work on the networks, then, it is important to look at the cultures of IT teams, their approaches to network management and other related issues.
“Company cultures can be impacted by everything from management styles to industry and company size,” said Brown. “If you’re merging two cultures, this can be a large point of friction and a significant obstacle that impedes success.”
Cultures can also impact the applications used — whether open-source or proprietary software. When you merge a predominantly Windows-based network with a Linux network, for instance, you have a lot of interesting cultural decisions ahead. Do you migrate towards one OS or the other? Either way, you’ll have some trouble on your hands. Windows and Linux users, after all, are often quite different camps. If the majority is already on Windows, it’s probably safest to go with that. But make sure you take steps to appease the Linux side and provide an avenue to address complaints. By the same token, if cost cutting requires a move to Linux, the Windows camp needs to be educated on the new OS.
The bottom line in all this is keeping users informed. Regardless of the type of network, OS or application, Brown said you have to pay close attention to the effect the network merger will have on the user. During the merger will applications or services be down at all? Don’t let the users find out about it when they come to work in the morning and can’t access their data. Give them plenty of warning, and a voice in the discussions about how the project will be rolled out.
If application changes are a factor, be sure to bring this up early in the proceedings. Regardless of how much of a nightmare that aging COBOL system may be for the data center, the users may love it and may not have much tolerance for change. Training is a good way to overcome this inertia.
“If you are going to be eliminating any applications or rolling out new applications during the network integration, this may require user education,” said Brown.
However, the need for training will probably slow things down during implementation. Thus there is a balancing act between the demands of rapid project rollout and user receptiveness to change. The more training and user involvement, the slower the project will go — at least initially. But once buy in has been achieved, it is probably quicker in the long run than trying to steamroll through a big change over the top of internal discontent and revolt.
Applications Must Be the Focus
While networking personnel may like to think that the network is the essential element in all IT matters, it is important to realize that like an OS, it is simply a vehicle for applications. Therefore, any tinkering with the network has to be done in the knowledge of how it will affect the related applications.
“Map out key applications and services, and then discuss which are the most efficient to maintain and where can you save money by eliminating redundant applications,” said Brown.
While merging networks, he said, it is also a good time to look at a potential third option. Perhaps rather than using a self-hosted application, it might be time to consider a cloud-based option. For example, if the companies involved are already considering merging two CRM databases, it might also be a good time to consider a cloud-based application such as SalesForce.
“Such moves could save significant time and money by reducing demand for internal resources and the time network teams spend troubleshooting internally-hosted applications,” said Brown.
