This is the first part in a case study series on SharePoint.
For about six weeks now, I’ve been learning and tinkering with Microsoft SharePoint 2007 (MOSS) at work.
Shortly after starting the new job, my boss — our Associate University Librarian — asked if I had any experience working with Microsoft SharePoint, and if not, would I mind looking into it a bit as a possible document management solution since our campus would be discontinuing its license with the content management module of Blackboard by the end of June . Campus I.T. was offering it for free, so she at least wanted us to consider it.
Now, at this point, I had never even used SharePoint, much less administered it (which, as Systems Librarian, is what would be expected of me). I’m a huge proponent of open source. I prefer Google productivity applications over Office. And as a developer, I’ve had to do battle over the years with a local WAMP stack, and have painstakingly suffered through cleaning up legacy FrontPage-generated code messes. So, I’m not exactly a Microsoft fan. I’d much rather develop a custom Drupal application myself.
But I did agree to at least explore and test the application.
What exactly is SharePoint?
My first item of business was to get a grasp on what SharePoint is, and what it can do.
After sifting through many lengthy wordy published descriptions, my best attempt at a “concise” definition is that SharePoint is a .NET-based rapid application development and deployment framework for creating scalable collaborative content and knowledge management systems.
Although I had never used SharePoint up until this task, I had definitely heard about it — from people that either loved it or hated it. Most of what I heard in the past, though, simply revolved around its document management uses.
Unlike its predecessor, SharePoint 2003, the revamped 2007 product is jam-packed with features. During these six weeks of research and testing, I have merely uncovered the tip of the iceberg in terms of acquainting myself with all of SharePoint’s features, and I continue to educate myself more each day that I use it.
Our campus is using the more robust MOSS, instead of just WSS (see this explanation).
Does it meet our needs?
Because our initial interest in SharePoint revolved around our need to replace the Blackboard content management module, I first looked at what SharePoint offers to meet that basic need:
- It provides a web-based content management solution that allows users with little or no HTML experience to create and edit data, without publishing or uploading via FTP or SSH.
- It provides collaborative workspaces (team sites, calendars, document libraries, etc.) that can be configured for open access to all library faculty and staff, or can be resticted to particular groups or users where necessary.
- It provides full version control, which keeps an accountability paper trail of any changes to a piece of content, and prevents users from clobbering each others’ changes.
- It provides a search engine that does full-text indexing of all content, including attached documents, except when restricted content is intentionally blocked from indexing.
The more I played around with SharePoint, the more I grew to like it, especially as a full intranet solution.
Pollak Library has no actual intranet right now. Instead we have a collection of stand-alone piecemeal applications that don’t actually work together, all of which require separate authentication (remnants of an old Front Page intranet, Blackboard, MediaWiki, WordPress, Google Sites, Google Docs, etc.).
I will blog more about the actual intranet development in later segments of the series.
Why did we agree to it?
After a demonstration and brief pitch to our library dean, my boss (the associate dean), our department chair, and the unit heads, my boss gave me the go-ahead to move forward with a production deployment of SharePoint.
Our reasons for doing so revolved around some pretty convincing arguments:
- Cost: Deploying our own SharePoint instance isn’t costing the library any money. The CSU Chancellor’s office purchased user licenses for the entire California State University system, and our campus I.T. is paying for the server license. From a fiscal perspective, this is as attractive as open source to us.
- Infrastructure: Campus I.T. agreed to install, maintain, and support our SharePoint instance if we use their server. Although this means that Library Systems does not retail full administrative autonomy (we have site admin access, not site collection admin access, per I.T.’s security policy), it also means that Library Systems does not have to dedicate staff time towards maintaining and backing up the server. With such limited staffing in Systems, our time and expertise needs to go more towards supporting services that impact our external customers; we’ll gladly take I.T. up on their offer to help with an intranet solution.
- Integration: Unlike our current piecemeal “intranet”, SharePoint will allow us a full interconnected portal. It works with Microsoft Office, and it incorporates web 2.0 tools like wikis, blogs, and discussion boards. And because I.T. authenticates SharePoint against Active Directory, library faculty and staff simply use their campus network login and password to access the portal (if they use their staff rollout computer, it automatically authenticates).
- Familiarity: Since SharePoint looks and acts like any other Mictosoft product, our users will already have a somewhat established comfort level when learning to use all the different features.
By no means does SharePoint meet all of our needs, but it satisfies the majority. I am confident that we can find alternative solutions, or painless workarounds, to meet our remaining needs. I have yet to find the one perfect portal solution — even Drupal.