COBIT and SharePoint
Applies to: SharePoint Server 2010
Topic Last Modified: 2010-06-15
The following is an excerpt from the book "SharePoint® Deployment and Governance Using COBIT® 4.1: A Practical Approach," which can be purchased at www.isaca.org book store.
Having completed nearly 50 SharePoint deployments, it is clear to us that SharePoint is much more than a simple replacement for a file share. We have witnessed firsthand how successful deployments enable a fundamental shift in the way people work together and improve productivity. We have also seen deployments fail and be abandoned, becoming “shelfware” littered with ghost towns of content. This governance framework was developed to make sure an enterprise’s SharePoint deployment is widely adopted and impacts the business in a meaningful way while reducing deployment and operational risks.
It took me a while to understand why people are drawn to SharePoint. It came to me during a question and answer session at a presentation on SharePoint capabilities I was doing for a group of users. A senior IT manager from a local hospital told me they had SharePoint 2007 and were looking to deploy it. Immediately I started talking about how great SharePoint could be for patient records, medical imaging and forms automation.
He stopped me midsentence and said, “We have systems for all of that and, frankly, they work just fine. What we are looking for is a way for departments to communicate better throughout the hospital.”I suddenly realized that SharePoint is a new kind of medium that allows people to broadcast and interact with channels of information.
SharePoint is like cable TV. Every channel is a different group of people who work together on initiatives within and between departmental groups. There can even be channels that are specific to an idea or group of people. It is the ultimate interactive TV except that it is a PC and runs over an IP network. Yes, it could be a great way to automate forms and share medical records, but at the root of it all, it is a great tool that allows people to work together more productively.
As “SharePointers” already know, SharePoint lets administrators and developers snap in or activate prebuilt Web Parts and features to quickly build pages with complex containers. These containers usually hold lists of things. These lists can be files, contacts, links to web sites, FAQs and so on. It also lets the user build pages (templates) that allow users to add content without requiring HTML or coding. These capabilities include a self-service model that lets users add sites, pages or content if they have the proper permissions.
Every initiative, product, team, department or user can have its own page or web site. Because of this capability, the growth of SharePoint is usually explosive and exponential in terms of size and complexity as users and capabilities are quickly added to the system. Each group has its own galaxy of needs and requirements to solve business problems using SharePoint. The wave of recognition by the business that SharePoint is a new tool and a new way to solve many common business problems is the catalyst for the SharePoint effect described previously.
While Microsoft has sold over 100 million seats of SharePoint, we estimate that only half of those seats have been deployed. The difference between what has been sold and what has been deployed is sometimes called the “white space.” This white space represents the licenses that are sitting unused. We believe most of these are in corporate environments. So why are so many seats of SharePoint going unused?
We believe the white space is a result of IT deploying SharePoint using a shared services model with little or no governance. Time and time again, we have been called in to consult after ill-defined SharePoint solutions, built by business units or IT on shared service SharePoint farms, have been released to an unprepared or untrained user community. Alternatively, we have seen SharePoint deployments become viral and overwhelm all planned support capabilities. In either scenario, returns are usually less than expected, stopping or curtailing planned rollouts because the promise of SharePoint has not been met. Proper governance will close the white space in the enterprise. The remainder of this text offers a governance framework that will ensure that expectations are met and the SharePoint investment maximized.
We believe that a well-enforced governance framework is critical for the successful deployment and operation of SharePoint. We will explore the case for governance and let the readers examine our reasoning.
Let us start with the case for governance by looking at the alternatives. One could let SharePoint roll out without any control. Staff could deploy as they see fit based upon their ability to develop applications and muster resources. Inevitably, the system can easily become a tangled mess with inconsistent branding, poor navigation and little or no security and control. Let us examine a real-world metaphor.
If it helps, users can consider themselves the zoning commissioners for “SharePointland.” The framework presented in this text provides a prescriptive approach to ensure that the SharePoint community thrives and grows.
I was struggling to come up with a real-world example of uncontrolled growth and it hit me: zoning laws for a community.
Imagine that there were no zoning laws. Contractors and builders could develop new projects as they wished. Chemical plants could be placed next to school yards. Twenty small houses could be crammed into a small area with sewers and electrical systems that could safely support only four or five homes. Zoning laws exist to make sure buildings are built within the limits of the infrastructure. Safety, noise and the proper mix of industrial and residential buildings are considered.
World-class SharePoint governance delivers many of the same benefits of zoning laws. Proper governance should create a stable and valuable set of processes and procedures that allow for growth in a controlled and productive fashion while limiting the exposure or effects of risk to the enterprise. It should utilize resources in the most productive way possible and it should prevent the oversaturation of critical infrastructure so that support and performance do not degrade.
If it helps, users can consider themselves the zoning commissioners for “SharePointland.” The framework presented in this text provides a prescriptive approach to ensure that the SharePoint community thrives and grows.
Our early attempts to apply CobiT to SharePoint governance, out-of-the-box, proved impractical. The CobiT principles were on target, but the order prescribed by following the CobiT framework, verbatim from Plan and Organise through Monitor and Evaluate, did not fit the chronological needs of a SharePoint deployment. These early attempts taught us that we needed to segregate CobiT principles into phases that mirrored natural rhythms found in a SharePoint deployment or enhancement life cycle.
Having seen firsthand how SharePoint is planned, deployed and maintained, we created a governance framework to parallel these efforts. The result is a practical and prescriptive model of how governance is applied within the SharePoint domain, using the CobiT framework. This guide is a direct result of lessons learned during SharePoint deployments and applying them in real-world SharePoint 2007 implementations. It represents the first known attempt to map CobiT in a practical way to the governance of SharePoint.
Our governance framework is broken into six phases (figure 3). The key point is that CobiT has been adopted at the process level. The governance framework presented in this text places all of the processes from CobiT 4.1 into one of the appropriate phases of the software development life cycle (SDLC) for the deployment, operation and enhancement of SharePoint. Once the CobiT 4.1 process is mapped within one of the six phases, specific control objectives that relate to SharePoint deployment or operation are prescribed to satisfy the essence of the control objectives defined in CobiT for that CobiT process.
For example, the scope phase of the governance methodology contains the following CobiT processes:
PO1 Define a strategic IT plan.
PO2 Define the information architecture.
A narrative explaining the risk of not conforming to the guideline is also included in each process description. A definition of the mitigation of the risk is offered, followed by a detailed discussion of a prescriptive approach to mitigation/compensation to meet the goals of that activity or process.
An example will prove helpful. In the example in figure 4, PO2 is a process of the CobiT Plan and Organise domain prescribed within the scope phase. Note how the essence of the control objectives has been mapped into SharePoint controls and activities. Also note the highlighting of the risks of not adopting these controls and activities and how these risks can be mitigated or compensated.
Notice that the prescribed control objectives capture the essence of relevant CobiT 4.1 control objectives within a SharePoint context rather than an explicit one-to-one mapping. These are identified by a letter designation that is unique to this application, so as not to confuse the reader with the CobiT control objectives, which are designated numerically. Conversely, note also that we map explicitly to every CobiT 4.1 process since we believe all of the processes prescribed by CobiT 4.1 are relevant and should be met to properly govern SharePoint.
The savvy CobiT reader will note that while we have included verbatim every CobiT process within our methodology, we have taken liberties at the CobiT 4.1 control objective level and prescribed activities that capture the essence of the control objectives in a way that makes sense in a SharePoint context. Note also that most, but not all, control objectives are captured within the methodology. Indeed, in many cases, we include additional activities and tasks that are specific to SharePoint deployment and governance. An explicit mapping between CobiT 4.1 at the process level and our framework is included in appendix E.
Finally, we have not listed every conceivable activity or task that could be prescribed to meet CobiT 4.1 processes and control objectives. The control objectives we have listed for each CobiT 4.1 process are general in nature and form a good place to start the governance of SharePoint and to mitigate or compensate for its risks. When reviewing this text, think of this framework as a starting point that can be added to based upon the needs of the enterprise.
It is not expected that all of the processes and tasks prescribed for every phase will be satisfied before moving to the next. This is a goal-oriented framework similar to Total Quality Management (TQM), which sets horizons for each phase. Some of the objectives may seem to be continually just out of reach, and that is fine. Think of them as goals: some are attainable while others may be guideposts to lead the way.
Throughout the governance framework, we continuously note the risks of not adopting or following the prescribed control objectives outlined for each process. Mitigating or compensating controls form an approach used by an enterprise to meet regulatory, statutory or business requirements. Controls specify the method chosen to address a risk associated with a process such as PO2 Define the information architecture. These controls can be applied as part of a mitigating or a compensating strategy. Risk mitigation means performing tasks or activities (controls) that will reduce the likelihood or impact of risk associated with a process, while risk compensation involves tasks or activities that tend to circumvent or avoid risk.
The control objectives specified in this framework for each CobiT 4.1 process are designed to meet mitigating or compensating goals and are exactly what IT auditors will look for when reviewing a SharePoint environment. Indeed, the majority of this book is focused on defining the proper control objectives to mitigate or compensate for risks associated with SharePoint deployment or enhancements. This text will also help in meeting regulatory requirements such as the US Sarbanes-Oxley Act (SOX) or the US Health Insurance Portability and Accountability Act (HIPAA).
Let us explore these concepts in greater detail, using driving to the store as a way to demonstrate the concepts in everyday terms. The driver of a car assumes a certain level of risk: “I might get in an accident on the way to the store.” A mitigating activity to reduce the impact (literally, in this case) of the risk associated with driving a car (and subsequently being involved in an accident), might include purchasing a Humvee. If the driver is involved in a collision, the chances of harm resulting are greatly reduced (mitigated) by driving a semiarmored 7,000-pound vehicle. A compensating activity to the perceived risk of driving to the store might be simply to walk instead. Thus, a modification in behavior, or process, compensates for the perceived risk of injury while driving, by avoiding the activity altogether.
There are many regulatory and statutory requirements for enterprises engaged in business. If a company undergoes regular compliance audits—SOX, HIPAA, Payment Card Industry (PCI) Data Security Standards or others—adherence to the framework in this publication, and by extension, the CobiT framework in general, will meet many of the compliance objectives and requirements for the operation and maintenance of SharePoint. Auditors will quickly understand the framework described in this text and ascertain what, if any, steps are needed to remediate compliance concerns.
Let us take a deeper look at how the governance framework is organized. The governance framework is based upon an iterative life cycle approach. The framework begins with identifying controls and processes that should be put in place to define what the business needs and what functionality should be included for the SharePoint launch. It progresses through a series of phases, preparing for the deployment and operation of SharePoint before it is launched. The framework continues with prescriptive advice for deployment, system operations and monitoring. Following this, we review the subset of activities that should be considered when undertaking an enhancement rather than an initial SharePoint launch. Note that this governance framework is equally valid on a fresh install or on an existing SharePoint deployment. The following describes the goals of each phase of the framework:
Scope—This phase is centered on defining the processes, people and activities required to set the scope of the SharePoint deployment. Goals include creating a steering committee, creating processes and procedures to gather a wide range of requirements, and then carving these requirements into a manageable scope.
Plan for launch—This phase is focused on developing the processes and procedures to successfully launch SharePoint. It identifies the skill requirements, assesses the readiness of the team, identifies any staffing or skill set shortcomings and develops a plan to address these issues. Service levels are agreed upon and the hardware and software requirements are identified and reviewed. Finally, content review processes are identified, retention schedules are defined and a cost allocation model to pay for usage is developed.
Prepare for operations—This phase defines the processes and procedures to support and operate SharePoint once it is launched. Note: this phase is completed before SharePoint is launched. Operational processes and procedures—including training the developers, reviewing software and hardware sourcing agreements, and determining how users are authenticated—are established. This phase also includes developing policies and procedures for backup, incident reporting and support, handling of change requests, and management of third-party services. Operational plans are developed and reviewed, tools to manage SharePoint are selected, monitoring practices for SharePoint are developed and ways to measure service level agreements are reviewed. Finally, policies are developed to monitor and evaluate internal controls, data sources, error logs and data integrity.
Launch—As the name suggests, this is the phase when SharePoint or an enhancement to SharePoint is launched. All of the activities from the scope, planning for launch and prepare for operations phases are put to the test. This phase is focused on creating the policies and procedures for managing support desk incidents, ensuring compliance with external requirements and accrediting how content is migrated, including the quality of the data once they have been migrated into SharePoint. The phase also establishes how the results of the data migration are communicated to the business and technical communities. Finally, processes surrounding the test plan are reviewed with regard to how changes are promoted between the development, test and production environments.
Operate—SharePoint adoption can be explosive. This phase is focused on developing processes and procedures to manage the tactical, day-to-day aspects of SharePoint. It includes acquiring and configuring tools to monitor the farm performance and system usage and then configuring them to ensure that SharePoint is responsive to users and meets their needs. Policies and procedures are developed for hardware and software enhancements and tuning, defining capacity planning thresholds, and reviewing procurement methods for additional software and hardware enhancements to ensure that they are acquired in a timely fashion. Administrative guidelines and policies for indexing, content storage and developing backup strategies are also developed in this phase. The operate phase includes developing storage and usage projections and monitoring them to ensure that the system can support expected responsiveness and load. This phase also includes creating policies and procedures to monitor growth projections against actual growth and recommend adjustments as needed. Training is also evaluated to ensure that staff has the background needed to manage the farm. Problem resolution policies and procedures are reviewed and modified as necessary to ensure timely response to user support issues.Additional activities in this phase include setting up policies and procedures to monitor expected vs. actual investments in SharePoint, maintaining documentation on the hardware and software configuration, and conducting operational infrastructure reviews ensuring the system architecture is up to date with the actual system as it exists. Finally, this phase includes a reexamination of governance policies to ensure that they are responsive to business needs.
Enhance—The enhance phase covers upgrades and changes to functionality or capabilities of SharePoint after it has gone live. The enhance phase processes and control objectives follow a subset of activities, policies and procedures from every phase described previously as necessary to ensure that SharePoint can change and improve as business needs dictate.
With any plan or framework comes risk. The items listed below highlight the most obvious risks that must be addressed in preparing and implementing this framework: • Inadequate executive sponsorship and direction• Unwillingness of IT to align or support business needs• Inability of the governing body to make decisions• Failure of internal staff or third parties to follow the policies and procedures set by the governing body• Information technology staff’s lack of discipline to follow policies and procedures• Deployment of SharePoint widely across the enterprise and current user resistance to governance because the risks or costs of the current ungoverned approach are not understood• The business’s demand for service levels that are not possible within the allocated budget or technology• The business’s demand for system features and functionality that are not possible within the allocated budget or technologyAll of these should be addressed head-on. These are obstacles that can pop up at any time and in any phase of the SharePoint initiative.
This framework was built to be practical. Each task or activity contains a description of what the item or activity means in the context of a SharePoint deployment and others suggest compensating or mitigating controls. Many tasks or activities include a table with sample entries. A mitigating or compensating control and the corresponding table should be completed for each task or activity so a record can be given to auditors and staff for reference as needed. Progress can be tracked using the worksheet in appendix D as the mitigating or compensating processes and procedures needed for a successful deployment are built. This chart is handy for highlighting areas that need attention and improvement.
|This framework is exhaustive in scope and breadth and it is not expected that anyone will satisfy every activity listed in every phase of the framework. Users should review all the suggested activities, and then complete as many in each phase as is practical for their situation. Also, it is not necessary to accomplish every step in a preceding phase to move into the next. Ultimately, the specific needs and constraints of the enterprise should determine when to move forward.|
A framework is not very useful without the tools to implement the prescriptive guidance. A list of tools can be found in appendix B. These tools are useful to gather the data or add the compensating or mitigating controls called for in the governance framework. Each governance activity is shown on the left side of the table and a cell is selected in the column headed by a tool if it can be used to help compensate or mitigate the risk associated with the task or the activity.
This framework can be used even if SharePoint has already been deployed. It is never too late to start governing SharePoint. Those working in an already deployed environment should begin by completing activities in the scope phase and continue through the framework from left to right. Issues should be remediated as policies are set and communication undertaken with users, often explaining the benefits they will derive from these governance efforts. Users can be invited to participate on the governance steering committee and their input actively sought. Appendix A includes a description of concrete steps to take to get started with this framework in the already deployed environment.
The remainder of the book consists of a chapter for each phase of the framework, including a list of the activities and sample tables to use to record progress. We have included a chapter on the governance of a cloud-based SharePoint deployment. Finally, the book concludes with appendices containing practical advice on how the governance framework can be applied to the deployment of SharePoint, including advice on how to get started governing your SharePoint farm.