Changing drivers for portal implementations

June 3, 2007

There was a time around 1999/2000 when first generation portals coming in place were solving the problem of consolidating information from existing web sites.  Hence they were strong in web “clipping” and allowed easy creation of dashboards. The better ones offered single sign on. However, they were up with very stiff competition – which is simple links and NT Domian/ADS authentication.

These capabilities are driven by having a single entry point to you corporate applications. That seemed to be the only driver here.

Then came mash ups, JSR 168 and WSRP.

 JSR 168, like J2EE JARsand WARs offered the Java world to deploy the same portlet anywhere. WSRP on the other hand was more tuned to mash-ups. No matter where you are running the application, as long as it follows wsrp, you could club UI elements of these applications together in a single page.

Now again, these capabilities are fixing the same problem, but are allowing easier creation of mashups and dashboards. Apart from that, now the are also trying to increase the application longivity and relevance. Which is by removing container lock-in and also by a standardized mash up protocol at the front end, keeing intranets talking to applications on heterogenous and non-standard platforms.

So the focus seems to shift from end user view, to developement and deployment view for a single entry point to an enterprise.

 Post that, in the last two years, they scrambled to add a whole host of applications over the infrastructure – collaboration, content management and others.

In the last two years, the real change starts to happen. Enterprises starting looking at SOA. Business agility, M&A and the dynamic business drivers in general along with increasing spend on IT – is forcing the enterprise applications to be more dynamic and agile then ever before.

The need for this agility drives Service Orientation at the back end layer, but leaves the choice of front end open.

Here, the portal vendors realized that they were in a very good shape to cater to “above service bus” needs. They have struts based UI framework – and other ways to create UI, they have navigation builders, authentication frameworks & SSO enablement, they provide frameworks for inter-application communication ( for both data and events) and extremely good support for existing applications as well. So theoritically, like SOA offers agility for business logic and business data, Portal architecture offers the same for presentation. It caters to single application, multiple brands as well as multiple applications with same  look and feel. It allows tying application built completely independently together.

So transactional applications driven by SOA drive portal from the other direction.

Portal vendors have responded to it differently. Websphere offers capabilities at both ends. BEA offers weblogic portal for SOA driven, Aqualogic UI for Intranet driven and a combination of both for needs requiring both.

Personally, with so much happening on the presentation layer – especially RIA and partly disconnected applications – it is hard to imagine the presentation of browser based applications remaining static for a very long time.

With the above capabilities, the drivers which make an organization go to market for portal products have increased to cover

1) Corporate intranets and extranets ( traditional need of a single entry point to corporate applications – going on from just sign-on to deep links to integrated workflows across multiple applications thus contributing to real productivity gains) Dashboards, report presentations and other aspects of BI are also being given increasing importance here.

2) Customer self service ( Some institutions like Banks, telecom etc. have the same user subscribing to multiple services – a single entry window to all of them leave users less confused thus reducing service costs)

3) Standardized web platforms for organization ( typically driven by SOA initiatives or by having an unmanagable set of heterogenous products – like 3 portal and 6 CM products) which also provides a set of “mini” applications re-usable across enterprise.

4) Collaboration (essentially a single workflow involving multiple people and multiple applications, primarily resulting in creation of a document)

Looking at the new set of feature improvement in portals, like increased Mashup capability for non-WSRP applications, embracing outside the firewall tools and collaboration infrastructure, increasin Content Management, Increasing interface with non-browser applications (like MS office), user created forms based applications via BPM, and more – they seem to be poised to address yet another business need – the need for ad-hoc applications.

Advertisements

3 Responses to “Changing drivers for portal implementations”

  1. Idetrorce Says:

    very interesting, but I don’t agree with you
    Idetrorce


  2. I cannot believe this will work!


  3. With havin so much written content do you ever run into any issues of plagorism or copyright infringement?

    My site has a lot of exclusive content I’ve either
    created myself or outsourced but it appears a lot of it is popping it up all over the web without my agreement.
    Do you know any methods to help reduce content from
    being ripped off? I’d truly appreciate it.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: