RE: CMS tutorials

"J Graham Zahoruiko" <graham.zahoruiko-aO66/[email protected]> Sun, 21 Dec 2003 18:06:06 -0500
Newsgroups gmane.comp.cms.general
Organization Refresh Software Corporation
Message-ID <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAp9VEomI3RkWCXVbMMW4M3cKAAAAQAAAAvrISMkryU02iWfNbjahPyAEAAAAA@refreshsoftware.com>
Andrew,

Greetings.  My apologies for the delay in responding - its really been a
busy week!

In my note I stressed the need to leverage the Open RDBMS as the point of
integration for all content systems (CMS) combined with an Open publishing
model (no API - use your own tools, scripting languages, application
servers, etc.).

Basically, portals are on the publishing side of the system (or the right
side).  (Left = CMS; Center = RDBMS; Right = Publishing).

The portal is for presenting content (or other assets) to consumers of
information (visitors to the portal).  Ideally, this information should be
pulled from its point of integration - the Open RDBMS and/or from other
enterprise applications such as CRM databases, product databases, HR
databases, etc. 

As it relates to the CMS features within portals, I believe that by
co-mingling a publishing solution (in this case a portal) with CMS
functionality is a mistake - there will be tons of usability and integration
issues.  Most of today's end-to-end CMS systems also combine the publishing
function and this is OK for Very Basic requirements (brochure ware sites),
but it is Not flexible at all and often leads to significant cost -
sometimes up to $25,000 per user per year - according to Matthew Berk @
Jupiter Research.  Many companies make the mistake of approaching their
problems by listening to a particular vendors approach to the architecture -
in most cases you'll end up with something proprietary that completely locks
you into proprietary technology. If you flip this around, and force the
vendors product to leverage Your RDBMS and Your publishing model - you'll be
in control and will find life is much easier.  And, you'll have a complete
system without all the overhead.

Specifically as it relates to portals, I find most customers requirements
are simply met with a "light portal" interface, which is typically homegrown
or comes with one of the application servers providing the security,
personalization, and component framework.

I divide portals into 2 categories:  Public facing & Internal facing.

Public facing portals typically deliver a segmented, personalized experience
for the viewers or consumers of content (information) - like yahoo.com or
the Portal Web site for your state or local government.

Internally facing Portals typically aggregate information specific to the
needs of the user (Office applications, financial charts, CRM interface, HR
information, etc.) and can be configured/customized to display the
information required by each user or group.

The NET/NET is, the RDBMS is for integration & storage, the CMS is for
managing content (creation, workflow, versioning), and the Portal is
leveraged for publishing information in a specific format for consumption.

If your users are simply looking to aggregate internal information into one
standardized interface for consumption, a "light portal" would work well,
but you may need to leverage a CMS to get the content into the RDBMS so it
can eventually appear on the portal.

Hope this helps, and sorry for the delay in responding.

Best,

Graham

________________________
J Graham Zahoruiko
President & CEO
Refresh Software Corporation
51 Middlesex Street
North Chelmsford, MA  01863

P: 978-251-8870 x221
F: 978-251-8872

www.refreshsoftware.com

SiteRefresh - Core Content Management
Free Online Trial & Developers Sandbox


-----Original Message-----
From: cms-list-admin-/[email protected] [mailto:[email protected]] On
Behalf Of Andrew.Bean
Sent: Tuesday, December 16, 2003 4:36 PM
To: 'cms-list-/[email protected]'
Subject: RE: [cms-list] CMS tutorials



Graham:

Thanks for the great note. I am in a similar position as Nagarjana
evaluating which direction our organization needs to proceed and your
insight is appreciated.

Can you please help me out further in my research by detailing the purist
role a portal should fulfill? I know it depends on the organization, I am
just looking for a definition. I see so many "portal" products that provide
CMS options that I don't know if our solution is a best of breed CMS or a
best of breed portal server. Marketing terms and abbreviations like
Enterprise Information Portal (EIP), components, and portlets are really
only confusing our search due to their inconsistent use across products and
feature sets.

I am having a difficult time establishing a common language of terms between
our work groups because of the overlap in these different products and
people's differing understanding of what they each are supposed to do for
us.

Andrew Bean
--
http://cms-list.org/
please trim your posts.

--
http://cms-list.org/
please trim your posts.