In the previous chapters, we discussed SharePoint strategy, SharePoint projects, and governance approaches. Now imagine that you are sitting at your desk and you want to unleash SharePoint into the veins of the organization. This chapter discusses how to grow SharePoint capacity, build and acquire skills sets needed, and allow the reader to understand some of the hidden costs of a SharePoint deployment, and how to assess success after the first year of deployment.
A: Assuming that this is an on-premise installation, the minimal deployment would be SharePoint 2010 Foundation. It already resides on Windows 2008 servers and can be installed for no additional cost. The Content Database and all other services can reside on that one server. The caveat is future-proofing for size, traffic, and lack of features available on Standard and Enterprise Editions.
A SharePoint Foundation deployment would be perfect for smaller operations (both in number of users and overall size of content) or as a Proof of Concept. It allows you to introduce the platform and gives organizations the opportunity to begin with core SharePoint collaboration and out of the box approval workflows.
Be wary of the growth of multiple deployments of individual SharePoint Foundation installations within your organization. Linking them together eventually will require a great deal of custom configuring and cost more than the money saved on not having purchased licenses, planned an architecture and managed a deployment. Attempts to reengineer SharePoint may come back to haunt you when trying to make adjustments to the architecture.
There are feature workarounds, for example pages can be coded to mimic some Standard and Enterprise features, but again is the time and cost of building and maintaining these workarounds going to be greater than the time and cost of having the Out of the Box solutions in place?
A common example of this workaround happens when Foundation is deployed as an Internet-facing site. To effectively use SharePoint for web pages you would need to have the publishing features that will be available in the Standard Edition. These features allow you to build, edit, and post content quickly through web parts.
Because publishing features are not present in Foundation, you could technically open up pages and CSS styles on the background via SharePoint Designer. To include these features would require hardcoding and that takes a high-level skill set. Since rapid publishing features are not available in SharePoint Foundation, the person responsible for the site would have to make any changes by hand coding. So a double loss is possible, one being the loss of time when a highly skilled member of staff would have to constantly make changes to the site and the other being the recovery time that would add up if an under-skilled staff member makes the slightest mistake! If your organization still wants to proceed with a Proof of Concept and sees the need to do so with Standard and Enterprise features there is a way to do so without having to acquire production SharePoint licenses.
If your organization has the Visual Studio Premium or Ultimate level MSDN subscription, then you possess a version of SharePoint that can be used for development and testing purposes only. Once a deployment is moved to production you will be responsible for the correct licensing in accordance with your server environment and Client Access License (CAL) guides based on number of users.
Assuming that this is an on-premise installation, a System Administrator could handle all the duties of installation and maintenance. This person, in short, would be in charge of all aspects from the very technical administration of the server and database environment including backup and security to the creation of site collections, adding/deleting users, and having to respond to end-user needs such as help desk functions and training.
The immediate drawback to this role of being the SharePoint person would be the organizational expectations of this person's time and the business-critical aspects that SharePoint would assume. For example, if critical records are stored in SharePoint, their care and planned recovery would need to be documented. Should an event occur, then this person may be in charge of too much of the entire IT structure and making the recovery of the single item of content could become a much delayed task.
The best plan of attack is to create a Governance Plan/Policies Document and committee (in which a System Administrator would be involved) to keep a watchful eye on your SharePoint deployment. The best way to approach filling roles for this committee is to divide and assign staff into groups such as Operations, Support, Development, and Business Goals.
Ideally if SharePoint is a major part of the organization's strategy then only having an IT admin resource could present some drawbacks. Normally these IT admins are operationally driven and may execute their task in that fashion. This could be very cut and dry. If their task is to install and configure a system they may do that in the quickest manner so as to get the project completed as soon as possible.
This type of execution would not take into consideration the actual business needs or objectives that SharePoint features could address, making this a potential failure before it even had a chance. Lack of communication and true goal setting with the business user section of your organization would ensure this. SharePoint is many things to many people but its true mission is to be a Platform for the end/power user community.
Note
If your SharePoint deployment does not included business-level goals and communication when setting strategy, the likely outcome is that SharePoint becomes "just another other tool to learn" for your staff that does not recognize organizational needs and therefore will not enable staff to realize their potential. In short, why not let your organization's business goals be the driving force for Solution Architecture?