Re: web site vs portal

Hi Rickard,

After a few unpleasant tasks as moderator - reprimanding Paul Bain and 
others for ad hominem attacks, and the occasional vendor blatant 
self-promotion - I would like to say that this is the most informative 
post by a vendor I have seen in some time.

I hope others will follow your example.

Vendors are quite welcome on the CMS list when they teach us something 
valuable about the problems and the process of CMS in general.

Rickard Öberg wrote:

> (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
>
> _______________________________________________
> cms mailing list
> [email protected]
> Subscription controls:
> http://lists.cms-forum.org/mailman/listinfo/cms
> Netiquette FAQ and related CMS lists - [cms-forum], [cms-pr], 
> [contentmanagers], [cmpros]
> http://www.cmsreview.com/NetiquetteFAQ.html



-- 
Bob Doyle
Editor In Chief, CMS Review - http://www.cmsreview.com
Executive Director, CM Pros - http://www.cmprofessionals.org
CEO, skyBuilders - http://www.skybuilders.com
77 Huron Avenue
Cambridge, MA 02138
617-876-5678