Re: web site vs portal

(Note: I'm a vendor)

Bruce Melendy wrote:
> we are currently looking at new platforms for our intranet, extranets and
> customer-facing web assets, and this question keeps coming up:
> 
> what's the difference between a web site and a portal?

That is an excellent question! My own position (as a vendor), when 
looking at the technologies involved and what our customers want, is 
simply this: maturity. A "web site" typically starts off as a simple 
information web (static or half-dynamic, with news aggregation and 
such), then expands with downloadable documents and "interactive" stuff 
like forums. Then, as the customer (who in our case is typically a 
medium-sized government branch or company/corp.) and web site matures it 
inevitably leads to what could be termed "portal" functionality: 1) 
integration of "real" applications and 2) stronger security 
(certificates, SMS tokens, Kerberos/NTLM SSO, digital signatures, etc.). 
The next step after that is (technical) integration with external 
parties. If you are a swede this progression will probably be familiar 
to you, as it is similar to the government guidelines published by 
Statskontoret 
(http://www.statskontoret.se/upload/Publikationer/2004/e200401.pdf).

The current common approach is to divide the earlier requirements from 
the latter ("CMS" vs "Portal"), for many reasons. One is the problem of 
cost: a smaller company cannot afford a "Portal" product, so a "CMS" 
cannot include such features or it would become too pricey. Conversely, 
a "Portal" has been seen as something "big" and "complex" and 
"technical" (because of the typical focus on integration and security) 
and hence have completely and utterly ignored such simple things as 
writing texts or creating menus (or if they have such features they are 
not easy enough to be used by my grandma). The approach, instead, have 
been to integrate "Portal" and "CMS" products in order to create 
"Portals with text". Kind of like: "For the price of two you get the 
value of one!".

Another is just technology. Portals typically have a different set of 
requirements, technically speaking, from those which manage content. I 
say "typically", because there is no real reason why it needs to be this 
way, other than the fact that it is difficult to do both, both in terms 
of know-how and development investment (trivia: which is why we in our 
company have both CMS-y experts, and people like myself who are more 
enterprise-y experts, and which is also why we used AOP to develop the 
whole thing, giving us a massively lower development cost than a 
traditional approach would mean).

We started late in the game (2002), understood the above problems, and 
hence wrote our product from the beginning to cater to all the involved 
customer parties:
1) Those with information need to be able to publish it easily and 
efficiently
2) The web administrators have to be able to control the web in great 
detail, with regard to security (roles,rights,logins) and design 
(fonts,colors,templates,etc.)
3) Developers have to be able to easily integrate new functionality into 
the "website" (aka "Portal"), using standard techniques like (last year) 
Portlets and (this year) JCR and WSRP. Having legacy integration 
techniques like iframe and reverse proxy portlets make it possible to 
integrate already available apps without having to rewrite them to 
follow the "latest and greatest" specs.
4) Last, but not least, it has to be affordable. Our smallest customer 
today is a one-man company who sells fishing gear (www.flyfisherman.se) 
and our "largest" is the Swedish IRS (www.skatteverket.se, not yet 
switched though). Finding a licensing model which "scales" from the 
small to the medium to the large, taking into account the fact that many 
in the medium range often mature (in a year or so) from a strictly 
content oriented web to an integration portal (with apps, secure logons 
and personalization/profiles), is critical. Another point is that the 
solution (both in terms of CMS and Portal) needs to be administrable 
without having to bring in external consultants all the time (such as 
fixing design and template issues). This is probably the most important 
factor for the long-term TCO.

I think we have managed to do all this quite well, and I'm not aware of 
many other products today that does this. Many fall either into the 
"CMS" or the "Portal" niche, but not many are able to handle both, and 
not many *want* to handle both, whereas from a customer perspective (as 
I see it) it is often critical to find a product that does precisely this.

With this as intro, specific comments below:

> now by 'portal' i don't mean yahoo; i mean internal employee-self-service,
> announcements, reports, portlets, dashboards, ERP and data warehouse access,
> etc; i also mean extranets for content providers, suppliers, distributors,
> B2B customers, and others.

I agree completely. This is precisely what we see our customers doing 
when they actually start building "portals".

> i'm struggling to come up with a good answer, but i feel it's got more to do
> with the technical differences between an application on a portal server
> versus one on a web server, and less to do with 'corporate' vs 'consumer'.

Agree, and as above, it also has to do a lot with at the level of 
maturity of the customer and their web. Many of our customers who 
started with a static content web last year now want to upgrade to a 
"Portal" (with services like the ones you describe).

> any thoughts on this, or references to good material, will be much
> appreciated.

FWIW, and HTH.

/Rickard