Have a problem with your HR department, you need a portal.  Need to get information out to your employees in a consistent manner, you need a portal.  Sale force needs re-alignment?  You need a portal.  Have a headache? portal…  Toilet stopped up? portal…

Monty Python should come up with a new version of Spam, called Portal!

I have seen too many people go down the road of building a huge portal infrastructure (mostly on J2EE) only to find out they have built themselves a glorified document management challenge and that they still need to build the applications that the portal was supposed to address. (Sort of like “Field of Dreams“, only you built the field on top of a landfill.)  So they build the applications the business is clamoring for using Web technologies and then integrate them via iFrames into the portal and the users think they stink.  There is inconsistency across the board for handling state in the different applications integrated into the portal and single sign-on is a joke.

Most portal infrastructures evolve or dis-evolve into application launchers for applications that span the enterprise ecosystem using a rigid UI application framework targeting the browser.  The wheel has been reinvented, don't use the explorer interface…use the portal...

Don't get me wrong, traditional portal frameworks are great for collaboration (SharePoint for instance) but stink for application frameworks.

Some people are waking up.  Since they know their internal clients are mostly running Windows in a highly managed environment, SmartClient portals are beginning to pop up.  The SmartClient Portal has many advantages:

• Host WinForms based applications for high input applications
• Host WebForms based applications for high read scenarios
• A debuggable local event model, input validation, etc
• Unified data access via SOA infrastructure (a whole other can of worms)
• Rich user interfaces
• Offline capabilities
• Integration with desktop based applications
• Etc..

However, before you go jump on the bandwagon there are a couple of architectural things you should consider:

• Web based data access patterns should not be used unless carefully considered.  Taking for granted the calling client will be network near to the data source is no longer valid.
• Single sign-on is still an issue, however, it moves closer to the user.
• Threading and asynchronous calls become much more important.
• A SmartClient Portal framework needs to be developed to commonly address eventing, data access, security/authorization, monitoring, configuration, etc…
• Use cases for deployment and updating of the portal need to be explored and proper technology (Auto Updater, 0-Touch and soon ClickOnce) need to be factored in.
• More to come…

SmartClient portals are bleeding edge, but have much more potential than traditional non-collaboration portals.  Look for guidance from the SmartClient Patterns and Practices book, and frameworks soon to come…