An employee portal: every enterprise needs one. Any corporation of significant size needs a Web-based vehicle which can provide employees a core set of features and utilities that can be accessed easily and seamlessly over the net. Every enterprise needs an employee portal. Or do they?
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Portal servers sound great on paper. They provide a central point for software integration, they allow personalization, they either provide their own content management system or integrate with external systems, and they provide tools for collaboration.
Task-based vs. Application-based experiences
The other key benefit to enterprise portal systems, if they are implemented properly, is that they can deliver a task-based, as opposed to application-based, experience to the end user. For example, a developer might rely heavily on JIRA for bug trackings, Sametime for messaging and perhaps a wiki for keeping product documentation current. Rather than having these three different applications running separately, each application could be ‘portalized’, and delivered through a configurable content spot called a portlet.
Multiple portlets can be aggregated together on a single page, and task-based dashboards can be designed to help make portal users more productive at their work. Furthermore, a portal provides facilities for going beyond simple portlet and page aggregation, and can allow portlets to actually interact, so the JIRA portlet could be coded to provide mechanisms that would allow it to simultaneously message and interact with the Sametime and wiki portlets.
Of course, the aforementioned promise is the check that portal sales-folk have always written; in practice, the portal experience rarely delivers the cash.
The wiki challenge
The previous scenario of a task-based interface mentioned a wiki. A wiki is the easiest content creation tool in the world to use, and if you’re interested in hosting a wiki, it’s pretty darned easy to set one up. But just try implementing a wiki in a portal: it’s a mess.
If you run your own server you can easily install some open source software and begin hosting your own wiki, or if you use services from a provider like Pair or GoDaddy, you can add wiki functionality at the click of a button. But what if you want to add standard wiki functionality to your portal server? If your employee portal package doesn’t come with standard wiki functionality like the Liferay portal does, you’re either going to have to develop the thing from scratch, or fork over a million dollars to buy a prepackaged solution, such as the IBM Connections or IBM Quickr tools that make it possible to use a wiki.
Why is a wiki so hard for everyone but Liferay to implement properly and freely? One of the reasons is that the URL is important to a wiki. A wiki might have a base URL such as www.theserverside.com/wiki/ (not a real URL). If you append a new word to the URL, such as www.theserverside.com/wiki/portals, the wiki either takes you to that content page, and if that content page doesn’t exist, it asks you to create one of your own. It’s so simple it’s mind-blowing.
Sadly, portal servers deal with URLs in the most bizarre and perplexing of manners. Implementing something as banal as a wiki is a huge challenge due to the way various enterprise portals handle, encrypt, decode and bemoan incoming requests. With an employee portal, you can’t just add query based parameters to a URL and expect that data to be made available to a server side component dealing with the request. You see, portal servers rarely behave as you would expect.
The problem with employee portals
The problem with developing employee portals for the enterprise is that the talk of integration and ease of use always runs into a wall when it comes to walking the walk. Developing applications for an employee portal can quickly turn into a headache. On one hand, trying to run a WebSphere Portal test environment even in the best of conditions continues to be a time wasting engagement of stopping and starting servers. On the other hand, standard development frameworks such as JSF require special ‘bridges’ that truncate key framework functionalities causing applications that work normally on Tomcat to fail when deployed to a JSR286 compliant container. Enterprise applications are hard enough to build on time and on budget as it is. The pitfalls of portal server development simply compound these issues.
Sadly though, the problem remains that there really aren’t any other viable alternatives to employee portals in the enterprise Java landscape. The feature trifecta of integration, collaboration and personalization reels in the managers during the up-front sales cycle and is just too powerful to resist. In the end, the results are impressive portal server hosting applications that are an extraordinary pain to develop, and fail to deliver the key features that the portal server software was originally acquired to provide.