There are many definitions for “Enterprise Portal”, this article aims at exposing a definition that is commonly shared in the Java EE world. People's understanding of portals usually differs depending on their background. PHP people usually see a portal as a bunch of blocks on a page, ECM people would see a portal as a delivery platform for their content, Dreamers see this as an off-the-shelves components that you can stick together through some kind of mashups and so on... At the end everyone agrees, portals are all about integration.
A portal must offer a single point of entry to multiple applications and they all must be well aggregated on a page so that the user doesn't have a Frankenstein feeling while navigating the portal. Last and probably the most well known part of a portal framework is about personalization. Once logged-in, the portal should be able to deliver content depending on various settings defined by the users.
While this article remains as neutral as possible, the author is leading the JBoss Portal project and JBoss Enterprise Portal product. The next article will cover JBoss Portal, while this one covers portals in general. Hopefully at the end of this article you should be able to decide if a portal should be part of your architecture or not.
A portal should be able to integrate into an existing infrastructure, it may not be the only component of a company and must be able to play well with the other parts. It means that the portal application can integrate with any SSO solution already in place or any identity solution which could be based on a database or an LDAP directory for example, data might already be existing and should not require to be modified.
It also means that a portal should not mandate your architecture but adapt to the one you want to build or already have.