7/1/2010
Let’s start off the article by saying that I am a very big proponent of Microsoft’s SharePoint Designer (SPD) product because it allows end users, administrators, designers and developers the opportunity to make changes that can directly impact productivity without the introduction of managed code. That being said, there are some issues that come with providing the freedom to do what is needed to maintain a SharePoint site, especially if someone else is on the hook if a person deletes a site, rebrands a page or causes other acts of madness with SPD.
One of the great features of Microsoft SharePoint Server (MSS) 2010 is that as a Farm Administrator I can check a couple of boxes and access to my farm’s site with SPD and other types of changes is DENIED! But let’s try to be a little more open-minded than taking the easy way out and just shutting everyone out of the fun.
Before we look at the code, let’s figure out what we want to do. The options are as follows:
- Allow the use of SPD
- Allow Master Page editing
- Allow users to Revert from Template
- Show URL Structure
The following lines of code can help you implement one measure of Governance, and some sense of sanity, within your SharePoint farm.
- SPSite site = SPContext.Current.Site;
- // Check to see if the properties have been previously set by Admin and if so, retain those values
- // These properties change the settings in Site Collection Administration for the SharePoint Designer Settings
- site.AllowUnsafeUpdates = true;
- site.AllowDesigner = IsSiteDesignerAllowed(site);
- site.AllowMasterPageEditing = IsMasterPageEditingAllowed(site);
- site.AllowRevertFromTemplate = IsRevertFromTemplateAllowed(site);
- site.ShowURLStructure = ShowSiteURLStructure(site);
- site.Dispose();
The code above is reflected in the UI within SharePoint’s Central Administration:
Let me try to explain what each option allows you to limit. First we have to the ability to limit SPD. In this case, we’re allowing the site administrators to edit sites with SPD. This is also scoped at the SPSite level, as well. deselecting this option will deny users to make changes via SPD.
Next is the “Detach Pages from Site Template”, which allows users to create their own design based off a template. It’s the equivalent of copying a template so it can be available in a stand-alone fashion.
“Allow Site Collection Administrators to Customize Master Pages and Layout Pages” enables changes to be made to those specific pages. This would significantly impact branding if you let users change the Master Page at will.
Finally, we have the ability to let users see (and manage) URL Structure. Moving pages, see which folders and files exist are just some of the examples.
So the purpose of showing the images is not for the code, but to show the potential flexibility that you have within your farm to allow some site collection administrators access to the tools needed, or restrict the use of those same tools to others.
As far as the code, a developer could continue with this and develop a feature where an administrator could turn on or turn off access on each Site Collection (SPSite) as needed. I like the fact that this solution is flexible and helps you govern your environment and the choices can be tuned on an as-needed basis. 6/29/2010
The first concern that a manager or a person assigned to a SharePoint implementation asks is “How many people will I need to manage the environment effectively?”. It might be written someplace, or maybe an expert can reveal a certain amount of staff per user ratio, but honestly, I haven’t seen it yet. At least from a real-world perspective there is not a “silver bullet” that you can bring to your leadership and have them sign-off on the expense of running your team. Again, there might be ideal numbers, but what it’s going to come down to is a negotiation between you and your leadership as to how many headcount can be added to your project/department budget.
Arguing Against the Mythical “Rock Star” SharePoint Team
Before we start this portion, I believe the only “Rock Star” SharePoint teams exist at Microsoft, top-level Independent Software Vendors and Consulting companies. I do think there are experts in the field that are above-and-beyond all levels in the Enterprise and Small and Mid-sized Business (SMB) market. So for deployments in general, call in the experts in the beginning and then start assembling a concept that is used in the NFL (and other sports), where teams draft the “best player available”. So the experts of the world are the “first and second round draft picks”, the people that will get you up-to-speed while you get your team where they need to be. Your mission as the leader/manager of the implementation is to find the best SharePoint people you can find. This task is hard enough, but as the economy continues to get stronger and demand for SharePoint professionals continues to grow (hard to believe but will happen) you will be happy to get people who can skillfully work as a team for your users.
My argument against retaining the “SharePoint Rockstar” is that you will spend 50% on one person, versus getting two people that can really help your deployment with support and operational concerns. Also there is a satisfaction-factor that needs to be accounted for. In a few months/years the person could get bored and move on an set you back to square one. This can happen with any employee, for many reasons, but if they’re a “rock star”, they want to be challenged and work with the latest technologies and if you do not offer that, that will put you in a precarious position. That’s why the “rock star” should be in highly dynamic environment where they are fed with this type of desired experience.
Do You Want a Scalpel? or a Swiss Army Knife?
This is another misconception that might bite you, having specialists in your deployment teams. If you are a large corporate team that needs a development team, a network/administration team, and a support team then you might be in a special situation initially, but I would say only 20% of the companies fall in that situation, the rest need an all-around SharePoint person whom is moderately experienced with a SharePoint skill (Admin or Dev), willing to learn what’s needed, can follow the published governance plan and can efficiently bounce from the various lanes that will inevitably appear in a day’s work. Working with the Help Desk or end users is a huge plus that can improve your customer service, as well.
The argument of having a person who *just* does dev or admin is a limiting factor that can determine how your team performs. Remember, think “Swiss Army Knife” during the first few years, there are going to be issues that come up where multiple hats and skills are needed. A developer cannot do an admin’s job and vise-versa, but an admin-focused person can help a development-focused person with tasks that involve Out-of-the-Box (OOTB) requests that a user has on a daily basis and after a couple requests can understand the concepts to study the required actions to finish the job in the future. That falls into the “Smart person” category. Someone once told me “You don’t have to remember everything, you just need to know where to find it”. This is appropriate in that you want people who can provide answers on a variety of topics, not a subject expert in one particular area. Build your team so they can cross-train into all areas.
Proposing an Organization
So this is what we really want to know, how many people and what type of roles do we need to be successful moving forward in the future? The short answer: it depends on how many people you have to support.
Let’s look at a small enterprise implementation with 5,000 users to support. You need the following roles:
- Manager, Lead or Project Manager (whatever your organization has identified as a responsible party)
- Three SharePoint resources (an admin with development experience, or a developer with admin experience)
- One customer support person that works on lower level requests, or train your help desk to assist you with these calls.
- Either a Database Administrator, or a resource in your organization that can handle the duties On-Demand. Some organizations might have SQL Server DBAs that can handle these tasks if given the right information to execute when needed.
That’s it, the multiplier is different whether SharePoint is hosted on-premise, in the Cloud or by a hosting provider. As an example, you might be able to forgo a DBA because your hosting provider supports the SharePoint databases in the farm, so one less person to have on staff.
In the end, You Know Your Organization, so Plan Accordingly
Different organizations need to focus on different objectives to be successful, so know what you need and focus your human resources on that task at hand. If you require custom functionality and have developers on-hand to meet that need, gravitate to those projects. If you have a lot of users who need training and a lot of hands-on help to get initiatives going, have a support-minded staff. Which ever way you choose to go, turning the ship around takes a more than a little time, so before that first person is assigned to your project/team, make sure that person will be successful and has the skill set for the work you are having them do for your team.
Everyone should be acutely aware in both good and bad years that very few leaders are going to give a team the organization to support a SharePoint farm with best-scenario staff numbers so having the flexibility to adjust is going to the biggest dividend related to your deployment. Building a team that will successfully launch the use and maintain a high level of supporting SharePoint is both challenging and rewarding, and like in most technology projects, finding a balance of people and process is the key to it all. 6/20/2010The starting decision around governance start with a couple of tightly coupled topics: Architecture and Environment choices. These two areas will determine the success of how your future work will be perceived by your users, sponsors and staff. Architecting a solid frame on how your SharePoint farm will perform and scale for the work that it’s intended to perform. Some of the questions that need to be asked: - How do we want to approach hosting the farm?
- On-premise hosting
- Outsource
- Cloud-based services
- Hybrid of On-premise and Hosted
- What type use are we expected to provide?
- Internet Public-facing Websites
- Extranet
- Portal
- Collaboration and document sharing
- Applications
- Records management
- What will we promise (Service Level Agreements (SLAs))?
- Disaster Recovery
- High-Availability
- Global deployment
Let’s start with the who/where your farm will be hosted. As outlined above, you can see we have some options, but the who and where you host your farm will be the biggest factor of governance because if you select on-premise hosting, there is an amount of control that you can implement and also have to “fill-in more blanks” when you develop a governance plan. This article will discuss explicit hardware or networking but we broach some areas that are not considered on a “typical” deployment How will we build out our farm? Let’s just say that we are selecting a Proof of Concept (PoC) strategy where we have been commissioned to build an environment that will “get us by” until we are fully funded. To me, this is a problematic start where governance is concerned because you are asked to stand something up quickly, but you’re probably taking servers that are available and then the environment turns into the future production environment. That’s a bad situation that happens too often, but I digress. Back to our PoC, so when we get “foster” servers for our environment, make sure the hardware AT LEAST meets minimum hardware requirements for SharePoint 2010 (or 2007). At this point, make sure you plan for a successful upgrade or project acceptance and use the SharePoint 2010 requirements, you might only get one shot to go to the well to get money for the servers you need (“Go Big or Go Home” strategy). Hosted solutions are better than they were a couple years ago, maybe that might be your route. You might not even have a choice, because more and more CIOs/CTOs are opting for this model to remove costs from their operating budgets. Most hosted options require less licensing (Windows and Support) and are handled different from an accounting side, so that is very attractive for mid-size and Enterprise-level organizations. Hosted (or Cloud) solutions also require less administration from internal staff, but have guidelines and governance for their own infrastructure, but this means you will have to know and utilize their rules structure. Hosting companies could meet your needs are now in the business of planning and building your infrastructure for size, scale and other deployment issues. To tie-in to hosted or cloud services, there are also outsource providers (possibly off-shore) that host your servers, just like your company, except physically off-site and managed by a separate technical staff. What do we want to do with SharePoint? This impacts our infrastructure and how we move forward, but we have to know which direction we’re going in, before we starting building out an architecture, or even solidify our requirements. Building out an appropriate hardware infrastructure means know what you need to get out of it. Determine if employees-only are your users, or external and internal, or anonymous users from an Internet website. Most companies start with document sharing and collaboration features within SharePoint, unless there is a specific business need. Fulfilling those needs are centered around storage, Disaster Recovery (DR) / High-Availability (HA) and User Experience (UX). Users’ acceptance of the platform is vital for PoCs and once you are in production the primary need users demand is space for their documents. Nothing kills enthusiasm to collaborate than to provide the tool and not plan or implement a solid storage plan. For site collections, if you offer less than 2GB, you need to figure out how to expand the largest of your user’s need. Groups with large files (images, CAD drawings, versioned word documents) can eat up a major of a site’s (or web’s) space once uploaded so you will have to figure out how to handle these collections that outgrow your current standard site collection. Special Considerations for Your Deployment (Yes, you’re Special) If you have the understanding that the world is not flat, you’re going to make your deployment a hit when you figure out if you need WAN Accelerators, or even if you want to have separate smaller farms (again, what are you doing). Do you need your farm available 24/7 or is there a business time frame that will suffice? What happens if you’re primary site goes down, or worse catches fire or destroyed? How long can you go without SharePoint? Do you have multiple support groups working on the farm(s) and do they follow the same operating practices? Touching on internal staff managing the SharePoint platform, if custom solutions (managed ASP.NET code) then development, testing and staging environments need to be an integral part of how you promote code through your farm. If you work with consultants, contractors or vendors, let them know what you're doing and how they can move their deliverables into production. Next: What are your staff requirements? Our next discussion will center around people. After you’d hired the consultants and contractors, is how many people do you need to permanently manage your SharePoint farm, what they should do and how will these staff support your users. 6/17/2010 Microsoft has built and sold one of the most successful products in the Enterprise space ever and with that comes a lot of possibilities, responsibilities and problems to solve. Once you’ve committed to the licenses and hardware, trained your staff to deploy, hired consultants to help and gained approval from your executives, it’s time to build a solid of understanding how you will support your users and what will be allowed and disallowed in your shiny new SharePoint farm. Let’s look at what you’ll need to consider at a glance and more information about each of these topics will be posted in the future. As a consultant at, and an employee of, Fortune 50/500 companies, I have seen governance become a huge issue that rears it’s head throughout the deployment lifecycle and in supporting your customers. Another trait that it is equally important is the Enterprise discipline required to keep your collaboration and application platforms consistently meeting the needs of your sponsors and business to provide the real value expected from the rollout of any technology, to include SharePoint. Let’s look at some of the issues all organizations can consider before deploying SharePoint and maybe it might help in other technologies, as well. 10/25/2009One of the issues in the past with Microsoft Office SharePoint Server (MOSS) 2007 was controlling the use of SharePoint Designer (SPD) within SharePoint's Central Administration or within a site collection, or even granular control at the site level. Well, it appears Microsoft has listened to the voice of the customer and implemented a solution which allows an administrator to check a box and limit SharePoint Designer use on a site collection basis. With some companies creating most sites as it's own site collection, this is a great option. Now, I know there were ways by modifying web.config files and other work-arounds to allow this similar feature but in most cases the feature had to be implemented on a site-by-site basis or it was "all-or-nothing". Adding this feature will allow enterprises and administrators decide how and who is allowed to make design, workflow or other modifications via SPD 2010. Some of the other choices are enabling the detaching of pages from the site definition, enabling customized Master and Layout Pages, and enabling the management of the web site URL structure. These choices are self-explanatory, but have great consequences of how much a user can change on the site. Options are always best in this case. Based on previous deployments, I know this ability will be very well received because some companies what users to have no ability to use SPD and others allow the full use of SPD, it's a governance choice. With the new interface, there appears to be more ways that a site can be modified and SPD 2010 will only be able to modify SharePoint 2010 sites so only the future platform will be impacted. |
|
|
|
|