I don't know if you've been following the thing about the network admin in San Francisco whose obsessive concern about the network he ran led him to lock his bosses (and practically everybody else) out of it...
There are going to be two big basic groups of reactions:
"This guy is a threat and we must put controls in place so no one person ever has that kind of control ever again."
"Yeah, I can see his point, bureaucrats and arbitrary rules and procedures can be the biggest threat to a network."
#1 will likely be voiced by the powers-that-be, often technically-uneducated administrators. #2 is likely to be the opinion of people who've had to deal with the people who would voice #1.
As usual, they're both right and wrong in about equal chunks.
I'll say this: technical planning and decision-making should be in the hands of technical people. Period. Engineers deal in a world of ones and zeroes, and stuff either works, or it doesn't, and it's ultimately their job to keep making it work. In this case, the network admin put some safeguards in place, with the blessing of the suits, because some dimwit managed to infect their probably-partly-Windows-based network with a nasty virus a while back that either did or could have caused some serious problems. Suits deal in a world of political and organizational squishiness, and too often, where that conflicts with engineering reality, engineering reality suffers. This is the sort of world where suits decide to change away from Notes/Domino and move to Exchange, for example, not for any fiscally or technically justifiable reason, but just because "it isn't Microsoft and the CIO doesn't know anything else."
That said, the right solution in this case is not to distribute system control to a disinterested and diverse collection of bureaucrats. If San Francisco does this, they're stupid. The right solution is to distribute control and oversight to a small group of technically skilled engineers. Five or six, max. Hire the best you can find, pay them what they're worth, and treat them with respect, and this problem will never recur.
OK, I can hear the laughing out there. Yes, I know no organization ever does this, even if they pay lip service to it in the hiring interviews, but it's the ideal. Dedicated engineers don't need assloads of money, but what they do require is the knowledge that The Right Thing Is Being Done By People Who Know Their Shit. They also know that this almost never occurs when non-technical management is making technical decisions. They further know that trying to paint technical decisions as "organizational" or "political" decisions is horseshit. Painting a tractor doesn't turn it into a cow.
But think about this: in an environment where he was surrounded by peers he could respect, a cadre with adequate resources, responsibility and authority, I don't think this guy would have ever gone down the sort of defensive, secretive admin path he took. By concentrating the control of the system in one guy and by not having the technical understanding to even ask what he was doing, let alone understand the response, the suits at the city of San Francisco brought this upon themselves.
OK, take a look at your own organization.
If you have a systems group headed by someone who came from your business component -- for instance, a sales VP who was "rewarded" for his marketing prowess by giving him the title Chief Information Officer, your organization is broken. Technical people will not respect the decisions made by an executive they perceive as being ill-informed as to the technical and physical realities of the tasks at hand. The executive also will tend to underestimate those realities and make decisions far too often based on marketing hype and the political pull of other nontechnical people in the organization. Sure, the exec should always keep the needs of the users in mind, but they should also know when not to let the inmates run the asylum.
Bad CIOs will also discount the opinions of the engineering staff because they perceive them to lack political or organizational finesse. This is a mistake.
Get yourself a small group of the best technical people, get them the resources they need, and actually listen to and believe what they tell you. They have professional pride and won't steer you wrong. They may steer you in a direction you didn't think you wanted to go, but no admin I know will deliberately build a crock of shit, mostly because they know they have to live in it.
A peer group also backs each other up. They'll know if someone is going a little loose in the brains and will adjust their work style to account for it and reel the rogue back in. A highly technical admin can BS the suits, but they cannot BS other highly technical engineers, and they won't try. The overall for-realness of your systems environment will rise, and everyone will benefit.
Oh, and keep an eye on what your engineers are buying. It's OK to ask those kinds of questions, right?