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.