Gene Phifer and Jim Murphy gave an interesting presentation on the portal of the future. It incorporated a number of things Gene has been saying about portals for a while as well as some new concepts. I’ll give Gene this, his “follow me anywhere” portal is getting closer to reality as we see more and more clients creating mobile portal sites. What’s interesting from a mobile portal standpoint is that I see a number of companies building one site and then creating a completely separate site built on a widely different technology to support mobile users. It kinds of defeats the purpose. That said, here are my notes from Gene and Jim’s presentation.
- Widgets and related technology will replace or at least live with the current portlets. Widgets, gadgets, flakes, etc are just more simple portlets usually built with a RESTful service. They are cheaper to build and easier to consume. You can see it with Google’s 4,000 gadgets. IBM and others are working on a widget standard. This isn’t a new thing btw, I’ve reported on it previously.
- My Portal will be important. Many portal sites in the past used the value provided by portal services but didn’t allow a whole bunch of “MY” in there. They were and are locked down sites. I think that as businesses get more comfortable with the Web 2.0 concepts, My Portal will finally come into it’s own. Gene and Jim really think it’s going to happen.
- Personalization: not to be confused with with my sites where you place widgets and portlets on your own pages. Personalization is usually an engine of some sort that takes what it knows about you and targets pages, portlets and content to you. This will drive your experience on the site. I’ve commented on this before as well.
- Clouds: I’m sure you all have heard of it. We love virtualization. We love getting a somewhat complicated technology up and running quickly. Cloud technology holds out that promise. Gene and Jim talk about five kinds of cloud approaches. All of which have various pros and cons. They include: Deploy a portal to the cloud, Cloud based portal as a service, Portal apps themselves in the cloud (WSRP and RESTful services like widgets), and private clouds for internal or external use. I wholeheartedly agree with Gene and Jim on this. Clouds are in our future and all the major vendors are jumping on board with various flavors of the cloud based approach.
- Web Oriented Architecture. They say do it or die trying. Calling a portal service as a simple little url can be very powerful. It’s worth a post or two just describing this.
- Social Object Aggregation. This is just a cool term for saying, all the neat social networking and Web 2.0 technologies and concepts will be part of the portal. They noted that there seems to be some uncertainty how this will work. Sharepoint 2010 puts a lot of that in it’s latest version. IBM both inserts that functionality and integrates to the Lotus Connections product. Oracle built WebCenter Spaces on their portal framework and Liferay has had blogs, wikis, and tags since version 5. I’m as curious as Gartner to see where this goes.
The Good, The Bad, and The Ugly
Choosing a Global Software Development Partner to Accelerate Your Digital Strategy
To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.
Get the Guide
It wouldn’t be a good portal future presentation without mentioning where portal has failed. They gave out the following points:
- Portal is expensive. Portal can be expensive to acquire and implement. I think cloud based services and web 2.0 concepts will help but it’s still expensive. That makes it harder to use the power if you have a limited budget.
- Long Deployment Cycles. Many have taken years to get a portal up and haven’t seen a huge amount of value from that. I’ve seen it personally. A lot of that has less to do with the technology and more to do with the “soft” parts of the project like vision, management etc. The fact remains that you do see long deployment cycles and that kills any ROI you hoped to gain from it.
- Complex Development Required. It’s true, portal can be needlessly complex at times. Content should be simpler to create. Portlets should take less time to build, personalization should be easier to use, etc. There’s a general trend of easing this but all the vendors need to do more. Microsoft does a great job with the simple stuff like documents, lists, etc but not so good a job with more complex web part development. IBM does a decent job with development but has a lot of room for improvement. They need to make it a lot easier for the simple stuff.
- Lack of relevance to individual users. Users are demanding more control. Many portal sites provide little to make it relevant. Again, Gartner pointed out that this may be less a problem of the technology and more in the implementation. I agree.
- New Silos created. Yep, the very thing portal is supposed to break down……………..it created.
They actually had a lot more content but most of the additional content is encapsulated in this summary. All in all a decent presentation.
Well, I have published myself different posts about portlets:
* Portlets in the light of OSGi and other technologies: http://www.jroller.com/dmdevito/entry/portlets_in_the_light_of
* The term “portal” is, at least, rather confusing!: http://www.jroller.com/dmdevito/entry/the_term_portal_is_at
* Portlet life looks like EJB, but future sounds like GWT: http://www.jroller.com/dmdevito/entry/portlet_life_looks_like_ejb
* The portlet/GWT comparison is in favor of GWT: http://www.jroller.com/dmdevito/entry/the_portlet_gwt_comparison_is
My conclusion is that:
(1) portlets are very over-hyped and expensive to deal with
(2) portlets are a standardization of the portal concept at the wrong level.
Well, portal is a architecture concept, just like REST. Portlets are a standardization of this concept into the API level, and introducing too much contraints.
IMHO, portal concept should have been better defined, just like REST, at the architecture level.
(3) GWT, for example, enables to define faster better portals than portlet technology.
Pingback: Les portails ont-ils de l’avenir | la petite fabrik / blog