Thursday, June 28, 2012

Traditional Portals are dead! Long live 'Script Portals'!

A little history of assumptions

As business grows and competition toughen, enterprises need to make business information more mobile. Around a decade ago, many believed unified web portals to be a rescuer in this mobility game. Technologists betted on web portals based on few two major assumptions:
  • Users will use web as their preferred channel for information consumption 
  • Users would prefer unified information under a single user interface


The reality of generation-i 

World wide web (www) is no longer the talk of the town. Users of generation-i do not believe in unified information anymore. They need information to be available as per relevancy. Today much greater information mobility is demanded where;
  • access channel is flexible and appropriate (www, mobile, tablets, etc.) 
  • controlled flow of relavant information push is preferred over pull behaviors


Limitations of traditional portal platforms  

With the massive buzz around portals, most major technology companies invested in own portal frameworks around a decade ago. Most of these were actually enhancements for existing CMS products, causing portals to be too heavy for the desired purpose. On the other hand, portal standards that emerged (such as JSR 168/268, Web Parts, etc.) were always server side standards causing the developers to be bound to a particular technology and to a specific portal platform.


Life is even harder for 'product' portals 

Product portals (built by ISVs) had even more challenges compared to application portals. 
  • If your product is serving B2B domain, your customer may have own information systems including portals and other channels. Your product information needs mobility and integration capabilities towards those existing eco system. Yet another separate portal could be challenging to sell specially for large customers. 
  • Product are expected to be maintained and developed for a longer time period. It is vital to select a platform which is developer friendly for coming years. Selecting between EpiServer, DotNetNuke, SharePoint, LifeRay, etc is not a simple choice to make. All these platforms will vendor lock you when you start implementing your custom portlets. 


New architecture for product portals - 'script portal architecture'

Imagine placing a Facebook widget inside a simple html portlet of your portal server. It is just a matter of coping and pasting few lines of scripts to make the widget to appear inside the portlet. For example following picture shows Facebook like-box placed inside DNN portal.

We can also develop our custom product portlets in a similar manner as Facebook widgets. With the advancement of HTML(5)/JS technologies, one can avoid dependency on server side portlet rendering completely. Development of each custom product portlet (lets call it a 'script portlet') can be fully decoupled from the server side portal platform, and may even be served from a different server altogether.

This doesn't necessarily eliminate the need for traditional portal systems. Most of the portal/CMS functionality may be used in conjunction with script portlets. Just that we do not develop custom portlets using server side APIs of the portal platform.

Under such an architecture, all your script portlets may be placed on any web page not just on the default product portal. If your customer already has an own portal these components can be easily integrated with copy-pasting simple scripts.
  • The information portlets of your product are decoupled from the traditional portal platform (DNN in this case) and the rendering is done at the client side using javascript DOM manipulations. Developers are now free to move between different portal platforms as need arises. 
  • Data required are fetched as JSON objects (JSONp for cross domain communication) and it is our own custom 'script portal' that integrates with business systems in preparing data. This architecture automatically builds a REST API for business functionality which could be used for deep integrations with third party systems. 
  • If script portlets need to communicate with each other, it is easy to implement DOM based messaging bus that will allow interportlet communication. Use of events will make the smart portlets to be independent without requiring knowledge about related portals. 

Monday, June 11, 2012

Leadership is not about winning every battle

A team is formed... goals are set… competition just begins... a member makes a wrong move… penalty costs apply… at the start, team is already being behind the competition…
Leader A thinking: I need the glory of winning every battle. I made my first move right, but he couldn't… we lost points.. I'm hurt… I will do everything possible for him to feel paying for it… and I need everyone to know if we lose, we lose because of him, not me… I need my battle glory !
Leader B thinking: Yes, we lost our first battle.. but more important is to win the war... learn from the mistake… keep the team together.. appreciate to gain back the lost team spirit… value differences and use for fightback… finally what matter most is not if we 'win the war', but if we are 'proud of the fight we put together' !
I’d prefer ‘fighting under leader B’ to ‘winning under leader A’ !