Provided by |
In many organisations, expansion of Microsoft's SharePoint technologies seems to be inevitable due to unofficial grassroots adoption and standardisation on Microsoft Office. However, organisations 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 organisations 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 finalise the ties and positioning of portals to the rest of their product portfolios, while small, independent vendors capitalise 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 percent (from 30 percent in 2003) due to product maturity and institutionalisation 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 US$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 organisation, 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 (click here to view Figure 1 ). Indeed, our Enterprise Portal METAspectrumSM rates SPS2003 as very good at content support/authoring, security, contextual delivery (personalisation), 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 personalisation that prevented us from recommending the previous release for enterprise use. However, although 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 organisation 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 organisations, 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 favoured 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 organisation is open to Java-based solutions, there are many competitors to choose from. If an organisation 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).
1%
2%
