The widely used term “portal” is ill-defined and often misleading, says software architect Neil Brown.
A portal is a framework of services that manages access by known users to “stuff” — data, discrete functions, documents and applications. The “known user” classification is necessary, Brown says. Without a defined body of users, what you have is a website.
Vendor and analyst spin is difficult to get away from, says Brown, who works at services company EDS.
“There are a thousand definitions of a portal, which means in practice there isn’t a real definition.”
Brown, speaking at the March meeting of New Zealand’s Worldwide Institute of Software Architects (WWISA), says the “spin” must be cut through before a business can make a competent decision whether a portal is appropriate to its needs, and what technical questions need to be answered for an effective implementation, he says.
He uses an analogy from physical architecture to describe a portal’s operation. You swipe an ID card to enter a door, and this lets you into one or several rooms where you can do things. The “rooms” may look different for different users, both cosmetically and in the repertoire of functions served up by the applications. There is a line of demarcation here, he suggests.
“Whether the walls are pink or blue — personalisation — is a matter for the portal. Whether there’s a fridge in the room or not is something that should be managed by the application.”
The chief division in the market is between infrastructure portal providers, who also deal in applications, and “pure play” companies, such as Plumtree, Epicentric and Citrix, which do not have deep application repertoires. The former, Brown predicts, will overtake, or even take over, the latter. “People are crying out for access to applications.”
Single sign-on to an authorised range of applications is one of the most attractive features of a portal for the user, he says. But this means huge issues of authentication — “who you are”, and entitlement — “what you can do”. Entitlement issues should be carefully discussed with users, he says.
Portals can be further divided into “self-service”, where the users have substantial control over their personal data and the choice of applications they access, and a more centrally controlled scheme. This has significant consequences for design, particularly in authentication procedures.
Content integration is the core appealing feature for the user. The ability to collaborate through the portal with other users may be significant in a particular environment, but is typically less so.
For the implementing organisation, several justifications are typically advanced, from competitive advantage to assisting marketing and improving customer loyalty. But the two big winners, he suggests, are economies of scale — being able to slot in new applications easily — and the web-enabling of applications. An industry is growing up around “wrappers” for applications to accommodate them to a web-based portal: portlets, gadgets, web-parts or blocks in the language of various vendors. These make the portal/application interface easier, but they tend to prescribe the way you do things, he says.
Directory access management is a significant, but often underestimated key challenge in portal design and implementation. Applications should be planned before making a decision on the portal but not implemented until the portal has been selected, because of the interfacing issues, he says.