Fatwire : 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.

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.


da75zxrjm4
.

Content Integration Platform and Content Interoperability

Few days back Fatwire Introduced Microsoft SharePoint Connector as part of its Content integration platform. This new connector enables Fatwire CMS users to seamlessly access SharePoint content to use on the web. The Content Integration platform provides web-services-based, peer-to-peer content sharing capabilities that gives CMS users access to content stored across the enterprise without ever leaving the Content Server interface, and publish it to their public sites, intranets and extranets.

Enterprise content which are spread and stored in various content management systems and across platforms, the integration and seamless access of the content is still a challenge. Efforts are being made to overcome to manage content across multi-vendor, multi-repository content management environments. Recently talked CMIS is another such effort which defines a set of protocols, exposed via REST and Web Services definitions, for platform-independent interchange of content.

“…….Using CMIS-defined HTTP calls, you will be able to do standard CRUD operations (create, read, update, delete) against any compliant repository, regardless of the underlying repository architecture “

Though there are couple of valid questions which still need to be answered around the concurrent operations across content repositories, but it seems like that various CMS vendors or specification authorities are going to use “common web services” as their technology to move forward.We will definitely look forward for the success of content integration platforms or CMIS as it’s hard to find projects that were successful where vendors

took JCR170 as their selling point, nevermind you still find sales guys talking about JSR 283 in their product presentations :-)

RFPs, Implementation Scope and Costs

It’s been quite some time that I am into responding RPFs and RFIs in Portal and Content Management space and sometimes jump onto implementation for the solution that we have provided :-) .
This post highlights issues that project delivery faces when a customer hides the information of its existing software infrastructure during pre –engagement stage.

Most of the customers do not supply enough information while releasing RFP. (for a mid-large size project it might just be a 2-3 pages of “relevant” information).
Along with RFP comes predefined “timelines” and “scope” and as usual, time-bound response is expected from vendors. In any circumstance you are paid to respond and get business for your company. You are not left with a choice, but to provide a solution based on one or two liner requirements with no information or volume of development, enhancement or migration of software/applications. Apart from solution, you have to mend your effort and cost estimations and make then inline with what was proposed to you.

Also, you must have experienced a time gap between the day you get the project and the day your SOW is signed off. What happens in this time gap? Answer is simple. You end up including another set of high level tasks that were neither part of RFP nor you have heard in your pre-engagement calls(lucky if you get this more), which slightly(as of now) adds to what you have proposed.

Few weeks later you will come to know more about customer’s existing s/w infrastructure and you are told that apart from portal development there is/are CMS/DMS/Back Office application that needs to be migrated or enhanced to latest version. Not bad so far. You start analyzing, assume few things, give better estimates and go ahead. Bad happens, if the existing CMS /DMS/Back Office application doesn’t fit in to the portal product that you proposed (Remember: it’s not your fault). Service providers end up doing all tricks to make the integrations work and customer ends up paying huge $$$ to product support and consultancy. These commercials would have been easily eliminated if right information would have given at right time.

“Right information at right time” is what makes a better response, which not only provides a better solution (considering all underlying application, their integration, SSO etc) but also reduces cost (Trust me, Indian service based s/w companies charge far less than any Product base company for their support and consultancy excluding license and training costs))

Portals: Intruding the ECM space?

If Portals are the underlying technology for the presentation, aggregation, integration and SOA implementation (as every vendor talks about it ), then the Content Management System (CMS) is what feeds the portals.

Portals have been designed to integrate with CMS products as a part of their offerings. At the same time they have come up with their own version of built-in CMS.

Besides Partnering with vendors from Web Content Management (WCM) or Enterprise Content Management (ECM) arena, Portal vendors are also working successfully towards their own built-in CMS. These built-in CMS provide you the best a CMS product can offer. Journal Content Management, Document Management, Integration with MS office or Open Office, Drag and Drop of your desktop files, Workflow management, Integrated Publishing and Search.

WebSphere Portal 6.0 Integrates externally with CMS products like Interwoven Teamsite ,Documentum etc , also includes IBM Workplace Web Content Management Version 6.0 which itself carries a full fledged WCM capabilities. BEA provides the integration with Stellent, documentum and Vignette CMS products but has its own Content Management system and virtual content repository. Open source player Liferay portal 4.2 has come up with portlets for Alfresco (another open source Leader in ECM),but again it has its own "Liferay Journal" CMS which covers most of the WCM functionalities.

Sun and Bea have partnered with FatWire to provide Portal Server customers with unlimited-use licenses of FatWire Spark Portal Content Management (pCM) software at no cost.

There is a definite and clear separation of a built-in CMS and a third party CMS integration on to the portals. The choice is up to you, it all depends on what satisfies your business requirements. As for small and mid-size customers, these built-in CMS are doing the job, that too with a lot of ease and bringing in cost benefits.

CMS market has always been more mature, streamlined and more professional. On the other hand, the Portal market are not making the impact that was expected of them and was so fiercly predicted by the experts, a few years ago. The reasons could be cost, need, ease of implementation or lack of expertise with the service providers. In such a scenario are Portal vendors adding on CMS to their product feature list to stay alive?

If yes, what next? Would they continue to break ground and venture into ECM territory as they have now ventured into WCM territory?