Five years ago there was a lot of hype around portal technologies. (You know of which I speak; portlets, JSR-168, WSRP, etc.). In 2004, Gartner listed technologies such as JSR-168(Portlet Specification), JSR-170 (Content Repository for Java™ Technology API) and WSRP (Web Services for Remote Portlets) at the peak of their hype cycle in their “Hype Cycle for the Portal Ecosystem“. My impression is that since then those technologies have kind of faded away.
In my personal experience, I have not seen any really successful portal technology deployments. (Of course, I am not implying that there are none such in existence, only I haven’t seen them). I have participated in my share of portal technology implementation projects, but none of them, I my opinion, did live up to their promise. Now seeing that there is less and less talk about portals (except from some software vendors that still are eager to sell their products that they have invested a lot in), I am questioning the future of portal frameworks as we know them.
What value do portals add?
In a discussion around web 2.0 technologies, a corporate communications person in a large international telecommunications company stated something like (I don’t remember his exact words) “portals have not really caught on – after all people prefer to read their email in Outlook instead of settling with the inferior experience in a portal”. This is a good point – many of the corporate portals focus on bringing a subset of functionality of other applications into a portal or workspace. But what is really the value added? After all, Firefox gave us tabbed browsing that has been adopted by all major browser vendors. Switching between your webmail and your (web-based) CRM system is only a Ctrl-tab away… In most scenarios, integration of applications using portal products did not deliver more than that.
A portal will add value when it is a common entry point where you can start when wanting to access information or a certain functionality. A typical example of this would be your corporate intranet. But it does not mean that the functionality necessarily needs to be delivered through that portal. Rather, it should guide or direct you to that application which delivers that functionality – only a click away.
Another area where portals could add value, is if data/functionality from several applications can be combined to add value. This has been a promise from portal frameworks that in my opinion has only to a very limited degree has been delivered. Inter-portlet communication did not happen to any large extent.
What is the cost of portals?
Compared to a plain web server technologies like Java Servlets, ASP.Net and the like, portal frameworks not only typically represent an extra licensing expense, they add quite a bit of complexity. In addition to configuration complexity, there is added complexity associated with customization and development. For instance, development models for portals are heavier and so are the development environments. Furthermore, portal frameworks constrain you in several ways, for instance when changing the look-and-feel or user interface experience. What is relatively easy to change in a standard web platform is much harder to change in a portal.
With the emergence of agile methodologies, disciplines like test-driven development and automated testing has become something that we have learned to appreciate. This has shown to be another area where portal frameworks get in your way as a developer- they are inherently hard to test.
The challengers
With the emergence of web 2.0-technologies, backed up by large Internet companies like Google and Yahoo! that do not sell software but services, the focus seems to be on lightweight technologies like Ajax, mashups, RSS, and REST-based services. Widgets/gadgets like the ones offered by services like Netvibes, iGoogle, Yahoo! and live.com are the soupe du jour. They offer a light-weight development model with a very low startup cost; no specific server-side technology knowledge is required, no specialized IDE or dev tools required. The big question in my mind is whether these will challenge “traditional” portal technologies as the leading enabling technologies for intranet content aggregation? Quite recently Netvibes chose to open source their JavaScript widget engine. Furthermore, open source projects like Shindig are popping up that aims to offer developers frameworks for widget development.
Portal frameworks also continue to evolve. JSR-168 has been succeeded by JSR-286 and there is a version 2 of WSRP. The question is if this is enough to to make portlets prosper. Personally, I don’t think so as the problems are at a more fundamental, conceptual level than API specifications. But time will show…
In conclusion
“Traditional” portal frameworks have not lived up to their expectations. The use cases for portal technology represent niche functionality, at most. Furthermore, portal technology represent a heavy development model that in many cases will slow you down, compared to other technologies. If you are considering implementing portal technology in your company, you should very carefully investigate cost/benefit. Do not exclusively listen to portal vendors; talk to peer companies that have implemented portals, inquire them about their experiences. Talk to devs. Keep a close eye on emerging technologies. Keywords include widgets, Ajax, RSS, mashups.