In the good old days, when your firm's Enterprise Portal was a "gateway to the world," the thinking was that you needed to standardize on one single Portal platform, and perhaps even on single enterprise portal instance.
However, as we all know, that's not really very practical (both for technical and organizational reasons), and multiple portal platforms have always proliferated within organizations.
To be sure, there are many disadvantages to running more than one portal tool. For example,
- There are integration challenges between multiple portal tools.
- You need different skill sets and resources. Even if each Portal platform you deploy is based on same broad technology (such as Java), you still need people who know the intricacies of individual tools. The problem becomes more complex when your Portal tools are based on different technologies (such as SharePoint and WebSphere).
- You also have to manage multiple different environments, hardware, software, licensing issues, vendors, and integrators.
However, in spite of these disadvantages, certain tools are better suited than others for specific scenarios and we often recommend deploying more than one portal technology to our larger advisory subscribers.
So if you are considering supporting multiple portal tools in your organization, make sure they each play well being just one component of the overall architecture.
For example, most Portal tools expect other applications to expose functionality in a well-defined way so they can consume it easily. However, when it comes to them exposing their own functionality in a similar way, they don't do a very good job of it. So make sure the tools not only can act as consumers but also producers of functionality that can be consumed by other portal platforms.
Specifically, this means they offer some sort of interfaces (APIs), so that external applications (portals or otherwise) can access those APIs for specific functionality. This will help you sharing functionality from one tool (such as its employee directory) as a service to get presented in another portal.
Standards play an important role here. Explore if the tools you are considering support some major standards like WSRP, JSR, CMIS and so on. Support for standards will save you from writing proprietary extensions and reduce maintenance overheads.
Each of the tools should support other common applications that you have. These are mostly those that provide directory services SSO and content management. Also consider how difficult or easy is it to replicate your branding, look and feel across different tools. Typically, each of them have their own way to create "Portal Themes" but you should explore if you can reuse CSS and layouts without making major changes.
Stick to platforms that are based on similar technologies. Even within the Java world, there are many options. SAP's NetWeaver Portal and Oracle's WebCenter are both based on Java but employ their own extensions that aren't supported in other Portal tools.
What I've also often seen in larger organizations is standardization on two Portal tools: One a traditional heavy-weight platform such as that from IBM or Oracle, and second, lighterweight offering, such as that from Liferay, Red Hat JBoss or eXo. This allows organizations to mix and match tools depending on factors such as features, reliability, scalability, and time to market.
You can read a summary of all these tools in our forthcoming Portals Marketplace overview for 2012 or for in-depth reviews, you can subscribe to out portals evaluation research.