Chapter.10 166. Chapter 10 SharePoint Configuration Management The CCB, coordinating with the technical authority and interfacing teams, can do the following: • Ensure that investigations are performed into the cause of failures and that suggested changes to the SQL platform are evaluated. • Allocate resources to such investigations (for example, the interfacing teams, whether they be the SQL teams, infrastructure teams, or others). • Determine the faults and their underlying causes. As an example, the “fault” would be that there was not enough space on the SQL server, while the “cause” would be insuf- ficient planning, lack of monitoring, lack of governance, or all three. • Authorize the investigation of design changes and any necessary corrective action and monitor the effectiveness of such actions (such as altering the disk type, altering disk capacity, or strengthening the monitoring process). • Monitor the 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 CM policy and the techniques to be applied on the project. If the policy deviates from that stated in the CM 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 as follows: • The designated CM authorities for the project. Who is responsible for managing the process, making decisions, and owning SharePoint 2010 (business and technical)? (For more information on this topic, see Chapter 9, “SharePoint Governance.”) • 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.) • The project manager should appoint a configuration authority who will control the CM activities on behalf of the project manager. Chapter.10 How to Apply Configuration Management in SharePoint. 167 Table 10-1 lists common configuration terms used in a SharePoint 2010 implementation project. Table.10-1. Configuration Management Terms Term Definition Configuration Item An item selected for CM. Configuration items are established on a hierarchical basis, with one item comprising the com- plete product (hardware and software). This is then broken down into its lower level constituent items or parts, each with its own reference number. Configuration Baseline A specification or product that has been reviewed and agreed on that therefore serves as a basis for further development. A baseline can be modified only through formal change control processes. Controlled Item An item that is not identified as a configured item but still requires controlling in a formal manner (for example, the SharePoint 2010 Quality Plan or SharePoint 2010 Project Plan). Configuration Control The systematic evaluation, coordination, approval, and dis- semination of proposed changes and the implementation of all approved changes in a configured item. Master Record Index The index or indexes to the master set of drawings and speci- fications that define the configuration item. This term is used generally to refer to a set of indexes that provides a record of the configuration items. How.to.Apply.Configuration.Management.in.SharePoint To apply CM in SharePoint, you need to state a policy for its use and define the related pro- cedures. You need to ensure that any deviation from this policy, together with designated CM authorities for the SharePoint 2010 implementation project, is documented in the SharePoint 2010 Quality Plan. Other CM details can be contained in the SharePoint 2010 Quality Plan or in a separate CM plan, depending on any contractual arrangements or the size and complexity of the SharePoint implementation. As the SharePoint Plan phase starts, so should CM. You must choose a set of methods, pro- cedures, and tools to satisfy the requirements in the following lists. If the client organization does not have any CM processes in place, you need to create those processes. An excel- lent method of doing this is to use your project management site (as detailed in Chapter 6, “Gathering the Resources for SharePoint Implementation,” which discusses SharePoint components and associated pieces in the section, “Using SharePoint 2010 Sites for Proj- ect Recording” on page 115) for CM because that is also where all the project data will be stored. Chapter 10 168 Chapter 10 SharePoint Configuration Management If the client does have a full CM process running, investigate it and find out if either there is connectivity between that and the Project SharePoint site or the CM process in place includes the following requirements: • Enable unique identification and description of SharePoint 2010 and its components. • Enable the evolution of products and their components to be controlled and traced. • Enable identification and control of the means by which products will evolve to sat- isfy their requirements. • Record securely and maintain all the information required. • Provide validated, identical copies of products. Note Sites in staging and production SharePoint environments should be functionally iden- tical. This means that the site structures should be the same; however, that does not mean they should be identical data-wise. Trying to make SharePoint sites fully synchro- nized between staging and production environments requires a significant amount of time and becomes more of an issue as the amount of data grows in the production environment. To satisfy these fundamental requirements, the CM system should provide the following: • Methods for unique identification and version control for all products and all compo- nents of a product • Methods for receiving and acting on observations about a product and for recording and controlling changes that arise • Methods for keeping track of all items being produced or used by a project, includ- ing items inherited or subcontracted • Methods for defining the means by which a product can be built or rebuilt, specifi- cally including any special requirements after delivery or after project completion • Methods for marking, storing, and handling all required media types • Procedures for controlling replication and distribution of products Chapter.10 Bring the SharePoint Item Under Control As It Develops. 169 Bring.the.SharePoint.Item.Under.Control.As.It.Develops Figure 10-2 illustrates when a SharePoint item should be brought under control and how the process could relate to a SharePoint 2010 issue tracking list (if there are no configura- tion tools available). Pre-Configuration Author’s Control Ad-hoc changes introduced Initiating Task (WIF) SharePoint 2010 Issue Tracking List (customized to include pre and post configuration statuses) VERSION CONTROL - DRAFT Initial Internal Release Configuration Baseline Established Creation of Indexes such as Master Record Index “Controlled” Issue Under “Contractor Formal Control” “Under Client Control” Changes introduced through commented feedback (e.g., review record) Changes introduced through formal Customer Panels and Contract Amendment Changes introduced through formal Observation Report & Change Request, reviewed by a Change Control Board Post-Configuration VERSION CONTROL - MAJOR METADATA - STATUS UPDATE METADATA - ClIENT CONTROL METADATA Figure.10-2. Configuration management item process related to a SharePoint list. Figure 10-2 shows the passage of a configurable item from its generation to the point where it comes under customer control. Each of the vertical lines represents a formal stage in the development of the item. After the internal review cycle is complete, the item will be raised to version 1, or if it’s being updated, to the next appropriate version number, and then it is issued for external use. From that point on, its status shall be recorded in the Configuration Baseline Index and any changes to the item must be introduced via formal configuration control procedures. (See the section, “Changes to Configured Items Must be Controlled” on page 171.) When the client takes delivery and control of the product, a for- mal Master Record Index needs to be generated for each configuration item. Chapter 10 170 Chapter 10 SharePoint Configuration Management Note The creation of a configuration baseline is not a one-time only event. These baselines are often recreated over time as major, coordinated changes to the environment are approved. Control the Item Prior to Configuration Management While a configuration item is being developed during the preconfiguration stage, the author is free to make whatever changes might be necessary on a day-to-day basis. Under- standing the development of the item is still important, and significant changes should be recorded as part of the configuration item. For example, in SharePoint 2010, you could (as shown in Figure 10-2) construct a list with version control switched on using minor and major versions. These versions allow you to enter comments as the item moves from draft version to draft version until it becomes a configured item. Bring the Configured Item Under Configuration Management at the Right Time As the development of the item stabilizes, the baseline standard can be declared and the item brought under configuration control. Each configuration item must be given a unique reference number. All configurable items must be regularly reviewed. The review record might initiate further changes to the item, causing the draft number to be raised. Maintain- ing all the comment copies of a technical document is not necessary, provided the record or minutes are maintained to provide the traceability of the review process. Establish a Configuration Baseline for Each Item A configuration baseline index shall be formally maintained as a status and history record of the project’s configuration items. The index must include the hierarchy and interrelation- ships of the items. At appropriate points in the project development and certainly when the product is ready for delivery, it is necessary to produce an index of all configuration items. This index is often called the Master Record Index (MRI). For software products, a build definition, which defines the software and computing content of the release, must be prepared. A suitable Software Build Definition template is available at: http://sbt.geoffevelyn.com. Chapter.10 Changes to Configured Items Must Be Controlled. 171 A.Configuration.Status.Account.Provides.History Configuration status accounting is a mechanism for providing records of the current status of all the project’s configuration items. The configuration status records provide complete traceability of what has happened to the configuration to date; these records can be cen- tralized into the SharePoint 2010 implementation project site. For example, you could have an item subject to version control and carrying metadata— a multichoice column called Configuration Status, for example. This Configuration Status column could have values defining the configuration level of the item. This means that not only do you have traceable history, but you can also identify when and who made altera- tions to the configuration status. Also, if any comments were made at the time, they would also be available. Changes.to.Configured.Items.Must.Be.Controlled Once an item comes under configuration control, changes can be introduced only by means of a formal change control process. All items in a SharePoint production environ- ment and SharePoint user acceptance document come under CM. Figure 10-3 shows a SharePoint 2010 implementation in a processing chain. The control process is designed to ensure the following: • The basis of the documentation supporting the configured item is maintained to reflect the delivered version. • The interfaces to other configured items, hardware or software, are clearly defined. • The traceability of configured items back to contractual requirements can be demonstrated. • Correct authorization is given to any changes. • The traceability between changes and modified parts of configured items is maintained. • For SharePoint software, simultaneous updating of a configured software item is prevented. Chapter.10 172. Chapter 10 SharePoint Configuration Management Project Staff Project Manager Project Manager Raise Change Request Initiate Investigation Task Quality Client Client Project Manager Test Modification Review Modification Raise Issue Update Configuration Baseline Accept Modification Accept OR Reject OR Reject Modification Convene CCB or SharePoint Governance Committe Raise an Observation Report (OR) Project Staff Quality Contractor Close OR / CR Release Next Version Decide on CR Initiate Task to Modify Product, Documentation Other Staff Figure.10-3. Report processing chain in configuration management. Chapter.10 Summary. 173 A need for a change can be identified by any of the functions connected with the project, by a subcontractor or by the client; the reporting processing chain as depicted in Figure 10-3 identifies that the configuration board is responsible for reviewing changes. All such requests for clarification or concessions, queries, or simply suggestions for improvement in the SharePoint item should be documented. Summary Every item concerning SharePoint running in a production environment is subject to CM, whose rules are bound by service management, governance, and the SharePoint 2010 Quality Plan. There will be those who would attempt to argue that CM is overkill, because there is far too much “process” and it would hamper SharePoint creativity. My response takes the form of a question: How do you know who created what? If the client cannot answer what constitutes SharePoint operations, they do not have an environment under control, neither do they have an environment duly documented to show the purpose, premise, and operation of the SharePoint environment. CM manages, records, and structures project data so that anything that takes place in delivering a product has a history from the point it was designed to the point it was imple- mented. For example, in the Plan phase of the SharePoint implementation, a number of investigations lead to document outputs that require signoff. These documents make up areas of the SharePoint implementation. 175 Chapter 11 Making Sure SharePoint Meets User Requirements Data Growth Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Content Usage Policies and Governance . . . . . . . . . . . . 180 Training and Education Planning . . . . . . . . . . . . . . . . . . . 181 Monitoring and Maintenance Planning . . . . . . . . . . . . . 185 Finding Out What the Users Want to Do with SharePoint 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 T he SharePoint 2010 implementation needs to meet user requirements and the client’s vision. The client’s vision can be defined through the three high-level organizational goals: • Organizational productivity • Personal/team productivity • Infrastructure productivity The three goals are also described in Chapter 2, “SharePoint 2010 Project Mantra,” and Chap- ter 3, “Content of Your SharePoint 2010 Project Plan.” The user requirements need to be obtained to ensure that you have a managed SharePoint platform, an understanding of interconnected tools and applications, and an understand- ing of how they will map to user requirements. Additionally, collecting these requirements allows you to better identify where data should be consolidated, reduce and improve data management, and reduce duplication. The output of this investigation leads to the production of a framework describing the structure and features applied to SharePoint 2010. If user requirements are not investigated, there will be SharePoint implementation pain, leading to a failure in SharePoint governance, and a failure to raise to an appropriate level the users’ understanding of SharePoint 2010 and what the platform is capable of. These shortcomings will make it difficult to implement and manage the SharePoint platform and lead to the following user-related problems: . manner (for example, the SharePoint 201 0 Quality Plan or SharePoint 201 0 Project Plan). Configuration Control The systematic evaluation, coordination, approval, and dis- semination of proposed changes. the SharePoint 201 0 Quality Plan or in a separate CM plan, depending on any contractual arrangements or the size and complexity of the SharePoint implementation. As the SharePoint Plan phase starts,. change control process. All items in a SharePoint production environ- ment and SharePoint user acceptance document come under CM. Figure 1 0-3 shows a SharePoint 201 0 implementation in a processing