Management — an indispensable condition for the successful implementation of SharePoint. Without it, failure is inevitable, and many companies have learned this the hard way.
It is necessary to study the technology, which will manage; It can not be assigned to it tasks that it can not solve. In this article, we will focus on the technical side of management. In addition, we will answer some important questions.
-How, indeed, seems driven implementation of SharePoint?
-What is the physical and logical architecture of this implementation?
-How many farms, servers, web applications, content databases, site collections and sites available in the implementation?
Unfortunately, the immediate answer to all three questions: «It depends.» The answers depend not on SharePoint, and the purpose for which it is used. The best way to find the answer in a particular situation — consistently go through four steps describe the design process management. As a result, you will not only answer to the above questions, but also to build a logical, physical and controlled architecture, relevant features of your business.
The focus of this article, I want to pay the very process, which consists of four basic steps. In future articles on this topic, I will explain how to apply the process to the specific circumstances, to obtain the optimal algorithm for building architecture. In addition, I will show how to use the technology for automation and application management policies.
Step 1: Determine Requirements
Step 1 is connected to management requirements. As a consultant, I spend about 80% of the time, helping customers to identify requirements and bring order to the information requirements for the preparation. Unable to find an effective solution, not realizing the requirements for it. SharePoint — is no exception.
The problem is that the implementation of SharePoint associated with numerous regulations. So I came to the conclusion that they are useful to categorize, and then determine which categories are most important for each step of the design process management architecture. So, I recommend to split the requirements of the following categories.
-Business requirements — the most important. They define the purpose of the decision which was asked to prepare the client. If possible, try not to mix business requirements specification. In most cases the technical requirements are artificial. If the client says, «I want a child site that does X» or «I need a button that makes the moment» that the client takes the position of a technologist, developer solutions. Advise him to escape from the details and formulate the desired outcome (x or y), without going into the intricacies of the technology. Provide design solution to those versed in this.
-Technical requirements. Sometimes it is necessary to take into account the technical requirements. For example, if a small general vendors will use their iPad device to access the decision, the provision of access through the iPad — the legal specifications. These requirements often refer to architecture — Compatibility with other solutions — or infrastructure, rather than to the functionality or features of the application.
-Requirements for the design process. They relate to the creation of solutions, but not to its purpose. Key examples of requirements for the design — budget and timeline.
-The requirements for information architecture. According to the conventional definition, information architecture relates to methods of description, the organization and content detection.
-The requirements for information management. They determine how to manage content throughout its lifetime: how it is created, maintained, archived or deleted. These requirements apply to safety, records management, audit and compliance with regulations.
-Requirements for the management of services. For the solution content and information is the actual service. Requirements for service management describe recovery, availability and performance. These assets are recognized for the purpose of service level (SLO) or an agreement on the terms of service (SLA).
Separation requirements on category is useful for several reasons. First of all, it is possible to detect dependencies between requirements. This will help you choose a more logical approach to the collection requirements.
It is necessary to consider and define the business requirements and technical requirements before it can be right to state other requirements. Once a decision is determined, we can determine the types of information associated with it. This forces to find out the requirements for information architecture and information management. Business, technical and information requirements define the requirements for the management of services. And they are affected by the requirements of the design process, in particular, budget and timeline. Perhaps the design requirements have to be adjusted to meet the requirements of other categories.
Important note: it is useless to discuss the requirements for the management of information and services are not yet defined business and technical requirements.
If the process is not well organized or introduced additional technical and business requirements, have to re-turn to the requirements of the information architecture, information management and service management.
The second reason it is useful to divide the claims into categories — more effectively proceed to the second step of our process, which focuses on the requirements and information management services. Reserved bilateral interdependence with the requirements of the design process, but, at least, finalized the requirements of business and information architecture on which defines the requirements and information management services. For information architecture requirements we will return to the last stage of the design process management. Define the requirements, you can begin to design solutions that meet these requirements. At this stage, you need to make a choice: to build or buy their own decision. Symptom right approach at this point: sometimes you come to the conclusion that the SharePoint — not the right solution for a specific requirement. Indeed, one can not but agree that SharePoint — not a panacea to meet the needs of the enterprise. Your process should be mature enough to overcome the excessive enthusiasm for the SharePoint when the product is just not suitable for a particular purpose.
We will not waste time on the analysis of technical options. While we are proceeding from the fact that the SharePoint — optimal solution in this situation and move on to the second stage.
Step 2. Harmonization of requirements to control parameters and their scope
In the second phase, we will determine how to design a SharePoint service in accordance with the specific requirements of the organization, especially in terms of information management and services.
First of all, it is necessary to clarify that we call the control parameters in SharePoint. Parameter Management — a configurable setting that somehow affect the controllability of SharePoint. Consider a simple example.
One of the requirements for the management of services should apply to the storage of content (that is, how much storage space will take the content associated with the decision). The requirement to provide a certain amount of storage is realized, of course, with the help of quotas. Quotas are a control parameter that can be customized according to the requirement.
Having identified parameter management that provides a requirement is necessary to define its scope. In SharePoint farm is the physical and logical architecture. Logical architecture is a hierarchy of farms, Web applications, content databases, site collections, sites, lists and libraries.
Web applications have a band and typically consume one or more services, such as search or metadata. A logical hierarchy is shown in Fig. The physical architecture refers to the servers in the farm and distribution services between servers. In other words, on what servers host Web sites on public services (eg, search), and on what — Database SharePoint?
The control parameters are typically in one and only in one container logical or physical architecture SharePoint. For example, the application of the quota — a family of Web sites. You can assign a quota for the site collection, but not for a child site or the entire web application. Nor can configure storage limit for a single user in the site collection group; the initial quota applicable to all content in the site collection, no matter who creates content.
Scope — absolutely critical concept, since it determines the need to whether more than one instance of any object in the logical and physical architecture. If the human resources department and a group of engineers require specific quotas (eg, engineers need more space to store documents and CAD images), then there is no choice: to serve the various needs must be two areas — one for HR and one for the engineers — to which the various quotas . Thus, optionally, go two families of Web sites. If every decision the company has the same requirements for information management and services, it is possible to manage a single farm, a Web application and a content database (size 4 TB) and one family of Web sites. But most likely, the requirements for the management of information and services from a variety of different solutions, and need a lot of areas.
In practice, the field of the control parameters so often tied to the site collections that I call family websites Administrative container architecture SharePoint. Many parameters control services and information, including quota ownership (membership in the Administrators group on the site collection), the area of the client, user and group management, auditing, blocking, sandbox and search options are linked to the areas at the level of the site collection. It is also necessary to take into account the possibility of a control parameter. For example, there is a wild claim management services — to back up data in major decisions every minute. If the amount of content is large enough, it is simply impossible to meet this requirement using API-interfaces SharePoint.
Another example — a sandbox. If the requirement of service management — to isolate the user’s code, you can configure a sandbox — a control parameter to the areas covered by the family of Web sites. Once activated the sandbox, the administrator of the site collection can transfer solutions in the sandbox and activate them. Ready features to add workflow, through which another administrator of a higher level can approve the decision before its activation does not exist.
In this case, the keyword «ready.» Although the parameters of SharePoint Management may have certain limited areas and opportunities, sometimes you can make or buy tools that expand these areas and opportunities.
Therefore, if there is a situation in which the requirements for the management of information or services lead to unacceptable architecture, you can work around this limitation, write or purchase code that eliminates the limitations or to return to the question of whether SharePoint best technical solution for the implementation of this requirements.
The second stage — the central part of the design process management. It is necessary to define how SharePoint can provide requirements for the management of information or services through the finished or advanced management options, and as a logical and physical architecture required to assign scopes parameters.
Step 3. Matching business requirements with control parameters, functionality and regions
Consideration requirements set in the second step usually provides an architecture that defines farms, servers, web applications, content databases and site vsb- sites. Sometimes architecture extends to the deeper sites, lists and libraries. The resulting architecture will ensure compliance and information management services.
Then you can further enhance the architecture to meet business requirements, in particular, the functional requirements implemented as a function definition, the template list, library, or site.
For example, assume that a business requirement can be accomplished by providing a blog site supervisor of the group. SharePoint implements blogs as a site definition (or pattern), so the logical architecture must include a site for a blog — is usually different from the other content on the site of the collective group.
Step 3 is similar to Step 2, but it uses a different set of requirements to achieve lower levels of the logical architecture. In step 3, the business requirements are not taken into account, even though they are taken into account in the formation of the requirements under consideration and information management services.
Typically, upon completion of this step in the logical architecture, resulting in a second step, adding any subsites, lists and libraries. As a rule, at the stage of 3 farms, servers, Web application, content database, or site collection in the architecture does not change.
Step 4. The combination of the information architecture and manageability
Even a simple SharePoint implementation usually contains more than one family of Web sites, Web applications and farms. And if the content is distributed between two or more site collections, Web applications, or farms, or databases and servers, the work becomes difficult to SharePoint.
First of all, complicated navigation. If you create content within a site collection — for example, the child site — you can add a reference to the parent container for easy navigation users. But if you create a second family of Web sites, such navigation links are not created. It is necessary to control navigation manually, or build or buy a tool for managing and reporting the navigation structure.
Complicated and administration. If a user needs access to the content in each of the two families of Web sites, it should be entered separately in each of them; Identity takes place within a family of Web sites. If you need to get the audit report content, the need to obtain reports from the two families of Web sites; domain configuration and reporting of the audit is a family of Web sites.
As a site collection, as noted above, are the administrative container SharePoint, increasing the load on the administrator immediately after, a second family of Web sites.
To administer and manage SharePoint implementation with two or more farms, Web applications, content databases and site collections best Windows PowerShell. With PowerShcll can organize cyclic processing elements of architecture, easily performing repetitive tasks. Several third-party tools provide an overview of the service SharePoint, no matter how difficult it has no physical and logical architecture.
When designing the architecture of the managed SharePoint implementation final decision almost invariably turns out to be more difficult for the daily management than we would like. The gap between handling and ease of use — an unfortunate consequence of the application platform with a limited but powerful functionality to service multiple business requirements.
Paramount importance workarounds, PowerShell and extensions to SharePoint. Fortunately for all of us, SharePoint has a great community of consultants, developers, project managers, IT professionals, engineers with a certificate MVP and information service providers.