Portals vs. Mashups

A critical Information Technology objective for most mid and larger companies these days is the integration of disparate business systems.  The reasons are several, but Business Intelligence (BI) is a decent overarching label for all of it.
The JSR-168 and related WSRP standards are intended to facility this but are they too late?
Something old … new again
Once upon a time, way back when a big disk was just M’s and RAM was merely K’s, our stone age solution to "integration" was to get different applications to at least run on the same terminal — and even that was rough.  I don’t remember that we even had a name for that.  Fast forward about 20 years and we call it "integration at the glass".
Of course, it’s more than just glass.
The real deal is that we now have a common UI framework (HTML/Javascript) and network communication standards(HTML) that allow even the oldest and crufty’st legacy apps [mostly] to appear together in harmony on the same desktop.  So why build a portal when you already have a browser?
Granted, that is something of a simplification.  There’s still some tricky stuff to work out, like common authentication and inter-app state synchronization to name two, but those are arguably as easy to solve near the desktop as they are on the server — the network connection is simply not the barrier it once was.  We no longer are looking at making the binary choice between thin-client and thick-client, but instead can spread application functionality almost arbitrarily across what was once the "great divide".
The choice is where you do your mashing.
If you mash using WSRP, we call the result a portal, but if you mash in the browser, you’re suddenly a Web2.0 social app — and likely with a better valuation too. 😉
Now, I do think there is an unanswered technology question here and that is the life cycle cost of these semi-thin clients — our tools are simply better and more mature for server style implementation approaches.  This is changing.
A real test case
An application we recently built at StomperNet is split in just this way.  It is composed of two user facing components implemented in Firefox that wrap local functionality as well as remote services hosted by a PHP server.  There were some lessons learned, both positive and not, but on balance our approach provided solution features that would have been very difficult to provide any other way.  With the maturation of XULRunner we can expect this type of application partitioning to become even easier.