Companies are going global everywhere, but even those that might not yet be spanning the globe may span their respective continent. When you have a global service in IT like SMS or MOM that ties different locations into a hierarchal structure, it is natural for people to assume that all administration should be done centrally. Should it?
The No. 1 recurring theme from IT people is "Do you know of anyway to pull this data out of (Insert Legacy Application)? Yeah, I know (Insert Current Technology) can do that, but we have some groups at other offices that are refusing to migrate to it because of x, y, and z." Most of the time x, y, and z are not actual technical problems that cannot be overcome. They are political problems based usually upon one of two things (or both):
* Poor past performance of the group that is proposing rollout of the new service
* Service control by management
Unfortunately, the technologists can only influence the first point because the second one is out of their hands. The really funny thing about this situation is that the purpose of management, at least to me, is to give direction and to resolve conflict. But it seems that usually when big issues are escalated up the food chain, this never happens and issues go unresolved.
Getting back to the main point, though, is the fact that when you want to roll out something that ties many locations together, some are unwilling because of a trust issue. After all, if an administrator at a central location makes a change that brings down systems at a remote site, that person is in front of customers. The only solution is to really give the control to the remote sites.
For the sake of argument, let's use SMS as an example. Many feel that only a few people should administer an SMS, but I fail to see why this is always the default stance taken. I live in San Diego and I have an SMS hierarchy that spans all the way to India. Do I really want to get up at 4:30 a.m. to see why a client isn't receiving a Win-Zip package?
This example shows why you need to have a distributed administration model and embrace the concept of forming matrixed teams across multiple locations. Why does an SMS packaging team need to all have offices in the same hallway? To me, one of the biggest problems in IT in general is a lack of talent.
If we have an administrator who is a quick learner and can follow processes and procedures, as well as come up with innovative ideas, why wouldn't I want him to work with our packaging team just because he lives in Germany? I would much rather have a team of extremely talented people that is geographically spread out than getting a less than stellar performance out of another one just because that employee is in the same location. You therefore need to have rock-solid policies and procedures
that can be followed, as well as an open mind to change when something doesn't work for a site (regardless of the size of that site).
Still using SMS as an example, there are many things that can be controlled from a central location, such as the SMS_DEF.MOF, site inventory and discovery settings, security patch scanning timelines, packaging templates, software distribution processes, among others. It's especially easy when many of these things don't change on a frequent basis (many of them go unaltered for more than the lifetime of a product). These things should be assigned to a "global" role -- a few people that are
responsible for maintaining consistency throughout the hierarchy.
However, there are other things that should be opened up to "local" roles -- package distributions, client troubleshooting, reporting, among others. There is, of course, some give and take here that should be worked out, especially around maintenance. Who installs a service pack? Who patches these servers? This can also become a political battle, but really it's a question of who accepts responsibility of that service at that site.
If the local support staff is willing to accept responsibility of a failed security patch on a server, then the only thing the "global" administrator should be concerned about is when they are going to do it. The real question is, if proper procedures aren't followed or if something fails, will other sites be affected. If the answer is yes, then the direction is clear.
You might also find that there are some sites with limited staff that don't want to be involved other than end user interaction and communications. "Local" roles don't need to be limited to an all or nothing stance. There could be a local coordinator role that simply notifies users before software distributions occur and answers their questions. They might also have input on when it's appropriate to do distributions and when it is not, since they are more involved in the local business. The
thing to remember is that they are part of the "SMS team," which gives them a level of control and ownership of the service at their site even though it is managed remotely.
These are just some suggestions to resolve poor group performance. As for service control, well, you're pretty much just along for the ride. I've found that the only thing to do in that case is to be as knowledgeable as possible on that technology so that the winner will want you on their team.
This article first appeared in myITforum, the premier online destination for IT professionals responsible for managing their corporations' Microsoft Windows systems. The centerpiece of myITforum.com is a collection of member forums where IT professionals actively exchange technical tips, share their expertise, and download utilities that help them better manage their Windows environments, specifically Microsoft Systems Management Server (SMS). It is part of the TechTarget network of Web
sites. To register for the site and sign up for the myITforum daily newsletter, click here
