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
.

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))

JAX India 2007: Web2.0: What you should do?

Craig McClanahan talked on the Web2.0 at JAX India 2007.You can find more detilas about what he covered in Shishank's post. Here’s a bit of elaboration of those 10 points what Craig suggested to make the web right :-
10 - Expose Data/Logic as services
* Content is more important than presentation.
* Use REST based Services when you “Can”
* Use SOAP based Services when you “must”
9 - Incorporate External Content
* No single application or database can contain everything
* Combine available content from multiple sources
8 - Seek QOS (Quality of Service) deals from Sources
* Authentication guarantee
* Performance provisioning
* API and format compatibility
7 - Give QOS Deals to users
* External consumer will also become dependent upon your content
6 - Adopt Agile Processes
* Continuous iterative improvement model
* Incremental release every 7-14 days
5 - Test Driven Development
* Reduce release testing
* Do aggressive unit /functional testing
4 - Architect for Scalability
* Separate view, logic and persistence
* Break into layers that can be independently scaled
* Add resource as needed for bottlenecks
3 - Embrace Heterogeneity
* Data and logic as “service” insulates layers both internally and externally
* Agile Technology benefits in for fast UI fixes
2 - Reach out to Mobile Clients
* UI for Mobile devices can share existing service
1 - Enable User Provided Content
* Participating in “mashups” counts
* User like to participate not just “view”

The suggestion that Craig has provided, gives a clear perspective on how Web2.0 should be incorporated gradually within your organizations portal, CMS or website.If you read the above points again I feel that some of them directly or indirectly take you to the SOA space where we re-architect our implementations so that our applications can be “loosely coupled” and “interoperable” when used as “services”.