Hi all, just my two cents on this one according to my experience both technically and business speaking. Has you may have noticed in the thread I have put the word "Products" in order to avoid discussion around "What is a Portal?" and "What is a CMS". Basically the customer defines what will be his infrastructure and how will it present to users (He can call it a Portal, an Information Library, a an Internal Communication medium, whatever) So the basis of my statements is the Enterprise usage of both those products and the vendors that market any of them today, not the future.
So when do I need a Portal Framework or a CM framework (products) or both? This is mandated by you needs and strategy to solve those needs, nevertheless there are distinctions today that may help you to decide what you need to buy in to. A Portal Products today are mostly targeted to Intranets. So basically from a practical point of view for a decision maker there is no point of comparing these products with Yahoo or whatever website that calls them Portal. These products will not help you do the same to the extent that you may be thinking. So the differences of a CM Framework (usually called XXXX-CMS) and a Portal Framework (usually called XXXX-Portal) must be viewed in terms of the problems they technical solve within the internet strategy and ultimately in terms of business benefits they bring. Stewart Manley wrote quite well what is today's perception of a Portal: >A "user experience model" if I may call it that. A way of interacting with >a system designed to provide a one-stop-shop for key information in the >organization and outside. A way of presenting that information in a >logical, consistent, functional and configurable manner. I would add that a Portal Package does not offer just a user experience model because otherwise most CMS systems in the market could well offer the same user experience model (playing with templates and web design). This is because CM Frameworks and Portal Frameworks usually do totally different things on the back-end of a solution although in the front end (the Internal Web Site putting information available to users) they appear to do the same thing in certain cases. So comparing both should not be judge by front end appearances but rather backend. So here is where the customer IT strategy plays the main role when choosing which to use (or both). Portal Frameworks are helpful when IT strategy encompasses mainly three areas of action: 1) Get information hold on multiple legacy systems (SAP, CRM, Document Management Systems, Clinical Trials Systems, information hold on VAX/VMS application, AS400, including file systems etc) up to the users of that information in order to foster easier and faster information access to information spread across multiple systems. They also allow one to intertwine information hold on external systems of you company with the legacy systems that you are using. 2) With 1), you also want to foster project based collaboration through the use of standard collaboration facilities (Forums, Jounals, Calenders, Annoucements, Shared Work Areas, Notes, etc). Note this standard collaboration facilities are loose coupled to any business process (much the same way as Email Program like Microsoft Outlook does, or this CMS-LIST, or any other productivity tool you may think of). Usually these collaboration facilities follow Structured Collaboration Methods. Some Portal packages go to the extent of this bullet. 3) The effective creation or management of information (content or data) is not done by the Portal Framework but by the systems that you have in place within your company. That is, these systems do offer you facilities to manage information in other to streamline the creation and deployment of "complex" information. Note that although some offer Document "Management" facilities this is done in order to foster document sharing not managing the creation of that information (this is up responsibility falls upon the person or group that creates it). So within these three areas IMO there is nothing saying that Portal Frameworks help you to build systems to manage information. By the contrary, they enforce that their areas of expertise are within managing access, providing access, and displaying information hold in multiple legacy systems that actually manage the information. Between managing access and customizing access is where Personalization features play its role in Portal Frameworks. After all not all users have access to the same information hold in internal systems and external systems, neither users share information the same way. Usually the strategy that encompasses mainly these three areas of action a problem arises. "I have so many systems, and so much information that can be put available that I do not know what I should put available. After all if my strategy is to put all it will cost me so much and I'll the budget neither the time for it." This is where the 20/80 rules comes in. Just put available information and collaboration facilities that users use most of the time (thankfully these are usually very simple things) with the most impact on the decision making process. Well enough said of Portal Frameworks. Let's go to CM Frameworks. CMS are mostly targeted to Intranets too. But their impact may go further than those environments (Internet Sites, Extranets, etc). In contrast with Portals Frameworks, CM Frameworks help's you to build to solutions were management of content (human readable unstructured information) is paramount. They will not substitute your legacy systems, they will complement them. So basically CMS Frameworks are helpful when IT strategy encompasses mainly these areas of action (not only but I feel that they are paramount): 1) Make the creation, management and deployment of content simpler, more predictable, and secure (collaboration facilities are important but their scope is the management of information, that is it's not loose coupled). 2) Make content available on most channels as possible (not just intranet but also on paper, PDA, CD-ROMS, etc). 3) The information will be managed, hold and deployed centrally by a system or collection of systems that know how to interface each other. This is usually compliant with the IT policies for critical information systems. 4) Empower user's with direct access to an unified framework of tools to create manage and deploy information directly to Web Sites or any other channel with the least IT Department intervention (in Intranets environments or any other). 5) Provide access to end users of content with reliable and accurate information justified by the implementation of policies and process automation facilities (Revision Control, Workflows, Audit Trails, Electronic Signatures, etc). 6) Bottom line, get content faster out to the users while easing access to information controlled under the system while enforcing automated accountability processes. Personalization in CMS comes in two flavors: 1) Personalized Content Management areas for editors, writers, designers, etc. User's can personalize their works areas on for them to see what they need to manage according to their role) 2) Between deploying information and targeting information is personalization in this second flavor. After all, not all users will want to access same content. Whether one is speaking about CMS Frameworks or Portal Frameworks, if eventually a system does not cope with any of these two strategies described more or less above in a cost effective manner, neither is one or another as far I'm concerned. There are much more to be said about each other but I hoped to have stressed what is important for now. It makes all sense that Portal vendors and CMS are targeting the same audiences is up to them to decide what they need more. Furthermore it makes also all sense for both vendors expand their products to cope with areas traditionally separated. But nevertheless, as I explained in my previous email this would not do much for customers if not done with a holistic view of content management and information access patterns. Holistic I mean, by encompassing the different processes that content can be created, managed and deployed and accessed (Quality Processes, Trainning Processes, Marketing Processes, Documentation Processes, CRM processes etc). If you think, most of the strategies are between both of described ones (neither just one or another). I wonder why? I tell you why because neither fills right for most businesses. Choose well and wisely (maybe soon you will not have to choose). Best regards, Nuno Lopes Independent Consultant. -- http://cms-list.org/ trim your replies for good karma.
