Guiding principles of network centralization and decentralization

At large companies in particular, it seems as if every couple of years, management decides to centralize everything that is decentralized and vice versa. Smaller organizations encounter similar changes driven by mergers or opening of new campuses or field offices.

More on network design Click here to download a PDF version of this chapter. For more information on this topic, see our FAQ guide on designing networks for speed and reliability.

In this section, we discuss guiding principles you should consider before making such broad changes.We then discuss some services that are good candidates for [network] centralization and decentralization.

Guiding Principles

There are several guiding principles related to centralization and decentralization. They are similar to what anyone making large, structural changes should consider.

• Problem-Solving: Know what specific problem you are trying to solve. Clearly define what problem you are trying to fix. "Reliability is inconsistent because each division has different brands of hardware." "Services break when network connections to sales offices are down." Again, write down the specific problem or problems and communicate these to your team. Use this list as a reality check later in the project to make sure that you haven't lost sight of the goal. If you are not solving a specific problem, or responding to a direct management request, stop right here. Why are you about to make these changes? Are you sure this is a real priority?
• Motivation: Understand your motivation for making the change. Maybe you are seeking to save money, increase speed or become more flexible. Maybe your reasons are political: You are protecting your empire or your boss, making your group look good, or putting someone's personal business philosophy into action. Maybe you are doing it simply to make your own life easier; that's valid too. Write down your motivation and remind yourself of it from time to time to verify that you haven't strayed.
• Experience Counts: Use your best judgment. Sometimes, you must use experience and a hunch rather than specific scientific measurements. For example, we've found that when centralizing email servers, our experience has developed these rules of thumb: Small companies—five departments with 100 people—tend to need one email server. Larger companies can survive with an email server per thousands of people, especially if there is one large headquarters and many smaller sales offices. When the company grows to the point of having more than one site, each site tends to require its own email server but is unlikely to require its own Internet gateway. Extremely large or geographically diverse companies start to require multiple Internet gateways at different locations.
• Involvement: Listen to the customers' concerns. Consult with customers to understand their expectations: Retain the good aspects and fix the bad ones. Focus on the qualities that they mention, not the implementation. People might say that they like the fact that "Karen was always right there when we needed new desktop PCs installed." That is an implementation. The new system might not include on-site personnel. What should be retained is that the new service has to be responsive—as responsive as having Karen standing right there. That may mean the use of overnight delivery services or preconfigured and "ready to eat" systems1 stashed in the building, or whatever it takes to meet that expectation. Alternatively, you must do expectation setting if the new system is not going to deliver on old expectations. Maybe people will have to plan ahead and ask for workstations a day in advance.
• Be Realistic: Be circumspect about unrealistic promises. You should thoroughly investigate any claims that you will save money by decentralizing, add flexibility by centralization, or have an entirely new system without pain: The opposite is usually the case. If a vendor promises that a new product will perform miracles but requires you to centralize (or decentralize) how something is currently organized, maybe the benefits come from the organizational change, not the product!
• Balance: Centralize as much as makes sense for today, with an eye toward the future. You must find the balance between centralization and decentralization. There are time considerations: Building the perfect system will take forever. You must set realistic goals yet keep an eye to future needs. For example, in 6 months, the new system will be complete and then will be expected to process a million widgets per day. However, a different architecture will be required to process 2 million widgets per day, the rate that will be needed a year later, and will require considerably more development time. You must balance the advantage of having a new system in 6 months—with the problem of needing to start building the next-generation system immediately—versus the advantage of waiting longer for a system that will not need to be replaced so soon.
• Access: The more centralized something is, the more likely it is that some customers will need a special feature or some kind of customization. An old business proverb is: "All of our customers are the same: They each have unique requirements." One size never fits all. You can't do a reasonable job of centralizing without being flexible; you'll doom the project if you try. Instead, look for a small number of models. Some customers require autonomy. Some may require performing their own updates, which means creating a system of access control so that customers can modify their own segments without affecting others.
• No Pressure: It's like rolling out any new service. Although more emotional impact may be involved than with other changes, both centralization and decentralization projects have issues similar to building a new service. That said, new services require careful coordination, planning, and understanding of customer needs to succeed.
• 110 Percent: You have only one chance to make a good first impression. A new system is never trusted until proven a success, and the first experience with the new system will set the mood for all future customer interactions. Get it right the first time, even if it means spending more money up front or taking extra time for testing. Choose test customers carefully, making sure they trust you to fix any bugs found while testing, and won't gossip about it at the coffee machine. Provide superior service the first month, and people will forgive later mistakes. Mess up right at the start, and rebuilding a reputation is nearly impossible.
• Veto Power: Listen to the customers, but remember that management has the control. The organizational structure can influence the level of centralization that is appropriate or possible. The largest impediment to centralization often is management decisions or politics. Lack of trust makes it difficult to centralize. If the SA [system administration] team has not proved itself, management may be unwilling to support the large change. Management may not be willing to fund the changes, which usually indicates that the change is not important to them. For example, if the company hasn't funded a central infrastructure group, SAs will end up decentralized. It may be better to have a central infrastructure group; lacking management support, however, the fallback is to have each group make the best subinfrastructure it can—ideally, coordinating formally or informally to set standards, purchase in bulk, and so on. Either way, the end goal is to provide excellent service to your customers.

Network centralization and decentralization
Introduction
The basics
Candidates for centralization
Candidates for decentralization
The icing
Conclusion/exercises

Reproduced from the Addison-Wesley Professional book The Practice of System and Network Administration, 2nd Edition, by Thomas A. Limoncelli, Christina J. Hogan and Strata R. Chalup. ISBN 978-0321492661. Copyright 2007, Addison-Wesley Professional. Reproduced by permission of Pearson Education Inc., 800 East 96th St., Indianapolis, IN 46240. Written permission from Pearson Education Inc. is required for all other uses.