News Stay informed about the latest enterprise technology news and product updates.

Potential portal problems

Everyone has had problems integrating multiple, diverse, departmental solutions of one type or another. In this column, Phil Howard wonders why we haven't learned our lesson.

Market Analysis

Potential portal problems
Here we go again. You'd think we'd have learned our lesson by now. Hands up everyone who has had problems integrating multiple, diverse, departmental solutions of one type or another. I can imagine a forest of arms waving in the air. Well, it looks like it's happening again.

Enterprise portal deployments tend to be expensive beasts. And, over the least couple of years, with budgets cut and large scale investments off the agenda for many companies, you can hardly blame portal vendors for looking for lower hanging fruit. To wit: departmental sales.

By no means all portal vendors have been taking this approach as a first line marketing strategy, but all have to a great or lesser extent, and some vendors regard this as their major market focus.

The perils from a user perspective are obvious. If departments or divisions are free to develop their own portal solutions then the danger is that they will end up with multiple portals from multiple vendors and then, if you decide that you need to implement a corporate portal, you will need to integrate or replace the existing portal solutions.

On the other hand, you can see the sense from a supplier perspective. If they can prove their value with one implementation then they have the potential to expand enterprise-wide in due course. Always given that some other vendor isn't doing the same thing in some other department. And there's the rub: they probably are.

There is some hope on the horizon. Standards bodies have started coming out with standards for portlets (or Web Parts or e-Clips or gadgets [although Plumtree doesn't call them gadgets any more] or whatever) and pretty much all the vendors have said that they will support these standards. Which is fine in theory but we all know what happens with standards: vendors always think they know better and add extra facilities. And, in any case, what about all the existing portlets that have been built that don't adhere to those standards?

The other good sign is that some portal vendors, Sun for example, are already talking about providing meta-portal facilities. That is, the ability to act as a corporate portal that takes heterogeneous departmental portals under its wing, so to speak.

But, as is so often the case, you take two steps forward and one step back. It is becoming increasingly easy to build departmental portals. This means that they are likely to proliferate. Microsoft, for example, has some 20,000 team-based portals based on the now defunct SharePoint Team Services. While it shouldn't be a problem integrating all of these within SharePoint Portal Server (apart from the fact that the Web Parts written for the old version of the product won't work with the new release and will have to be re-written), this an environment where a single vendor approach is obviously mandated. Imagine having 20,000 portals to integrate, where they were using diverse portal technology!

Far be it from me to dictate strategy but it would seem to make sense for corporate IT departments to establish guidelines about the development and deployment of portals, so that the potential problems highlighted here do not come to fruition.

Copyright 2003. Originally published by, reprinted with permission. provides IT decision makers with free daily e-mails containing news analysis, member-only discussion forums, free research, technology spotlights and free on-line consultancy. To register for a free e-mail subscription, click here.

For more information:

  • Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
  • Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
  • For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
  • Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.

  • Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
  • Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
  • Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
  • Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
  • Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.