In a previous post, I described a panel that I participated in where each of three consultants presented what they liked an didn't like about SharePoint. In that post, I gave you my "likes;" in this post, I'll continue the discussion with what I think are SharePoint's disadvantages or shortcomings. While the product is quite good, there are definitely areas where it could improve -- some of those areas have more to do with the way Microsoft markets the product than the product itself; none-the-less, they are disadvantages.
- Accessible to a wide range of skill levels
You'll notice that this particular bullet point is listed twice -- once on my "like" list and once here. The reason for it appearance here is simply this: SharePoint is almost too easy to setup, configure and use. Normally, this isn't a bad thing, but in SharePoint's case, it has led to trouble at many companies. At a recent SharedInsights conference, I had the opportunity to speak with a number of professionals who were interested in SharePoint. One of the attendees described a situation in his company where a non-technical, non-IT employee downloaded the SharePoint bits and spun up his own Windows SharePoint Services environment. The issue isn't so much about the actual instance of the WSS server as it is a matter of management; since this installation was done with out IT's knowledge, it's impossible to control and ensure operational integrity. Most of us, I'm sure, have either used a tool or created one that was widely distributed in the general population and provided great value, but did not come with the official support of a larger corporate group. These tools, if they're good, quickly become "mission critical," and a nightmare to support if something goes wrong. My own experience was with a really useful expense reporting system built in Access -- it was created in my division, but as folks from other groups saw it, they also wanted to use the same tool. In much the same way, SharePoint is like the expense reporting application -- pretty easy to use and distribute, but it can lead to headaches for groups responsible for keeping the technology lights-on as it were.
- Rigid architecture
Microsoft has made great strides in providing a fairly flexible architecture that is both easy to use and able to be extended to fit individual organizational needs. Unfortunately, this flexibility isn't universal in the product. Very key areas of the tool are horrifically rigid. To make certain kinds of changes, you're required to modify, what is in effect, the based product interfaces (all of which could, as Microsoft constantly reminds us, be changed through a service release). The best example of this rigidity is the out-of-the-box interfaces for adding, editing and deleting list items. As you might already know, everything in SharePoint is a list. As such, these contributor interfaces are quite important to the product. Let's take an event list. Try scheduling an event for a time not on a 5 or 10 minute increment -- say 7:11 am/pm. Now, this may seem trivial, but I know of a baseball team that recently signed a deal with 7-11 convenience stores and now start their night games at 7:11 p.m. If that baseball team wanted to use a SharePoint event list to keep track of all of their games, they'd have to modify the out-of-the-box list item entry interface to insert additional values in the minute drop-down box or change the drop-down to a text box. Think this is an unrealistic example? Consejo just finished delivering an intranet solution, on SharePoint, for an MLB team (thankfully not the one in this example). Granted, if the solution were an Internet solution instead of an intranet solution, the team could have simply written a custom field control (great flexibility), but the out-of-the-box interfaces for these more internally facing solutions simply aren't as flexible... which brings me to my next point....
- Really great at too little
I've always heard that Microsoft identifies commodity features in a space and produces products that meet 80% of those needs. While I can't take credit for this position, nor do I think it's entirely accurate, I do see the wisdom in it. SharePoint, in particular, suffers from the Jack-of-all trades problem: it isn't really good at any one thing. It's document management features aren't as good as Documentum. It's web content management features aren't as good as Ektron (or even the product it replaced -- MCMS 2002). The wiki and blog templates that ship with the product are passable, but don't compare with SocialText for wikis or Community Server for blogs. It's collaboration features and integration with Office are admirable, but you can't take content offline easily (even though Groove can). All-in-all, it's good at a bunch of things, but not great at any. As a result, I constantly run into customer needs that can't be met as well as either the customer or I would like. The counterpoint to this complaint really comes down to the sheer combination of features in a single package: if you need a good all-around product that can handle many common information worker content management (broadly) needs, SharePoint is usually a good fit -- being good at a lot is SharePoint's strength.
- To many partner-based solutions
Like the first bullet in this post, I've listed the broad partner community as both as asset and a liability for SharePoint. It is true that no one software company can realistically produce a perfect solution. However, I get concerned when a product has to consistently rely on a partner community to lend features or functions not found in the base package; this usually means that customers must a) spend additional dollars to get the solution they need and 2) deal with multiple parties to support their solution (finger pointing between Microsoft and their partners has been elevated to a sport). One could certainly argue that a broad partner community is an asset, since it does give customers additional flexibility in finding the right solution through the coupling of "best of breed" features. True... this is why I'm on the fence on this one. As it stands though, Microsoft seems to market SharePoint as it's content management platform (effectively the only content management platform for Microsoft). However, there is an absolute ton of bolt-on solutions for SharePoint. They run the gamut from scorecard solutions like Alegri CIO Scorecard to work management to point solutions like Automated Well Lifecycle Solution for the Oil and Gas Industry from geniant. In addition, Microsoft (to its credit) recently released a set of "application templates" for MOSS 2007 and WSS 3.0. Each of these templates support the management of information for a given "vertical," such as a help desk, a baseball team , projects and clinical trials (there are almost 40 templates available). The trouble is that these templates are generic; just like the templates shipped with the product. If you really want to address very specific needs you need to turn to a partner like CorasWorks or Quest Software (who recently acquired Workplace Architects) for both templates and new web parts that address customer needs specifically. Ultimately, you almost always have to implement a partner product, in concert with your SharePoint implementation, to get the solution that will meet your needs. The easiest example of situation is in the search space -- I almost always recommend Mondosoft's Ontolica suite to improve search functionality.
- Inconsistent feature lifetime
Anyone who has been working with SharePoint since the 2001 days, knows that various features have come, gone and come back again. Some examples of here today, gone tomorrow and back again are items like workflow (started in 2001, almost non-existent in 2003 and back with a vengeance in 2007), versioning (major and minor versions in 2001, only major versions in 2003 and major/minor versions reintroduced in 2007) and meta data enforcement (2001 would force meta data entry through all interfaces, 2003 only enforced meta data entry when using the web or Office interfaces, and 2007 re-introduced end-to-end meta data enforcement - albeit not as thoroughly as 2001 - controlling content meta data through workflow). As a result, customers who have implemented solutions across the three versions are whipsawed from one feature set to another -- loosing functionality and, in some cases, gaining it back again as they upgrade. Not only does this approach make it very difficult for IT to support the platform, but it creates training nightmares for end users. I can certainly sympathize with the product team at Microsoft -- it takes a great deal of effort to rebuild an entire product (as they did between 2001 and 2003) -- but you can't simply eliminate features that are useful to customers between versions; you must keep what you have and add on (unless there's a really good reason to phase out a feature).
- Microsoft’s "Go-To-Market" for Web Content Management
Microsoft made the decision, with this version of SharePoint, to discontinue it's web content management server product, Content Management Server. In its place, it added features to SharePoint (specifically MOSS) to support web content management. Unfortunately, instead of mimicking the features provided by MCMS (or other dedicated WCM tools), they made the WCM features fit inside of what SharePoint natively understands: lists and libraries. While Microsoft can point to a number of public sites running on SharePoint, I just don't think SharePoint is the right tool for managing content in a public web site. Perhaps it's the weird URL patterns created by SharePoint (since web pages sit inside of a special document library -- a "pages" library -- every URL has "pages" in it) or changes they need to make to SharePoint to force WCM into the platform (see this blog post from Tyler Butler on the SharePoint team regarding anonymous access sites on SharePoint as an example) or the restrictions around how you can use master pages and/or themes in SharePoint (you can only have one master page per site for example) or simply the fact that navigation is really just enumerating every site in the site collection (using the site hierarchy to display the various navigation levels), the platform just doesn't really "fit" the WCM model almost every other vendor in this space uses. Being different isn't a bad thing if it works, but I don't think WCM in SharePoint works; it's close, but not totally there.
Ultimately, I must admit that I like SharePoint. I think it's a great product, despite what I perceive as its failings. The Office product team at Microsoft should be commended for producing a tool that is quite broadly useful. I would encourage anyone who hasn't used SharePoint to download the trial version of MOSS or simply install WSS on their Windows server. I think you'll be impressed with its ease of use and tight integration with Office; as a colleague of mine was famous for saying -- it just works. That said, you need to understand how you'll use the product and in what context; understanding both what SharePoint does well and what it doesn't will help you avoid a bad implementation that doesn't add value to anyone's work day.
Give me feedback. Tell me I'm wrong or simply give me more examples for either list. I would love to hear from you.