Thủ thuật Sharepoint 2010 part 46 ppt

294  CHAPTER 11 maNagiNg NavigatioN aNd UNderstaNdiNg goverNaNce SHAREPOINT GOVERNANCE This section provides a high-level overview of SharePoint governance. We first define governance and then work through some different approaches to building your team. Finally, we will review each of the major areas within SharePoint and describe the different types of policies that should be developed to support your environment. What Is Governance? Governance, in the SharePoint context of this chapter, is the set of policies and procedures devel- oped to ensure that your SharePoint environment is able to consistently provide a robust, stable working environment for your users. These policies and procedures are the guiding principles that keep your environment configured for the best possible support. They are usually based on best practices that are adjusted to fit your organization’s needs. Governance covers many different aspects of the environment, including the following: Infrastructure  Information architecture  Development and customization  Support and availability  The following sections cover each of these areas and provide insight on the different questions and scenarios that should be considered as you develop your governance policies. We will also look into different ways to build your governance team, and even ways to help promote the need for gover- nance within your environment. Getting Started with Governance One of the hardest parts of SharePoint governance is simply getting started! If you are in an organiza- tion like most, governance comes in one of two flavors — the lifeline to keeping things going or the thing that should have been done to avoid issues. In some places governance doesn’t tend to be high on the list of priorities until something major happens that causes everyone to say, “Wow, if we had just done X, all of this could have been avoided!” When handled correctly, governance will be the driving force of your implementation. When ignored, your implementation will be at risk on several fronts. The most common elements to suf- fer when governance is ignored are funding, usability, and supportability. For example, consider the situation in which many different projects are developed at once by different groups, all using SharePoint. If none of the teams building the solutions are working together using common stan- dards, you are likely to get several drastically different solutions. This may seem fine at first; differ- ent problems require different solutions, right? It’s fine until an end user encounters a completely different look and feel for each similar site they have to access. Consider the Quick Launch — what if its location differs on every site users access? Imagine the confusion and frustration that could cause, and then imagine all the extra help desk support you would need to answer all the questions it would be flooded with! Conversely, imagine what the situation would have been like if, when new departments wanted to use SharePoint, clear sharePoint Governance  295 guidelines were in place that outlined the purpose of the environment and the things that could and should be done to the site. At the same time, you don’t want to have to be the gatekeeper for every action, especially those that don’t really matter to you and your responsibility to keep the farm running and happy. How do you fi nd the balance? You build a team and implement governance policies! The remainder of this chapter is dedicated to providing you with the information needed to begin building and developing governance policies within your SharePoint implementation. While it’s easy to fi nd existing best practices and standards for governance policies, keep in mind that they need to be integrated into your specifi c, unique environment. Because governance policies consist of guidelines to ensure that your environment remains stable and supportable, it is critical that your team reviews the best practices and adapts them as appropriate. Governance Team Because SharePoint can be used for many different purposes within the organization, the team that supports the environment should be representative of the entire company. By working together, this cross-functional team will be able to develop specifi c policies and guidelines that represent the needs and requirements of the entire organization. The following list describes some of the key players that you should include in your governance planning: SharePoint Owner  — This role should be fi lled by the person responsible for the SharePoint budget. By including them in the governance planning, you ensure that they hear fi rsthand the needs of the organization and how SharePoint can be implemented to solve those needs. SharePoint Farm Administrator  — This should be the person responsible for keeping the farm up and running and happy. It is essential that this person be a key player in developing the governance policies. After all, administrators cannot successfully fulfi ll their job responsi- bilities unless they have a say in what can and cannot be done within the environment. SharePoint Solution Architect  — This role should be fi lled by the person who is usually responsible for confi guring the information architecture. This should be someone who under- stands both the technology and the business, and then merges the needs with the product to deliver the overall layout for the organization. SharePoint Designer  — This is the person responsible for the “look and feel” of the site. Usually, this is someone who is part of the marketing or communications department, and who directs the way the organization brands its SharePoint environment. SharePoint Developer  — This is the person responsible for developing custom solutions that will be deployed to the environment. SharePoint End Users  — This is the person or group that represents the end users. This is a key role to include in your planning. You can build the best, most advanced system in the world, but if users are confused they won’t use it or appreciate all the hard work that went into creating it. In larger organizations, this should be a cross-departmental team that repre- sents the larger community of users. 296  CHAPTER 11 maNagiNg NavigatioN aNd UNderstaNdiNg goverNaNce At this point, you are likely thinking, “Who wants to put all those roles in a room and get them to work together toward one common goal? Won’t it make decision making harder with multiple roles included?” The simple answer is yes — involving more people, who represent more opinions, will probably make the decision-making process take longer and will add more complexity. However, the end results will be much better than mandating decisions without input. The process of defin- ing governance is a business activity, not technical. It will be up to the SharePoint Administrator to guide the team about what is possible then to implement the team’s decisions. Take branding as an example. As the farm’s administrator, it’s likely that you do not care what is being built, but you probably care quite a bit about how it is built. It is irrelevant to you what colors and fonts are chosen. What does matter to you is what is being done to the farm in order to deliver the branding solution. Are custom master pages being built? If so, are they being deployed to the farm via Features and Solutions or are they being manually deployed to each site collection? Typically, the SharePoint designer doesn’t really understand the environment and how things need to be done; the designer just knows what needs to be done — the fonts, colors, and layouts that will convey the com- pany’s brand. Or imagine if your business users were responsible for configuring the governance policies around the search feature. Clearly, this wouldn’t work; they don’t have the tools and skill sets needed to make decisions like that, or info about the best time to run indexing to avoid slowing down other processes. While their input is critical to ensure that search will ultimately meet the business needs, the final decision on implementation should be left to the team that is responsible for managing the server. Defining Policies and Procedures A governance policy can take many forms. It can be a long, detailed process that identifies everything that needs to be done for the configuration and management of SharePoint. It can also be a simple statement that identifies what is being done to manage specific areas within the environment. As stated earlier, the purpose of governance is to help you manage your SharePoint environment. That may mean you need to develop detailed corporate policies, or it may mean you just need to work through the list of recommended areas and make notes. Before creating any policy, the most impor- tant thing to do is to think through all of the business areas that will be affected and carefully plan how they will be incorporated into your environment. Another thing to keep in mind is that governance policies should be considered “living” policies. In other words, they are not created once and never changed. They are created once and then maintained by a group of individuals, updating as necessary so that they can continually support the organization. Just as organizations change over time, so must your governance policies if they are to retain their value. sharePoint Governance  297 SAMPLE SHAREPOINT GOVERNANCE POLICIES To help you get started, here are two different sample governance policies. Client Confi gurations In order to best support the SharePoint environment, support needs to be limited to specifi c client confi gurations. While every effort will be made to support multiple environments, [company name] will need to put limita- tions around the standard environments that are used to access SharePoint. The following list identifi es the different supported environments and confi gurations: Windows Vista, Windows 7  Offi ce 2007, Offi ce 2010  IE 7, IE 8  In addition to the supported environments, the following environments will be tested and any issues identifi ed and communicated to users: Mac OS  Offi ce 2003  Mozilla Firefox  Windows XP  [Company name] will make every effort to provide solutions for multiple environments, but under certain circumstances it will be necessary to use the supported confi gurations to take full advantage of the features available within the portal. Site Quota Templates Site quotas will be used to manage the team collaboration sites. Three differ- ent quota levels will be created. By default, each site will start at the level 1 quota. When a site is approaching the quota limit, the help desk will review it and make any necessary adjustments to the existing content. If no adjust- ments can be made, the site will be elevated to the level 2 quota. If the team is notifi ed that they are reaching the level 2 quota, the help desk will again review the site content. If it is determined that the site will continue to require additional storage space, then downtime will be scheduled and the site will be migrated to a dedicated database. These are just two examples of the many governance policies that can be created to support your environment. 298  CHAPTER 11 maNagiNg NavigatioN aNd UNderstaNdiNg goverNaNce Infrastructure Now that we have looked at the team and how its members work together, we can start to focus on some of the key areas for which governance policies are created. Let’s start by looking at infrastruc- ture. The following list contains some of the key things that should come to mind when you start thinking about the physical environment: Client machine configurations  Server topology  Installation and configuration policies  DNS settings  Site management  Quota templates  Recycle Bin settings  Usage reporting  SQL management  Server monitor  Backup and restore policies  Anti-virus/security  For each of these areas, you should record what you are doing to configure, manage, and maintain the desired configuration. By developing a plan for each area, you will be able quickly respond when issues are identified. Information Architecture Information architecture (IA) defines how content will be organized within your environment. Some of the key questions addressed in IA planning include the following: How many web applications will be created?  When are new site collections created and where are they created?  For example, let’s look at a common scenario for a mid-size organization that is getting ready to implement SharePoint. They have purchased SharePoint because of the value it provides to the orga- nization through the fulfillment of multiple efforts. Specifically, they are looking for SharePoint to provide the following functionality: Corporate intranet  Team collaboration sites  Department collaboration sites  Corporate extranet  Corporate website  sharePoint Governance  299 SharePoint probably provides an unlimited number of combinations that could be used to configure the preceding requirements — but just because you can, doesn’t mean you should. Imagine what would happen if you just started creating sites as they were requested. What if you end up mixing your col- laboration and intranet sites? How would your users know where they needed to be to collaborate and share content versus where they needed to be if they wanted to consume information from the organization? At this point in the book, you are already aware of the need to plan your environment, and you are probably well on your way to planning exactly what you should be implementing. What may not be clear, however, is what planning the IA has to do with governance. It’s simple, really; by creating an IA plan and assigning an owner, you are ensuring accountability — for the proposed structure, for future requests, and for all of the “exceptions” that are generated along the way. You know it will happen: As soon as you build and implement the perfect solution, a manager with enough budget money or power comes along and wants something just slightly different from what you planned. No matter how hard you plan to include everything, there will always be an exception. In this case, you deal with the exception through governance. Because you have created a governance policy that outlines the IA for the environment, you have something to fall back on as you deal with the excep- tion. The person on the governance team responsible for creating and defining the IA will then be responsible for making a decision about where and how to address the requested exception. Development and Customization Development and customization governance policies will define how and when customizations are made to your environment. The customizations include anything that is not created using out-of- the-box tools, such as Office and Internet Explorer, and includes things such as SharePoint Designer customizations, sandbox solutions, and custom Web Parts. Keep in mind that these customizations can be things created in house, as well as third-party tools that can be purchased. The key point with this area of governance is understanding what types of customizations are being made to your environment. A simple example is the deployment of customizations. Are they being deployed manually (i.e., changes are made to each web front end individually) or are they being deployed through a solution package? As you learned in Chapter 13, the only supported method of deployment is through solution packages. This is a primary example of the type of policy that should be included within your governance plans. Another example is the use of SharePoint Designer within your organization. As detailed in Chapter 22, SharePoint Designer is a powerful tool that can be used to make many power cus- tomizations to SharePoint sites. However, like any editing tool, training is required to use it prop- erly. Imagine what would happen to the number of support requests if every user simply opened SharePoint Designer and starting making changes to their sites! Just think of all the potential things you would have to fix or recover. Now imagine if the use of SharePoint Designer were controlled in some fashion, and only trained and educated users were able to make changes to their site using SharePoint Designer. Sure, you would still have support issues but they would be nothing compared to the first scenario. The final area we should cover in this section is the process for deploying content to the produc- tion environment. How will customizations be approved and processed before they are deployed to production? This area includes everything from the initial deployment to any required maintenance 300  CHAPTER 11 maNagiNg NavigatioN aNd UNderstaNdiNg goverNaNce over time. Here are some of the questions you should be thinking through as you develop your gov- ernance policies for deployment of customizations: Who needs to approve customizations? Keep in mind that this should be determined early in  the process before any development or purchasing is started. What criteria and standards must customizations meet in order to be added to the farm?  What is the schedule for deploying customizations to production?  What development and QA environments will be in place to support the process of testing  and deploying customizations? What processes and procedures need to be put in place to ensure that customizations made  today will work correctly with customizations made in the future? By taking the time to work through each of these questions, you should be able to identify specific policies and procedures that should be included within your governance plan. Support and Availability Support and availability covers the users’ expectations of support within the environment, and is often referred to as the service-level agreement (SLA). This SLA is basically a statement clarify- ing what can be expected from the farm. Your organization may already have SLAs, in which case SharePoint will just become part of those same agreements. If no SLAs exist, it is important to define them for your implementation. This should be communicated clearly, so that users are not caught off guard. For example, users may be caught off guard in the following scenario. A group or project has a tight deadline and the team is working overtime and through the weekend to wrap it up. They are storing and collaborating all of their information within their project SharePoint site. What would happen if one of their big project deadlines was scheduled during your weekend patching window? While it is true that even with an SLA in place there is no guarantee that this scenario won’t happen, having one in place at least ensures that you did all you could to avoid the situation. Another thing to consider in this area of governance is content restoration and what users should expect. This would include the different levels of restoration, such as site or list, and the expected duration of the restoration. Documenting all of this before users create content in SharePoint will go a long way toward setting realistic expectations about what they can expect in terms of support. It should be a part of a department’s expectation as they adopt SharePoint that they understand the SLAs and recovery time of the farm in the event that their content is more mission critical than the SharePoint farm. If this is the case, then the department needs to either not adopt SharePoint or work through normal management channels to modify the SLAs for SharePoint. This will often include additional hardware, third-party software, or personnel. Selling the Need for Governance SharePoint administrators frequently claim that they want to implement governance, but just don’t have the time, resources, or support from management. It’s important for those administrators to understand that something is better than nothing, and anything they can do to create governance summary  301 policies will help them better support their environment. It’s also essential to convey the benefits of a good governance policy to others in your organization. The following sections offer some advice on different strategies you can use to help foster the need and importance of governance within your environment. start small and Grow One of the most common mistakes in the SharePoint community is that when an implementation project starts, those responsible either go all out in developing their governance plan or they do nothing at all. We would encourage those who fall under the “nothing” end of the spectrum to con- sider starting small. To do this, think of the key things that you will be doing within your environ- ment, and then think of the key policies or procedures that you could put in place to better support those initiatives. Start small, and start only with the areas that make sense for your implementation. Prioritizing is critical: determine which areas of governance will be most useful and start with those. If you are going to spend the first months of your implementation focusing on using SharePoint out of the box, put the task of defining policies for customization on the back burner. If you have limited time and resources to dedicate to governance planning, start with what is most relevant and build the remainder into the future project timeline. Communicate the Value If you want to convince the organization to provide the resources needed to plan for governance, management needs to see and understand the value of the governance being developed — and it is your job to help them see this! If your organization is already using some form of governance, then whenever possible you should be communicating to management how it is helping and improving the way you are able to provide service. Conversely, if you don’t have any governance enforced, com- municate how not having it is causing problems that could be avoided. It may take time and it may take a few big events for them to recognize the value, but eventually they should provide you with the resources you need to develop, implement, and maintain the governance polices. You should also piggy-back on any defined informational governance that your company has in place. For instance, if HR has a defined plan around information that creates an availability, recoverability, and update timeline, then tie those expectations to the data in the sites (site collection) on which the data resides. SUMMARY We have covered a lot of ground in this chapter! We started by looking at all of the different ways to configure navigation and then discussed the importance of setting standards or guidelines con- cerning its use. That led to a discussion about governance and its importance within the SharePoint implementation. We concluded by looking at the different areas of SharePoint and the role that gov- ernance plays in each of these areas. Realize also that these activities are not one-time occurrences but are in a constant state of “update” as long as you have your farm. By this time, you are ready to move forward with the implementation, but not without first creating that governance plan! . content in SharePoint will go a long way toward setting realistic expectations about what they can expect in terms of support. It should be a part of a department’s expectation as they adopt SharePoint. critical than the SharePoint farm. If this is the case, then the department needs to either not adopt SharePoint or work through normal management channels to modify the SLAs for SharePoint. This. organization brands its SharePoint environment. SharePoint Developer  — This is the person responsible for developing custom solutions that will be deployed to the environment. SharePoint End Users