This article can also be found in the Premium Editorial Download "SharePoint Insider: SharePoint 2010 implementation project plan: Keys to success."
Download it now to read this article plus other related content.
Since its first release roughly a decade ago, SharePoint has become increasingly popular with organizations of all sizes for its content management and collaboration capabilities. It has grown so much, in fact, that it’s easy to find enterprises that use SharePoint 2010 features
To avoid such issues, organizations need to sit back and develop cohesive plans for approaching a SharePoint 2010 deployment so that their collaboration investment doesn’t creep out of control. That means thinking carefully about three major issues.
Security, security, security
Like most products, SharePoint brings its own layer of security to the game, and organizations would do well to think about how they’ll manage that security right from the beginning. Because SharePoint will inevitably contain information subject to regulatory and industrial controls, and because most enterprises are subject to at least one set of those controls (think SOX, GLB, HIPPA, PCI DSS, and so forth), it pays to think about security up front.
For example, how will permissions be assigned to resources? It’s easy enough to just use SharePoint’s groups and place users into them, but as permission needs become more granular -- and they will -- an administrator could easily end up managing hundreds or thousands of groups. Instead, consider third-party SharePoint products that add role-based access control (RBAC) to a SharePoint 2010 deployment. Many tools add RBAC to the entire organization, enabling consolidation of file, SharePoint, Exchange, SQL Server and other permissions.
How will a manager audit those permissions? It’s challenging to ensure that only the right people have access to resources, determine that permissions aren’t changing inappropriately and report on “who has access to what” using just the native tools. Again, third-party products can help, but the sooner you implement them, the easier these tasks become.
Don’t allow SharePoint to do what the organization’s file servers have probably already done: slowly grow into an unmanageable state.
Managing SQL Server
As the back-end storage engine for SharePoint 2010, SQL Server often gets short shrift in the SharePoint planning process. Beyond ensuring that there is sufficient SQL Server capacity to handle SharePoint’s demands, what is there to do?
Understand first that SQL Server is not a file server -- but that is, by default, how SharePoint treats it. Smart organizations either deploy a form of Remote BLOB Storage (RBS) to get large files out of SQL Server and back onto the Windows file system, or they use some equivalent third-party mechanism to accomplish the task. Keeping SQL Server trim will mean sustaining better SharePoint performance.
And speaking of keeping SQL Server trim, who’ll be maintaining it? It’s easy enough to say, “Our SharePoint guy(s) will do it,” but managing and maintaining SQL Server is a specialized and distinct skill set. It might not mean having to hire a database administrator (DBA), but if you happen to have DBAs on staff, they’re a good resource for establishing a SQL Server maintenance plan and providing some informal training to the SharePoint team. If there is no DBA, plan to get some DBA training for SharePoint administrators. Those administrators are the ones who’ll be responsible for the SharePoint server. While enterprises might delegate individual site maintenance to certain employees throughout the organization, it still takes an IT professional to manage SharePoint -- and SQL Server -- at the server level.
Keeping track of SharePoint
Speaking of managing SharePoint, what’s the organization’s plan?
Typically, one or more servers are bonded together in a SharePoint farm, which will be managed by IT. Site collections form a top level of organization and are also usually managed by IT, but the individual sites within a collection may be created, or at least managed, by non-IT users. Think of SharePoint as a kind of “shared Web hosting service” where users with a business need show up, create a site, configure that site and populate that site with content. IT doesn’t need to participate at the site level, making it easier for users to make collaboration resources available quickly.
SharePoint is optimally poised to become a “private cloud” service: The right users should be permitted to create sites to meet departmental or project needs, much as organizations use Web hosting services to create simple websites on demand. However, those users should have to “pay” for their SharePoint usage. Make sure SharePoint’s costs can be allocated to its actual users by implementing some kind of charge-back scheme, even if the accounting department doesn’t actually move numbers around. This make it easy to trace a SharePoint 2010 deployment’s costs directly to its business usage, keeping it from being viewed as more “IT overhead” and helping rein in unnecessary growth -- without artificially restricting necessary growth.
It’s key to think hard about how the group will manage SharePoint and what policies will be adopted to control -- but not necessarily limit -- its growth. With the right plan in place, organizations get a better return on their investments and ultimately prevent SharePoint from creeping out of control.
About the author:
Don Jones is a senior partner and principal technologist at strategic IT consulting firm Concentrated Technology LLC.
This was first published in November 2011