Interwoven TeamSite Usability with personalized content

As we know, content personalization is fairly common requirement in WCM world. Every customer wants to present the information which is relevent to their customers instead of content flood. Content personalization is being asked at user specific or user role specific.Content personalization is probably an old school requirement but still lots of companies talk about it where they have not reached to the extent of personalization, they would like to achieve and bring better conversion rate using their online channel.

When we need to provide personalized content using Interwoven TeamSite, it can go little tricky. Few people may not like this statement but this is the fact or I would say you pick any other content management tool as well and you will find similar problems. TeamSite provides great abilities to integrate it to any delivery platform if we define our content structures and meta model correctly but when we need to define user specific content it looses its charm because of content virtualization.

If you have loads of dynamic content on your site which is specific to a user or a role, then it will not be easy to virtualize this in the CMS and without a completely virtualized site in the CMS, CMS user experience can go really bad!! There are ways around this to define preview templates in the CMS and preview individual pages but it does not give you flexibility of virtualizing the complete site inside the CMS.

The key problem with Teamsite and personalized content is, user will find difficult to locate content inside TeamSite and he may end up browsing tons of folders!!

This scenario happens quite often and only solution I tend to suggest my customers to make extensive use of

Interwoven TeamSite bookmarks or

IDOL search platform

So just a word of caution, please consider CMS usability a lot when you are trying to present personalized content. This may sound simple as part of the implementation phase but it can make your business users absolutely mad when they need to mantain the content!!

Autonomy/Interwoven “Meaning based Marketing”

Couple of months back when Interwoven was acquired by Autonomy, I was fairly surprised about this acquisition. I was wondering Autonomy’s thought process for this move. I was not very clear

• How autonomy will use Interwoven’s flagship product TeamSite?
• How will they market it?
• Did they acquire Interwoven because of its customer based?
• or eDiscovery solution because Interwoven was fairly strong in this area.

But when Autonomy launched its campaign with buzz word “Meaning based marketing” I was able to visualize it clearly!

Autonomy is very good in knitting the new companies under its umbrella flawlessly and it has proven over the time like K2, Verity, Zantaz and Merdio etc which were acquired by Autonomy at one point of time and they were completely absorbed into Autonomy suite.

Autonomy seems to have similar plans for Interwoven as well with its new buzz word “Meaning based marketing”!!

Autonomy IDOL engine which can listen structured/unstructured content on multiple channels and test across all types of customer interactions and then deliver the content to targeted customers. You will find that TeamSite/Media Bin/Live Site all will become part of the bigger campaign from Autonomy now automatically..isnt this cool from Autonomy?

Read this paper from Autonomy and you will get the gist of it!

This concept looks pretty cool on paper but I am very keen to see some working demo or web cast of it which I am not able to get hold of…

Share your views on the success factors of this campaign from IWOV ..aha no Autonomy!

Fatwire/Portal Integration

Long time, didnt write much about my latest experiences of CMS world!

Okay recently I got a chance to explore Fatwire WCM and further to work on Fatwire/Portal integration problems. This was fairly interesting project where I found, a service company delivered a working solution without considering the operational mess of it!

Fatwire is fairly light weight product, you can get it up and running fairly quickly compared to Vignette where you need to consider multiple servers and couple of services and then integration between its services for its deployment architecture. Fatwire WCM is a again a simple war file cs.war which can be deployed to your loving application container like Tomcat, Sun portal, JBoss ..so personally I do not see much of compatibility issues.

Flex assets are great capability of Fatwire which enables developers to add new fields without much of problem. Flex assets means flexible assets which can be extended on need basis. Design of flex assets is key but lets not go into that detail for the moment. Fatwire works great when Fatwire is going to work in the delivery stage itself but this is not the real world scenario.

Large enterprises tend to use some robust and proven delivery application servers like Weblogic, Sun portal, JBoss etc …so challenge comes while integrating Fatwire with portals.

As always, while integrating CMS solutions with portal, we always ask a basic question before start thinking about detail design

• CMS centric design which means CMS will have more control on the implementation
• Portal centric design which means portal will drive the navigation structure and content

and as always, business wants to have more and more control on the site instead of IT to avoid raising change requests, waiting for release cycles so I tend to push for CMS centric design some time.

To achieve CMS centric design, Fatwire WCM has to expose content to delivery platform and to expose the content, Fatwire WCM provides web services like

• Asset.wsdl
• AssetSet.wsdl
• Miscellaneous.wsdl
• SitePlan.wsdl

Each web services exposes set of functions which can retreive the content from Fatwire WCM and display on delivery platform.

Although we can retreive content but I would like to make you aware that the complete integration framework can be fairly complex where you need to agree all the interface specs between CMS and the portal so that portal can understand the content and consume it. This can be a daunting task and over all delivery time can be couple of months itself depending upon your experience level itself.

A portal centric design using Fatwire can have very easy implementation but it has serious impact on the CMS usability and you may end up delivering a system which is managed by your support teams instead of  business users.

CMS and portal integrations are critical aspect of your web site delivery and while defining the integration framework, you should seriously consider about the operational use of the content management system. You may get a working system as part of your delivery but you will realize the actual solution when it is operational!

Interwoven TeamSite migration

I just completed a very interesting project where we upgraded legacy TeamSite 5.5 to latest TeamSite version 6.7.2 and another instance of Interwoven TeamSite 6.5 to TeamSite 6.7.2. This project was just not only upgrade but it was migration to new data centre as well which adds complexity to it and while moving to new data center, we need to bring all the best practices to ensure Interwoven platform is supported and mantained correctly in future.

In this blog, I have defined the high level steps for Interwoven TeamSite upgrade.

Further TeamSite upgrade has two parts

• Code uplift
• Content uplift

Lets talk about content uplift process itself. This is the scenario where you are moving your TeamSite instance from one machine to another machine

• Copy the content stores from production CMS 5.5 to target interwoven TeamSite 6.7.2 environment.
• The content store size can be quite large, so plan for couple of hours downtime on production machine to copy the content from existing TeamSite 5.5 to latest TeamSite 6.7.2.
• To copy the content, you can do it various ways like

1. Tar the content store and copy tar file
2. Use disc copy from one machine to another machine but this is generally quite difficult to copy the disc across data centers
3. If you are existing machine is correctly integrated with back up solutions then you can use netApp facility to clone the file system. This can be really handy and it can be done in the matter of minutes!!

• Extract content to the target backing store like /iw-store/archive. This step can take couple of hours and further it depends upon the size of content store, network speed, I/O speed.

Pre-requisites for Content Extraction

• Avoid extraction of content store on the same file system mount where your TAR file is located because it can cause high number of R/W operations on the disk and it can slow down the process.
• Before kick off content extraction, always ensure  that you have enough amount of disc space to extract the content
• Ensure you have enough number of indoes available for archive store and production store mount points. This can be extremely difficult to recover if your content extraction copy, extraction process breaks in between.
• Ensure, all the back ups etc are cleaned up and turned off before you kick off content extraction. You are going to extract large amount of content and your content snapshots can take up your complete space itself.
• Kick off content extraction and it will take couple of hours to complete
• On completion of content extraction, create new content EDITIONS to ensure the latest content in STAGING area of each branch is part of your EDITIONS as well. You need to perform this because IWMIGRATE only migrate EDITIONS and it does not migrate STAGING area and you will loose content history from STAGING
• Before we kick off iwmigrate, we need to run user migration on archive store and production store. There are set of steps we need to perform this and couple of Do’s and Dont’s which will be part of my next blog for Interwoven user migration.
• Please ensure it 100% that user permissions are correct on archive store and further, there are no existing tokens on your target production store.
• Follow the same set of checklist for production store as well like disk space, inodes, backups, snapshot clean up before you kick off iwmigrate

/iw-home/bin/iwmigrate -m /iwmnt/default -o /iw-store/<store name> -b /default/main -a 200000 -g

Cache size is fairly important and it can break your content migration if it is not set correctly.

Here we are migrating the content from default backing store to btcom backing store where -a option means cache size -a <cache_size > Number of objects kept in the cache

You can always redirect the log of iwmigrate to a log file for monitoring and further please ensure to run iwmigrate  in background so that it does not break because of connection timeout.

DB/FileSystem based content repository

This is a very interesting architecture question..While building a content management system this is the most important decision to determine about the content repository.

There are lots of pros and cons on this…

DB Based Content repository:

Key advantage for DB based content repository is

Dependency management: If content set is mapped inside the database then any change in one content item, will manage other content items quite effectively. This is one of the key pain point, I see with the file system based content management systems. Any organization would like to have content integrity on its website and to ensure that dependency management of the content is absolutely important.

For eg if we are updating a news article, then news item will be updated on your home page, news home page and actual article page itself..

If we need to perform this in FS based content repository and site is static then it is bit hard game to manage.

But still file system based content repositories has lots of advantages

1) Content versioning: You can manage content versions very easily like any other svn system..You have lot better auditing in place.

2) Point in time snapshots: You can manage point in time snapshots very easily. Using IWOV, you can take content editions and you can roll back to older edition to any point of time. You can keep site history 3,6,9,12…anything very easily. This is a great feature from content audit stand point

3) Release Management: You can manage multiple releases at the same time in very effective way using file based content repository. For example if you have a large website and you have multiple teams working at the same time on different releases. As part of release cycle, if you need to add some content to your production system then you can add delta content on development systems and you can move the content as delta content to your production system..Content merge across various application releases is fairly challenging for DB based systems.

4) Hardwired DB tables: Database tables are very hardwired and any change to those tables is not straight forward once the system is set up. Further if your system architecture is completely DB dependent then if later on you need to alter your content structures then it fairly complex operation in Vignette. So your content type definitions are one done are not very open for modifications

5) High DB Connections: To get simple information, you need to connect to the database and so many DB calls are always cost you in various ways. For example in Vignette, complete content is stored in database,

To fetch the content they have a huge SDK but so many DB calls were hitting performance massively and because of this they have released new API set which is getting the values from DPM cache.  This leads to DPM cache settings and again there are good number of performance glitches and now next solution is HPD…(High performance Delivery) I hope, I am clear where I am heading here!

Further if multiple people need to work on different areas of content and preview there own web sites then it is fairly easy using FS based CMS systems like IWOV/Alfresco where people have there own workareas or sandboxes but this is level of granularity is not easy to achieve in Vignette

So there are lots of areas where we can see challenges on this and will be great to know what do other developers think about it…

Alfresco Content deployment capabilities

Okay I have written about IWOV, Vignette and let me put more thoughts on Alfresco now

I am quite facinated with Alfresco, but at the same time I would like to say, still it has to go long way to server large organizations!

One of the key challenge we identified recently with Alfresco about its content deployment capabilities

As per my analysis, content deployment architecture is still in its very early stages and it needs to mature a lot for sure. Currently with Alfresco we can not do deployment to the database, if you need to write anything to the database then it can be written using custom java classes but it leads to the issue of transactional content deployment..basically if I want to deploy all the static files and need to publish all the articles to the portal side database as part of the same transaction then it is not possible. Your DB records has to go first and then you will invoke the file system deployment.

Further if I need to run the file system based deployment as an external service then it is not possible

Alfresco porvides transactional capability if I need to deploy static content to three servers but if we need to deploy mix and match of the static content then it is not possible..

Further, as part of the content deployment, if I want to index the content or clear the cache on the portal then there is no way to bind both the things together.

Content deployment service from Alfresco needs lots of further extensions…

Issue with VCM Versioning capabilities

I had a very interesting week…I was working on Vignette implementation from last couple of months and we are using VCM 7.5, VAP 7.4, VBIS for content migration, FURL etc..

Recently my client asked me about audit capabilities using VCM and I started exploring more on this area, I was amazed to find some facts..I was expecting Vignette to have very strong content audinting capabilities but to my surprise Vignette struggles with it ..

VCM just provides very rudimentry versioning capability and even to take automated versions, you need to write custom triggers. Truly I never expected from enterprise content management system to have such a basic scale of versioning capabilities.

Further you can not take point in time snapshots using VCM…which means if for any reasons, a site needs to be rolled back three months back, then you just can not do it. Only way to rollback is to rollback the database and you will loose all the information for the three months. This was surprising for me and I had long discussion on this on Vignette developer forum and Vignette Sr product manager Bertrand de Coatpont provided his views on this.

Bert explained this and reason for it was, VCM has its content repository in the database and you can not have check in check out, versioning capabilities if content repository is as file system..something similar to Seibel, SAP etc..You can read the complete discussion thread using the below link

http://success.vignette.com/gm/message-1.24.40524

VPS has developed an extension for it which provided the capability to know the content item state before or after modifying the content item but it needs to be integrated with product in the upcoming releases..Vignette has confirmed that this is part of their laundry list at the moment.

Now this particular point opens a very interesting architectural discussion which is while building the core foundation of CMS product then, file system is the right place to store the content or database..

I will write about this in my next post..

Issues with IWOV CMS

In my last post, I described quite a lot of features for IWOV TeamSite and they are truly marvellous. But as we take it forward and enterprise needs get complex then we go for customizing IWOV a lot. This is good that IWOV provides us the ability to customize the tool in a very nice, clean and supported way but at the same time it puts pressure on dollers!

One of the key issues with IWOV teamsite is to manage the navigation system of the website. If I need to move my content in the website from one BU to another BU or archive the content then IWOV TS is incapable of keeping track of links and fixing them automatically unfortunately. There are only few ways to manage it

1) Restrict the user to move the content which is definitely not a very nice feature to have!
You can manage this to some extent by defining different roles in TS but still we are restricting the problem to happen but we are not fixing the problem from root.

2) Heavy customizations where you manage the relationships using extended attributes or any other custom code to manage and track the relations. This can be a really complex implementation if we start going in this path because system needs to track all the user operations for cut, copy, move, delete and further this can happen on branch level, directory level, file level, multiple hierarchies of the directories or multiple files etc. So it is definitely a daunting exercise to customize and can be a very expensive solution to manage the content.

Teamsite’s incapacity to manage the links is one of the biggest pain point in its implementations and the reasons for this IWOV does the content management using file system rather than database and its FS based content stores are still not intelligent enough to do such features.

Vignette is definitely a better choice in terms of navigation management where if you change the content strcuture, it can manage content relationships very nicely because it is managing the information in the database.

Further there are lots of feature I would like to see coming OOTB from teamsite so that development efforts can be reduced a lot.

Web 2.0 Support: OOTB feartures with teamsite to support web 2.0

Content tracking support: OOTB features to support the content tracking on the web

SSO : TS supports integration with siteminder but still it has no of bugs which IWOV should fix in the next release

Connectors to Migrate/transform the content: IWOV needs to come up with a framework to support the content migrations and content transformations. There is a very powerful tool available in Vignette called VBIS where you can draw the content migration process as flow diagrams where similar content migration using TS is an overly complex process which requires lots of efforts to get it right

Content Archiving: Simple content archival process to be managed by the tool itself which should move the content into correct areas inside the system and on the web site as well

OOTB support for friendly urls: TS should OOTB components to support friendly urls rather than custom code on each implementations…

Ability to add multiple cms nodes: Currently TS does not have OOTB failover process which is a key feature they should enable going forward

Easy ways to define help in flash mode: Currently it requires to build extra flash modules to provide training to content authors but there can be easy ways these videos can be built and shared with content authors

There can be lots of issues like this and lots of areas of improvement in IWOV TS but still I am in love with this tool and do like it a lot for people to use it!

In my next post, i will start detailing out my experience with Vignette content suite as well..so stay tuned on this channel

Home

My name is Amar and I am working as CMS Lead Architect with Virtusa UK currently. I am working with content management technologies from past 6 years.

I started my journey with content management systems with Ericsson in Sweden where we migrated TeamSite 5.5.2 to TeamSite 6.1.

Huge interest with content management systems and thought couple of days back to start pouring my thoughts here as well…