SharePoint: Why Not?
In many organizations, expansion of Microsoft's SharePoint technologies seems to be inevitable due to unofficial grassroots adoption and standardization on Microsoft Office. However, organizations that have determined they would benefit from a portal framework should still evaluate their options, which include moving to or coexisting with other portal frameworks.
META Trend: In 2004/05, enterprise portal governance will be a critical issue for Global 2000 organizations reconciling multiple portal frameworks (from ERP systems, content management tools, e-commerce packages, etc.) and declaring the principles under which federation will take place. By 2005, large vendors will finalize the ties and positioning of portals to the rest of their product portfolios, while small, independent vendors capitalize on market opportunities around new technologies, verticals, and Sarbanes-Oxley. By 2006, portal frameworks will become a key delivery point for process automation involving human-oriented workflow. By 2007, portal and composite application frameworks will have merged and become indistinguishable; in addition, we expect the overall portal project failure rate to decrease to 10% (from 30% in 2003) due to product maturity and institutionalization of best practices.
The most common questions about portal products are “Is it any good?” and “How does it compare?” and “What does it cost?” However, when it comes to Microsoft’s SharePoint Portal Server (SPS), the most common question is just “Why shouldn’t I use SharePoint?” In our research, clients asking this question fit a common profile: they have pockets of Windows SharePoint Services (WSS) sites already growing across the company, they have a licensing agreement with Microsoft that includes SPS client access licenses at no extra cost (the servers must still be purchased for $3,995 each, but this is inexpensive by portal standards), and they are faced with selecting a portal framework for the company. In these situations, Microsoft seems an inevitable choice given that it already has momentum in the organization, fits its productivity and desktop software strategy, and would incur minimal cost. So the question is simply trying to uncover any red flags that would make it worth the effort to halt the spread of SharePoint technologies and pay for a competing product.
The good news for many of these clients is that, since its 2003 release, the combination of products and services that comprise Microsoft’s portal solution is competitive (see Figure 1). Indeed, our Enterprise Portal METAspectrumSM rates SPS2003 as very good at content support/authoring, security, contextual delivery (personalization), and XML/Web services capabilities. Clients who have not evaluated the SharePoint products since the 2001 version should re-evaluate them. Microsoft has made great strides to remedy the deficiencies in scalability, administration, and personalization that prevented us from recommending the previous release for enterprise use. However, though Microsoft has closed the gap, SPS is still not best of breed in any one category.
Most often though, a client asking “Why not SharePoint?” is looking only for “gotchas,” not major strengths. The largest feature gap is around application integration. Although all other portal vendors have expended considerable effort on building/soliciting portlets into common applications, Microsoft has not stressed this yet (programmatic integration through BizTalk Server is supported). However, it is the close ties or requirements with other Microsoft technologies that are most likely to hamper SharePoint adoption. Microsoft’s portal framework depends on a slew of other Microsoft technologies, such as the other Office components, SQL Server, Active Directory, BizTalk Server (for integration), Visual Studio.Net (for developing Web parts), Windows, Live Communication Server, Content Management Server, and IIS, which an organization may not want to commit to. Moreover, it is not just these technologies, but also the requirement for their latest versions, that has hampered adoption in large organizations, which tend to manage upgrade cycles on a one-to-two-year lag. For example, Windows Server 2003 is required for WSS functionality.
Competitors
Even when a product is a strongly favored incumbent, we recommend performing a due-diligence investigation to see if competitors have key value propositions that would justify the extra cost. Companies often find that the process of preparing an RFI or RFP and talking to vendors with a different point of view reveals gaps in the original plan. To make the search quicker, we recommend being honest with competitors and letting them know that Microsoft is a favored incumbent. Clients should tell them what their technology environment is, how Microsoft portal technologies are or will be used, and ask them what they have to offer that Microsoft does not that would justify their cost. Most competitors will stress integration of the portal components, application integration, platform independence, and openness to non-Microsoft framework components as benefits.
If an organization is open to Java-based solutions, there are many competitors to choose from. If an organization is mostly a Microsoft shop, it should look for vendors that offer both programmatic (e.g., portlets can be coded in Visual basic or ASP and can call directly to COM) and technological (e.g., Windows, Office, Content Management Server) compatibility with Microsoft products and technologies. There are several Microsoft-friendly vendors, including Open Text, Plumtree, Vignette, SAP, and Computer Associates.
Coexistence Strategy
Supplementing, rather than replacing, SharePoint is another option that can be explored, though we warn that bypassing a full architectural decision definition of a knowledge worker infrastructure (KWI) is likely to cause future pain (e.g., WSS will lead to other de facto product decisions). In many organizations, the collaboration infrastructure planner would have to expend significant amounts of political capital to reverse the flow of WSS and police its ongoing ban. Even if WSS has a solid position in an organization’s KWI, there are still two ways that a separate portal solution could coexist. First, a portal product could take the place of SharePoint Portal Server as a layer above a collection of Windows SharePoint Services sites (see Figure 2). Small groups would still use SharePoint to create sites for themselves, post documents and Web pages, and set up discussion groups, but the “uber portal” would provide application integration, single sign-on, process automation, more advanced collaboration, and content management facilities Perhaps more important, it would also provide a federated governance layer above the Windows SharePoint Server sites to tie them together. This will not be easy at this time because portal products have limited WSS integration. The second (and less preferable) form of coexistence would be to have two enterprise portal infrastructure stacks - one from Microsoft and one from another vendor. Because the two portal frameworks would provide overlapping capabilities, users would determine which portal to use based on some set criteria such as job function or department. This option is less preferable because it introduces redundancies. If this option is necessary, redundancies should be reduced by having the two portal frameworks share infrastructure components (e.g., content management, usage tracking) as much as possible. A coexistence strategy still requires central IT infrastructure and architecture group involvement to ensure appropriate fit.
Governance
Portal governance must be addressed regardless of the combination of Microsoft products used to compose the portal framework and the possible presence of another coexisting portal framework. This is more of a problem for Microsoft customers because theirs is the only product that really encourages grassroots adoption by default. Products from other vendors must also be governed, but their top-down deployment approach makes this easier. Indeed, allowing groups to set up islands of disconnected SharePoint sites could cause more harm than good, as managers of ungoverned Domino deployments in the 1990s can attest. For organizations that decide to postpone any portal decision, this becomes even more important to avoid having an enormous number of unmanaged sites in a few years.
Bottom Line: Organizations should not let grassroots adoption of Microsoft's SharePoint technologies lead to an automatic enterprise decision. SharePoint is a competitive framework, but it should be evaluated to determine whether it should be the enterprise portal for the organization, coexist with another framework, or be isolated.
Business Impact: Selecting a portal framework will lay the foundation for initiatives that benefit from collaboration, information sharing, and application access.
META Group originally published this article on 7 June 2004.