Content Delivery Options in CMS

Recently, I was part of a Web Portal selection process, various vendors proposed their product and came up with demos, and tried their best to answer most of the questions which we asked them in our RFP.

One of the questions was about ‘Integration with our existing CMS’. This was the area where I was interested, so I was attentive and analyzed every word they spoke about integration. Unfortunately, none of the MQ ‘leaders’ were convincing enough on the CMS integration side, moreover, they were trying to propose their WCM product,  in line with their Portal Stack.

I was quite surprised while they were pushing their WCM product, without even knowing why and for how long we(customer) were using other vendor’s WCM product. They were having no idea about the volume of content we had and how simple or complex our implementation was.  It’s quite common for vendors to propose related products alongside their core product. But, when it comes to Integration of their product with other vendor-product, you will often hear them saying – ‘we have a partnership’,  ‘we can write a custom connector’, ‘we can use web services’ etc…. But how truthful are they while making these claims is an intriguing question? I think it is better to research integration options beforehand or ask your vendor for a specific case study along with customer testimonials.

Coming back to the topic of this post –

We all are aware that the vital principle of the content management system is to separate content from presentation. This is true, as we don’t create different versions of the same content differently for different delivery platforms. One content can be targeted to many channels such as – desktop browser, portal interfaces, mobile devices, etc…and when we say different delivery channels, we have different options to deliver the content to these channels,  I will cover some of them here –

  1. Presentation Templates: This is pretty common, most of the implementation takes this approach, be it intranet microsite or internet website, developers can use product-specific APIs to fetch the content and present the same to the site visitors.
  2. Presentation Portlets: Some of the content technology vendor ships CMS portlets for their portal products. Ex. OT-Vignette, IBM (Authoring/Rendering Portlets), and others. On the other hand, few core CMS vendor ships content portlets for different Portal Products. These portlets can be deployed on the supported portal platform and are responsible to fetch the content from CMS and display it on a portal page. You can configure CMS portlets in a portal page which can display your content from one or more CMS sites/nodes/workspace. Most of these portlets provide an interface to create, manage and display the content.  Management Functions are quite limited and if in case they do not cater to your requirements, you may want to extend these portlets and write additional custom code based on your requirements.
  3. Presentation Templates(For portal interface):  This is straight forward. You can use this approach when there is no clean integration available between your CMS and the Portal Platform. Write a simple presentation template as mentioned in #1 for fetching the content, apply the right CSS(as per your portal look and feel), and make sure that the HTML you use is aligned with the portlet/channel/i-view, etc. Once the template is complete, publish the page as HTML(static publish). Configure your portlet to fetch this HTML file. This is a quite simple/fast/non-expensive way to get your CMS content on a portal page. A disadvantage of this approach is that it’s a one-way communication channel. You can only ‘read’ your static content. Dynamic content delivery, in-context editing, and User Generated content will not be applicable in this approach.
  4. REST: This could be one of your options to access content if your CMS provides REST APIs for accessing the CMS data. All you need is to use REST URLs and access a resource in the system and get the output in either XML or as a JSON object. Once you have the required information/content, you can apply the presentation to render it. It’s not only the read but a  supported REST service that provides developers with Create, Edit, Update, Delete (CRUD) functions for operating on the specified content/content-object.
  5. RSS: There are a couple of scenarios and options to fetch and render content using RSS.  Take an example of a news feed from CMS – You can write a content template to search your News content based on publish date/time, retrieve the data, and generate the RSS XML. You can now either display it for a web page or you can consume it in an RSS Portlet/Reader. Another way is to export your content as XML from within the CMS and write a utility to generate the RSS XML and to display/consume it.
  6. Content Delivery on Mobile: If you are using a WEM stack with a Mobile delivery platform integrated with your content management system, it becomes fairly easy to target content to a particular mobile device. You can leverage the device database to know the device’s OS, type(touch/key-based), screen(size and resolution), and apply the right presentation (Layout and CSS) Template, before rendering it to the Mobile device. If you are not using any sophisticated mobile delivery platform, you can use application filters to Modify(Only HTML & CSS) your actual CMS specific Presentation templates based on the type of device group (as you don’t have a huge device database in this case)and then target the content + presentation to the Device Groups.

Apart from the delivery options I mentioned above, there could be other ways to deliver content from your content management system. It all boils down to your requirements, the participation level of end-users at the presentation end, and most importantly, the delivery interface.

Thanks for dropping by and do share your experience and your approach to content delivery from CMS.

Web Content Collaboration: Extending WCM Realms?

FatWire recently announced the release of two new products -Gadget Server and Community Server. These social computing products are tied directly to FatWire’s Content Server (CS), a Web Experience Management (WEM) platform.

Real Story Group Analyst Apoorv wrote a nice post with some great takeaways.

Yes, there are not enough gadgets for content contributors and the community server does not offer anything more than just blog functionality, but I think the idea behind is to “populate” or “pull” content from the end-users. A young platform laid out for a two-way content collaboration i.e. exchange of content from both corporate content contributors and site visitors.

Having said that, this is my take on the recent release –

1. WCM Implementation in Conjunction with Portal:

Customers with existing Implementation of FatWire Spark-PCM on Sun/Weblogic portals have the luxury of using various portlets that are tightly integrated with CS. Administrators could easily configure portlets based on the editor’s needs. So, in this scenario, just a few WCM specific gadgets will not make much of a difference for editors, but developers can easily place these gadgets on any web page as a part of the FatWire page layout process.

Personalization is a capability that every portal offers, based on requirements, personalization at multi-levels can be configured using the portal itself. Additional Investment on gadget server will not be many benefits unless you have a requirement to let template developers utilize the capabilities to add gadgets on web pages during the page layout processor for the end-users to personalize their dashboards with these light-weighted apps. The usage of gadgets becomes positive within the WEM framework where  Site Admin wants to create a page with a certain layout and include these gadgets within the slots. It’s a quick and easy way of developing new content-centric pages. Another advantage is gadgets created within FatWire’s Gadget Server can be exported for use on third party websites such as igoogle.

2. Pure WCM implementation for external WebSites:

It depends on what type of website one has. For a website selling products online, it will be a nice idea to implement functionalities offered by Community server as it will get you customer’s feedback and reviews related to product sold. This can potentially be a platform for you to support customers online, share best practices or share product manuals. As good it may seem from the user end, it is equally difficult from the website management perspective. Most of the user-generated content will be stored in the Production environment while Staging will just be used by internal content editors. Different information will be stored in various silos and IT will have to work around syncing of content between environments.

3.  Pure WCM implementation for internal Sites/Microsites:

I see a huge potential in this area. We have a large number of ‘social networking’ platforms and tools in the market and over the internet. What lags in the WCM space are the tools and functionalities by which internal users within an enterprise can be networked together and form a ‘content collaboration’ space.

With community and gadget server integrated within the WEM framework, the realm of WCM is extended, so does the flexibility of retrieving and contributing information from the internal users. If wisely implemented and keeping security and authorization into consideration, information and knowledge can be reused, relevant content can be collaborated from across the boundaries and from within a business unit of your enterprise. Now, it’s on the individual organization’s WCM strategy how they drive productivity around the information. All an all a right Content Strategy that identifies the demarcations and overlap of document, social and content collaboration.

Most of the organizations believe in the ‘push’ of the content. The push of content happens at various levels, it can be targeted to either one business unit of the organization, or a partner on the extranet, or the site visitors on the internet.

There are valid use cases and business requirements for the same, but that’s not the point where the story ends. Enterprises today are not just targeting content (newsletters, campaigns, product info, recommendations, etc) to the end-user but the emphasis is being given to ‘pull’ of information from the end-user. There is a need for a business channel that is interactive. This 2-way methodology of content contribution and collaboration helps organizations to–

1-  Create a Knowledge repository from the users of a particular business unit working towards a similar goal.

2-  Get actual feedback from the site visitors

3-  Interactive Support

and most importantly –

4-  Reach out for useful insights

Rich back-end content management systems with complex features are around for a while. A non-technical business user finds it difficult to learn, contribute and manage the content.

WCM products lag User Experience, which is quite seriously taken up by collaboration products. Amalgamations of these two categories of products are on the roll and the adoption will be fairly wide shortly.

Content Integration Vs Content Migration

Few days back Fatwire Software announced the launch of the Fatwire Rescue Program for Vignette and Interwoven WCM customers.
The program will enable customers of Interwoven and Vignette to upgrade to FatWire’s WCM solutions at no license cost. However, this holds good only if they engage Fatwire’s supported or so-called ‘proven’ migration tools and services.
Vamosa and Kapow. I hope this move will hold well for Fatwire in WCM market space.

If you remember Fatwire already has a Content Integration Platform(CIP), which is a “web-services-based” content sharing tool. In this Fatwire CMS user can access content stored across the enterprise without leaving the Fatwire CMS interface (CS-Direct). CIP offers connectors to access content from Documentum, SharePoint, and Windows and Unix file systems.

So why this rescue package from Fatwire when they already have a solution in place? Here are my insights on the demarcation between the two offerings and the differences in the approach –

1. In Content Integration Platform, the source WCM/ECM sever must be up and running in order to serve the content. The only difference will be accessing the content using Fatwire console (dash/advance/insite interfaces).
[Access + Connector = Integration]

2. Fatwire rescue program is based on the expertise and past experiences of Content Migration service providers (Vamosa and Kapow). Server Instances of Teamsite or Vignette will not be required after full content migration.
[Entire data movement (Assets/Content/Templates/Workflows/Roles/Security/Users/Publishing Events) = Content Migration ]

Since there is no Fatwire connector for Vignette and Teamsite as of now, I believe this is another way of attracting the customers to move completely into Fatwire at lower cost (No license cost + No Running Instances of Teamsite or Vignette required).

Content Migration is a very risky, customers are advised that there is no fully automatic or a neat way of doing it. Manual intervention and tweaking of trusted scripts, XMLs and non-java based templates is very much required in order to do the migration. Evaluate and request for case studies or a proof of concept from the product vendor before you make a decision.

I am glad that in the midst of acquisitions in the WCM space, Fatwire is the one of the niche player who is moving a step forward by collaborating with content migration service providers like Vamosa and Kapow. I hope this move will hold well for Fatwire in WCM market space.

How IBM is #1 in web portal software?

IT analyst firm Gartner, Inc., has ranked IBM as the worldwide market share leader in the Portal Products and User Interaction Tools enterprise software segment. Here is my take –

There is no question on the capabilities and functionalities of IBM WebSphere Portal V 6.1, which is well designed to collaborate the information from users, communities, corporate enterprises, and the Web. I will not discuss the cool and robust features of IBM but will list down the external factors that might have influenced the ranking-

1. Technology: Still the market share of .net is much less than java. IBM being a java based portal and is adopted by organizations who either already have java based software infrastructure or their decisive people are pro-java. I agree with Janus

“Microsoft is known to give away SharePoint like candy, so SharePoint might indeed have less revenue. A substantial portion of SharePoint licenses remain unused.”

Yes, the Adoption of SharePoint (MOSS) is much higher than any portal in the market (07-08), and who does the marketing better than MS, but the point has still not reached where SharePoint can be ranked as #1.

2. Choice: Do customers have choice?..ummm –lets find out-
a) Opensource/Liferay: Even though Liferay is named as the Visionary portal product in Gartner’s magic quadrant, the financial industry has no confidence in this open source portal. On the other hand, IBM software is being used by the top 10 global banks.

b) Sun JES Portal: before the acquisition: The setting sun finally decided to stop the further release if its enterprise portal product (last version 7.2) and decided to contribute towards Websynergy and Webspace (Liferay-Sun combo Prj).

c) Oracle/Weblogic/Webcenter: Oracle invested huge $$$ in their Webcenter portal project but failed to market their so-called strategic portal product. Market still questions Oracle’s portal leadership. With five portal products under its belt, seems like that sale and marketing team is confused on which portal to highlight. I believe that aqualogic and weblogic are doing pretty well but not widely adopted as IBM WebSphere.

3) Leadership/Support/Cost: IBM tops the chart in terms of cost for its product, services and support. Even then, organizations opt for security, availability, collaboration and other web2.0 stuffs over the cost. It might be because IBM promises better ROI. I believe that 2011 will be a crucial year for IBM portal after the economic recession ends as most of the organizations have kept their decisions on hold for buying an expensive portal products.

There can be other reasons as well such as innovations, industry types, underlying architecture etc that might have valued customers more in buying this product.

More information about the report, features, and a case study is here-
http://www.eweek.com/c/a/Web-Services-Web-20-and-SOA/Report-IBM-Number-One-in-Portal-Software-333186/

Let’s get SharePoint Integrated

I’m currently seeing a new trend these days, it’s about portals and content management systems going above and beyond their technologies, language and platform to get integration with SharePoint. I have put my views on how Content Management Systems (Fatwire and Immediacy WCMs 6.1) are tending towards integrating with SharePoint. Now, it’s the open source portal which will come up with a similar kind of integration with SharePoint.

Integration with Sharepoint from a non-open source Java based portal is not new. IBM Websphere uses WSRP for communication with Sharepoint, while Sun Portal Server 7.2 integrates with Windows SharePoint Services (WSS) 3.0 which provides a set of portlets to get deployed over Sun portal.

Latest in this area is about open source portal Liferay 5.2 which is about to get release soon is coming up with a feature to integrate with SharePoint. The Implementation of the SharePoint protocol will allow saving documents to Liferay as if it were a SharePoint server.
Except WCM, most of the customers feel that SharePoint has more “admin” friendly document collaboration features, document categorization, roles based document access and defining document types on the fly. Altogether it provides better DMS capabilities.

As neither Fatwire nor Liferay has their own full fledge document management system. Enterprises with existing SharePoint investments and who are looking for a portal or WCM solutions can look for these connectors/portlets.

Anyways, the thought around these integration approaches is to have “seamless access” to SharePoint’s repositories without leaving the actual Interface of either portal or web CMS.
As far as cost is concerned, I am not sure if the “SharePoint integration” will be a part of Liferay Community Release or if there is any additional commercial involved in its Enterprise Edition. On the other hand Fatwire-SharePoint Integrator costs tens of thousands $$$ for each Sharepoint deployment.

I will constantly look in this area of integration and will provide more information as soon as community version of Liferay is released.

Blog at WordPress.com.

Up ↑