Wrapping up this three-part series, we’re going to look at why evaluating SharePoint in addition to traditional point solutions may be a good idea. We’ve covered why point solutions are required and how point solutions are evaluated; it’s time to give the underdog a chance.
SharePoint is a different kind of animal. Whether you’re viewing it as a traditional document management system / enterprise content management system, a collaboration platform, or a development platform – it won’t fit neatly into any of those buckets or any of the dozen or so more buckets you could try to stuff SharePoint into.
Trying to fit SharePoint into an existing paradigm is going to be difficult. If we follow the metaphor of a bucket, features keep oozing out. As a collaboration platform you wouldn’t expect enterprise document management features like records retention and legal holds. As a document management platform you wouldn’t think about social features or tight integration to messaging. So no matter what one view you have of SharePoint, it’s probably incomplete. It’s incomplete for all of us.
As mentioned in the last post, in most cases when the evaluations are being done for point solutions, there’s a “custom development” option which is the pariah because of the perceived cost. Custom development from scratch is the most expensive option. However, configuration of an existing tool is the least expensive option. So where do you put a solution like SharePoint when it’s a bit of configuration and a bit of development? It doesn’t fit neatly into either model.
The easy costs to calculate are the software costs. If you’re in an organization that has an Enterprise or Select license agreement, you’re probably already licensed for SharePoint and you may already have an implementation. The direct out-of-pocket costs for licensing SharePoint is a clear winner with few concerns.
Of course, there’s more to costs to than just the software costs. You must also consider the implementation costs, training needs, and integration.
Implementing SharePoint as a platform at the smaller scale is trivial. It can be done internally or by nearly any Microsoft partner. If you need a moderate or large deployment you’ll still find help and guidance easy to come by. If you decide not to do the implementation yourself, there are numerous vendors capable of installing SharePoint. Because it’s a mass market product you won’t be locked into a handful of partners or the software vendor to install the software, and thus will likely spend less for the installation.
Configuration for the need you’re trying to solve will obviously take more effort than a cookie cutter point solution, but with a rich set of tools, perhaps not as long as you might believe.
No matter how intuitive a system is, it’s going to require training. Whether you’re looking at training for the system administrator or the employees who will use the system, SharePoint has a distinct advantage when it comes to training. There are numerous publically available training materials from books to videos to job performance aids. If you can dream it someone has probably made that kind of training for SharePoint.
When you compare these options to the often overlooked training materials of a point solution provider, the difference is striking. If you want to get users actually using the system, SharePoint will be easier to learn – assuming they need to be trained at all, as they may already know it.
Organizations are awash in systems that don’t talk to each other or that only talk to each other by way of an interpreter. As a result, it is difficult to get the same answer out of two different systems or even compare one system with another. Certainly, it’s possible to do integrations between point solutions and core systems, however these are necessarily expensive and frequently fragile. Furthermore, if there are integrations with the core systems, the point solutions may be difficult to use.
By building on SharePoint, we have a large number of built-in integrations to the client side, and a number of back end interfaces that anyone can write to. On the client side, most organizations use Microsoft Office for which there’s out-of-the-box SharePoint integration, including Word, Excel, and PowerPoint, Access and OneNote.
On the back end, there’s REST, web services, and even a client side object model for accessing data. Basically, whether you want to write an integration in PHP, Perl, Java, or .NET there are integration points to be hooked on to – solving half the battle in doing any kind of an integration.
Develop or Not
At the end of the day, it all comes down to a decision about whether you want to build your own solution or leverage someone else’s. One of the benefits of someone else designing a system is that you get their expertise in the industry and therefore won’t have to think things through yourself. However, reality often comes crashing down, when you realize that your organization doesn’t do something the same way as the software developers thought it should be.
Traditionally, we’ve thought of internally developed solutions as substantially more expensive than dedicated systems – but this thinking applies only when the solution is being developed from the ground up. My clients often find that developing small applications on top of SharePoint is much more cost effective than a point solution. In probably 80% of these cases, no development is required, and in those cases where development is required, rarely do we exceed the planned cost of a point solution.