Follow-up on my earlier post on “Gadgets/Widgets in the Enterprise”

This is a follow-up to my earlier blog post on Gadgets and Widgets in the Enterprise.

I am currently engaged at a client who is developing an enterprise application to manage their customer records. Their entire business revolves around their customers (well – if you are a hospital then your business revolves around your customers – patients!). The business users need to review information about their customers in near real-time and make decision and provide updates.

They have engaged a product vendor who had an existing product to manage this information. The product vendor’s architecture approach revolves around the gadgets/widgets based approach. They have broken down the user interface into many small blocks (which they call portlets). These portlets are put together into a page and displayed to the user. The pages and portlets are implemented using a combination of HTML and heavy JavaScript and are rendered to the browser (along with bunch of ActiveX for charting etc.).

The user has some flexibility to select number of columns to display portlets in. The vendor can control which portlets the user cannot remove from the page or move from its current position.

However, there are few problems with this approach.

1. These portlets have very limited capabilities to communicate with each other which force them to implement very self-contained portlets. This results in some duplication of code across portlets.

2. Their portlet runtime on the client-side is not based on any standard JavaScript library which makes it difficult to manage and maintain in long run.

3. Their server-side implementation is not based on any industry standard runtime (e.g., ASP.NET, JSP/JSF etc.) which create major hurdles in enterprise integration. For example, if they wanted to take few portlets and deploy it in their enterprise portal (say on SharePoint or WebSphere Portal), they will have to re-write these portlets as SharePoint web parts or WebSphere portlets. This defeats the whole purpose of “reusable enterprise gadgets/widgets”.

4. The portlets do not invoke loosely implemented services at the backend which make it extremely difficult to use enterprise data with other departments, agencies and business partners.

Given these issues and the fact that there’s a lack of enterprise SOA approach and enterprise repository for services and gadgets/widgets, the portlets usage will be restricted to this product implementation.

Hopefully a future version of this project will address some of these issues and make it easier for IT to deliver on the promise of business agility and flexibility using approaches such as SOA and Enterprise gadgets and widgets.

Until next time…