What is the alternative to an enterprise portal strategy in the Java space?

Question

Disillusionment with the Portal Space

I'm seeing a disturbing number of large, enterprise clients who have become disillusioned with their enterprise Portal experience, especially those in the WebSphere Portal Server (WPS) space. Millions have been invested, yet the promise of personalized content with aggregation and integrated collaborative tools has never come to fruition. The move to WPS 7.x is a big rip and replace move, and clients are wondering if they should move somewhere else completely.

Portal Software: A horrible option, but what's the alternative

There are loads of Portal haters out there, and sometimes a portal solution is indeed overkill, but when you're talking about large, multi-national corporations, how would one recommend they architect a global solution without a portal server?

Portals aren't always as fun to work with as Tomcat or JBoss AS, but when it comes to integrating multiple applications, managing content, updating individual applications that are deployed as individual war files, managing security down to the portlet level, proving a certain amount of personalization to users, and help with the overwhelming task of managing the thousands of pages large scale enterprises have as part of their internal and external websites, is there a better technology out there?

Garnering community insight and feedback

I've been trying to garner as much insight as possible. I wrote a little article on TSS about the issue:

Which other alternatives to portal exists on market?

I'm also resurrecting a thread at the CodeRanch to see if I can get any insight from that handsome crew.

Updated Thread Asking for an Alternative to a Portal Software Stragety. Circa 2012

I'm also looking for some insight from the twitterati (@potemcam).

It's not so much a cross-posting as much as it is an attempt to really gather some keen insight from the community. If I can get some solid responses and experiences, I'd like to aggregate them into an advice article over at TSS.

What is the right alternative to an enterprise Portal in the Java space?

By the way, I'll be cross-linking to this question from the other sites as well so people with the same questions will be able to bounce back and forth and see what the community is saying on this topic.

Answer 1

First, you need to consider what problems Portal was designed to solve. Is it, as Wikipedia suggest, to bring together information from diverse sources in a unified way? If so, what other ways do we now have to do this?

Well, first, how do you bring together information from diverse sources? The obvious answer is to call a variety of (web) services. This introduces issues of contracts and network latency, blah blah blah, but these are things poorly solved by portal, so it's your call. Suppose the services are RESTful? Does that make managing contracts easier? Possibly.

Then, how do you unify the information? One of the issues that Portal solved was how to bring these disparate items onto one page, and have them load independently. AJAX has grown up since then, and the same effect can potentially be handled using XMLHttpRequest calls to the various (RESTful?) services to get your data, and then using a shared set of style sheets.

Will this work? It can and does. Is it more manageable than JSR286 portal servers? Probably. Are there still a ton of issues to overcome? Definitely. But it's a viable alternative.

Answer 2

I have recently been deeply involved in the Java portal server scene. It was chosen as an inexpensive alternative to SharePoint, as we were able to find a portal provider carrying comparable features. We went with eXo Platform and though it is primarily advertised for social features, it is fully compliant as a JSR286 portal server.

A Java portal can be incredibly powerful, but it naturally comes at the cost of seeming over-engineered and unnecessarily complex. The general customer response we've received has been that the basic configuration and overhead of a server can be too much. I have yet to find a portal platform or alternative that can offer a verbose feature set, yet remain acceptably slim for a set of operational requirements. Years of feature bloat between competing portal platforms have seriously cludged the market.

Growth in the Java portal world has been agonizingly slow. You will find dated interfaces, archaic UX, and every action will leave a bad taste in your mouth. There are few innovators here, eXo Platform being one of the very few that we found to be making a concerted effort at modernization.

Given all of that, you can still create a reasonable product in the JSR268 world with a measure of success. We were able to do this by leveraging JAX-RS services for each portlet, basically cherry-picking portlet features and functionality. All database access runs from the web server separate RESTful services for optimized CRUD operations. It takes an imposing diligence with an excess of effort that not many are willing to commit.

You can also go completely ground-up and build yourself a 'portal' with servlets and JAX-RS. This can be done much more rapidly than standard portal development. However, you will fall short when it comes to supporting the full set of configuration features found on a standard web portal.

Simply, there is a serious entrapment cycle of excessive feature sets stifling innovation that does not appear to be changing soon. Game-changing breakthroughs are unlikely to occur because the heavy hitters don't see the meta evolving. But your only alternative option is to re-invent only the features you want.

Answer 3

I don't agree with Matthew, none of the issues with enterprise portals are caused directly by the technology. The problem is almost always a lack of clear focus and direction.

What is the problem you are trying to solve? Try and nail it down to some specifics. I can probably guess that move information out of email in-boxes on to some searchable content solution will come fairly high. As will finding information that lives on shared network drives. Then there's probably a question around workflow.

Beyond that it starts to get a bit nebulous and that's where the solutions fail. If anyone tries to sell you a portal with a demo showing an unrelated team searching for information on his problem and finding another team has already solved that problem isn't recognising how people work.

I don't want this to turn into a long waffle, so I'll ask one question. Does your portal solution allow you to share information with your peers as easily as your email client? Specifically, my application crashed and I want to send you a screen shot. I can paste that straight into my email, that won't work with web based solutions. Does it integrate with Office? Who is going to get all the existing information onto the portal?

Focus on the people, their interactions and their needs and forget the technical first. Second, moderate the people's expectations and wishes with a dose of reality.