Saturday, April 18, 2009

CIO's Organizational Challenges Changing Portal Strategy to Widget/Gadget?

Few years back companies have started implementing Portal solution using Portal products. These Portal products were mainly from leading vendors like IBM, Oracle, BEA etc. Sales people from these companies have done extraordinary job by convincing CIO’s the benefits of implementing Portal products, never the less they applied shopping mall analogy to it. Also they have associated enterprise vision with this product because of licensing price, feature set and need of high back end horse power.

Some how this enterprise vision is not linked with company readiness, governance and existing IT investment of companies. Probably this is the reason these important criteria’s were given high importance during SOA implementations, which came in subsequent IT wave. Now a day, you may see these as being Portal and SOA service offerings for IT services companies.

Some of the objectives that CIO’s set for going with Portal products are –

1) Consolidation of web sites
2) Improvement in staff productivity by way of self service and reducing information glut
Off the shelf available features
3) Collaboration capabilities

But because of some organizational dynamics enterprise portals are not able to scale up to real enterprise level hence reducing ROI in the process -

1. Most of the above objectives are linked with softer benefits except for first which translates in real hard benefit. This makes difficult to sell portals to business user. Hence internal users see portal implementation as IT initiative rather than business initiative, except in situations where it is external facing.

2. CIO’s of big and medium organization have different priorities to these objectives.
But I would see these objectives are mostly pain areas of bigger company CIO’s than medium organization. This is because typically bigger companies have grown, build lot of disparate web sites/application and made IT investments in content mgmt, search, security, user directory store etc. So these companies are left with two options,

1. Use portal off the shelf features
2. Integrate with existing products/solutions
First option challenges portal capability Vs explicit technology products. Portal being generic product does not match feature set of specific products. But main problem while evaluating portal products is evaluators do not compare feature set that are needed for their need rather they try to compare best available feature by specific products. Eventually these companies do not use content mgmt, search, security etc features of portal but integrate with existing technology stack thus increasing total cost of ownership and reducing ROI.

3. One can say that it is governance issue which CIO’s/Portal leader have to address/decide. But as per management discipline CIO needs to handle these initiatives in democratic way, which means CIO needs to take application owners with them. While application owners are not very sure how Portal is going to impact their current status and job profile. In this process, they make sure to convince the management by saying that they would like to see first version of portal release and take a decision.

Also second argument that I have seen is about timelines and who will pay for migrating to portal, Would it be application owner or portal leader? Since Portal implementation is phase wise implementation with 1st phase typically takes some where 12 to 18 months of rollout (considering infrastructure setup, integration, SDLC etc). This typically means that during this process application owner’s budget for 2 years is spent on enhancing existing app or creating apps away from portal than migrating to portal. In this long process efforts that are spent on portal initiatives are diluted.

4. End users ask for Yahoo or Google like portal capabilities for usage within the enterprise

Apart from above strategic issues that CIO’s faced, Portal implementation also comes with technical challenges as below –

· Portlet specification in lasy few years is matured from vendor specific API’s to JSR 168 to JSR 268 which resulted CIO’s spending on migration activities
· Limited real estate available on Portal pages for portlets
· Portal pages can not be bookmarked using browser feature of “Favorite”, This is the way end users are accustom rather than forcing them to use Portlet for book marking.
· Rigid Personalization/Customization requirements leads to increasing horse power at back end , which eventually results in buying more portal licenses

Over a period of time above issues resulted in more down to earth and realistic Portal scenarios

· End users able to see summary information/data in small window while they can go to individual application for more details. This is more realistic approach rather than trying to consolidate “N” no of application within Portal framework
· Quick time for implementation
· Substantially reducing horse power requirement at server side which means reducing server cost as well as licensing cost
· Limiting Personalization/customization requirement rather than asking for Yahoo or Google like capabilities/scalabilities from Portal products

These scenarios have resulted in widget/gadget alternative as best option. Although widget/gadget was present much before portlet specification, ad banners etc are widgets only. However, now there is a considerable interest in using these within the enterprises for more sophisticated portal like applications.
You will see implementation of this approach at places like e.g., etc.

Even lot of portal vendors are providing widget/gadget capability within Portal, some of them are providing direct integration with Google portal as well. Surely it means that Portal vendors have realized the benefits and are incorporating these feature set under Portal umbrella quickly, although those have now tagged under web2.0 bucket.

There are few open source frameworks available which can get you up to the speed quickly to build light weight portals. These light weight portals addresses pain areas typically faced with Portal products -

· Provides “inbox” type of functionality on portal, while users can go to respective application to see more details
· Quick and low cost solution
· Does not need high horse power at back end
· Personalization/Customization needs are addressed using client side persistence mechanisms which is resulting in reducing server side load hence hardware requirements

Apart from above, it has added advantage in terms of supporting Web 2.0 capabilities like -

· Mashing up at client side using light weight technologies based on Web Oriented Architecture (WOA) like REST, RSS etc.
· This light weight technologies gives flexibility in integrating with different languages and platforms
· Client side integration between Widgets

So IT community is left with one argument that Widget/Gadget is not backed with any industry standard while Portlet specification is backed with industry standard like JSR 268. But in last few years, I have seen customer’s spending lot of efforts in migrating from one portal version to another, one portlet specification to another etc. This may be because Portals products are not very matured but this is not a convincing answer to business users.

Look forward for my next article on different capabilities available in widget/gadget frameworks.