But what should a marketer's technology toolkit contain?  If you were only to follow what WCM/WXM vendors promote, you're only seeing a small part of the picture.

In fact, Digital Marketing can mean many things depending on the context.  If you are a marketer, you might want to:

• Create and update your web sites
• Personalize and optimize your interactions with users
• Build landing pages
• Acquire, profile, prioritize, nurture, and manage leads
• Create, manage, and measure the effectiveness of email and other digital campaigns
• Monitor and gather intelligence about your brands
• Engage with people via social media
• Mobile-enable all this interaction
• And so on...

Consequently, you can find many types of tools that claim to provide “Digital Marketing.” If you map these capabilities to tools, you will need one or more of the following and probably some others too:

• Content and Experience Management tools for Web Content Management, Digital Asset Management, Site Management, and Personalization
• Lead Management tools
• Campaign Management tools for creating and managing campaigns using email, social media, web, and mobile
• Social Media Monitoring and Intelligence tools
• Landing Page Management tools
• Combinations of many of the above in self-styled "suites"
• And so on...

As you can imagine, there's a panoply of tools out there. In our forthcoming advisories and research, we will try to de-mystify the highly crowded and fragmented digital marketing marketplace.

As with our other reports, we will also provide a methodology for mapping business needs to technology alternatives, as well as a roadmap for evaluating digital marketing vendors.

• Multi-database support
• Upgraded search functionality with support for auto-completion and stemming
• Update notification and single click updates for Joomla! as well as any extensions

These features represent another step in Joomla's long, incomplete journey to try to become more amenable to enterprises. But before you get all excited and start thinking of using Joomla! for, say, your enterprise intranet, keep these points in mind:

1. While Joomla! announced added support for databases other than MySQL, in reality, it only adds support for Microsoft SQL Server. In fact, Microsoft's influence is quite visible (and is probably good for the project), and the new version also supports Microsoft Windows Azure. Support for others databases (Oracle, et.al.) remains in the works. As with all issues related to Joomla!, how soon extension developers update their code to take advantage of new platform capabilities will actually dictate how much you can adopt those capabilities. Many extension developers will update their code but many will not, so you will need to make sure the extension you want to use supports the database you want to use.
    
2. As for the search engine, it's really a core extension. So all you need to do is activate this (it's disabled by default). However, you will again need to make sure extensions are updated to take advantage of new search functionalities. Even if they are, there will be some issues in terms of managing the current search module's existing index alongside the new index.
    
3. And finally, for single click notifications to work, you will again need to ensure the extensions are updated to incorporate that.

So, overall, the new features are indeed useful, especially in an enterprise context. But a lot depends on extensions you plan to use and so make sure you plan well in advance. Consult the Web CMS Report for more details on potential gotchas here.

Finally, if you are upgrading your existing Joomla! installation or plan to deploy it for a new initiative, this would be the time to push extension developers to update their code.

Social Media Monitoring and Intelligence is an important tool in a digital marketer's arsenal. Of course, digital marketers also require tools for Lead Management, Campaigns (using email, social media, and mobiles), Landing Page Management, and so forth. We club all such capabilities under the umbrella of "Digital Marketing."

If you are a web or a digital marketer, you can source these capabilities in many ways. For example:

• You can consider a standalone Lead Management or Social Media Monitoring tool. There are a huge number of such tools - mostly SaaS based - in the market and this marketplace is seeing a rapid evolution
• Your existing Collaboration, Portal or Web Content Management product provides these. Jive is an example of this (we review Jive in our Enterprise Collaboration and Social Software Report)
• You already use a CRM platform that also provides some such capabilities. Salesforce.com, for example, has started offering Social Media Monitoring capabilities via its acquisition of Radian6

There are many other ways too and whether you  use an existing platform or a standalone tool depends on many factors. This is an emerging marketplace and there are not too many best practices out there. We will provide detailed guidance in a subsequent advisory for subscribers but in the mean time, remember to evaluate such tools with the same rigor as you would any other enterprise tool selection.  Most of these sevices promise quick setup and time-to-market, but you should still take the time to follow vendor selection best practices.

We will provide more detailed guidance about these in a future advisory paper, but in the meantime, here are the key points to consider:

1. Which Devices to target: This obviously depends on your target audience and what constitutes a mobile device for you. While simple cell phones, PDAs, smartphones, and tablets are quite obvious, what may be less obvious are devices such as gaming consoles or even the good old television that can act as delivery channels in some contexts. In my previous organization, I worked on developing a strategy for a hospital that wanted to be able to stream patient data on a linux-based handheld device carried by docs. Even without going that deep into what constitutes a mobile device, at the very minimum, you will need to decide what kinds of phones and tablets you want to target. This includes both the form factor (or the size) and operating systems (iOS, Android, et.al.). We've discussed this issue in these blogs before:
   • Thinking Holistically Beyond the Smart Phone
   • Android Tablet or iPad
2. Mobile Apps, Web Apps, or Hybrids: There are many ways to develop applications and sites for mobile devices. So you'll need to decide whether you'll stick to browser-based web apps, create downloadable applications, or use both for different use cases. We provide some guidance on which option is suitable for specific use cases in our advisory paper Mobile-Enabling Enterprise Applications: Browser or Downloadable Apps? as well as number of blog posts like:
   • Different Ways for Building Mobile Apps
   • Mobile Apps are Dead. Long Live the Mobile Web
   • Mobile brings site-building tools back from the dead
   • Mobile - the Next Web CMS Frontier
   • DAM and mobile: should you go with a dedicated mobile app?
3. Existing tools or new ones: You probably already have numerous enterprise applications that  provide some sort of capabilities for building mobile applications or web sites. For example, many Document Management vendors provide device specific applications to access a subset of functionality provided by their tools. Similarly, for a mobile website, you could possibly use your existing Web Content Management (WCM) tool or a Portal tool. Alternatively, depending on your scenario, you could invest in a sophisticated mobile middleware framework:
   • Advisory: Adapting Your Content Management Platform for Mobile Delivery
   • Blog: An iPad for DM and RM?
   • Blog: FileNet P8 on your iPhone
4. Managing content for mobile site and related architectural Issues: Publishing a mobile site will raise additional issues related to content duplication, publishing, workflows, and presentation. So you will need to have a handle on technical issues such as:
   • Do you employ a separate repository for mobile content (and this duplicate content) or do you use a common content repository?
   • How do you publish content from your regular web production environment to mobile environment?
   • Do you repurpose or recreate content?
   • How do features such as in-context editing and rich text editors work for mobile websites?
5. What happens to existing websites and content:  You obviously would not want to throw away your existing site, especially if it was not developed a long ago. So it'll be important to understand how you'd reuse existing content or mobilize an existing website. There are many approaches and tools to do that but if you've followed some basic principals of content management -- such as separating your content from its presentation -- you should experience fewer problems here.

There are many more considerations -- such as information architecture and user experience in a mobile context, content migration, alternative development approaches, and so forth. Yet, addressing the key starter issues above will give you a good launch point in your mobile roadmap.

What has been your experience and what are the key issues you've faced? Please feel free to comment below, email or tweet me.

DOM and associated technologies -- such as Automatic Document Assembly, Document Automation, Document Composition, and others that we clubbed in our evaluations under Dynamic Publishing -- play very closely with ECM tools. The documents that are part of these sub-systems (such as Insurance Policies, Telephone bills, Quotes or Customer Correspondence) are or should be a part of broader business process. So you need to be able to apply library services to them (check-in/out, versions), take them through a workflow, declare them as a record, or archive them for long term.

In spite of seemingly close interdependencies between DOM and ECM, not too many Document Management or ECM vendors have really done a good job of offering a seamless solution for both. Some that do offer some capabilities are IBM, Microsoft, EMC (via its acquisition of Document Sciences' xPressions), Oracle (via its numerous acquisitions like Skywire and Docucorp), HP (it acquired Exstream), Pitney Bowes, and possibly a few others.

Adobe also has LiveCycle, although it is likely that it will be reducing its focus on LiveCycle in lieu of sexier Digital Marketing and Media sectors (more about Adobe's recent announcements in a separate post). In most of these cases, ECM vendors have acquired an external tool to offer these capabilities and as a result, there has not been a really close integration between their ECM repository and DOM tool.

We don't know yet if Perceptive does a better job but we'll keep watching. Mean while, if you are evaluating DOM-type tools, remember this advice from our advisory titled "Dynamic Publishing Systems -- A Technical Overview,"

Dynamic Publishing should not be considered as a standalone system. Content and documents that are within the scope of Dynamic Publishing are often subject to the same stages and processes as any other content, such as publishing workflows, version management, archiving and so forth. Hence, you should consider Dynamic Publishing as part of a broader content management initiative. It is very important that the DPS you select has basic ECM capabilities (repository services), or provides connectors to integrate with external ECM, search, and portal tools.

 We'll keep watching...

Now that is obviously not a very scalable model especially if you have to support end users with different types of mobile phones and tablets. Many organizations are increasingly encouraging employees to "Bring Your Own Device (BYOD)" and so supporting all different types of devices that employees could potentially bring may not be trivial.

However, this argument is starting to get diluted, as emerging approaches can get the best of both worlds, albeit with tradeoffs. So while building a native app using proprietary APIs and platform specific languages (such as Objective C for iOS) is what many people think of for building apps, you can also build cross-platform apps using more standards-based technologies like HTML5 and Javascript. 

As an example, the open source framework PhoneGap (now acquired by Adobe and proposed to be part of Apache Software Foundation) allows you to create HTML5-based applications that can run on many mobile platforms.  The difference between these HTML5-based cross-platform apps and regular web-apps is obviously that these can access native device functionality (like the camera) by using a "wrapper" that PhoneGap provides. There are other approaches as well, such as those that allow you to code your app once but then compile it for each of the specific platforms you want to support.

So if you do decide to offer downloadable apps to your employees or customers -- ideally in addition to a regular web app and not at the expense of it -- remember that building an app does not necessarily mean you will have to employ proprietary or platform-specific technologies. There are many ways to build apps and you should evaluate each of these approaches with respect to different factors such as functionality, cost, time to market, user experience, and performance.

This is a longstanding debate and proponents of both approaches will point to numerous benefits.

By using mobile web, you get the benefits of a standard based approach using which you can target a broader population of mobile devices. Downloadable apps --  they include device specific native applications as well as those based on so called RIA (Rich Internet Application) technologies like Flash - promise a richer user experience optimized to specific devices. 

As with any technology, there's no single answer for all scenarios. As with desktop environments, I believe multiple approaches will co-exist on mobile devices as well.  The question is how to discern when to go browser versus app.

In our recently released advisory briefing, Mobile-Enabling Enterprise Applications: Browser or Downloadable Apps?, we explore this very topic and provide some guidance on when to use which approach. The table of contents for the advisory is as follows:

• Key Takeaways
• Introduction
• The Case for Web Apps
• HTML5 Brings New Mobile Browser Capabilities
• The Case for Downloadable Apps
• Conclusion

The advisory briefing is available to all of our research stream subscribers.

Fortunately, portal platforms offer multiple approaches to addressing this challenge. The trick is to decide which approach makes best sense for your scenarios. These approaches differ from each other in terms of cost, ease and speed of implementation as well as in terms of the range of scenarios they can address.

In our recently released advisory, Eight Ways to Integrate Content into Your Portal, we examine different ways - ranging from completely decoupled ways to very tightly coupled ways of doing just this. The table of contents is as follows:

• Key Takeaways
• Introduction
• Eight Integration Approaches
• Displaying Integrated Content
• Conclusion: Which is the Right Option?
• Additional Notes

The advisory briefing is available to our Web CMS and Portals & Content Integration research stream subscribers.

We have made many updates to the existing vendor reviews. Most enterprise portal vendors have released minor or major updates to their tools and so we have refreshed our evaluations to reflect those changes.

Besides individual vendor evaluations, the other key updates are:

1. We've modified the structure of the reviews, to bring them in line with our other research streams as well as for better readability
2. We've added new evaluation scenarios for the content integration products that we cover
3. We've archived a few vendors that are moving out of this space, but if you are keen on them, you can still access existing reviews from the archives

Perhaps most importantly, we have also started tracking very closely how each portal platform supports mobile access and delivery. Frankly, barring a few vendors, most are not really providing anything more than a very basic support for mobile devices. That's a bit of a disappointment, as we'd have expected portal vendors to do much more.  Mobile is a big area of focus for us now, and we'll be writing much more about it in all our reports as well as elsewhere. 

• A vendor we cover in our Portals and Content Integration report for its mashup capabilities has started calling itself a provider of "Real Time Intelligence"
• In their briefings to us, many search engine vendors use terms such as Business Intelligence and eDiscovery to describe their offerings
• Similarly, many Web CMS products have been adopting monikers such as Web Experience Management or even Customer Experience Management

Doubtless all these vendors employ well-staffed marketing departments who spend a lot of time working up this sort of nomenclature.

However, there are some common underlying pressures and trends at work here. In many cases, vendors simply follow what's currently hot or in vogue, often after intense PowerPoint exchanges with industry analyst firms. In other cases, vendors attempt to target a different audience and hence try to switch from a more "techie" sounding name to a more "business" sounding name.  In still other cases, a handful of products in a category  become so dominant that other vendors need a different label just to register their presence.

Personally though, I believe when a label becomes so abstract, it becomes difficult to know what the tool actually does. It also becomes impossible to know what other products to compare it with (which is of course what every vendor wants: "we're unique!").

This is why we always recommend that you don't forget the basic reasons for buying a product when conducting an evaluation. You are probably looking to accomplish some specific goals -- say, improve your publishing, editorial efficiency, or site presentation and interactivity -- and rarely pursue something as vague as "Experience Management." Even if you want better Experience Management, make sure you break it down to more tangible functionality, such as Site Testing, Analytics, Personalization, Promotional Campaigns, Social Media Integration, and so on. Our reports can of course help because we spend a lot of time doing just this to get you the Real Story. 

All the acquired vendors have reasonably long standing Web Content Management Products, among others. But because you never know how an acquisition turns out (case in point OpenText's RedDot acquisition), many prospective customers become hesitant to include those products on their shortlists. They raise concerns about products' future road map, support quality, pricing, and many other issues.

To be fair, all these products are certainly not going to die anytime soon. However, many of these fears are indeed genuine, and you should carry out additional due diligence when considering these products. It takes some time before clarity emerges.

In any case, there is no dearth of products in the Web Content Management marketplace. We cover more than 40 such vendors in our Web Content Management Report.

We also provide specific advise for these acquisitions, supplemented with additional guidance via phone or web meeting for our subscribers. In particular, please check:

• HP plus Autonomy equals Buyers Beware
• Customer perspective on Oracle acquiring FatWire
• A First look at Adobe Digital Enterprise Platform (Subscribers only)
• Adobe To Acquire Day - First Take-ECM Perspective

We'll have some additional comments about the Autonomy acquisition shortly...

In this video, I answer many frequently asked questions about the Portals marketplace. These questions address various aspects such as mashup tools' perceived user friendliness, trends in the Portals and Content Integration Marketplace, and finally whether the Portal technology is still relevant.

For the real story on vendors in this space, check out our Portals and Content Integration Report. Meanwhile, if you're a subscriber, you can  access this advisory paper that explores different alternatives for creating "Portal like" applications.

So if you are a web publisher and want to use your Web CMS for publishing to social channels, what should you do?

Many site owners will want to press their CMS vendor or open source community to build specific integration paths to enable publishing out to these social networks. Most tools that we evaluate have at least begun to answer this call.  But that's not really a scalable model in my opinion. What happens when another social network becomes hot, and you need to publish to that too? What happens -- as is often the case -- when a network changes its APIs?

Instead, you should take a step back and take a more long term approach. Out of the box integration with individual networks is fine, but insist on an integration framework that allows you to add additional social networks or channels in future. The framework should allow you to add a new external destination but also provide core plumbing services such as security, logging, exception handling and reporting in a consistent way across all social (or other) channels -- rather than one at a time.

Also remember some basics of multi-channel publishing.

Many Web CMS products provide in-context (and inline) editing capabilities that enable you to write new content within the visual context of your website. However, if you are pushing selected content to Facebook and Google+, you have multiple contexts and experiences, so you will want to think in a more agnostic way. Therefore, whenever you ask vendors to demo their slick inline editing interfaces, make sure to spend enough time evaluating the usability of their traditional, form-based interfaces.  In a multi-channel world, you'll be using them more often.

You should also evaluate how the tools segregate presentation from raw content. This becomes important especially if you use rich text editors and allow your content contributors to apply styles on content. This will become problematic when published to multiple social networks. So ensure that there is a clear separation between presentation as well as content.

Your content contributors should understand that if what they write travels to multiple other channels, they really have to be more disciplined about using styles, rich text editors, and inline editing interfaces. (BTW, I could say "mobile" instead of "social" and end up with the same advice.)

Finally, remember that with growing number of external destinations where you can publish content, more than tech integrations, you need to have a true interaction strategy in place. Don't auto-publish blindly; as my colleague Tony says, "Because you can, doesn't mean you should."

EntropySoft, a content integration and migration vendor, has released a new connector for Twitter. EntropySoft already has a set of connectors that get OEM'ed into various packaged content and document management systems, many of which we cover in our evaluation reports.

This new connector enables enterprises to access content (tweets and other information) stored in Twitter. EntropySoft says the primary objective here is to archive those tweets in a corporate archiving system. Once the Twitter content is in one of your own repositories, you can do pretty much anything that the target system allows you to do -- such as declaring tweets as records and applying retention policies on them.

Many organizations have been experimenting with various alternatives for managing their employees' tweets. Some enterprises, for example, employ their Web Content Management system or a Portal-type application as a tweeting interface, so that they can subsequently manage those tweets as content in their larger application. By using a connector-based approach, in contrast, employees can tweet using any of their favorite tools but those tweets can still be brought back into an internal system for subsequent management.

There are some challenges that you'd need to address with the latter model, though. Besides the practicality of considering tweets and more generally social content as records, there are also issues of ownership and legality related to extraction of tweets from Twitter and archiving these in your own systems.

In any case, the ability to access social content via such tools has many uses. Many of the products we cover in our various reports -- such as Document Management and ECM tools like Alfresco and EMC Documentum as well as search engines like Endeca and Exalead -- turn to with EntropySoft to supply connectors within their products. We don't know yet if they plan to use this new Twitter connector too but if and when they start using it, it could become marginally easier to search, index, and archive social content from within your existing systems.

Single-source and multi-channel publishing are often two important requirements of a content management system. While these are rather common features now when publishing to more than one web-based destinations (such as an Intranet and a public-facing web site), it has never been easy to publish to print and web using the same source.

There are many reasons for this. For example (thanks to @pranshuj for sharing these): proper typesetting - hyphenation and justification, text wrapping, and font control (e.g.. Kerning) work differently in print than they do on the web. The way graphics are handled by browsers and more broadly the way editing, sub-editing, page composition works is also different for print and web. Finally, the tools of the trade and the process of handling advertisements for web and print is quite different.

Because of these reasons, the two systems have usually been different and often result in a lot of duplication in content storage, workflows and other aspects. Many content management systems have tried to address this but have only been at best partially successful.

Sitecore, with its acquisition of Pectora seeks to address this old but very important gap. With more and more people now consuming even the print content on their digital devices (such as iPads), addressing this gap will provide a good differentiation for Sitecore.

However, remember the two worlds are still very different sometimes in terms of processes, tools and stakeholders. So while the new tool will provide an integrated setup with "connectors" (which can have varying levels of effectiveness), it remains to be seen how successfully this gap is bridged and if other WCM players follow suit.

Digital Forms, also known as smart forms or eForms, are improving and becoming more useful, especially compared to paper-based forms.  Once you collect information or content via these eForms, you can apply business rules to the content, take it through a workflow or archive it.  As a result, it is important to consider eForms-based content acquisition as a component of overall content life cycle.

In our recently released advisory, Best Practices for eForms, we explore different aspects of eForms and provide practical advice for organizations that are considering a transition away from traditional forms.

Key sections of the advisory paper are:

• Comparative Benefits of eForms
• When to Use eForms
• Standards
• Some Best Practices for eForm Deployments
• Dealing with Signatures
• eForm Software

The advisory paper is available to our Document and Records Management research subscribers. 

1. Standardize and Simplify: We wanted to make it easier for you to compare product weaknesses and strengths at a glance. So, as we have done with our other reports, we switched to "harvey balls". Harvey ball-based charts have many advantages as compared to those based on traditional check marks, something we've explained in this post.
2. Update technology guide and evaluation criteria: We have updated the technology guide sections of the research, which describe the search technology landscape as well as the evaluation criteria. The criteria have been updated based on trends in the search marketplace as well as based on our customer enquiries.
3. Vendor updates: In this version, there's an updated review of Vivisimo's Velocity. In the coming weeks, more vendor and tool evaluations will be updated.

If you are a subscriber, you can download your copy of the updated report. You can also download a complimentary sample of the search and other reports. 

First a little background. FatWire offers tools for managing different aspects of website production and engagement. These include its flagship "Content Server" for Web Content Management and few others, such as Community and Gadget Servers and a Mobility Server. Content Server itself has seen multiple owners in the past -- changing hands from Future Tense to Open Market to divine and then finally to FatWire. In fact you can still see mention of FutureTense in Content Server's XML code.

So what does this acquisition mean for you the customer? Here are my quick thoughts in no particular order.

1. This hopefully brings an end to ownership changes and could mean more institutional stability for an otherwise well-regarded tool. In spite of having been acquired so many times, FatWire has always been rumored to be in the market to find a new owner. More recently, it flirted with EMC but finally found a suitor in Oracle. Oracle will likely invest more in R&D, to make improvements as well as target wider markets. Oracle will hopefully invest in improving performance, extensibility, and adherence to industry standards.
2. Oracle is a tough contract negotiator, and incumbent FatWire customers may be in for a big jolt here, if you are already an Oracle shop, however, you may be able to locate a good deal
3. Oracle already had Web Content Management capabilities as part of its own ECM suite (something it acquired from Stellent). However, like EMC, they focused more on Document and Records Management services, and proved unable to innovate at a pace expected of a WCM tool. This probably bodes poorly for those customers of the former Stellent platform who are focused on WCM (expect Oracle to try to convert you to FatWire).
4. Going by past experience, Oracle will likely try to embed some of its own components into the Content Server platform, at first as an option, but then later as a requirement.  The might include database, application server, and search engine, as well as possibly WebCenter Portal.  Oraclization will prove a boon to some of you, but a bane to others; keep your eyes open
5. Oracle also acquired ATG in late 2010. I think FatWire and ATG provide for some very interesting possibilities - if integrated well (note the emphasis). Sure, there are overlaps, but the two products have distinct strengths. While FatWire's strength is obviously managing web content, ATG's strengths reside in more delivery-tier oriented aspects such as catalog management and e-commerce. This is slightly different from the case of some other Oracle acquisitions, such PeopleSoft and JD Edwards which possibly had considerably more overlaps. Having said that, integration between two products is always a tough task, and real integration will take time
6. The EMC relationship is now cloudy going forward. FatWire did invest considerable resources in their Documentum integration story and we don't know how long will they keep investing in that under Oracle. FatWire's site still has this page about their relationship with EMC but I'd be surprised if this page remains up for a long time. If you get a 404 error when you click on that link, you'd know the partnership is over.

We'll be watching and analyzing. Our research customers will receive a detailed advisory about this soon.

Let's look at what's driving this. The last decade has seen continuous improvements to search technology. At least in theory, today's search engines can crawl more complex repositories, can handle many more documents, and run faster and more efficiently. All you need -- the story goes -- is the ability to convert search results to an RSS feed, build some kind of a simple widget-based environment that displays those feeds, and you are up and running with a functional portal application.

But don't stop there.  The same logic can also get extended to other web technologies. Search engines can act as replacement to traditional integration mechanisms since they can crawl multiple repositories. They can also handle more sophisticated applications such as e-discovery.  So, why invest in portal or portal-like technologies at all?

My advice: don't buy into this hype.

Before you decide to build a web or portal application that's driven by your search engine's index, first consider if that's the best approach to get at all types of information you want to display. You'll quickly find some inherent limitations.

For example, most search engines make certain assumptions and approximations in the way versions, security, and duplicates get handled. The security profile on the document might have changed after your search engine indexed it. Sure, you can take advantage of your search engine's "late-binding" security capabilities, but that only adds more overhead to processing time.

Moreover, in those cases where your application knows exactly what to get from the repository, using search indexes and queries adds even more overhead. "Showing 1 of 1" is hardly the best way to display the local temperature inside a weather gadget.

The point then is that a search-based query is not the most optimum way to access your back-end data for the typical diversity of enterprise portal scenarios. Before making a major platform decision, be sure to consider alternatives that could prove faster more accurate.

A content management implementation is also a software project and you would require some way of estimating your effort (and hence costs). However, in our experience, established methods such as COCOMO and Function Point Analysis generally don't fare well  for packaged software implementation efforts in general -- content management projects in particular.

In our recently released advisory, Alternative Estimation Methods for CMS Projects, we examine the shortcomings of traditional approaches, and explore what would work for a CMS project.

Here's the table of contents for the advisory paper:

1. Key Takeaways
2. Introduction
3. Package Integration Is Still a Software Project
4. Estimating Content Management Projects
5. Key Advice
6. Conclusion

The advisory paper is available to our Web CMS, DAM, and Document Management research subscribers. 

Most of the time, how your content management system persists content does not impact end users. However, it can have a great impact on IT and admin folks. It also impacts your architecture as well as overall costs. Hence we recommend that when you are evaluating your content management needs, you should also explore how the tool persists content for its ongoing day-to-day usage.

In our recent advisory, Key Considerations for Choosing the Right Storage Alternative, we look at different considerations that are relevant when deciding if you should select a content management system that uses a database or a one that uses a file system.

Here's the table of contents for the advisory paper:

• Key Takeaways
• Introduction
• Management versus Archival Services
• Some Vendor Examples
• Key Factors to Determine the Right Persistence Alternative
• Conclusion

The advisory paper is available to our DAM, Web CMS, and ECM research subscribers.

While all these Portal-like scenarios have common aspects, they are also vastly different from each other. Consequently, there are multiple ways, ranging from out-of-the-box tools (many of which we cover in our Portals  as well as Web CMS Reports), to custom solutions to build such applications.

In our recently released advisory briefing, Alternatives for Building Portal-Like Applications, we explore different ways of building Portal-like applications and offer advice on which approach to choose for your specific requirements.

Here's the table of contents for the advisory paper:

• Key Takeaways
• Introduction
• What does a Portal do?
• Alternatives for Building Your Portal-Like Application
• Conclusion

The advisory paper is available to our Portals, Web CMS, and ECM research subscribers.

I personally don't like generic terms to be product names -- "we licensed Web Experience Management" doesn't sound meaningful to me -- but that's a topic for another post.

Re-branding product names or dropping the original vendor's name is nothing new. OpenText has done it numerous times before. Anyone remembers Gauss, Hummingbird and all the others that led to these numerous name changes?

And they are not the only ones. A few days ago, IBM also renamed their WCM offering. They dropped "Lotus" from the WCM product name. So the WCM product is now called IBM Web Content Manager. I'll speculate they might do away with some of the other brands such as WebSphere and Tivoli too in near future.

Many times, a re-branding signifies that an acquired technology has been well integrated with the parent - both in terms of organizational integration and product integration at a technical level. Sometimes, it's also accompanied by additional enhancements or a change in product's focus. But a lot of other times, its more of a marketing gimmick -- a mirage -- to give an impression that the product (or the vendor) has been integrated well with rest of the offerings. At times, it's also about riding a new wave of hype.

Both these vendors are finally getting rid of original product names that came from the vendors they acquired. Having those in the product name has its advantages. For companies like IBM and OpenText that have acquired numerous companies, having the name of original vendor helps you navigate through the complex organizational structure and makes it easy to understand some of the legacy intangibles that explain a product's strengths and weaknesses. While that legacy is helpful for customers, for the vendor it brings major disadvantages, and they hope a new name shows the product is now "part of the family."

For you the customer evaluating products, make sure to suss out a product's history and evolution. In our evaluation research, we actually cover this in good detail, so that you have an idea of product's background. That is also helpful to understand how seamlessly (pun intended) the product integrates with rest of the vendor's offering. In fact, many times, vendors get upset with us for citing older product names in our reviews. However, we do that intentionally to actually show the product may actually differ from their remaining offerings -- exactly the kind of thing a vendor wants to hide.

In any case, do take the time to understand product's roots and history before making a selection decision. Our ECM Suite Family Trees (OpenText, ECM and Autonomy) along with our reports will help.

Since a mobile site is the new "in thing" now, many of these services that were popular in early days are making a come back -- albeit in different form. Today you can use services like Ubik.com (powered by Volantis), Mozeo, MoFuse, and many others to quickly create sites  optimized for delivery to mobile devices.

Services like these provide a low cost and a quick way to create mobile presence. Some of them can also provide  advanced features for customization, such as specialized branding templates in lieu of existing canned templates.

But you should also ask yourself, are you still just creating another Geocities-style presence for the mobile world?  It's worth asking, because you may quickly run into limitations. If you're exploring any these options, get answers to these questions:

• Can you modify the user experience for different types of handsets based on devices' capabilities and limitations?
• How will you ensure that your main web presence stays in sync with mobile web presence?
• Do you have to create content twice - once for your web site and then again for your mobile site?
• How will you embed applications to enable transactions or build features such as personalization?
• If you employ a mobile site-builder service today to get up and running quickly, can they provide a migration path should you opt for another alternative in future?

There are many more such issues. Once you start addressing these, you may find that building a mobile site is no longer as quick and inexpensive as you might have thought.

In any case, as with other tools, evaluate these services from a longer-term perspective, and not just today's quick time to market.