Silly question, we all know the answer. It’s a way of providing a consolidated view of a large amount of data in a manner that suits the user. In case you want reassurance read the standard Wikipedia definition Regular readers will recognise that this again stresses the need to concentrate on the delivery pattern which is traditionally from raw data to the computer and then to the user. A change taking place in our daily environment right now is the reversing of this direction. The trend toward user-defined environments is being supported by individuals’ options around devices and web places.
So are user-driven portals mashups? Not necessarily. They certainly could be, but for most enterprises, much of the data will not be readily rendered in a suitable form for mashups. Rather than using existing data as static reports delivered through a portal, it is becoming more desirable to shift towards allowing the user to be able to ‘interact’ with the data. This gives them the ‘experience’ they seek, rather that which the IT department delivered in response to a business requirement definition. I should say that this is not an exercise in blame on the IT department, or even the business manager who defined the requirements. It’s a simple observation that we can do better with the technology that we have available today.

The portal is really a bridging mechanism between computers where data are organised logically (fixed, stable, and relational stores) and people for whom context and dynamic circumstances are the defining issues for what they want to be able to act upon. There are a wide range of tools that enable this bridge, but as the source data to be delivered is the driver the tools, naturally focus is usually on this and the challenges surrounding practical issues of sources and formats.
Classic portal tools, the techniques and the specialists using them, deliver exactly what is defined by the user. Users are starting to expect more as a result of through rich internet applications, and they expect obedient, smart and capable applications. Maybe this is an expectation driven by web-based portals, where the commonality of the ‘base’ technology is a given and since 2001 we have had the benefit of JSR 168 defining interoperability between web portals.
The result is increasingly ‘rich’ and ‘interactive’ user experiences that seem so different and encourage users to expect more, better, faster with a focus on what they want. Do we need to separate the two portal approaches so much? IBM and SAP have already added AJAX to their portal products to improve the visual perception but what is really required is a continuation of the convergence between content management and data-based reporting. Adobe has tried to hit this and made it a big feature of their enterprise play at Adobe events, but was it to the right audience?
The pitch is to use a conventional portal tool to construct and deliver a ‘managed’ framework of computer services onto which Adobe is added as a true presentation layer to provide the user focus, you get to learn more here. Much as I like the result it is rather ‘oil and water’ in terms of the skills and approaches and therein lies the challenge. When we come down to reality the definitions of both and their ways of working, responsibilities are just too different to make this obvious.
BUT I do believe that as a technique it warrants investigation as it does enable a decoupling between the ever changing user focus and the cost and difficultly of repackaging the portal reporting framework. It’s also the start of a sea change in the way to think about delivering and maintaining quite a few complex requirements.