Best candidates for network decentralization

Fault tolerance. The duplication of effort that happens with decentralization can remove single points of failure. A company with growing field offices required all employees to read email off servers located in the headquarters. There were numerous complaints that during network outages, people couldn't read or even compose email, because composition required access to directory servers that were also at the headquarters. Divisions in other time zones were particularly upset that maintenance times at the headquarters were their prime working hours. The motivation was to increase reliability, in particular access during outages. The problem was that people couldn't use email when WAN links were down. The solution was to install local LDAP caches and email servers in each of the major locations. (It was convenient and effective to also use this host for DNS, authentication, and other services.) Although mail would not be transmitted site to site during an outage, customers could access their email store, local email could be delivered, and messages that needed to be relayed to other sites would transparently queue until the WAN link recovered. This could have been a management disaster if each site was expected to have the expertise required to configure and maintain such systems or if different sites created different standards. Instead, it was a big success because management was centralized. Each site received preconfigured hardware and software that simply needed to be plugged in. Updates were done via a centralized system. Even backups could be performed remotely, if required.

Customization. Sometimes, certain customer groups have a business requirement to be on the bleeding edge of technology, whereas others require stability. A research group required early access to technology, usually before it was approved by corporate infrastructure standards committees. The motivation was largely political because the group maintained a certain status by being ahead of others within the company, as well as in the industry. There was also business motivation: The group's projects were far-reaching and futuristic, and the group needed to "live in the future" if it was going to build systems that would work well in the networks of the future. The problem was that the group was being prevented from deviating from corporate standards. The solution was to establish a group-specific SA team. The team members participated in the committees that created the corporate standards and were able to provide valuable feedback because they had experience with technologies that the remainder of the committee was just considering. Providing this advice also maintained the groups elite status. Their participation also guaranteed that they would be able to establish interoperability guidelines between their "rogue" systems and the corporate standards. This local SA team was able to meet the local requirements that were different from those of the rest of the company. They could provide special features and select a different balance of stability versus cutting-edge features.

Meeting your customers' needs. Sometimes, the centralized services group may be unable to meet the demands placed on it by some of the departments in the company. Before abandoning the centralized service, try to understand the reason for the failures of the central group to meet your customers' needs. Try to work with the customers to find a solution that works for both SAs and customers, such as the one described earlier. Your ultimate responsibility is to meet your customers' needs and to make them successful. If you cannot make the relationship with the central group work, your company may have to decentralize the necessary services so that you can meet your group's needs. Make sure that you have management support to make this move; be aware of the pitfalls of decentralization, and try to avoid them. Remember why you moved to a centralized model, and periodically reevaluate whether it still makes sense.

Advocates of decentralization sometimes argue that centralized services are single points of failure. However, when centralization is done right, the savings can be reinvested into technology that increases fault tolerance. Often, the result of decentralization is many single points of failure spread all over the company; redundancy is reduced. For example, when individual groups build their own LANs, they might have the training only to set up a very basic, simple LAN infrastructure. The people doing the work have other responsibilities that keep them from being able to become experts in modern LAN technology. When LAN deployment is centralized, people who specialize in networking and do it full-time are in charge. They have the time to deploy redundancy protocols and proactive monitoring that will enable them to fix problems within a defined SLA. The savings from volume discounts often will pay for much of the redundancy. The increased reliability from a professional SLA-driven design and operation process benefits the company in many ways.

Another point in support of decentralization is that there are benefits to having diversity in your systems. For example, different OSs have different security problems. It can be beneficial to have only a fraction of your systems taken out by a virus. A major software company had a highly publicized DNS outage because all of its DNS servers were running the same OS and the same release of DNS software. If the company had used a variety of OSs and DNS software, one of them might not have been susceptible to the security hole that was being leveraged. If you are the centralized provider, accept that this may sometimes be necessary.