The latest victim in the Web Content & Experience Management (WCXM) space is Refresh Software, who finally called it quits in recent months after a long period of, well, lack of refreshment.

Early in the last decade, Refresh Software made the now familiar transformation from web consulting company to software vendor, replete with outside funding and an imported "professional" CEO.

Refresh took a somewhat novel and useful approach to web content management: you could retrofit their content database and simple entry forms behind a pre-existing website or web application. This obviated the need to replace your entire front end when you implemented a CMS-based back end.

At a time when marketing managers were beginning to assume control of web publishing operations, few customers took to this approach -- Refresh became an explicitly techie sale -- but some enterprises saw value in such a highly decoupled architecture. Refresh customers who clearly understood what they were buying into seemed quite happy with the technology.

Alas, somehow Refresh lost their way. I can't offer any special inside dope on the company, but based on watching them in the marketplace over the years, I suspect their demise can be traced to three fundamental problems:

1. Lack of implementation partners
   Small- to mid-sized vendors can make a go of it with their own professional services consulting groups in lieu of a channel approach (Ektron is doing this now), but in the event, they need to make a real commitment there, since consulting is not a simple business to manage. Refresh never seemed to build up either a broad consulting channel or deep internal bench.
2. Permanent bootstrap mode
   Although Refresh did acquire some outside funding, it continued to stay in loosely organized, start-up mode at a time when competitors were maturing their operations significantly. For example, product engineers at Refresh often did double-duty as support techs -- which was great for customers, sometimes -- but also meant that at other times both product release cycles and customer support could suffer.
3. Meandering roadmap
   This was the killer, I suspect. Refresh initially committed to its simple, page-oriented approach -- pointing out correctly that not all web publishers need or could handle the overhead of highly structured, reuse-oriented systems. The company then did a complete about-face and wandered into the realm of "component document management," an area their technology (and likely most of their customers) were quite unsuited to support.

For better or worse, it takes more than good technology to succeed as a vendor. In fact, many outwardly successful WCXM vendors have sold rather poor technology (c.f., HP/Autonomy/Interwoven TeamSite). Operational acumen clearly matters, but so does building a sustainable community around any offering.

This is yet another reason why we pay increasing attention "vendor intangibles" in our comparative product evaluations, and you should too.

Best wishes to the former Refreshians as they move on to other firms.

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. 

So why don't we review MarkLogic in our Search & Information Access research? It's a fair question to pose, and some of our subscribers do ask, often after talking to MarkLogic salespeople.

To answer it, my colleague Theresa Regli and I wrote an advisory paper "Is MarkLogic an Option for Enterprise Search?" It describes what enterprise search is; what MarkLogic is; and why MarkLogic isn't enterprise search.

Subscribers can download the paper here.

Regardless of whether Android tablets can compete with iPad, the fact remains that Android has taken operating system out of the equation now. And this has serious implications for site publishers targeting mobile devices.

In earlier days, one of the features that differentiated one mobile phone from another was its operating system. Companies like Nokia and Apple invested huge amount of dollars developing Symbian and iOS. But what Android has done is that it has allowed lesser-known or even unknown vendors to compete with the Nokias and Apples of the world. 

It has also opened up a huge potential for companies to target a big mobile population that can now afford a "smart phone" without shelling out a bomb. In several countries in Asia and Europe, mobile phones are expensive because they are not subsidized by wireless service contracts.  But with less expensive phones now having the ability to access the web -- and mobile penetration far exceeding PC penetration -- the universe has suddenly expanded.

With opportunities come challenges, especially if your organization is one of those who want to target this population. Unlike iOS where Apple controls the hardware, Android does not have that benefit. Android devices range from small 2" form factors to large 10" form factors. They also vary hugely in capabilities: some run on a 500 MHz processor while others run on more powerful dual core, 1 GHz processors.

You could of course create "apps" for your applications. But that obviously is not a scalable proposition.  For one, you don't want to be creating an "app" for everything, and secondly, it is not trivial to create apps for all different operating systems and deal with the intricacies of  different "app stores."  You will probably need to achieve a balance between an "app" for some scenarios and a web application for remaining scenarios. In any case, if you are not sure, its best to take an incremental approach.

Start with getting your basics right such as by maintaining a strict separation between your content and presentation (and therefore beware of rich text editors). Focus more on standards-based output that can support basic re-purposing with minimal effort. You can then decide whether it make sense to create a native "app" or invest more in a web application to achieve more fine targeting.

In fact, it's still not uncommon for authors to have to learn a specific XML syntax in order to be able to write structured content. That may be one of the main reasons standards like DITA have little appeal outside of techdoc. Xopus' web based editor, however, does a reasonable job of keeping the XML abstractions from authors.

That said, any XML editor is far from WYSIWYG. They can't (and maybe shouldn't) be, because structured content tries to take the presentation out of the actual content. So don't be fooled by demos too much -- there are still many challenges in adopting structured authoring.

As for SDL and Xopus, perhaps more importantly: don't think any SDL product now immediately comes with a well-integrated Xopus editor. Integration takes time, and SDL has a lot of very different products. I'm sure they'll be able to demo it soon, but we've noticed that SDL's "integrations" are often quite shallow at first. For now, it's not necessarily an advantage over the competition.

Scotland provided a decent-sized crowd from both the private and public sectors, who all seemed very savvy regarding ECM -- frankly one of the better informed groups of people I have met in a while. 

The theme of the day for me was dynamic publishing.  With the continued push for all public services to provide stronger online services, along with the recession driving more customer self-service in the private sector, complex publishing is clearly a hot topic.

What was also interesting was the relative skepticism of the audience about existing products.  More than one came to me and used the immortal words "Well the IT Department suggests I use product X, but I'm not so sure..." in all cases it was the same über-product that IT was recommending.

I also found lots of interest in both our Content Technology subway map, and in the ECM3 maturity model. Will be interesting to see if today's concerns are reflected in the next cities we visit. 

It will be interesting to see how these companies blend. Really Strategies, while having some experience with DITA, has largely focused on traditional publishing, while DocZone.com has almost exclusively focused on DITA-based technical publishing. Over the last year we have seen each of them "inch" into the other's market as DITA is being adopted outside of technical publishing and publishing, and media companies have begun to look for low cost XML solutions (e.g. SaaS).

Publishing and media companies are under a lot of pressure to "innovate or die" as traditional print-based journalism has begun to rapidly disappear. Really Strategies offers a relatively high-end solution for publishing and media and a client/server-only version. DocZone.com provides a low cost SaaS version. Together they can potentially serve a broader range of customers.

DocZone.com is in a unique position in that its product is portable to any underlying XML technology. The value of portability was shown when their original platform XHive Docato (now known as XDB) was bought by EMC. They maintained that platform and rapidly built another version on top of open-source Alfresco. At the same time, they simplified the interface and consolidated their intellectual capital in the user experience. That type of innovation should stand them in good stead as they blend the technologies.

In addition Really Strategies will gain from DocZone.com's European presence and strong global focus.

Really Strategies has pledged to maintain DocZone.com's product and customer base. The combined companies will be headquartered in Audubon, PA. So.... (for the second day in a row), "tread with caution" if you are considering buying either DocZone or Really Strategies, as it could be quite some time before things truly settle down.

Now SDL has acquired Component Content Management (CCM) vendor XyEnterprise. Time will tell how this acquisition plays out, but it does illustrate how the CCM marketplace could be consolidating into larger players

At first glance it appears to be an odd acquisition, since, as our CCM research subscribers know, XyEnterprise Contenta and SDL Trisoft compete head to head in the marketplace. On closer look however, there is some logic in the acquisition. SDL Trisoft provides pretty strong DITA capabilities and reuse in a multilingual environment. Though not a large vendor, XyEnterprise brings a range of products:

• Contenta, a DITA and S1000D CCM
• XML Professional Publisher (XPP), an XML-rendering engine
• LiveContent, a dynamic delivery engine

SDL says that XPP and LiveContent will be integrated almost immediately. SDL has also indicated that Contenta's S1000D version will continue to exist as a separate product and the strengths of the DITA version (e.g., workflow, authoring bridges) will get integrated into SDL Trisoft. That will not be an easy task, and we anticipate it will take years to complete.

So there are some additions with XPP and LiveContent, and some gap filling (e.g., S1000D), but SDL has a long way to go to make this a truly integrated product. And while XPP is a good rendering engine with a long track record relative to its nearest competitors, it has also grown a little long in the tooth now, and has not kept up to date with all of the newer standards (like XSL-FO).

As in all acquisitions there will inevitably be fall-out and change, and just how well a small New England-based firm like XYEnterprise will operate as a part of a European roll-up remains an open question. How nicely they will play with the Trisoft team is also something to watch closely. So.... (you could see this line coming), tread with caution if you are considering buying either Trisoft or Contenta, as it will be quite some time before things truly settle down.

EMC has made a developer edition of Content Server freely available, and they have also provided a similar free developer environment for xDB. At the same time, each free developer edition will have an accompanying online community that provides code samples, tutorials and full documentation.

All in all, this represents quite a significant turnaround for EMC Documentum and one that is to be applauded. I can speak from personal past experience of the nightmare of finding basic technical advice regarding Documentum releases, and being reduced to scouring the web for potential (and often unreliable) information. This announcement will also provide a sigh of relief for those who have had to pay license fees for Documentum development environments. More importantly it shows EMC 'opening the kimono' (as that awful phrase goes) more widely than we might have expected.

We often comment that Microsoft has also gone from being a secretive firm (even about current releases) to (in the case of SharePoint) a very positive level of openness, community support and involvement. As always it will be time that decides the success of the EMC initiative, but I suspect it will be just as successful as Microsoft's community initiative around SharePoint, as there is an established, vibrant and very sizeable Documentum community out there who have long awaited this day.

The need to support complex, component-based publishing is growing, and is likely to continue growing in importance over time. Yet at the present time component content management remains a highly fragmented and poorly understood sector. We try and do our bit at CMS Watch to make sense of it for you the buyer and user of this technology. Doubtless some of that $12m will go toward better messaging and product articulation from Mark Logic. That said, all the vendors in this space could probably use some refreshing -- particularly in developing more business-friendly user interfaces -- for the field to really take off.

In simple terms the Quark XML Author 3.0 has been integrated with IBM FileNet Content Manager P8 4.5 to provide DITA functionality in an enterprise environment. And though most industry partnerships are barely worth the paper they are written on this one is at least interesting - if not quite the revolution it proposes.

This is not the first time that FileNet has supported XML; they had an integration with Arbortext about 10 years back that enabled companies to author in XML and store in FileNet. However, at that time it was Arbortext that supplied the smarts for managing the XML, FileNet was essentially a "dumb repository." This time is a bit different. IBM has modified FileNet to support DITA and XML, with Quark providing a Word-based XML authoring experience.

To be clear, though we welcome this announcement, as always we have to treat it with a good dose of skepticism. Such skepticism is justified as this is not the first time an XML implementation in FileNet has been pushed to the market. Additionally this announcement is not an acquisition of Quark by IBM for the purposes of driving DITA -- simply a partnership, and both have many partnerships.

Nevertheless, there are three industry trends that are currently driving the adoption of XML, Component Content Management (CCM) and DITA in the enterprise.

It is becoming possible to author in a familiar, non-threatening editor
For years, XML editors have presented a technical interface to users, largely because these editors have been around for more than a decade and used to be used by technical authors. Now tools are becoming Word-like or even Word with XML "under-the-cover.". For example Quark XML Author for Word is (unsurprisingly) Microsoft Word with a C# plug-in. It looks and acts like Word, with underlying structure is supported by Word styles. It is an XML editor, but more importantly it is Word.

DITA for narrative documents
The OASIS DITA for Enterprise Business Documents subcommittee has been working on solutions to present an aggregated view (e.g., document view) of DITA rather than the traditional topic-oriented view. DITA content can now be presented as a document that looks like a traditional Word document, but with DITA topic structure under the covers.

Growing awareness of the cost of unstructured content
A growing number of organizations now see the unstructured content that exists in narrative business documents as standing in the way of processes that could potentially be automated end-to-end. This lack of structure leads to inconsistency, poor readability, and the inability to reuse content. In many cases, because of the inherent lack of structure, content remain hidden. Moving to highly structured content can be another step towards optimization and automation of content processes.

IBM is of course a sizable market player, so their attempt to broaden the reach of DITA and by default XML and CCM across the enterprise is noteworthy. With EMC also making some moves into the sector through their acquisitions of XHive and Document Sciences, it's a market that is starting to heat up, the big question we are all asking is, "is this just a marketing phase, or is this a trend." We'll keep watching.

Hence, the report itself has changed dramatically, with nine new evaluations added to the report including Quark, EMC, Adobe, Mark Logic, and XYEnterprise.

You can read more in today's press release, and all the details in our newly-updated XML & Component Content Management Report 2009. If you are a subscriber to our XML & Component Content Management coverage, you will receive your update shortly.

UIMA is one of those technologies that's hard to capture in a few words, but you can think of it as a pipeline-processing architecture and associated APIs for creating text-analysis components. Examples of such components might include tokenizers, summarizers, categorizers, parsers, stemmers, named-entity detectors, and so on. The oft-cited use case for UIMA is preprocessing of text destined for indexing by a search engine. But in fact, UIMA can be used in other contexts, as well. Any application that needs to parse or filter text, basically, is a candidate for UIMA (at least in theory).

IBM originally unveiled UIMA (to little fanfare) back in 2004, using it in the now-discontinued DB2 Intelligent Miner product before finding use for it in OmniFind Enterprise Edition (covered in our Search and Information Access Report 2009) and LanguageWare products (as well as, more recently, IBM's eDiscovery Analyzer). Except for a few users in government and academia, and one commercial firm (text-analytics vendor Nstein, which offers a dozen different UIMA "annotators"), UIMA never found traction outside the confines of Big Blue. Ultimately, in 2006, IBM open-sourced the technology and threw it over the wall (so to speak) to Apache, where it has been silently incubating ever since.

The significance of UIMA, technologically, is that it allows chunking of text-processing steps into units of work that can be implemented in different ways by different vendors, yet without losing interoperability. In theory, if your UIMA pipeline utilizes Vendor A's named-entity extractor today, but tomorrow you decide you want to use Vendor B's extractor because it's cheaper or better, you can simply swap out the respective annotators. (In UIMA, an annotator is like a plug-in filter.) You have a standardized pipeline architecture with Lego pieces (so to speak) that fit tightly together, instead of a jumble-bin of parts with randomly-sized square pegs and round holes.

The significance of the OASIS announcement (coming at this particular juncture) is hard to judge. It may be just one more data point (if any more were needed) validating the notion that interest in all things search-related is steadily rising. But it may also be an early indicator of interest in semantic-web technologies of the kind many (not all) experts feel will be important in the transition to Web.next-point-oh.

Regardless, it's the kind of "data point" we try not to overlook. So if UIMA begins to pick up steam now (finally, after five years) and land on a lot of other people's radars, don't say we didn't warn you.  We'll keep watching as part of our information access research, and share what we find with subscribers.

This session -- based loosely on ESPN's Pardon the Interruption -- will be a fast-paced debate exploring a variety of controversial ECM-related issues and trends. We'll have our own list of topics, but we encourage you to bring some of your own to the session too.

Pardon the ECM Interruption will be held on Wednesday, April 1, at 11:25. You can sign-up and read more about the conference here. Hope to see you there!

Where there remains a disconnect between buyers and vendors - is in just how expensive and difficult good capture technology can be to acquire. For it seems that now OCR (optical character recognition) is commonplace, that buyers still imagine that dealing with the issues of distributed capture, multi-paged documents, multi-languages, in multi formats is somehow easy, and by default should also be cheap.

In fact the difference between the high end capture vendors (such as Abbyy, ReadSoft and Kofax) and low-end OCR is the difference between a bottle of wine vinegar and a bottle of vintage Krug. For at the high end, capture systems not only recognize multipage documents, but also relationships between pages and the context and content on them. They can recognize and capture a paragraph that is written in English, and just as accurately capture the native language Chinese footnotes related to that paragraph. They can capture at a staggeringly fast and accurate clip -- and once configured and running are typically far more accurate and faster than humans keying the same information in to a system manually.  And of course, they cost more. 

Key advice to buyers: don't underestimate the value of good clean captured data at the start of your process.  Remember the maxim, rubbish in = rubbish out. At the same time don't underestimate the capabilities of what are genuinely some of the most technically advanced products in the ECM stack -- as it is likely that just for once, the right vendor may be able to do more for you than you think.

Here's why.....ECM systems can be scalable or they can fail to scale well. They can have modular architectures that allow you to simply add more elements as required, rather than multiply the entire system as things expand. They can be scalable in that they have built in high availability, automatic failover support, run on enterprise grade application servers and databases. They can be scalable because they have been tested and proven to handle very high volumes (hundreds of millions of documents) in the repository and/or tested and proven to handle very high throughput rates (tens of thousands per hour or minute). There are many ways in which an ECM system can scale or not. But the biggest element determining whether the system can scale is your usage of it.

Consider that some users have many files (images/CAD files etc) that are a GB or larger in size, by contrast another may have an average file size in the small kb's (xml fragments for example). One user may handle a very small number of highly complex, large, ever-changing virtual documents, while another one a very large volume of static transactional images. Some firms want to centralize their ECM system and allow access to remote users via the web, others will distribute the architecture widely to combat latency issues.

In other words.....there are as many ways to scale an ECM system as there are to use an ECM system -- and no vendor out there has a monopoly on scalability. For where a SharePoint would be a good fit, a Documentum 6.5 may not, and vice-versa.  Where an Alfresco may scale perfectly a better fit in another instance may be an Objective. Additionally it's always worth remembering that the ECM system is only as good as the operating system, database, application server, storage hardware, and the network that it runs on

The key of course as always is to fully understand your needs first, then match those needs against the capabilities of the products currently available, alongside your own architectural environment. And though it can be argued that some systems are more scalable than others, remember that every vendor will claim their product is scalable, you have to ask yourself "what does scalable mean to me?" And then test their claims accordingly.

But guess what? Hades has apparently frozen over, because according to Microsoft's Scott Guthrie, "later this year" Microsoft will begin providing 24/7 PSS support for jQuery, the popular open-source JavaScript library.

Microsoft's seemingly unusual move here stems from its recent decision to bundle jQuery (unmodified, not a forked version) with Visual Studio as part of Redmond's official development platform. "Going forward we'll use jQuery as one of the libraries used to implement higher-level controls in the ASP.NET AJAX Control Toolkit, as well as to implement new Ajax server-side helper methods for ASP.NET MVC," says Guthrie.

This is certainly welcome news for the AJAX world (which owes its existence to Microsoft, who introduced the XMLHttpRequest object in Internet Explorer 5.0, back in 1999). Libraries like Dojo and jQuery represent a kind of programmatic Switzerland for the AJAX world, shielding programmers from disparate browser behaviors that otherwise tend to  make AJAX programming problematic for the non-ninja. Microsoft could easily break Dojo, jQuery, and the rest of AJAX-kind if it were to make (further) unwelcome changes in the way IE supports things like DOM and XMLHttpRequest. The fact that Redmond is on board with jQuery means the status quo will probably be preserved. Or at least, that's the signal it sends.

What will be interesting to see is whether Microsoft begins bundling (and providing 24/7 support for) other open-source products... and keeps its promise not to fork people's code. Is jQuery the beginning of a trend? Or the beginning of the end? We should know more in a few months.

In the meantime, perhaps the dearth of Ajax controls that we cited in SharePoint Report will be addressed sooner rather than later.

The discussion ranged widely from Social Software, hosted content management, process integration (which unfortunately got short shrift), and whether Google really captures the "wisdom of the crowds." You can listen to and download the archive here (registration required).

There's much more to say about the topic of Web CMS. For more structured education, you might want to check out our Fundamentals of Web Content Management Technology online course.

You can perhaps reduce your pain by reading this nifty little white paper, "Content migration: options and strategies," by James Robertson of StepTwo Designs. It's a wonderfully concise survey of your likely toothaches and options for dealing with them.

James is not optimistic about outsourcing the migration project, but as others have pointed out, staffing depends on how you organize the effort, and there is potentially a role for temporary help.

You'll also want to pay close attention to the question of metadata. Oftentimes enterprises implement a new system in order to employ tag intelligence for publishing and navigation. Someone knowledgeable needs to add all those tags -- at least as part of the final migration QA process. Like transforming the content itself, you'll find automated classification tools a mixed bag at best.

Everyone can agree though, that the more attention you pay to regularly cleaning up your content beforehand, the more likely this particular dentist visit will prove less painful.

In recent years Quark has lost ground to Adobe InDesign. There are many reasons for that, but from our perspective (XML & Component Content Management), Quark simply did not handle XML very well, and InDesign was more capable in that area. Quark began to signal an interest in XML when they announced the hiring of their new President and CEO, Ray Schiavone, formerly President and CEO of Arbortext, one of the frontrunners in XML-based authoring and publishing products. Schiavone brought a considerable amount of knowledge about XML to Quark and quietly hired a number of former employees of Arbortext that had left after its acquisition by PTC.

Quark more strongly positioned themselves in the XML multichannel publishing world with the launch of their Quark Dynamic Publishing Solution (DPS) in March of this year. DPS uses Quark Transformation Engine, essentially an XML rules-based engine, to convert content coming in from many sources to XML then renders it to multiple channels.

The acquisition of In.vision now takes the XML publishing process back to the content contributor -- Word of course being a ubiquitous authoring tool. While some would argue that QuarkXPress is an authoring tool, it is really oriented towards designers - few content contributors would ever want to work in Quark directly.

What does Quark gets out of the acquisition?

• Integrated XML-based content contributor software, making dynamic multichannel publishing accessible to broader areas of the enterprise
• Expertise and functionality in SPL (Pharmaceutical XML standard) and DITA (fastest growing XML standard)

What does In.vision get out of the acquisition?

• Global sales force
• Access to broader opportunities for the use of its products

But what does the customer get out of this? Well, In.vision and Quark have been working together as partners for a number of months, with some hand-offs to show for it. But the integration is not complete. For example, you can't just say "publish to DPS" from Xpress Author. DPS is treated much like a call to the DITA Open Toolkit. Round-tripping from XML to design to XML is possible, but not productized yet.

In the long run, customers may see some benefits:

• Access to XML-based publishing software that allows not just simple layout, but full camera-ready layout
• More DITA-based publishing for the enterprise

This acquisition moves In.vision from a small XML solutions company into a much larger realm, and this allows Quark to move closer to XML-based enterprise dynamic publishing. But full integration will take time. We'll keep watching...

As you might expect, MOI portal product managers sent us testy responses. Suggesting a portal product is less than "fully SOA-enabled" evidently touches a raw nerve with vendors. We replied in turn that savvy customers believe SOA is more about the flexibility and opportunities that loose coupling affords, and less about, say, available WSDL files.

Thankfully, now we can just point them to this handy posting by ZDNet blogger Joe McKendrick, "Ten ways to tell it's not SOA." (Hat-tip to Dion Hinchcliffe.) In particular, check out #8, and this commenter's useful extension of the notion of "platform."

Portals can indeed play an important role in your SOA strategy, but only when they don't make you lock in to other proprietary platforms.

Adobe is to be commended for making good on its commitment (announced in January of 2007) to turn the PDF format over to an independent standards body. Everybody benefits from this move. Adobe no longer has to bear the burden of maintaining single-handedly what has grown to become a breathtakingly elaborate format specification (over 1300 pages long), and the PDF developer community no longer has to wonder whether the format will forever remain quasi-proprietary.

Adobe needs to do the same thing now with XMP (the eXtensible Metadata Platform), the XML metadata format for images (and other asset types). As readers of our Digital & Media Asset Management Report 2008 already know, XMP is seeing widespread use in the DAM and MAM spaces (and getting more popular by the day). It is supported by virtually all Adobe products, and is an integral part of many subvariants of PDF (such as PDF/A), some of which have been ISO standards for years, ironically.

XMP has been under Adobe's control since it made its first appearance in 2001 (as part of the Acrobat 5 release). It's an important standard, one that needs to evolve quickly, in response to community needs and under community direction. (The last revision of the XMP standard was published in 2005.) Adobe is pushing the XMP standard ... at Adobe's pace and in ways that benefit Adobe. (The parallels with PDF are numerous and obvious.) There are lingering technical issues waiting to be solved, however. Issues whose solutions shouldn't have to be dependent on Adobe's needs only.

Let's cut to the chase. If Adobe wants to demonstrate its commitment to openness, it should do for XMP what it has already done for PDF: Put it in the hands of a legitimate standards body. Right now it's open in name only.

With any expanding technology there are bound to be "growing pains," and this is certainly true of DAM. In talking to vendor CEOs and CTOs, their customers, consultants, developers, fellow analysts, and other cognoscenti at the Henry Stewart conference, I heard certain concerns raised over and over again. I'll summarize the major ones quickly:

Silo proliferation: Many large enterprises have gotten to the point where multiple media repositories are being supported internally for multiple uses by multiple groups. Consolidating assets across a balkanized DAM landscape is often difficult for a variety of reasons. The challenge is to unify the media cloud with some sort of federation technology.

Media sharing across geographies: An organization headquartered in London has artists in Paris, editors in Montreal, and videographers in New York. How do the various offices collaborate on the processing of shared resources (including very large video files), without unacceptable latencies or bandwidth exhaustion?

Metadata handling: Which files, under what circumstances, should have XMP metadata embedded in them as opposed to being passed separately in a sidecar payload? How do you apply access control to metadata at the attribute or element level? How can you secure metadata against tampering (and detect tampering when it occurs)? How can you encrypt metadata so that unauthorized individuals who gain access to an asset can't see the metadata? If an asset with embedded metadata gets passed back and forth between DAMs, how do you keep one system from overwriting the metadata created by the other? (Ingestion rules may cause collisions.) These are just some of the metadata-related issues that "enterprise DAM" customers are struggling with.

Integration with enterprise systems: The typical DAM product was not designed with interoperability in mind and represents "yet another proprietary silo" in an IT environment. To address this, most vendors have added Web Service APIs to their DAM products. But as Jason Bright (founder and CEO of MediaBeacon) points out, all this does is open up a few peepholes into what's basically still a crazy-quilt of vendor-specific API methods. It doesn't really solve the problem.

Systems take too long to implement: Enterprise DAM projects are complex, expensive, and risky, typically involving a "cast of thousands" (many stakeholders), with a high potential for paralysis by analysis. Customers as well as vendors are desperate to improve the "time-to-value" proposition. This may account, in part, for the recent trend toward SaaS-based DAM. (North Plains Systems announced its entry into the SaaS fold at the Henry Stewart show this week.) Nevertheless, SaaS isn't for everyone, and DAM "in the large" requires serious research and advance planning, regardless of supplier model.

Of course, I should point out that you can shorten your research time considerably with the aid of The Digital & Media Asset Management Report 2008, our 275-page guide to the DAM market, containing no-nonsense evaluations of DAM and MAM products from 18 established vendors. (You can see a free online sample here.)

The challenges around Digital Asset Management are daunting and grow by the day. But the same can be said of the attendant opportunities.