AUCKLAND (02/24/2004) - It's sometimes forgotten when choosing portal technology that organizations don't "willy-nilly" change application servers.
And it's one reason why you shouldn't commit fully to a development strategy or platform until you've selected your portal vendor, says Neil Brown, a senior solutions architect for Electronic Data Systems Corp. (EDS) in Wellington.
Brown acknowledges that this may be a controversial position. But he says he has worked with several vendors and considers himself a "pragmatic architect" who maps the strengths of products to the project. He divides them up into portal-specific ("shallow") and application specialists ("deep").
In the latter group are the integrated software suite big guns, IBM, BEA, Microsoft, Sun, Oracle, Sybase. In the first group are companies like the leading portal independent, Plumtree, Epicentric and Citrix. He suggests that because suite vendors have no good reason to "bend over backwards" to help their smaller, more focused rivals, they are "a good place to start" for those portal-seekers wanting server-delivered material such as dynamic content. Besides, much portal technology is proprietary.
Independents, by contrast, pride themselves on offering technology which can work on a variety of platforms.
Brown, who claims a decade's portal experience in Europe, the U.S. and New Zealand and clients in telecoms, healthcare, e-government, finance and education, says standard definitions of portals are misleading.
He scoffs at definitions like: "A simple, standard solution for a well-defined business need." Portals are not simple; they consist of various technologies bundled for convenience and impact a wider variety of applications in an organization. They are a lot more complicated than "slapping on a front end", he says. Most problems come when trying to integrate different functions.
Moreover, he has never seen the same problem twice. A portal is more like "a framework of services that manage access by known users to 'stuff'" -- stuff being data, functions, apps and documents.
While vendors will make a range of claims and features for their products, Brown says there is common ground. Single sign-on (difficult but major advantages; don't give up on this), authentication (becoming easier but still a bit of a headache), entitlement (what users can access), content integration, support for delivery to any device (great if out of box, otherwise difficult), infrastructure (not out of box).
Other features, such as personalization, collaboration and use-based billing tools, Brown considers useful but not necessarily a must-have. Out of all the advantages for implementing a portal, two reasons have the biggest financial impact, he says. These are creating economies of scale and the process of web-enabling applications. Similar issues arise in portals to Web enablement, he says.
So here's how to do it. Assess your real business drivers and organizational needs, identify likely users and their patterns of use, the functions wanted, what source systems you have and will have, and your current IT strategy. Extend your scope beyond vendor products to realize full economies of scale. Your portal should then be chosen and a gap analysis done relating to issues like authentication integration, account management and support.