Centralized administration means having one point for control and policy. For example each site might have its own pair of DNS servers, but the data on these servers might be completely, partially (e.g., domain names but not host names, or a top-level domain name but not sub-domain names or host names), or not at all controlled (allow each site to create domain and host names) by central administration.
How much centralization or decentralization to have in a large organization? There is no best answer to this question. As the SA for a larger organization, you will likely have to understand what parts of the system are centralized and which (if any) are not. In a smaller organization, the SA may be asked for an opinion on policy and procedures, and will need to decide what services should be under a single, central control and which should not.
Note that this decision isn't all or nothing! Centralization is a spectrum, with total control by a central authority at one extreme and no central control or policy at all at the other. Furthermore it is likely that some services will be more centralized than others. Most services will have control policies somewhere in the middle.
Factors to consider when creating policies or procedures (when deploying a new service) include availability of local expertise and training costs, budgeting issues, and organization management structure and politics.
Centralization can often improve efficiency and reduce costs. (At HCC software licenses were too expensive per class or even per campus, but per college we got great terms!)
Centralization usually means consistent policies and procedures across the enterprise, always a good thing.
Centralization or partial centralization works well for well understood or commodity services such as printing, file services, and email.
A poorly run central administration means slow response times and often a worse service than a local "do it ourselves" admin service can provide. It can even drive up costs with bureaucratic overhead such as needless levels of management. Other problems can include inability to communicate directly with required people, time wasted with pointless reporting, micromanagement, inflexibility, etc.
(HCC story: IMAP mail server when down but web mail service remained up. Rather than report to the SA in charge of that server, I was forced to report to my dean, who was forced to report to some V.P., who called the manager of our out-sourced admin service, who called the help desk, who entered a trouble-ticket, which was eventually sent to the SA in charge of the mail server. Of course none of these management people knew what IMAP was so the problem was never reported correctly.)
Decentralization usually works better when deploying new technology, or if various users will have special requirements (one size fits all is a motto that will doom many projects).
Decentralization can improve response time and lower overhead and other costs.
If poorly managed decentralization can lead to higher costs, and no recourse if no local expertise is available (which may be needed in many areas!). Local politics and personality conflicts can lead to very poor quality of service, as well as poor recognition for local SAs, just because some local manager doesn't budget correctly, or automatically says no to any upgrade or change. (This happens more often than you might think!)
Decentralization can cause inconsistent policies and procedures. Central budgeting can cause local service to suffer scarce budgets.