29 June 2011

Does Microsoft need a SharePoint App Store

Yes and no.  You see, its just not as easy as a black and white response.  You could argue that SharePoint needs an app store because there are far too many specific use cases for which it’s out of the box experience is ill suited.  However, SharePoint does ship with a number of “apps” (Microsoft calls them “Site Definitions”) that can satisfy relatively simple needs with little or no work.  The challenge is whether the out of the box archetypes like “team sites” or “document workspaces” in Foundation or “publishing portal” or “search center” in the Standard/Enterprise versions are sufficient; could Microsoft or a 3rd party effectively create additional, purpose-built archetypes to improve end user adoption and overall usage?

To illustrate this point, let’s suppose you need to create a web-based collaboration space to work on a document with a small team of people inside your company.  It’s actually quite simple to use what SharePoint provides immediately. You’d likely start with a “document workspace” (shown in Figure 1).  The workspace can be provisioned while you’re reviewing the document from within Microsoft Word (or another Office product) or from SharePoint’s web-based interface. You can even invite your colleagues from the same interface (within Word) or, again, through the web interface, without any trouble. Once the workspace is provisioned, you’d automatically have a library to store the document (and the document would already be waiting there for you and your team members). In addition, the workspace would show who was participating in the workspace through the members list (with direct links to their individual profile by clicking on their names), a task list to assign & track responsibilities, an announcements function to communicate with your team and a discussion thread for working exploring topics relevant to the document. All of these features are packaged up and provisioned automatically. So what’s the problem?

Figure 1 – Typical Document Workspace in SharePoint 2010

What happens when you want to create a quick, web-based file sharing site and “invite” others inside or outside of your organization?  You’ll quickly find the standard SharePoint site definitions fall a bit short.  SharePoint does have features that support file sharing through sites and libraries; users could even access and edit those files through Office on your desktop or use Office web app through a browser.  There’s also the possibility to let non-employees access the site.  Unfortunately, the collection of features, along with the requisite security model are not available in a shipped SharePoint site definition.   As a result, an end user would have to start with an existing site definition, like a “blank site,” then add a combination of lists and libraries to create the environment they want.  Next, they would grant internal participants access to the site, applying library/list-specific or document-level permissions as necessary.  If the users aren’t in Active Directory (like the non-employees), SharePoint allows you to use SQL Membership to store those non-employee IDs in a SQL database.  However,the non-AD authentication configuration work requires you to manipulate machine-level settings in an XML configuration file, create databases on a SQL server and grant specific application pool identities access to the database.  Most of this effort is typically outside the expertise of an average end user; even if they weren’t, because of the changes necessary to the farm, most administrators wouldn’t want end users changing these settings.

Ultimately, there’s little evidence that SharePoint is wholly unsuited for collaboration needs inside the enterprise.  If fact, you could argue that SharePoint, given its breadth of functionality, has no equal in the collaboration space.  However, there are well-documented challenges in creating you own applications on SharePoint.  Remember that SharePoint, by Microsoft’s own admission, is a platform and not a product.  This means companies are either left developing their own applications or buying from a 3rd party.  This begs the question: should Microsoft devote some of their R&D budget to developing applications on top of SharePoint?  Further, wouldn’t building applications on SharePoint, in fact, be more useful to a greater number of people than adding new features to the platform?  This approach would certainly go a long way to blunt attempts by companies like Huddle, 37 Signals, Box.NET, HyperOffice and others to discredit SharePoint for purpose-build solutions.  Microsoft has demonstrated, historically, their willingness to drive down this path with new site definitions like the “Fab 40.”  Unfortunately, some of these applications were just silly (like the Baseball Team management portal) and they never followed-up with equivalents on SharePoint 2010.

If you’re searching for specific applications on SharePoint today, you’ll need to look to the myriad of 3rd party vendors like Bamboo Solutions, Coras Works, SharePoint Solutions or the app store concept from the larger SharePoint community called Sharevolution.  Unlike Apple and Google (or even Microsoft’s own online store for everything from Windows to XBox to non-Microsoft hardware), Microsoft has not created that one-stop-shop to find specific solutions built on SharePoint.  One can only hope that, in the future, Microsoft does something more creative than simply redirecting the domain sharepointapps.com back to the SharePoint product site on Microsoft.com. 

21 June 2011

Technology Just Gets in the Way

The idea that most folks in IT, and even some  on the non-IT side, spend way too much time worrying, thinking and generally kvetching about technology is almost passé these days – everyone knows it true, but they still get wrapped up anyway.  Incredibly, most people tend to see the process of solving business challenges exclusively through the lens of what a specific tool can solve.  This condition is never more obvious than when firms start discussing SharePoint. 

Inevitably, there are discussions that start out well – focused on business needs and what users have to accomplish.  Then, for some strange reason, things go seriously awry.  In the words of Ace Ventura, Pet Detective – “Gee, Chuck, the date started out good. Just before we got to the party she seemed to tense up.”   Perfectly rational people start discussing if SharePoint’s wiki has sufficient functionality, can the firm really use the out of the box search, are the records management features robust enough for the entire enterprise?  All of these questions are very reasonable to ask if two conditions have already been met: 1) you know what problems you’re trying to solve and 2) you have well-defined goals and corresponding metrics to measure if you’ve successfully met those goals (notice I avoided using the word “requirements”).  Unfortunately, most organizations fail to satisfy either condition before pushing head long into a “how do we implement SharePoint” discussion.

If you regularly read this blog, you’ll know that I’ve already said SharePoint is not the answer.  However, this is true of any technology if you haven’t clearly defined what you want to accomplish.  No matter what tools you might be considering, you must be clear about what you’re trying to accomplish AND ensure that your goals are achievable.

Published on the Word of Pie blog, there’s a great post about taking a break from ECM that illustrates this point perfectly (though through the broader lens of ECM).  In the post, Laurence Hart (@piewords) describes all of the challenges with ECM implementations.  He does such a terrific job that I’ll end this post with only one bit of advice; read his post.