from Chapter 10
SharePoint Configuration Management (CM) involves controlling specifications, drawings, software assets, and related documentation, which define the functional and physical characteristics of a SharePoint implementation, down to the lowest level that’s required to assure standardization. The CM process also provides a documented, traceable history of the development lifecycle of SharePoint in an organization, including modifications, upgrades, or variants.
On many small SharePoint projects, the only deliverable is a single report that needs to be ”controlled” rather that configured, without the full weight of CM policies being applied to it. A “controlled” document is produced in accordance with Document and Data.
SharePoint, when implemented, is defined by identifying the configurable items that are based on its critical technical, administrative, and maintenance components. The selection process is one of separating the elements of SharePoint on a hierarchical basis for the purpose of managing their baseline characteristics.
For the implementation, your BUILD tasks show what is required to be implemented in SharePoint, and each of these fall under CM; this means understanding how the procedures relate to controlling any work carried out in the installation of SharePoint. The features that are associated with the implementation, installation, and configuration of SharePoint, as well as any associated assets (e.g., documentation), are subject to CM.
To summarize the BUILD tasks, they are:
- Deploy a Pilot System
- Deploy a Staging System
- Deploy a Production System
Within each of these Tasks there are subtasks concerning the installation of hardware, software, key components and there are major decision gates from stakeholders in these tasks, (meaning sign offs, for example) from the completion of the SharePoint Pilot to Staging to Production. Configuration Management is critical in ensuring that changes to these environments are controlled.
In SharePoint, a configurable item is any entity in SharePoint that requires control – you could therefore apply configuration management processes to any data content types in SharePoint.
The following figure illustrates the degrees of control, which are applied to a configurable item during its implementation lifecycle.
Initially an item is uncontrolled while under development by the author. The author is the creator of the item (e.g., SharePoint Administrator / Architect / Interfacing Team member, perhaps even a person uploading a document into a Document Library). The item becomes controlled once a unique identifier has been allocated and the item is subject to review. Once the development of an identified configurable item is sufficiently stable to declare a baseline standard, it will be subject to configuration control processes.
Documents that are not identified as configured items (e.g., SharePoint 2010 Quality and SharePoint 2010 Project Implementation plans) will still be controlled in accordance with Document and Data Control.
On small projects, configuration management techniques may be applied by the project staff using a simple SharePoint list to control baselines as well as to record the version / issue status of the identified configurable items.
On larger projects, particularly where a large number of hardware drawings or modules of SharePoint features have been produced, CM may be delegated to specialist staff. The advantage of a central site CM facility, with its own specialized staff and archive, is the long term maintenance of project configuration records. However, the production of SharePoint add on features (e.g., Web Parts, Automation, Branding, Site Definitions, etc.) is particularly well suited to the use of configuration management and tools, remaining under project control.
The complexity of the SharePoint implementation may also define the product that you decide to use to manage CM. For example, if you have a development team working on the SharePoint project, you may wish to use Microsoft Team Foundation Server. A video that describes how to use this product can be found at http://subversion.apache.org/. However, a SharePoint 2010 Team site can also be configured to hold an Issue Tracking List to carry out basic CM tracking and Product Lifecycle control.
Configuration Management Applies to SharePoint
Configuration Management is mandatory for all SharePoint projects, not just its implementation. You cannot have a controlled SharePoint environment without records concerning its makeup and traceability concerning changes made. As a Project Manager, the handover of SharePoint is not just a document stating “I’ve finished implementing SharePoint for you, off you go”, it’s a system handover meaning everything that the Project Implementation can be audited on and everything that the Project has an asset of (and that includes all documentation, technical specifications, software assets, etc.)
Configuration Management is needed for any deliverable of hardware or software or where there is a change to either of those in a production arena. Configuration Management applies to configured items that are used in the development of a SharePoint product but are not a deliverable in their own right. Typical configuration items include:
- SharePoint 2010 specification (design, topology, network connectivity)
- Test Plans
- Drawings (high-level and detailed)
- SharePoint Software Assets, and if any additional development applied to SharePoint, any code, program listings, associated documentation
- Service or User Manuals
Other items to which Configuration Management applies must be identified by the Project Staff and staff during the SharePoint Implementation; these would be subject to review by the Project Manager or a nominated configuration authority.
SharePoint configuration management defines processes that describe the following:
- Makeup of Infrastructure
- Software and Hardware Assets
- Modification / Procurement
- Tracking and Audit
Understanding the Components
Even before building a SharePoint instance, and even before someone mentions - "hey what kind of server do you want?" You need to create a report based on the schema required for your SharePoint sites; to do this, you document through analysis the capacity and performance levels your SharePoint farm needs.
Assuming that you have accomplished these steps and have defined the specification, you then need to ensure you have the level of documentation required to install SharePoint from start to finish.
It is vital that you have people running SharePoint Configuration Management who follow the process and can engage others to follow. When configuration management personnel leave a SharePoint project without replacing them with other qualified people, the relationship between a well-implemented configuration management program and maintaining basic project integrity can become painfully clear.
The basic or lowest level of configuration items for SharePoint under which configuration management (CM) will apply is the software under which SharePoint operates.
Initial design of a site if not under strict control does not need to come under formal configuration, but in some circumstances it is really important. For example, let us imagine that a SharePoint Team Site starts as a very small Project Management Office (PMO) site, in a company where the culture isn't strict in terms of website control, and did not document the PMO site design. Without company buy-in to a CM there is a risk of SharePoint 2010 implementation failure – meaning that quality cannot be inspected in SharePoint use.
Failure to introduce CM, without full support and understanding from the client, leaves SharePoint 2010 implementation projects open to issues of credibility and a loss of customer confidence. Such a situation can also result in additional unplanned costs in time and resources that are needed to redo the work.
When to Apply Configuration Management in SharePoint
You can use CM in SharePoint for just about anything that needs to be controlled, from an item going into a site, to a process concerning document management, to a workflow that’s tied to an Issue Tracking List, to administration of a site. Because CM is a methodology that can be applied, all you need to do is follow the procedures as outlined here. The focus is on the implementation of SharePoint, the three phases of implementation, and how it maps to CM. The phases are PLAN, BUILD, and DEPLOY.
SharePoint CM ties into managing SharePoint through issues that concern outages and failures resulting in users not able to carry out their work.
For example, let’s say an element of SharePoint implementation has failed. Users are unable to save new work to their sites. Upon initial investigation, it appears that the SQL Server has no capacity remaining following an upload of data from a File Server. It also appears that there was little monitoring or measurement concerning growth rates on the SQL Server. Because you have a Configuration Change Board (or your SharePoint Governance Committee if you don’t have a CCB), you can count on them to plan and manage this situation so the client is comfortable that the resolution will result in a more effective platform.
The Configuration Change Board (CCB), in liaison with the Technical Authority and Interfacing Teams, can:
- Ensure that investigations into suggested changes on the SQL platform and the cause of failures are undertaken
- Allocate resources to such an investigation (i.e., the Interfacing Teams – e.g. SQL Teams, Infrastructure Teams etc.)
- Agree as to faults and their underlying causes (i.e., fault, not enough space on SQL server, cause insufficient planning, lack of monitoring, lack of governance)
- Authorize the investigation of design changes and any necessary corrective action and monitor their effectiveness (i.e., alter disk type, alter disk capacity, strengthen monitoring process)
- Monitor progress of these investigations
- Identify reliability – and significant failures
- Identify maintenance problems
The Project Manager Specifies the Configuration Management Policy
The Project Manager is responsible for defining the configuration policy and the techniques to be applied to the project. If the policy deviates from the one that’s stated in the Configuration Management procedures, those deviations must be defined in the SharePoint 2010 Quality Plan.
Additional issues that also need to be recorded in the SharePoint 2010 Quality Plan are:
- The configuration management authorities for the project, who are responsible for managing the process, making decisions, owning SharePoint 2010 (business and technical), etc.
- The identity of the root document or source from which all configuration status records can be traced (normally this is the SharePoint 2010 Quality Plan)
- A configuration authority who is appointed by the Project Manager and who will control the CM activities on behalf of the Project Manager
Several common configuration management terms are important to understand at this point.
A configuration item is selected for configuration management. Configuration Items are established on a hierarchical basis with one item comprising the complete product (hardware / software). Subsequently, this is broken down into its lower level constituent items or parts, each with its own reference number
A configuration baseline is a specification or product that has been reviewed and agreed on, which, therefore, serves as a basis for further development. A baseline can be modified only through formal change-control processes.
A controlled item is not identified as a configured item, but it still requires controlling in a formal manner (e.g., SharePoint 2010 Quality or SharePoint 2010 Project Plan).
A configuration control is the systematic evaluation, coordination, approval, and dissemination of proposed changes, and the implementation of all approved changes in a configured item.
Master Record Index
This is the index(es) to the master set of drawings and specifications, which define the configuration item. This term is used generally to refer to a set of indexes that provides a record of the configuration items.