This acquisition is an unusual move, as for many years Hyland has been synonymous with document management and workflow solutions for the mid-sized banking and healthcare sectors. With this acquisition, Hyland takes a fairly serious stake in the higher education sector. But not a dominant stake: the higher ed sector has many players; for example Perceptive Software has over 400 clients there, and its a highly competitive market to get into.

Of course it's up to Hyland to decide how to run their business, and where to target their efforts, but it's for their customers and the likes of me to question if this acquisition will prove to be a distraction to the current customer base. I can't help but conclude that it will, as the Hershey acquisition not only takes them into a big new market (though to be clear Hyland did have a few higher ed customers prior to this) but it also delivers a completely new and overlapping ECM technology set. Hyland have not just bought market share, they have bought a lot of new technology. For a company that has long built and developed its own technology, it's hard to predict how this will play out. 

It may be that Hyland will take the best of both technology sets and develop something impressive, but that is hard for even the likes of Oracle and IBM to pull off. They may continue to run the two product sets completely separately, but then there will be overlapping resources and functionality and potential rivalry and confusion. Hyland could just let Hershey do their own thing but as Autonomy and Open Text can attest, that isn't easy either.

Many analysts including yours truly, as well as Hyland's arch competitors, tend to speak respectfully about them as they epitomize the ideals of midwestern honesty and friendliness when doing business.  This acquisition though will test that culture I think, and though I can see no reason for existing customers to get worried quite yet, it wouldn't be a bad idea to watch how things progress with a cautious eye. There may be lots of kisses now at Hershey, but they may not last. (Sorry, I couldn't resist that one!)

India recently finalized its 3G policy and although we are way behind many countries, it is expected that 3G subscribers will cross the 100 million mark - that's more than the total population of many countries - within 5 years. With one of the lowest rates in the world (20 paise a minute or about 0.5 cents for a 3G video call) and innovations such as the $35 tablet, I don't doubt that estimate at all.  3G will reach where wired broadband could not.

What concerns me though are some of the other challenges that remain largely unaddressed:

1. I don't think the content providers and app developers have understood local pricing yet.  Many of them have their global pricing strucutures applicable here. In fact, many of them have actually priced their offerings higher in India. I am no economist but I also understand that the incremental cost of producing a digital product is miniscule as compared to that of a physical product. A small blog post is not enough to discuss all the intricacies of pricing but the content providers (and also the vendors) should keep their options open for differential pricing as well as pricing which is in line with cost of other things. After all, a customer who pays 0.5 Cents for a 3G video call is hardly likely to pay $20 for a social networking client
2. It is just not sufficient to have iPhone or Blackberry versions of your site if you want your content to be consumed more broadly. You need to be able to have much more fine-grained support for different types of handsets, and not just a few types of smart-phones. We detail why this is important and how this can be implemented in an advisory paper, "Adapting Your Content Management Platform for Mobile Delivery"  for our subscribers.
3. Localization is very important. There are 22 official languages and many more dialects as well as unofficial languages spoken in India. So your content systems should make it easier for users to interact in local languages.  Having a Unicode compliant WCM system is not enough; you also need to have local language interfaces to enter content in users' language of choice. I'm not suggesting that there should be a version of TweetDeck in all 22 languages, but you get the idea.
4. Apart from the language, there are many other unique aspects that these systems should support or enable. As an example, if some of the vendors were to come up with an out-of-the-box accelerator for building Matrimony or Astrology sites -- the two most popular type of web content in India -- I am sure they would have a big customer base
5. And finally, for  app developers, there is a serious lack of support in terms of SDKs, APIs, policies, and documentation for them to be able to create language-specific, localized applications.  As an example, some app stores do not allow you to submit applications that are ad supported. So you can only submit apps that are either free or paid but not that are supported by any alternative business model. If someone wants to develop a highly unique application such as the one that allows tobacco farmers in rural India to participate in tobacco auctions, the only way to make money would be by way of ads (example courtesy @pranshuj)

In one of the conference keynotes, a speaker explained how mobile apps are going to be big. He gave his own example of how he starts his day by checking his Facebook account, prepares for a music concert, books movie tickets, and does a lot of other stuff all using his "smart" handset. While I don't subscribe to this hype - in this case, our friend probably doesn't have a laptop or life - I do believe that there is a huge opportunity waiting to be tapped, and  some of these challenges will need to get addressed sooner than later.

On a related note, I will be speaking about how to manage content for the mobile world in my session at the J. Boye conference in Aarhus. Please feel free to leave a comment or send me an e-mail if you'd like me to cover anything specific.

First, a tip of the hat

On the whole, traditional analyst coverage of Web CMS technologies has gotten much better than ten years ago when I started analyzing the market, and this MQ continues a positive trend. Gone are bizarre predictions of WCM getting folded into larger ECM platforms, replaced by a greater focus on the needs of web teams and their customers.

And now what you really need to know...

The MQ tries to fit some complex choices into two-dimensional diagram. Many (including my colleague Alan) have critiqued the overall format. For now, let's just say that if you're serious about the technology you're going to select, you need to dig deeper.

Specifically, you'll want to:

• Carefully assess a broader set of key players, including open source projects, many of which are quite ready for prime time. Our Web CMS evaluations evaluate 45 solutions head to head.
• Look closely at important weaknesses (not just cautions), with less emphasis on marketing acumen and other investor concerns, in favor of digging into real implementation weaknesses, like serious architectural problems, support shortcomings, and post-acquisition dislocations.
• Structure your selection process as a multi-dimensional challenge, where the goal is not to ordain Leaders or eschew Laggards in a generic way, but to find the right fit for your needs. There's a right time and place for nearly all the 45 vendors we cover, if you consider varying architectures, costs, developer vs. contributor ease, geographic footprint, vendor intangibles, community support, integrator savvy, and a variety of other factors.

The biggest trap for you

The biggest potential trap for you with this MQ is Gartner's continued over-weighting of "name" vendors. It is only a slight overstatement to say that the bigger the software vendor, the weaker their WCM tool. It's been that way for more than a decade. This does not mean that only small vendors and open source projects can create great Web CMS packages. Larger vendors just seem to lack the agility and interest to keep up. It's not a big market, and their attention lies elsewhere.

This has real consequences for you if you select a tool based on putative staying power or supposed platform consistency of an IBM, Open Text, Oracle, Microsoft, or Autonomy. For some bitter history here, you have only to look at the train-wrecks that were implementations of EMC's now deprecated WCM products. Customers bought EMC's web content management tools for a variety of reasons: perceived platform consistency, the free licenses thrown into document management mega-deals, and last but not least: favorable analyst reviews. Many of these implementations became failures of epic proportions, sometimes with career-stifling consequences for project leaders (but alas, rarely any blowback for the people who recommended the tool). This is serious stuff, folks.

The way our approach differs from Gartner's really surfaces in the divergent conclusions we reach about Autonomy-Interwoven's TeamSite toolset. Autonomy wins most top-right status with Gartner. We don't rank vendors that way, but you can see from our Autonomy review (excerpted in a free sample you can get here), that when we put TeamSite through a more multi-dimensional evaluation, they come out among the less desirable vendors in several meaningful categories.

What's a buyer to do?

How can different analyst firms come to radically different conclusions about vendors in an established marketplace? The main difference lies in our methodologies and target audiences. For a well-rounded view of your technology choices, seek multiple assessments.

However, now that I've got myself caught into going along with the metaphor, I'll make the most of it. As Time Magazine wrote ninety years ago:

"Touts & breeders, millionaires & jockeys froze with fear last week when Santrock, racehorse, crashed into the rail in a race. Santrock, blind in one eye, is dangerous. Bumping the rail he could not see, the horse pulled a blinker over the other eye. In total darkness he smashed terrified through the rail, turned somersaults, crashed through both rails on the backstretch. His jockey was thrown, badly bruised. Experts felt it lucky Santrock did not kill both himself and jockey."

Horse races can be spectacular. And we've seen software vendors careen like that too.  However, you should probably keep your eyes on the field.

One of the most succinct descriptions I've come across was posted by Jay Hill (of Lucid Imagination) in a LinkedIn group:

"IDOL (Intelligent Data Operating Layer) is Autonomy's search engine. IDOL servers are essentially the indexes themselves. Data is indexed into an IDOL server or a group of servers. There are connectors (FileSystemConnector, ODBC Fetch, etc.) which extract data from content sources, import the data in IDX (Autonomy format) or XML file formats, and then index the data into an IDOL server or servers. A DAH (Distributed Action Handler) can be used to query a cluster of IDOL server. A DIH (Distributed Index Handler) can be used to index to a cluster of IDOL servers. [...] Results are returned as structured XML."

What I like about this description is that it brings IDOL down to its essence: it's a search index, that lives on your server as an executable. When something's plugged into IDOL, powered by IDOL, or integrated with IDOL, this really means you'll have the IDOL, DIH, and DAH executables running alongside the other software. Operating these is hard-core "command-line cowboy" kind of stuff.

Now, there are plenty such cowboys around, and they're perfectly happy with the software. But unfortunately, quite a few of Autonomy's other customers weren't quite prepared for it, and ended up unhappy with what they bought. Of course, it's tempting to blame the vendor's marketing and salesforce for this; but that's a bit like accusing a tiger of hunting deer. You can't really blame them for trying.

In reality, the burden is on you, the technology buyer, to inform yourself before you commit. That will take more than just reading the one paragraph description above. The review in our Search & Information Access research takes twelve pages to get to the core of what the tool actually does, what it's good at, and what it's not. In the end, Autonomy has some clever technology, but there's nothing mystical about it. And there's no reason to let yourself get caught in the headlights.

Vendors are especially excited, such that Product X is no longer a WCM offering but a "WEM Suite" now. But you should be forewarned that in their quest for improving presentation management, vendors are soft-pedaling many core CMS concepts which haven't really seen a lot of innovation in recent times, and this, too, could impact your website visitor experience.

The services that make up the "E" part have been around for a long time, including: analytics, multi-variate testing, landing page management, CRM integration, personalization, template management, social functionality, and so on.  So, we are witnessing a natural progression and not something drastically new. The big difference now is that -- while these features tended to come separately in the past -- the trend now is to more tightly integrate them with traditional WCM services.  In many cases, these additional features are natively provided by WCM vendors themselves as part of a larger package.

You don't have to look far to find examples. Clickability, one of the hosted WCM vendors that we cover in our WCM evaluation research, recently announced a new module called Website Marketing Accelerator (WMA).  It's targeted at B2B marketers, enabling them to focus more on visitor segmentation and targeting. Other vendors such as IBM, Day, Fatwire, Open Text-Vignette, Autonomy-Interwoven, SDL, Sitecore, Alterian, EPiServer, et. al., have also been promoting their so-called WEM capabilities rather than core content management functionality. Some of them have gone as far as changing their product names.

You can understand this new emphasis because in many scenarios, content managers want to manage the consumption and interaction experience -- and not just the production process. Also, experience management includes the sexy stuff: personalization, Rich Internet Applications (RIAs), Social applications, User Generated Content (UGC), and other Web 2.0 stuff, while core content management services entail less fancier features, such as authoring, workflow, library services, and publishing.

If you are new to Web Content Management, don't assume that vendors and consultants have figured the basic stuff out. In fact, as an industry we have not really solved some fundamental content production problems:

• Online authoring for most people, most of the time, is still a buggy and sometimes painful process
• It is still difficult for business users to create and participate in workflows
• Publishing from one environment to another still remains one of the most trickiest aspect to master
• Caching of web content remains a black art
• Issues related to standards and formats still plague the industry; You don't know if you'd be able to watch your home videos in 5 years time or not or whether the fonts and styles as you know them today will exist or not
• Many more challenges of content production, such as those related to multi-site management, content reuse, deployment, and so forth still remain tauntingly difficult

Don't get me wrong. It's important to manage visitor interaction, and often the best people to do this are content contributors and publishers. But you should know three things:

1. In the early days of WCM, systems typically followed the current all-bundled-in-one-system approach, and the long-term results were not always positive: reduced capabilities at system edges and and architectural inflexibility led to various knots that were difficult to untie.
2. Your WCM vendor may not be the right supplier for the varied services they are peddling today. Template management, native to your WCM tool? That's a good candidate. Blogs and wikis? Maybe. Testing and analytics? Probably not.
3. Above all, good content lies at the heart of good services and a constructive customer experience.

Vendors differ markedly in how they approach the "E" part. The pros and cons of your various choices constitute a large topic in itself, something that we cover in detail in our online Fundamentals of Web Content Management Technology course as well as our WCM evaluation research. So, call it WCM or WEM. The acronyms don't matter too much. Just remember: there is no point in having a great website front-end with content that's stale or fails to engage users in its own right. Get the production part down, or your visitors won't stick.

However, make no mistake: FAST may be a lot less expensive, but it's certainly not going to come cheap. Not in the least bit because implementing it right will still be an expert's job. There's a real risk that your SharePoint integrator will charge you for what amounts to their own on-the-job training. Nor will it be a breeze to keep running -- a lot easier than the old FAST ESP -- but still quite hard, especially at a large scale.

Nevertheless, the main surprise -- as always with all things SharePoint -- is bound to be the total licensing fee. For starters, you'll need the Enterprise Edition of SharePoint, because lesser (cheaper) editions don't support FAST. That also means that for every internal user you'll need eCALs (Enterprise Client Access Licenses). And then, of course, every FAST server needs an additional license, as well.

Microsoft licensing is complex, and becomes even more complex when you're talking about many seats (when you might be able to get volume licensing discounts). Plus, pricing will vary in different regions of the world -- so it's impossible for me to give you exact figures. Most of the cost lies in the Enterprise licensing, which you might already have. (If you want to know what the exact differences are between the editions, Microsoft has a detailed comparison.)

But if I take the various figures given to me in Dollars and Euros (or see this nice example in Pounds), the result is a lot steeper than I had expected. When I run the numbers for a fairly typical FAST setup for 1,000 users, it would cost around $125K extra if you don't already have Enterprise licenses for another reason. (And that's just the licenses, not the specialist work needed to create a good search experience.)

So does this mean you should discount FAST as an option? Not really. Certainly, FAST will quickly run up in cost when you have a large number of internal users, but it's still quite a lot cheaper than it used to be. And its licensing has one large advantage over many competitors: it's based on seats and servers, not the numbers of records indexed. You won't have to worry about your ever-expanding repository of documents suddenly breaking a licensing limit of, say, 500,000 documents. As long as your FAST servers have the processing power to keep churning through them, the price is fixed.

But as Peter Sejersen over at J.Boye notes about SharePoint WCM alternatives, "contact Microsoft early on in any large project, before you decide on one system or license model over another." Likewise, for search, don't just assume FAST will be a cheap add-on, because there are plenty of vendors in our Search & Information Access evaluation research that would gladly undercut Microsoft's pricing. And most of them have plenty of functionality to offer that out-searches SharePoint's basic capabilities, while easier to run and implement than FAST.

So even when you consider search as just one of the moving parts in your SharePoint project, it'll pay to run the numbers and compare the functionality with third-party products. When you do, FAST may turn out to be comparatively cheap, or surprisingly expensive. It all depends on your specific scenarios. And it's not something you'll want to decide off-the-cuff.

We also explore the pitfalls. To quote:

"As a high-level specification, however, CMIS may not provide the performance or breadth of functionality that users seek with respect to SharePoint integration."

While SharePoint's CMIS support is clearly welcome, it's not a silver bullet, and integration between systems remains complex and costly.  Meanwhile, many ECM vendors have developed deeper and more sophisticated (albeit non-standard) integration methods. In a forthcoming Advisory Briefing, we'll critique the various different ways that major ECM vendors integrate with SharePoint.

Just remember that when a system has a "SharePoint Connector" -- be it CMIS-based or not -- this doesn't mean that your all your needs will be met. 

Enterprise Content Management IBM-style is typically a million miles away from ECM Microsoft-style. Rather than the broad collaborative environments SharePoint targets, IBM goes after high volume imaging, intensive and complex rules, as well as case and process management. Layering analytics into the equation is only really possible when you have normalized incoming information/documents at the capture stage. Hence this acquisition.

IBM already had some pretty good capture capabilities, but Datacap offers better, and in particular Datacap had a number of industry specific solutions that could be of great interest to IBM. In fact it may well be this ability to extend FileNet more deeply into sectors such as Healthcare and Logistics, as well as further enhancing their existing presence in Insurance and Government, that drove the deal forward.

From a buyers' perspective many acquisitions are problematic, but this one might prove positive.

Let me explain.  To achieve solid business goals with ECM you often have to bolt incompatible components together and hope for the best. Vendors' response -- the ECM Suite where everything worked out of the box and in any configuration -- is still just a dream. Nevertheless, some ECM Suite offerings are starting to look better integrated and a bit more uniform, whilst yet others still look like Frankenstein's children.  Some ECM acquisitions are little more than standalone cash cows, others (like this one) could enhance existing products.

I don't doubt for a second that we will see more ECM related acquisitions (some of which will be capture related) before the year is out. But far from this being a sign that the market is consolidating and shrinking, it is rather a sign that the market is growing and getting ever more competitive.  And as always I will make a point of saying that only time will tell how well this acquisition works out. On paper today it seems pretty sound.

Though I'm an analyst, not a fortune teller, my best guess is that Adobe will turn Day's DAM into another "boxed" solution, much like the products of their Creative Suite. Under Adobe, Day's DAM will more likely compete with Extensis, Canto, and Xinet for mid-market, lower-priced, and departmental DAM needs, than grow into an enterprise player. As Apoorv pointed out in our first take on the acquisition, Adobe doesn't have deep experience selling server-side software.

Otherwise, Adobe has a lot of work to do on their new DAM product before it can compete with the major players in the DAM space. As a buyer with creative specialists employing Adobe tools on the desktop every day, don't assume that buying Adobe's DAM is necessarily the right choice for you.

One observation: although the SaaS-based web content management vendors continue to do well, they haven't reached the critical mass that many observers predicted several years ago. We still see greater interest for on-premise solutions -- particularly for Intranets -- but also for public websites. Although hosted providers garner more deals each year, they don't dominate the Web CMS market, and if there's some tipping point here, it feels a long way off.

For you the customer, I encourage you to at least explore the SaaS alternative (too many dismiss it outright), but by the same token, don't get sucked into the hype that the future is "all SaaS." The future is partly-SaaSy. You have a lot of choices either way. I hope our detailed evaluations can help you make the right decisions.

Products like Adobe LiveCycle help the automatic generation and dynamic delivery of personalized documents, usually for customer communications such as insurance quotes or e-bills sent by your telco. 

Adobe's LiveCycle's customers who wanted ECM capabilities had an option of using an embedded Alfresco repository. But now they will also be able to use Day's CRX as well as have tighter integration with Day's Digital Asset Management and Social Collaboration offerings. The announcement does not say anything about whether Alfresco will be replaced by CRX in LiveCycle, so if you are an existing customer of this offering, you'll need to wait and see what the implications may be. 

Existing Day customers may better benefit from the acquisition as they will likely be able to use some of Adobe's personalization capabilities (such as clickstream cloud) in conjunction with LiveCycle as well as have a tighter integration with Adobe's Flash, Flex and other technologies.

The deal will conclude in December 2010 and the FAQ mentions that the current management of Day will continue through 2011. But we recommend you ask for a detailed roadmap from your rep.

The deal also has a significance in terms of the general marketplace. For many organizations, the content lifecycle includes much more than what is "typically" considered part of ECM. In many cases, the end document (e.g., policy or bill) consists of some standard elements such as salutation and greetings along with elements that are specific to you. In the case of a policy, the specific elements could be based on your risk profile or legal terms based on your state or country of residence. In the case of a bill, these specific elements could be new tariff plans or campaigns based on your past history. In these examples, the organization needs to collect information (such as demographics), take it through a business process and then based on some rules, dynamically generate and publish the end result. 

We believe that all of these should be part of content lifecycle and that is the reason why in our ECM & Document Management Marketplace 2010, we've argued that features such as document assembly and dynamic publishing will get increased attention from mainstream ECM vendors in the future. Many other vendors that we cover in our ECM research, such as EMC (with Document Sciences),  HP (with Exstream), Oracle (with Documaker) already have offerings that strive to bring together these two aspects. We plan to include a separate section on Dynamic Publishing and review many such products in our next version of the ECM Report.

As for Adobe and Day, the question that nobody can answer at present is whether Adobe can really sell enterprise-grade customizable software. Their history of selling shrink-wrapped, lower-priced, high-volume software has built the firm into a Silicon Valley giant, but their ability to sell small-scale but very high-value enterprise software deals remains untested. The biggest danger for current Day customers may be that Adobe will want to take the technology, and over time commoditize it into shrink wrapped low-cost functionality bundles. But again, at this stage we can only speculate. And you as a buyer and user of the technology can do no more than act with extreme caution and ensure that any promises made by the Day and Adobe are solid and verifiable.

However, the greatest focus of this upgrade has been addition of a new "App Store" functionality that allows you to create enterprise-specific App Stores from where authorized users can download and apply applications for their own use.

JackBe's marketing would like you to believe that they are the first ones to bring this App Store concept -- popularized on the consumer side by Apple -- to the enterprise. However, they are not. Most Portal vendors we cover in our research already have some sort of catalog from where users can pick and choose components and assemble new pages or even applications. Among the Mashup vendors, IBM Mashup Center also offers a catalog for your users to search for, browse, categorize, rate, and tag components.

However, JackBe does deserve credit for bringing this functionality into focus. One of the key expectations of modern day enterprise software, including Portals and Mashup software is the ability to shorten time to market. This can be done if you are able to increase reuse rather than reinvent the wheel every time, which in turn means you need to have better facilities for managing reusable assets: the ability to share, search, tag and categorize, tracking the life cycle of those assets, measuring the effectiveness of reuse, and finally the ability to extend them and use them for use cases for which they were not built originally.

We cover the reuse aspect in a dedicated section in our research and have found that most products are not up to the mark here. Most of them are plagued by poor usability of their interfaces, inflexible nature of finding assets, and no ability to define a process for accepting a resuable asset. In most cases, even though you can pick a component from a catalog, there's very little you can do in terms of extending those components.

But make sure you test any mashup service -- including Presto and its new App Store --  for your scenario. Find out how easy is it to customize things such as modifying the process for adding components or creating a new category for your assets.

Initially, vendors were skeptical about providing information for a vendor neutral, independent analyst operation. Things have changed over the years, primarily because buyers like you have come to trust our evaluations as a complete and objective resource. The vendors are now more forthcoming with access to customers and solutions. It's made our job a lot easier, and it has also contributed to making the research more complete.

This is one of the big reasons I'm really pleased with the 5th edition we released earlier this month. It's been rounded out by lots of input from practitioners who are putting these solutions through their paces every day in large and small deployments and for both simple and complex analytics scenarios. My updates this year were also informed by my colleagues at Semphonic, who spend a lot of time "hands on" with Omniture, Webtrends, Coremetrics, Google Analytics, Yahoo! Analytics and Unica, and much of my own vendor selection work.

While we've seen change in the market over the last year, notably the acquisition of Omniture and Coremetrics, I don't think of this as consolidation. I think of this as part of a continuum in the evolution of analytics that was started when Google acquired Urchin, and continued with Yahoo's acquisition of IndexTools.  Specifically, these moves represent large, well-funded companies purchase analytics because of their perception that analytics can help them add value to their existing offerings and create upsell opportunities within their existing client base.

What I find interesting and perhaps more challenging from a consumer perspective, is that the base line functionality of these tools can no longer be taken in a vacuum, but has to be considered in context with the influence and direction of the larger company. So, the question you face in the future may go something like this: "I like Coremetrics functionality but I also like the idea of being able to embed Omniture tags in our Adobe Creative Suite content. What's the trade off if I go with one instead of the other?"

Trade offs in functionality and price already exist today. What I see frequently is that tool selection often comes down to nuanced differences in functionality and price. Sure, it sounds clever to say "all analytics tools are basically the same" or "you can get 80% of what you need from Google Analytics." But if you look really closely at the solutions you'll find small but important differences...differences that translate into solution acceptance or rejection by your user base (such as ease of use), or complete data analysis (such as ease of analytics data export).  

I think you'll find our evaluations helpful as you begin to explore those trade-offs.

Unsurprisingly, in Germany (SAP's home market), two WCM vendors have latched on to this. They offer integrations to publish content from your CMS, instead of using SAP's more complicated tools. e-Spirit's FirstSpirit allows editors to manage content from the CMS interface, which no doubt is more familiar to them than SAP's. eSpirit then publishes the content out to the SAP portal.

Two weeks ago, CoreMedia announced a completely new integration for their CMS. Their method is now the opposite of e-Spirit's: instead of publishing out to the portal, the vendor offers iViews (SAP's equivalent of portlets). These will then serve as dynamic publishing components; in short, this enables in-context editing and staging previews within the SAP portal. This also means you have a lot more freedom in what type of content you publish in the portal: CoreMedia can also do images or video.

The main drawback to CoreMedia's approach, of course, is that the content will stay in the CoreMedia repository, instead of in SAP. (As opposed to FirstSpirit, which stores live content in SAP.) This will mean the initial implementation might be easier with CoreMedia, but getting SAP's TREX search engine to index everything that's visible in the portal will take more effort. (You'll have to feed CoreMedia's content into TREX for SAP to even be aware something's there other than the presentation portlets.) At any rate, how easy or hard the CoreMedia integration will prove to be is something we'll have to see: according to the company, the first two customers will go live with the solution in September.

For NetWeaver portal customers, it's good to have these to differing offerings to contrast to SAP's own editing and publishing tools. And since both CoreMedia and e-Spirit are branching out of their German market, you could consider a closer look, even if you're in the US.

That leaves me with one interesting question though. If you're going to use a CMS to manage the content for your intranet, that makes perfect sense. But do you really want to use NetWeaver Portal, if it's just going to be an expensive and complicated delivery tier? I'd say that if you don't plan to primarily use the portal to expose SAP, you should probably consider this carefully; even if you already have the portal implemented. Carefully weigh the pros and cons of possible mixes of CMS, portal, and SAP whenever you plan big changes. There's plenty of options that might prove more effective than what you currently have.

The topic of search crops up one way or another in nearly all the advisory calls we receive from our research customers -- including inquiries about other technologies, like ECM, Portals, Web CMS, DAM, and so forth. Search is essential; search is omnipresent; but woe to project leader who believes search engines are omniscient. Of course, this doesn't stop enterprise search vendors from claiming omnipotence.

Which brings me back to Autonomy. From an initial focus on enterprise search tools, Autonomy has become a roll-up vendor after acquiring a variety of other information management suppliers such as Interwoven. As a financial strategy this can be successful, and investors seem to cotton to Autonomy.

As a technology strategy, vendor roll-ups are problematic. Autonomy's technology strategy is to rip legacy search subsystems from acquired products, replace them with some pieces from its own IDOL toolset, and then promote its particular approach to search as a distinct advantage for you.

Specifically, Autonomy will try to sell you on the value of "meaning-based computing." Even if you can get your mind around what meaning-based means, you should remain skeptical that Autonomy has technically spectacular or original services here. More importantly, you risk getting sidetracked from your original goal of, say, creating a user-friendly repository for your 50,000 Office documents.

This wouldn't be as big a problem if Autonomy hadn't acquired so many aging technologies, especially in the WCM and DAM segments. Don't be surprised when, upon asking about missing or substandard functionality in these areas, your Autonomy reps deflect with search-oriented -- oops, I mean "meaning-oriented" -- answers.

Now, if you're buying a DAM, Records Management, or Web CMS package, you can't sneeze at better search, but in Autonomy's case it comes with some very complex and maintenance-intensive technology in IDOL. It also invites a slew of upsells of nearly limitless optional modules. Before long, you've turned a content management project into a serious search investment. Autonomy's delighted, but is that what you really intended?

Again, search is important -- but in the context of a broader content management effort, search becomes a complementary service. So when you examine Autonomy's toolsets, best to ignore all the talk about IDOL unless what you're really looking for is an enterprise search platform. When evaluating Autonomy offerings across the many marketplaces where it sell products, we continue to look carefully at what each package was actually intended to do. You should too.

First, to illustrate: about a year ago, I read Jon Mark's blog post: "when most Twitter users say CMS, they mean WordPress, Drupal or Joomla!. [...] So I panicked a bit. I know WordPress. We very occasionally see Drupal in a vendor selection, and never see Joomla! at all. I've never been involved in an implementation with either. [...] So, are we really that out of touch?"

I'm sure there are many out there that would immediately have thought Jon really was out of touch. Because WordPress, Drupal and Joomla account for millions of implementations. To the general public, if they even know what a CMS is, those three have almost become synonymous with the term. To the point that even a serious newspaper like the Guardian would suggest WordPress as the ideal CMS for the Birmingham City Council, lamenting WP never got a fair chance: "Why wasn't it good enough for Birmingham? It seems that there's a prevailing mindset in some parts of local and central government that thinks that if you (actually, taxpayers) aren't paying through the nose, then you're not getting value for money."

Stop right there.

Yes, millions are using these systems and are perfectly happy with them. (In fact, I've commented a few times how, for instance, WordPress is one of the few systems that casual editors actually like to use.) That's why they rate very well in the "simpler" scenarios we describe in our Web Content Management evaluation research. And most of those millions of implementations fall in one of those categories. On the other hand, there are, for instance, no multinationals running all of their online efforts on simple open source PHP systems. Not because they're against open source, or because they think PHP isn't good enough, or because they're eager to "pay through the nose." But because these systems don't really work in their scenarios. (As a side note, I'm not even generalizing all open source PHP systems here -- some, like Typo3 for instance, are quite complex; and a .NET open source system like DotNetNuke is quite straightforward.)

Saying you could do "anything" with any given CMS is true to an extent. But it's like saying that the bicycle that's so healthy for your daily commute, would also be great for a ride to the South Pole. Sure, you certainly could, but the real question is: would you really want to? And if all you know is bicycles, wouldn't planning a trip to the pole be a great occasion to find out what other transportation would be available?

So what does make a project more "complex" than those "simple" scenarios? Well, we could talk about that for a long time (in fact -- it's what we do on this blog most of the time). But to give just a few examples of what would go beyond a "simple" scenario; some of the things that quickly add up complexity:

• Scale of the CMS deployment: Having hundreds or thousands of contributors, and tens or hundreds of thousands, or sometimes, millions of content items. If a CMS tends to display users or content items simply as lists (newest on top, or alphabetically) you can imagine this becomes rather unmanageable at this scale. You really need a lot more sophisticated controls to deal with it, such as efficient search. It gets quite hard to find out who's doing what, where, and when in your system without repository services, audit trails, integration with directories -- and so on.
• Scale of the published websites: Running a simple PHP CMS on a hosted LAMP server is quick and easy. However, you may find that what works for thousands of visitors doesn't at all scale to millions. Many of the simpler systems we cover are actually much harder to run when you try to use them for high traffic (because they aren't really prepared for it, so you'll have to customize, adapt and use a toolbox of tricks) than complex systems which come with out-of-the-box functionality for massive scaling.
• Content re-use: When you want to use the same content in multiple places in a website, and/or in multiple sites or channels. Especially when this involves placeless content, deployed based on different criteria (automatically and manually). It will quickly build up the complexity of both the core system, but also the interfaces in order to keep it all manageable and intelligible for users.
• Globalization: Just take a look at an airline website. There's not a shocking amount of content, but usually it'll have to be available in at least dozens of languages, in multiple websites targeted at various countries. This means content needs to be translated, but also adapted to nuances of local requirements. Managing this effectively is quite hard, and complexity tends to increase exponentially for each locale added.
• Workflow: In many cases complex workflow is overrated, and straightforward "save - review - publish" would be more than enough. But there are scenarios that won't do at all. If, for instance, content has to be checked by legal, or translated into multiple languages, preferably (to save time) in parallel, you need to be able to design complex branching workflows to deal with this.

Of course, there's a lot more, and if this interests you, I'd suggest you have a look at the introductory chapters of our Web Content Management research. But suffice it to say, when I say "this system is great for simple scenarios, but don't think it'd be just as great for complex scenarios" -- I really do mean complex scenarios. (But that doesn't mean I hate bicycles.)

In the end, what it boils down to is using the right system for the right job. Use something simple and cheap for a simple problem. But don't forget that sometimes, complex problems demand complex solutions. It would be ridiculous to buy a train to get groceries; just as ridiculous as getting a bicycle to haul tons of bricks.

• Folding WordPress MU (multi-user) and regular WordPress into one system means you'll now be able to run multiple blogs from an install. This means WordPress is now more like Movable Type:
• "Custom post types" mean WordPress can now do other content types than just "posts" and "pages" -- this seems trivial for most WCM systems, but it's not something to take for granted. This means WordPress is now more like Drupal (and its CCK, to become part of Drupal 7 core).

Is this great news? I'm sure many would think so. And I like WordPress as blog software (even though I think Movable Type may still be the better choice for running multiple blogs). I can also see its appeal as simple web CMS (it's more user-friendly than Drupal, but can be made to do pretty much the same things). As the WordPress blog says, "Arm your vuvuzelas!" -- to which I'd like to add: "bzzzzzzzz."

Let's face it, the main reason so many have started to use WP as a CMS to power sites other than blogs is simple: because it's easy to use. (For blogs.) Every feature (and every plugin) added to WP threatens that same ease of use. And as soon as you start making it jump hoops to do more complex things than it was designed to do, you completely loose the advantage. Use it for more than dozens of pages, more than two languages, or more than just a handful of sites, and WP will begin to hurt.

I'll keep repeating my mantra: WordPress is great for a blog. But there's a real risk of it being turned into a very mediocre CMS. It really depends on your scenarios, and there are many reasons you'd want to look beyond WP. Don't mistake WordPress for a cheap and simple alternative to just any other system in our Web Content Management research. That would be like using a vuvuzela to play Brahms and Ravel.

I was recently advising one of our customers throughout several vendor demos. It was a great reminder of why we spend so much time explaining what each system does exactly. And a substantial part of that is translation from sets of arbitrary lingo to more generically intelligible terms.

Witness one of the vendor's attempts to explain: "No, in our system, paragraphs are not paragraphs, they're page elements." So why not call them that? (And, of course, one of the developers at the other side of the table remarked "but paragraphs are page elements" -- "yes, but these pages aren't pages." The ensuing confusion took a while to clear up.)

Without knowing a system's quirks, you're never quite sure. Is a masterpage a page, or is it a template? Is a content template meant for design or for modeling? Is the design really the layout or the structure? Or is it, maybe, a class? And how about the smallest uniquely identifiable content item in a system. It could be a node, or a post, or an instance, or an item, or a page. Of course, as mentioned, sometimes a page is not a page. And a site doesn't necessarily represent a site.

A rose by any other name would smell as sweet. But in content management, you're likely to be cut by a thorn before you'd recognize the stem. Hopefully, eventually, everyone will be able to settle on some kind of content management Esperanto. We've suggested some common terminology in our WCM evaluation research and try to apply a kind of thesaurus to each product we assess.  However you accomplish it, find out whether a vendor's spade really is a spade -- before you start shoveling.

It's a vibrant market characterized by substantial R&D investment, as well as new (and rumored) acquisitions. We're not sure the acquisitions of Omniture (by Adobe) and Coremetrics (IBM, pending) are good for you the customer, but you can check out our analysis of the pros and cons, then decide for yourself.

With this edition we also add noted French analytics vendor AT Internet to the mix.

Subscribers can download the new evaluations here. If you want a sneak preview, you can get a free sample here.

The platform has many new features such as:

• Plug-in based architecture allowing you to host multiple portal type applications or add on other components to your Portal infrastructure
• A complete new user interface that is based on the GateIn Portal. The UI is based on Groovy framework and replaces the existing JSF based interface
• It uses a different page model in which each page is stored in a Java Content Repository (based on eXo JCR)
• An in-built gadget container based on Apache's Shindig allowing you to host and run gadgets along with portlets
• Some of the other features are support for Right to Left (RTL) languages, a new identity manager, and a cache implementation

Many of these features above are not just enhancements but completely new development efforts. While it is called EPP 5 and targeted as a next release of their existing EPP 4.x, remember that it is really a new product for all practical purposes. We describe some of the platform's other demerits in our Portals and Content Integration evaluation research.

But today I was struck all of a sudden by what seems to be something of a change to daily business.  In the past year point releases for many of the more prominent ECM vendors have been much less about fixes and much more about co-existence. To explain...

Though every software firm regales me with tales of how they "replaced" FileNet or EMC or whomever, the truth is usually that they are now installed in the same locations as those legacy vendors.  Gone seem to be the days of "one ECM to rule them all." Instead people want to use multiple ECM applications, and when they introduce the likes of Microsoft SharePoint into the equation it is very seldom to actually replace an incumbent supplier (despite what the vuvuzela-blowing Microsoft channel would have you believe). It is more typically in addition to the incumbent supplier.

For an old-timer like myself (though you would never guess it to look at me) this normally raises concerns,  since the goal for the last 20 years has been to get everything in a single repository, or at least to attempt to. The very idea of multiple ECM suppliers in one location, on the surface at least, flies in the face of this goal, but the reality of the situation is probably somewhat more nuanced.

In the past year increased and expanded support for connectors and adapters of all sorts has been the key theme, and an almost literal acronym soup of protocols are being supported from CMIS to CIFS to IMAP.  What suppliers are slowly coming to accept is that the future is heterogeneous, and that to survive they need to be a team player. If your product doesn't play nicely with the products already in place then you are unlikely to make much progress. This is a good development all round, but its not without its drawbacks.

As a buyer you should absolutely expect any new supplier to be able to technically adapt to and interact with your existing environment. There is often no good reason other than to fatten a suppliers paycheck for you to throw out systems and processes that work perfectly well and replace them with something new.

But be aware that just because a supplier says that their product supports this or that protocol or integration point does not mean that they all do so in the same way.  For example WSDLs (the stuff that describes how a Web Service talks to others) can range from the verbose and barely literate to the simple and profound.  Likewise integrations with common applications such as Word, Outlook or SharePoint can be pug ugly or near transparent. 

Standards are a good thing, and the fact that suppliers are in a rush to adhere to as many as possible is an equally good thing. But don't confuse compliance with a standard as everyone doing things the same way.  They all theoretically reach the same end (hence adherence to the standard) but getting to that point can take many different directions.

So if co-existence of a new application into your existing information management environment is important to you then be sure to test and demo those elements before purchasing. Otherwise you could see your new suppliers' idea of team play akin to the French soccer squad: complete with disagreements, work stoppages, and an early bath becoming the most likely outcome.