Enterprises frequently inquire about what format to employ when archiving electronic documents. There are two competing formats for archiving electronic documents: TIFF (Tagged Image File Format) and PDF/A (Portable Document Format - Archival). The TIFF format is the most widely used globally and pre-dates the PDF/A format. However, the PDF/A format has some very distinct advantages and therefore will continue to grow; it could potentially become more popular than the TIFF format in the future.

ECM research stream subscribers can download the briefing here.

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.

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. 

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.

In addition to this, today we reached something of a milestone with more than 4000 people coming to download the ECM Maturity Model, a truly remarkable figure when you stop to think about it. The decision to make the original model completely open source and free was definitely the right one, as public and private sector alike have been able to simply download the free PDF without charge or obstacle, and they have definitely done in style!

All of us here at Real Story Group have been practitioners in our own right prior to becoming analysts, and our work is centered solely on helping buyers and end users so the maturity model makes perfect sense. ECM is complex and bewildering at times, and we have seen an enormous need for a tool that quickly helps you get a grip on where you are now and where you need to go in the future.

Progressing the model further remains a challenge though. We have not always be great at following up with the community as we would have liked. For those willing to roll up their sleeves and help, we do welcome you. Frankly the model is not going to progress much further by our efforts alone. That being said, it's in a pretty good state at the moment, and compared to others out there we can be fairly bold in stating that we believe it to be the deepest and most comprehensive available, and we plan to keep it that way - and keep it free.

So, with your help, a more comprehensive Version 3.0 update will come in time. But for now we will have a little celebration at the milestone, and look forward to hearing more of your stories and feedback regarding your use of the model with anticipation.

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.

Possibly the highlight discussion related to a major university considering a move from LiveLink to SharePoint. Senior management are convinced it will be a simple move and very cost effective, while others have their doubts, on the grounds that 10 years of customization and integration may make the migration phase alone an extraordinarily expensive challenge. I think they may be right...

So, tonight a drive from the northwest to to Birmingham, potentially traffic hell -- but with yet another interesting venue at the end of the drive, the Motorcycle Museum.

I love to hear about what enterprise customers are up to, what's working, what isn't, and just generally sharing thoughts and ideas. So don't be shy -- come along and say hello!

In the context of the debate around a new U.S. Federal government OMB policy on the use of persistent cookies, as well as other national governments' interest in enabling site visitors to opt out of web analytics tracking, Google's stated goal is to make opting-out "easier."  The company has responded by developing a downloadable browser plug-in that disables Google Analytics data collection from all sites using Google Analytics.

Why is downloading a plug-in considered any easier than disabling cookies from within your browser options? Or adding websites to your exclusion lists? 

I can understand why some people may want to opt out -- especially for particular websites -- but it's important to understand that Google has selected the "nuclear" option here in lieu of using its market authority to promote a more modest, site-specific approach. (Competitor Omniture, now part of Adobe, provides a site-specific opt-out service, but doesn't promote it heavily.)  Adopted widely, the nuclear option will add to the myriad difficulties that already compromise web analytics accuracy. The impact will be magnified if Google's approach gets endorsed through the new Federal cookie policy and other government policies.

To be clear: I understand reasonable privacy concerns.  My alternative would be to provide site visitors with the option to use their browser to opt out of tracking from the specific website they are visiting, or opt out of all tracking from the particular web analytics solution, but not automatically default to the latter, as Google has done.

Why would Google promote the all-encompassing opt out? After all, it's the biggest web analytics service provider in the world by a large margin.  Global opt-outs hurt its customers.  Except that its customers don't pay anything for the service, whereas government goodwill is critical to Google's success in many other lucrative areas.  For Google Analytics customers, it's just another reminder: there's no free lunch.  

In essence CMIS allows different document management systems to interoperate at the repository level. So for example if you have a legacy system or two, or have plans to sunset a previous document management investment, you may be able to utilize CMIS to help with the migration of documents or to simply allow the old system to remain running, with documents at least accessible via the new system.

CMIS has the backing of most of the leading vendors in the space, and most have CMIS adapters available or in development. Any new system you buy should be CMIS compliant -- or on a sure path to compliance.  Remember that your new system will itself become a legacy system one day, and it may well be beneficial to link it to other repositories at a future date. 

There are much more complex, rich and impressive ways to integrate ECM systems together, and at times there is a need to leverage those methods;CMIS itself is no more than a base line.

For example CMIS is not a process interoperability standard, so don't assume it will give you business-logic integration; also, the first draft of the spec necessarily focuses on basic repository operations and not more advanced services, which may or may not come in subsequent version.  So CMIS is not a complete panacea. 

Nevertheless, it's a standard of more importance to enterprises than it is to vendors, who rather like the idea of locking you into their way of doing things.  Hence my enthusiastic encouragement to you to include CMIS support as a requirement on any future ECM or Document Management RFP.

In other words, it's been useful -- if something of a hidden gem.

Click to enlarge

Here at the Real Story Group we have also used it with our customers. As an example, see the picture above that shows how we applied it to help track the progress of a client over the course of a year.

We found that this type of visualization is a great way to quickly spot which areas need maximum attention and  you can then easily prioritize your efforts.

Do you have any experiences with the model to share? We'd love to know your story and/or any feedback. Some anecdotal feedback we have received has been quite amazing, with some of the world's largest public organizations making use of it. And that is the whole point of us releasing it under community commons:  You can adapt it and adopt it, you can do what you will.

As my colleague, Jarrod mentioned in his post, we are working presently to update the model, incorporating community feedback. Truth be told we are rather overdue here, but it a voluntary effort and we have had other fish to fry, such as launching the Real Story Group!

Going forward, we also plan to add some tool-kits to the model. The tool-kits will include questionnaires and templates that provide you with a starting point to translate the model theory into practice. But we welcome your participation to make this a truly community driven initiative. So, watch this space -- and let us know your experiences with the ECM3 Maturity Model.

• 11,000+ unique visitors to ECM3.org
• 3,300+ downloaders of the model
• Some exciting stories of people sharing their real-life experiences using the model (we will be sharing our own stories in some subsequent blog entries)

We know that version 1.1 of the model is long overdue, but we've been collecting community feedback and will be working to publish a "dot release" in the coming weeks. From what we've seen so far, no major changes will be needed, just some minor tweaks here and there. However, if you feel inspired to add to and expand the model let us know, as we would love to see version 1.2 and even 2.0 at some future point.

Please continue to send your suggestions, comments, and examples of how you are using the model. Thanks for all of your help in creating something that is making a real difference in the industry, and do remember this is true open commons. Make use of it, it's yours!

To quote:

Workflow services can help minimize the cost and time required to coordinate common approval processes -- but only if the service does what you want it to do, and users don't "work around" the system....

Subscribers to our WCM and DAM research streams can download the workflow paper here.

The first one, "Using RFIs in the Procurement Process, explains potential benefits (including, yes, time savings) of employing Requests for Information as a preliminary step in your technology selection process. To quote:

With most prospective technology buyers, great effort is normally expended on an RFP process at the cost of the RFI. In fact, there often is no RFI, which is backward thinking; the purpose of an RFI is to gather information so that you can make better decisions. It is also a key tool for early elimination of those suppliers that cannot or should not be working with you.

The second paper, "Making Sense of Software Licensing," coaches you how to obtain the best deal, especially from larger, platform vendors. To quote:

We have seen up to 90 percent reductions in actual pricing versus list prices. Although these extremes are uncommon, 25–50 percent reductions are not unusual.

Our research subscribers can comment or ask questions directly on the page after logging in. Look forward to hearing from you.

While some web managers in the Federal Government might wish to use Google Analytics, historically that solution has been more hamstrung than others because of Google's use of persistent cookies.

If you practice web analytics in the Federal government you know that persistent cookies are verboten by order of OMB -- unless you get approval from the director of your agency. In the real world of agency politics, that's like reaching the Mt. Everest summit. While other analytics solutions (such as Omniture and WebTrends) will certainly provide more accurate visitor data if they use persistent cookies, they aren't dependent on persistent cookies for data collection.

While Washington has seen some debate about loosening up the persistent cookie restriction, there has been no public movement since a flurry of activity and public comment during the summer of 2009. I expect that this will get resolved at some point before the end of 2010, but no one knows for sure.

Meanwhile, Google has issued a work-around.  According to the company, you can virtually eliminate the persistence in the GA cookie by using built-in tracking code functions to set the cookie time out to "0" in the two parameters below: 

Of course, this raises an interesting existential question: is a persistent cookie with time-to-live set to zero still a persistent cookie? Functionally, it becomes a session cookie, expiring when the browser closes.

Federal web managers have a more practical question: Why bother approving Google Analytics unless there was the possibility of being able to use it?  As for whether a non-persisting persistent cookie is acceptable to OMB...well, we'll have to await guidance on that.

You'll find no lack of answers.  My colleague Alan argues persuasively that ECM is most useful as a term to describe the biggest platform vendor offerings. Industry association AIIM defines ECM as "...strategies, methods and tools used to capture, manage, store, preserve, and deliver content and documents..."  AIIM also held a clever contest to define ECM, where the winning submission suggested it was about laundering and generally taking care of your documents as if they were your clothes.  The discussion continues, and there are no lack of definitions.

I suspect the emphasis on ECM definitions stems from a disconnect. We have this all-encompassing term -- Enterprise Content Management -- that doesn't reflect how marketplaces and real-life projects actually break out into very specific categories and disciplines, like Document Management, Web Content Management, Digital Asset Management, Information Architecture, E-discovery, Process Improvement, and so on.

I think there's actually a deeper question that's looking for an answer here. Let's strip out "enterprise" and simply ask: What is Content Management?

My definition is...

Content Management is the management of content.

Now, at this point you might be feeling ripped off, because of course that definition is a tautology. But please bear with me.

The goal in implementing content technologies and related processes is really to apply management principles to content. Unfortunately, "management" too frequently gets conflated with "control." This is a common thread through many definitions of ECM in particular: "controlling unstructured information." Yet, management is much more than control. Good management also features enablement and empowerment. Management implies rules, but also supports creativity -- often in different amounts in different contexts.

By thinking in terms of management objectives, we liberate ourselves from definitions that are too narrow, prescriptive, or technical, and instead focus on business outcomes. For example, it is fashionable now to talk about distinguishing "managed" and "unmanaged" content. I think this is a mistake. After all, the minute you decide to delete some seemingly unmanaged content -- such as a comment on your blog -- you have made a management decision. If you leave MySites turned on in your SharePoint installation, enabling individual employees to provision new team spaces whenever they see fit, you have made a management decision.

What I am really urging you to consider is a spectrum of control and enablement that is business context-specific.

There are many precedents for this. After all, we take it for granted that the enterprise will manage human resources, and that the management of those resources will encompass both control and enablement (again to varying degrees, depending on the context). Ditto for financial management.

As a practical matter, the management of content means first of all inventorying and prioritizing your existing content stores, before settling on technologies. Ask yourself in each case, what does it mean to manage this information? Don't be surprised if management means varying the way you exercise control, enablement, rules, and empowerment across different contexts.

Then explore suitable technologies. You may need Document Management systems with defined workflows (control) -- while supporting individual discretion at key points (enablement). You may also need free-form Collaboration software (enablement) -- as long as it comes with an auditable archive (control).

When you get to that point, let us know if we can help you.

From the introduction:

An important, yet rarely acknowledged architectural and product development shift has transpired over the past couple of years in the content technology marketplaces we cover. The debate has shifted from "Suite vs. Best of Breed" to "Platform vs. Product." This is partly a natural evolution in vendor marketing as technologies and marketplaces mature. Yet this shift also has profound implications for you, the customer. Beyond the normal criteria of cost, functional fit, and vendor fit, you need to assess a tool's position on the Platform-Product continuum against internal needs and capabilities.

The three-page briefing offers five specific steps your enterprise can take today to make sure you make the best technology choices for near-term and long-term success. To subscribe to our research so that you can receive advisories like this, contact us here.

XAM (eXtensible Access Method) is a specification developed by SNIA (Storage Networking Industry Association), and has been around in its first version for just over a year. Its goal is simple: to ensure that content can be archived for long periods of time in a storage disk environment. At first sight you might be forgiven for thinking that this is a goal that was achieved long ago, surely if you move an item of content to a disk it will sit there for ever if need be? Well sort of, and then again no, not really. I have personal experience of working with firms that have found this out first-hand, and at a cost. In the most extreme example I can recall, a highly regulated firm had terabytes of content archived, going back over a period of many years - yet virtually all of it was inaccessible - they only kept it to prove they had it, should a regulator call and ask. Thankfully the regulator never asked to see the content retrieved and put to use, for if one had done so this particular firm would have been in very serious trouble.

The problem that firms face when required to archive content for long periods (for example 10 years or more), is that over that period of time applications change, formats change, storage technology evolves. In addition, throughout this period there is typically a need to move archived content from one location to another, to reduce costs or to increase performance (online to nearline to offline for example). What with all this going on a disconnect occurs at some point, and though the raw content data moves, the metadata and logic to access and utilize it gets lost or broken. The content, whilst taking up disk space, becomes inaccessible and unreadable.

The key reason for this is that storage disk technology was built for transactional/structured data types and as that is by definition transactional in nature, and highly structured, it is relatively simple to move it effectively from one storage location to another. Unstructured data ("content" as we like to call it) works very differently: it exists in a myriad of formats and structures, can typically be accessed only by particular applications and relates in turn to historical, retention and access data.

XAM cannot resolve all of these issues, but what it can do is provide a standardized method for storage systems (particularly those focused on long term archiving) and archive related applications (such as RM or ECM systems) to talk to one another. This ensures that at some level, if not all levels, content can move between devices over the long term and that it remains readable and accessible by any XAM compliant application.

As XAM is actively supported by all the storage vendors in today's market (at least, I am a not aware of any exceptions), it should have a good chance of success. However for this important initiative to really succeed, it requires buyers to demand that their archival applications (ECM, DAM, WCM systems etc.) also be XAM compliant, and so far the number of applications that are remains small. For this to succeed there needs to be equal weight given to both elements of the equation, storage devices and the applications. I am all for standards, just as I am all for methodologies. I am a big believer that doing something in a structured manner, at the very least, delivers consistency.

As such, I would recommend you add XAM to the list of specifications and standards you list on RFPs that go to content technology providers. An XAM-compliant product will not in an of itself resolve your archiving issues, but its at least a step in the right direction. That alone is something.

This same lifecycle mantra is promoted heavily by enterprise content management (ECM) vendors looking to get into the social computing game. But does that mean you should buy Social Software from your ECM vendor? I have my doubts. The end-goal is effective networking and collaboration, so any tools you acquire should still be measured foremost by that yardstick.

This issue rose to the fore at the E2.0 conference, where I saw brief demos of forthcoming Social Software products from ECM vendors Open Text and EMC|Documentum. Disclaimer: I only saw demos, and we'll reserve final analysis until after we can talk to customers deploying shipping software.

Open Text Social Media

Open Text was demonstrating a new product called "Social Media," still in beta, due out later this quarter. It's an internal project, led by a team within its collaboration group, but Social Media is not built off Open Text's old collab platform. In fact, it really just provides social networking, with collaboration services promised for later editions. To that extent, it felt a little thin on features. Open Text was promoting a very new -- I thought rather cosmic -- user interface (see this screenshot from Sandy Kemsley). They built the UI entirely off AJAX, which impressed me, and supposedly optimized it for speed, which if true, would be something of a differentiator in this space.

But Open Text is really touting its "candy and aspirin" approach: sweet social with an analgesic back-end. Thing is, I saw no evidence of any aspirin. In fact, I found nothing "Open Text" about it at all. For example, it does not natively use LiveLink as its repository. Social Media has its own, proprietary repository -- from which you can move or copy items to LiveLink -- exactly the same thing you can do with SharePoint libraries. I did not see any native lifecycle management tools, nor any sign of other Open Text services in which you may have already invested. It even has its own, new search engine, to add to the three others that Open Text already supports. Social Media is built in C as a free-standing server. The company says that's for speed (again, a good thing), but the architecture still feels like a one-off system.

Maybe there's more there I didn't see. Open Text can comment if so. And again, it's early days for this beta platform.

Documentum CenterStage

As an aging but venerable ECM player, Documentum is taking a bit longer to come to market. Its "CenterStage" offering remains in customer testing, and not due out for general release until later this year. But it's been a long time coming and has generated a lot of buzz in the Documentum community.

CenterStage is really a kind of hybrid: partly a new interface paradigm for multiple Documentum products, and partly a more social replacement for the company's eRoom collaboration product. CenterStage offers wikis, teamspaces, and the like, but the real "candy" here is its all-Flex rich interface. I've criticized this approach before, but unlike Documentum's Flex-based WCM client, you can actually configure the CenterStage UI via XML files. That's good, though I still don't like Flex for multifaceted enterprise applications. I'm a browser bigot. Standards and all that. But again I'll withhold further judgment until CenterStage sees real combat conditions.

On the plus side, CenterStage's various services all seem to be built off Documentum's core Content Server repository. In theory, this allows you to leverage a variety of repository services, but as always, you need to assess closely what's bound to the repository and what requires separate application services (i.e., more licenses and products). You'll want to test carefully. Still, Documentum's approach seems promising, if you're not in a hurry.

The Marketplace

Other major ECM vendors have brought Social Software products to market, but our research suggests they're not faring particularly well either. Let's review them: Oracle (thin, fragmented), Microsoft (missed the boat with SharePoint 2007, conflicted about SharePoint 2010), and IBM (nice start by re-purposing internal applications in Lotus Connections, but slow-footed and diffused since then).

You can get functionally much stronger tools from pure-play Social Software vendors, but at the cost of missing out almost completely on any information lifecycle services. Customers presently seem to prefer it that way. In a world where user adoption is king, I recognize the thinking: fire at everything, and let your search engine sort it out later. At some future point, perhaps when you go to delete an old discussion thread, you are going to have to make some real management decisions.

In the meantime, the Social Software marketplace has reached an interesting phase from an evolutionary standpoint. Some very large dinosaurs are lumbering around. You'll find a plethora of small, fragile, but adaptable mammals flitting successfully among them. Today, I think the mammals are winning. Tomorrow, meteors could strike. We'll keep watching. If you're looking for the inside story on individual solutions, please check out our evaluations.

We should be clear on the fact that purveyors of large enterprise software systems, in particular those who offer ECM, WCM, and DAM systems, are in business to sell you silos. And there's nothing inherently wrong with that. The problem comes when resources that need to be made available to multiple applications are spread across silos not built with sharing in mind. Encapsulation becomes a detriment in this case.

At a high level, there are various ways to approach the problem. One is to try to consolidate silos. Another is to build a cobweb of point integrations between silos and the applications that need access to them. Yet another is to leave silos "as is" and front them with an abstraction layer designed to hide the patchwork nature of the data infrastructure. The problem with the latter approach is that one abstraction layer seldom fits all. You can end up with a zoo of connectors between silos and abstraction layer and still not achieve your interoperability goals.

The problem becomes more acute by the day as silos proliferate and content finds its way to the edges of the network rather than to any central spot. In just a few short years, IT managers have gone from cattle ranchers to cat herders. What's a cowboy to do?

The key thing to realize, I think, is that federation and interoperability strategies, in order to be successful, require standards-based communication between participants. If silos obey certain standards around CRUD-and-query, access control, security, payload formats, and wire protocols, a unifying abstraction layer can be more like a bus or backplane, and less like one of those spaghetti-wire switchboards you see in 1940s movies.

In an ideal world, no one would ever have to know or care how many silos an organization has, as long as they're connected in a transparent manner, so that applications (and users) can have a natural-feeling logical view into what looks like a purpose-built single silo (appropriate to the app in question). One gets to this point only when silos and applications start speaking the same core languages, protocols, and data exchange formats. CMIS is an example of an attempt to execute on this philosophy -- an attempt to enable interoperability of siloware via a meta-protocol built atop standards. This is a good thing. The alternative is anarchy.

If history has taught us anything, it's that silos aren't going away. Marketing appeals built around silo-busting are therefore not really credible. Silos are, in fact, good and necessary, or we wouldn't have them. It's how you wrap your arms around them that counts.

 I have to say, the idea of government web sites using Google Analytics makes me a bit uneasy from a privacy perspective. I just can't get comfortable with the idea of the government passing data to GA so Google can come up with new ways to advertise and market.  

There's a lot of activity going on these days around the subject of web analytics and government as it relates to the Obama Administration Open Government initiative and the release of the Web Analytics Association Report on Government and Web Analytics.

We don't usually think of the public sector as a hotbed of web analytics activity, but change has been long overdue. It's great to see that change may be on the way. Hopefully it will be sorted out so that there is a reasonable balance between analytics value and personal privacy protection.

Would you like to suggest debate topics? Already circling in my head:

• Is "Enterprise 2.0" more meaningful than "Social Software"?
• Blogging is passé -- vive micro-blogging?
• Can social computing consistently bring real ROI?
• Should community managers have to worry about information lifecycle management?
• Are social content ratings really helpful ?
• Tools: suite or best of breed?
• Should your website/intranet have a community or be a community?
• Do you really need an enterprise micro-blogging tool when we have Twitter?

Any feedback on these? Some better than others? What to drop and add? Reply below, or you can continue this discussion on Facebook or LinkedIn.

Many thanks. Hope to see you there...

The White House blog is inviting comment on how a new cookie policy should be shaped: http://www.whitehouse.gov/blog/Enhancing-Online-Citizen-Participation-Through-Policy/

I've posted my comments on the site and have reprinted them on:http://wam.typepad.com/wam/2009/06/us-federal-government-cookie-policy-under-review.html

My recommendations for a new policy are fairly straightforward:

• Allow the use of first party, persistent cookies for Web site measurement.
• Prominently disclose how Web site measurement is used and how the data is collected and analyzed.
• Provide instructions for how users may delete persistent cookies from their browser settings.
• Combination of PII and unique visitor ID (persistent cookie ID) will not be used for analysis.

What do you think? Is this enough? Not enough? I'm all for privacy protection as those of you who've read the commentary I wrote with Tony: www.cmswatch.com/Feature/191-Data-Ownership

However, I would advocate a balance between privacy and analysis, so that Federal web managers can provide more effective sites.

What's your take?

A good case in point is MediaBeacon, whose R3volution 3.0 product has such a convincingly Adobe-like facade that I mistook it for Flex technology the first time I saw it. But it's actually straight HTML, CSS, and JavaScript.

MediaBeacon made a conscious decision to avoid Flex, not so much for technology reasons per se, but for larger concerns around Web standards. The company's CTO, Jason Bright, explains it this way: "Flex, like ActiveX, Silverlight, and Java Applets before them are, in a sense, replacements to the browser. Each replaces the web browser in a proprietary way. While I love Flex as a technology, I do not think it is a good strategic decision to throw out the traditional browser for a new client-server model no matter how attractive."

Part of the issue, says Bright, is the fact that Flash requires a plug-in -- it's not a browser-native runtime (any more than Java is). He adds: "Things like AJAX and HTML, driven by powerful libraries like Google Web Toolkit, allow apps to have just as much power as Flex, without replacing the web browser's native rendering capabilities." Plug-in technologies, Bright seems to be suggesting, do not steer the direction of web development. And historically, that's certainly been true.

But by the same token, web-apps that run inside the firewall (WCM and DAM apps in particular) are not necessarily subject to the same constraints as public-facing web-apps. An enterprise can choose to standardize on (or mandate use of) Java -- and Java applet technology -- or not. The same is true for Flex. Inside the enterprise, the rules are different.

Just bear in mind that the vendors who are switching to Flex are taking a gamble, and if you go that way, you're taking the same gamble. Plain old AJAX and HTML, right now, are the "tried-and-true" technologies of the browser-client world, and likely will be for a while. Bear that in mind as you go shopping for "new, improved" WCM and DAM systems.