It’s Curtains For Portals
Tuesday, 09 January 2007
By Robin Bloor, Partner
Portals first emerged when the browser captured the hearts, minds and imagination of the software industry. With the advent of the browser, the windowed desktop was suddenly passé and the assumption was that the browser itself could become a kind of desktop. It wasn’t websites like Yahoo!, Excite, Lycos and AOL were also dubbed portals because they provided a similar kind of entry point to surfing the web.
Early portals evolved into the idea of an “Enterprise Portal” - portal software that provided a coherent access to all relevant enterprise applications, as well as to information available in the enterprise and to relevant external information services. Business users could arrange ‘portlets’ by choosing elements from a common set of interfaces to back office systems. Access to intranets, extranets and useful Internet resources could also be available. The business user could simply “pick and mix’, with a little help from IT.
It Was Never Going To Work
This idea was never going to work because there were too many business applications that portals could not accommodate (Windows and client/server apps, AS/400 apps, old mainframe apps, etc.) It was never going to be possible to convert all of those applications to have browser front-ends before the browser front-end itself changed. Here we are in 2007 and it has changed. Everybody’s talking about Web 2.0; Web 2.0 is certainly not your elder brother’s browser interface.
The portals that have been built and implemented are usually half-solutions at best. The rug is being pulled from under them because Web 2.0 is promising a shiny new GUI and portals are already beginning to look like something the dog won’t eat.
It Was All Wrong Anyway
In my opinion, portals were a wrong idea from the start. The crux of the matter is this: When you want to use some sort of access device, be it a desktop or a laptop or a PDA, you want either to navigate to stuff or do stuff. In a sane and secure world, you need to authenticate who you are before you can do anything. Authentication requires some kind of ID management software. If there were such a thing as a “portal” it should have a deeply intimate relationship with an ID management system that would ultimately allow the user to invoke permitted applications. So far so good - we might just be able to imagine a portal that does that - I believe that Sun has such a product.
But the next requirement simply blows everything away. The “portal” needs to be able to present a workable interface on whatever access device is being used (or possibly, refuse to execute because it isn’t possible) for whatever service has been requested.
For this, you need much than just a browser. You actually need a whole Service Oriented Architecture. What we are gradually uncovering here is a whole set of presentation services that needs to include identity and security services, messaging services (both for work flows and communications), interface presentation and translation (possibly dynamic) and probably, registry-based navigation.
And that is why it’s all over for portals; portals are miles away from being able to fit into SOA. Even if Web 2.0 wasn’t making them look terribly long in the tooth, they’d become an embarrassment when you tried to integrate them into a Service Oriented environment. It’s time to close the door on portals, and tiptoe quietly away.
By Robin Bloor, Partner
Portals first emerged when the browser captured the hearts, minds and imagination of the software industry. With the advent of the browser, the windowed desktop was suddenly passé and the assumption was that the browser itself could become a kind of desktop. It wasn’t websites like Yahoo!, Excite, Lycos and AOL were also dubbed portals because they provided a similar kind of entry point to surfing the web.
Early portals evolved into the idea of an “Enterprise Portal” - portal software that provided a coherent access to all relevant enterprise applications, as well as to information available in the enterprise and to relevant external information services. Business users could arrange ‘portlets’ by choosing elements from a common set of interfaces to back office systems. Access to intranets, extranets and useful Internet resources could also be available. The business user could simply “pick and mix’, with a little help from IT.
It Was Never Going To Work
This idea was never going to work because there were too many business applications that portals could not accommodate (Windows and client/server apps, AS/400 apps, old mainframe apps, etc.) It was never going to be possible to convert all of those applications to have browser front-ends before the browser front-end itself changed. Here we are in 2007 and it has changed. Everybody’s talking about Web 2.0; Web 2.0 is certainly not your elder brother’s browser interface.
The portals that have been built and implemented are usually half-solutions at best. The rug is being pulled from under them because Web 2.0 is promising a shiny new GUI and portals are already beginning to look like something the dog won’t eat.
It Was All Wrong Anyway
In my opinion, portals were a wrong idea from the start. The crux of the matter is this: When you want to use some sort of access device, be it a desktop or a laptop or a PDA, you want either to navigate to stuff or do stuff. In a sane and secure world, you need to authenticate who you are before you can do anything. Authentication requires some kind of ID management software. If there were such a thing as a “portal” it should have a deeply intimate relationship with an ID management system that would ultimately allow the user to invoke permitted applications. So far so good - we might just be able to imagine a portal that does that - I believe that Sun has such a product.
But the next requirement simply blows everything away. The “portal” needs to be able to present a workable interface on whatever access device is being used (or possibly, refuse to execute because it isn’t possible) for whatever service has been requested.
For this, you need much than just a browser. You actually need a whole Service Oriented Architecture. What we are gradually uncovering here is a whole set of presentation services that needs to include identity and security services, messaging services (both for work flows and communications), interface presentation and translation (possibly dynamic) and probably, registry-based navigation.
And that is why it’s all over for portals; portals are miles away from being able to fit into SOA. Even if Web 2.0 wasn’t making them look terribly long in the tooth, they’d become an embarrassment when you tried to integrate them into a Service Oriented environment. It’s time to close the door on portals, and tiptoe quietly away.
Comments