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

Question

So, I got my wrist slapped by asking this question over on StackOverflow. I guess the previous iteration of the question was not one that gets resolved with a concise enough answer - hopefully some of the edits here will help.

Anyways, one commenter, Perception, suggested that I reposted the question over here where some of the handsome and intelligent readership might be able to provide an answer. Here's the question as it was posted over at SO, but edited a bit to be more specific in focus.

---

I'm trying to garner insight from as many sources as I can, and I wanted to hear from the big brains at Stackoverflow (well, I guess it's now all about the big brains at stackexchange).

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

Looking forward to hearing your advice. By the way, I'll be cross-linking to this thread from the other sights 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.

---

Hopefully this iteration of the question will be well recevied by the programmers community at stackexchange.

Answer 1

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 shoowing 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.

Answer 2

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.