No.

If you’re a good SharePoint Administrator, this should be your default answer for most requests that you receive. No, I’m not crazy, and yes, I’m serious. Don’t believe me? Let me ask some basic questions:

What is the single most important job of any System Administrator? (Hint: It’s not installing the software.)

Let me ask a different way: What is the one thing that an end users expects of a system more than anything else?

(seriously… think about it…)

The System Administrator for ANY system, including SharePoint, is very simple: Keep the system up, available, and usable, and secure. It doesn’t matter what the system is… end users expect it to be there for them when they need it (and they always need it now). It’s not installing more software, providing TPS reports (yellow only, please), answering phone calls, sending/responding to emails, updating facebook/twitter, or reading Slashdot or XKCD. If you’re the Sys Admin, you have one job… protect the system. In general, this means maintaining existing functionality.

There are two evil, rogue groups of people (joking) that are your arch enemies in your one purpose in life: Business Users (including management), and Developers. Lets compare…

Business Users are…	Developers are…	SharePoint Administrators are…
…constantly trying to get more “value” out of the system. …coming up with ever more creative ways to make the system do something it was never intended to do. …believe that the system has infinite capacity and resources. …believe that their actions have no impact on any other actions in the environment. …believe they are the most important users, above and beyond every other user. Or, to put it another way: Trying to increase use while decreasing investment without any change in expectation.	…developing solutions that operate at the “code” level – the deepest areas of the system that provides the least amount of protection from rogue activity. …believe their code is perfect. …are under pressure to deliver functionality, regardless of architecture. …focus on “latest” technologies/frameworks without regard for change requirements on the target platform. …are not developing in an environment that closely mirrors the production environment. …not performing load testing of their code, or frequently considering performance impacts of architecture (behavior on a single-user machine is dramatically different than heavily taxed multi-user environment). Or, to put it another way: Trying to introduce new system functionality without regard to existing configuration, performance impacts, testing, or architecture.	…constantly attempting to maintain current system characteristics despite ever increasing utilization. …fielding questions from end users on common functionality. …attempting to ensure the system does not exceed infrastructure limitations (i.e., disk space). …maintaining and verifying backup processes. …frequently responding to requests to “fix” user mistakes (i.e., “accidentally” deleting sites after 3 distinct confirmation prompts). …told to make infrastructure changes by people who do not understand (or don’t care about) the overall system impacts. …constantly listening to complaints about how bad the system is. Or, to put it another way: Trying to maintain existing functionality and performance despite a constantly changing baseline.

You could think of it this way: The business users and developers are constantly trying to do more with less, while the SharePoint Administrator is being held accountable for any negative experiences the end user may experience… regardless of cause. The goals of the business users and developers are fundamentally opposed to those of the SharePoint Administrator.

This also means that a good SharePoint Administrator (or really any system administrator) has one job: SAY NO. At least initially. :)

“I can’t say No” you might be saying. I understand… and you might be right. Saying “No” outright can be a “career-limiting decision”. So, instead of outright "No”, it may be possible to help others come to your own conclusions… though you’ll have to do your homework first. In some instances you may find that “Yes” is really the right answer anyway. As you review what you’re being asked to do or implement, document the answers to the following questions:

• What does this do to the OTHER users of the system? Will it or should it be available to them?
  • Is the implementation heavily localized? Will the deployment of it be global to all users in the environment?
• What does this do to the performance of the system?
  • Always assume that the functionality is to be heavily used.
• What does this do to the security of the system?
  • Is the functionality appropriately secure? Does it involve any exceptions to common/standard security policies?
• What does this do to the stability of the system?
  • Does the software fail gracefully? What is the impact if the solution does not work? Are there any external systems this solution is dependent on?
• How does this affect the maintainability of the system?
  • What is the patching process for this solution? Can it be updated when necessary? Does this introduce any regular maintenance demands?
• How does this affect the disaster recovery and backup strategy for the system?
  • If the environment needs to be rebuilt, what is the process? Do existing DR plans safely recover this solution?
• How does this align with vendor best practices for the system?
  • Are the correct objects referenced and used appropriately? Are the frameworks used proper?
• How does this affect the upgradeability of the system?
  • What are the foreseeable impacts to your ability to upgrade to the next version of the product?
• What is the administrative overhead of this change in the system?
  • What is the difference in people-hours required to maintain the system before vs. after this is deployed?
• How does this align with your own operational practices and policies?
  • Is there anything your company might care about that isn’t listed above?

What the business understands boils down to one simple statement: Increased Cost ($$$). If you can describe what the financial impact will be to the system and the company for the change being requested, the business can make a better decision about whether to move forward with that change. The business usually views this strictly from the view point of licensing, developer time, or the initial purchase… but in truth, there’s almost always an operational impact to deploying a change. Our job is to quantify that operational impact, in dollars, so that the business can decide whether the new functionality is worth it. If the business decides it is worth it, then you can say yes because you’re going to receive enough funding to compensate for the change. If the business isn’t willing to fund at the level necessary to support the change, then the business is effectively telling you that they don’t want the change, or they are willing to accept a reduction in the level or quality of service. If someone says they are willing to accept the reduction of service, you should point out that you’re going to quantify and advertise the reduction in service to all of the end users. The goal here isn’t to be a jerk… but rather to either set expectations appropriately with the end user community, or to make the acknowledge that they’re not really ok with a reduction in service.

The main point is, if the business is willing to back up their request with funding such that you, the administrator, can meet the current and ongoing expectations of your end users, then by all means, say yes. More often though, when faced with the financial reality of the request being made, many business will simply say “never mind” and move on or find a different way. Occasionally someone else will say yes without factoring all of this in. Look for the person that’s afraid to take a vacation and is constantly complaining about the business making unreasonable requests of them… that would be where the request landed. :P

Comments

• Anonymous
  December 13, 2011
  Well said, Mr. Mullendore!  I think one of the insidious challenges here is for people in a dev-ops role where the system administrator is also the developer!  Not every business has figured out that these need to be or should be separate roles!

• Anonymous
  May 09, 2012
  Great post. I'm explaining this a lot as well. A good parallel to draw is that a SharePoint support team is really a service provider.