At the NAB show, futurist Marina Gorbis talked about the seismic shifts taking place in the world of content creation and used examples of installation art pieces to illustrate trends like algorithmic content and non-human content creation.

Exhibit 1 is what I call "real-time fashion". In 1998, artist Nancy Paterson created a stock market skirt . Economists say there is a relationship between the stock market and fashion fluctuations. If the market is doing well, the skirt length reduces and if the markets are floundering, the length increases. The installation art consists of the mannequin Judy, a computer, several display monitors, and a mechanical system of motors, cables and pulleys. Some Perl scripts analyzed online stock quotes, and the skirt length adjusted accordingly.

"Painting the town LED" is Exhibit 2. In Erik Krikortz's art project Emotional Cities, the aggregated responses to "How are you feeling today" are used to light up a city's skyscrapers and serve to illumine the city's zeitgeist. You'll recognize the more prosaic version of this as "sentiment analysis" which is increasingly being added to marketers' tool kit.

Not mentioned by Gorbis but Exhibit 3 is "Writing on the wall". The Think Exhibition at New York's Lincoln Center to commemorate IBM's centenary consisted of a 123 feet long data visualization wall, which displayed dynamic patterns based on data feeds from the city's traffic, pollution, and sunshine indicators. The art on display was not a Da Vinci, but perhaps a Fibonacci.

Conventional notions of what constitutes art get challenged in these explorations. Similarly in an age of convergence, boundaries blur and traditional categorizations like platforms and channels can crumble.

Metadata so far has been operating in a linear, unidimensional fashion and has been helping make only basic connections and discovery for us. Are our information models, sense-making apparatus, and systems (and yes, even our own evaluations) ready for this brave beautiful world of multi-dimensional interconnectedness? What do we need to get ready?

Welcome your comments below...

Those are important topics, but I think an even bigger to-do for enterprises is to bring the right skill sets to bear. One key skill set to engage here is enterprise architecture.

If you examine the individual applications and platforms that employees access to complete work every day, you end up charting myriad of different systems in the typical enterprise. Some of these may be loosely aggregated within a portal, while others may not. The digital workplace concept, though, helpfully turns the table around by looking at it from the standpoint of the employee, rather than the enterprise. There's clearly an opportunity to apply well-known user experience methodologies -- such as User Centered Design (UCD) -- to improve your colleagues' effectiveness here.

But as you dig deeper into the employee digital experience, you'll discover more than just clunky, freestanding applications. You'll find:

• Information and process flows that span multiple systems
• Siloed data and content
• COTS vendors pushing their own separate mobile apps
• Diverse security and information access needs

Cataloging and understanding the business value of all these systems is the job of an enterprise architect. If you are trying to transform your digital workplace, then you'd do well to engage your enterprise architecture team -- you have one, right? -- in reconstructing the pieces into a greater whole.

Just remember that the point is not to re-arrange boxes and arrows to work your way forward from back-end systems to employees, but rather to re-arrange what happens on your colleagues' screens by working your way backwards. Is it too simple to say, UCD + EA = New Digital Workplace ?

If you're an enterprise architect tackling some of these issues, I'd love to hear from you.

As I mentioned in my recent blog post, the big guns were present and correct in logo form. Oracle, EMC, and IBM cropped up regularly with reference to infrastructure, alongside Quid and Connexcia building on top of Lucene. A great deal of time was spent discussing relational databases versuss NoSQL schema-less data structures and Hadoop / MapReduce clusters.

So much so, that you'd get the impression that the business case for Big Data was a done deal.

In the details of the discussion was a clue: Big Data was defined as "workloads that we just couldn't handle before." Big Data's three-Vs of variety, volume and velocity certainly provide a framework around which the IT- literate can debate. However, it wasn't until the discussion turned to practical business scenarios in which this horsepower could be utilized that things got really interesting.

Here's a selection of some viewpoints expressed in the room:

• The longer and louder that we discuss Big Data, the more the public are aware of the volumes of data that are stored about them; therefore privacy becomes paramount
   
• Today, the easiest way to justify a business case for a Big Data project is to fold the effort into a storage consolidation program, rather than tout the benefits of data analysis, (even though that analysis is potentially hugely valuable for the business)
   
• Data quality and source management remain big open questions, especially with extra-organizational information. Pre-existing "data quality" tools can address structured data integrity, but when you bring in, say, external social media data, these tools may not suffice

Valuable as this debate was -- especially to an audience of architects and information nerds (like me) -- it did make a  comment on the subject resonate in my head, that for many at this stage in its lifespan Big Data is "...a clever toolset desperately looking for a purpose..."

Whilst some organizations with well-considered information architectures may be able to jump right in and find real benefits right away, for many (or most) others, Big Data remains at least at present, puzzlingly opaque.

So don't feel bad if you don't have a strategy.  It's a work in progress for everyone.

"So, Uncle Matt, what do you remember most about 2012? Was it the London Olympics?"

"Well my impertinent nephew, 2012 was in fact the year we learned about 'Big Data'."

" 'Big' Data? Wasn't there much data around before 2012?"

"Oh there was loads of it. It was just until then, we'd not been told to notice it. Not until an unholy alliance of analysts and software and storage companies like IBM and EMC began to point out that it was really, exciting. And coincidentally enough, it turns out they had all sorts of solutions to manage all this data."

"Wow that was lucky. So, did they work ?"

"No of course not. But then again they were the same tools we'd been using for ages, and they'd never worked then either."

This imagined interchange echoes some of the conversations we've been having within RSG about the Enterprise Search market. For much like "Big Data," Enterprise Search has been around a long while, but has never really fulfilled its promise. And Enterprise Search -- just like Big Data -- is due for a resurgence in the market, to get cast as something new and wonderful, disregarding the fact that it's not new and didn't work the first time around.

Consider the following:

• The term "Search" itself provides a negative connotation as it tells you there is a problem, that stuff has been lost. Just as Big Data accurately describes a lot of "stuff" --  much of which we have no idea how it got there, and the bulk of which is likely junk.
   
• A history of overpromising that Search will magically fix everything, when it patently won't. Just as slicing and dicing of data at ever more granular points will somehow give our businesses ever more accurate insights.
   
• The myth that search engines can extract gold from junk has long since been debunked, just as anyone who has ever tried running data warehouses full of dirty data can attest: it just doesn't work.



• Bundled search with business applications is "good enough" for most people (particularly as expectations are low), as is most basic BI (Business Intelligence) reporting more than enough for most business folk.
   
• Web searching is a totally different challenge to enterprise searching, but few seem to understand that differentiation. Just as mining big data is a totally different paradigm from analyzing a specific local dataset.

From recent conversations with subscription customers, it's clear that the underlying business problems that led to so many big search projects are still there. Burned by their previous experiences with big search projects, however, organizations are learning to bite off ever smaller chunks of these issues. If anything the Enterprise Search market has stalled or even gone backwards these last few years.

Fortunately the crazy hype around Big Data has yet to infect the Enterprise Search market, but following Oracle's acquisition of Endeca and HP's crazy year in which they acquired Autonomy, there is undoubtedly a vacuum in the heart of the Enterprise Search market ready to be filled.

But is it going to be yet more hype and unfulfilled promises that flood into that gap, or will we move on and finally start to deliver on the promise?  What do you think?

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

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

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

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

As corporate requirements for search and content management have intensified, so has the demand for tools that help organizations create, administer, and publish semantic structures.

You the customer can choose from among several fully-featured taxonomy management tools, yet each vendor has tackled the problem of managing vocabularies from a different angle. So how do you figure out which one is right for your context?

I've just authored an advisory paper that evaluates a collection of leading enterprise-level taxonomy management tools head to head:
·    Sempahore Ontology Manager (Smartlogic)
·    Synaptica
·    Data Harmony Thesaurus Master
·    TopBraid Enterprise Vocabulary Net (TopQuadrant)
·    Intelligent Topic Manager (Mondeca)

Learn about each tool's key strengths and weaknesses, add-on modules available, and SharePoint integration capabilities. Find out which vendors excel in multilingual vocabularies, ontologies, governance, and cross-mapping.

Subscribers to the RSG Enterprise Search stream have automatic access to the evaluations.  Others can purchase it online here.

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

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

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

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

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

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

My advice: don't buy into this hype.

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

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

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

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

Of course, there's no shortage of SharePoint-related events right now, but we've sensed a need for something different, something to add real value to those entrusted with evaluating, buying, and managing SharePoint systems.  In short, an event for those of you looking to develop a SharePoint strategy.

Hence the agenda will critically examine when to use SharePoint, and when not, and most importantly how to increase your chances of success in broad and large deployments.

The summit format is a mix of structured discussions with your industry peers, along with practical advice from recognized -- yet approachable -- experts in an informal setting.

When we plan a summit like this, we think about what you the customer wants: meaty sessions devoid of hype, cheerleading, or bias -- with an emphasis on open debate and exploration. Meeting in a fabulous venue doesn't hurt either.

Consider sending a team to join us and your fellow SharePoint travelers.  Jarrod and I are looking forward to meeting you in person, and giving you the opportunity to get "The Real Story" on SharePoint.

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.

1. "What does an information manager do?"
2. " How does she do it?"

And then proceeds to answer them both.

The book is called TIMAF Information Management Best Practices Vol. 1. I recommend it.

The longer I'm in this business, the more I see the common problems we all face as -- at their core -- information management challenges. The problem with the term "Information Management," though, is that it feels very abstract and doesn't seem immediately relevant to the workaday struggles of the typical website or data warehouse manager. Consequently it's a term that gets bandied about in academia, but not so much within the modern enterprise.

I think this book -- edited by Bob Boiko and Erik Hartman -- will help change that. It's a preliminary collection of best practices that's more specific and detailed than you'd see in the trade press, but more actionable and case-oriented than you'd see in an academic treatise (the authors are all practitioners and consultants). It's also mercifully vendor-free. [Disclosure: two of my colleagues (Alan and Apoorv) contributed chapters.]

If I had any criticism it would be that the book perhaps over-emphasizes content (versus data) in general, and structured content in particular -- a faint shortcoming that's more than redeemed by the step-by-step approach taken in most of the chapters.

As you prepare for a new year, consider going back to the basics, and check out this book.

One of my pet peeves about both mobile and social is the amount of hype surrounding the topics. There's no denying they're of huge importance to any enterprise right now, but the buzz can be deafening. However, conference organizer Erik Hartman has created a great program, with a nice mix of theory, tools, and a lot of practical use cases. I think attendees will get many useful ideas out of it.

I'll be talking about mobile delivery and social engagement through the tools and systems you may already have (such as a web content management system). Theresa will focus on digital assets -- getting video, audio, and brand assets to the mobile web. But of course, we're not just there to talk -- the interesting bit of any event is always to listen. (Fortunately, about half the presentations will be in English -- so no need to learn Dutch to attend.)

So join us the 7th in Utrecht, and if you're there, come up and talk to us. As a reader of this blog, you'll receive a 200 euro discount by using the discount code RSG2010.

66KB is the metric I use to represent the average document in a typical public or private sector organization. This is not just a random guess you see, it is an educated random guess. When you take into account the regular and small documents (the tiny notes and memos) alongside the wacking great Powerpoint slides that most firms store, then 66KB turns out to be a pretty accurate average file size. Whether you use a mean, median, mode, or wild guess method to calculate, it typically comes out somewhere around 66KBs.

I find many people tend to think that the average document size is much higher than that, and in your organization it may be. But whether you employ my average number or use your own, the fact is that most documents are not individually all that big when you come to think about it. 

However, you then need take into account:

• All the changed versions
• All the duplicate copies lying around
• The copies sent via e-mail for information or review or no clear reason at all
• The drafts, the final drafts, the finals, and the final-finals

Suddenly that 66 KB file can be better calculated at around 4.12 MB. Or to put it mathematically if we take a geometrical progression of two then:

66 KB x 2 = 132 KB then 132 KB x 2 = 264 KB then 264 KB x 2 = 528 KB then 528KB x 2 = 1.03 MB then 1.03MB x 2 = 2.06 MB then 2.06 MB x 2 = 4.12 MB, and so on. It's always a little unerving how these things stack up so quickly isn't it?

Or to put it yet another way: for every 4.12 MB you have sitting on your system, it is quite possible that only 66 KB of it is of any value at all. Regardless of exactly how you do this calculation, in my experience the outcome has always been that the vast majority of what we pay to store and manage on our information management systems is complete and utter junk.

When I get briefed on new versions of software, vendors are often a bit apologetic when they can't point out some cool new features or interface updates. It's almost as if they're used to briefing people that don't really care all that much about the inner workings of a system. I find that somewhat amusing, since to us, the innards of any system represent a significant part of the whole.

Point in case is Sitecore's 6.3 release. The headline would read something like "adds support for cloud" -- more specifically, Microsoft Azure (with others to follow). Dig a little deeper, and you'll also come across a "more efficient" clustering of content management servers, the machines that provide the editorial interface.

In order to support that, Sitecore has had to do quite a lot of refactoring of the internal infrastructure. 6.3 introduces an "event queue." Basically, the server will signal events (e.g., saving a content item) to the database, and the database will sync this to other servers. This means 6.3 has a lot more flexible scaling options than previous versions. You could, for instance, install one server in the US, and one in Europe; editors would have a faster connection to the server closest to them.

However, when I hear that an "event queue" has been added into the mix, I shiver a bit.  I respect Sitecore's usually pretty thorough design and development, and would expect them to get this right. But there are plenty of things I could imagine to go wrong, from small hiccups to large stumbling blocks. I've seen those in plenty of systems that use similar queueing. The key thing here, therefore, is that we won't know until 6.3 is battle-proven in some large scale deployments.

So why is this a minor release, and not -- considering the architectural implications -- a major one? According to Sitecore, versioning is based on "impact on existing implementations," i.e., backwards compatibility. That's sensible; but in this case, don't let it fool you. Sitecore 6.3 adds a lot of potential; potential for flexible scaling, but also potential for choking. We'll be watching to see how it fares in real life scenarios.

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.

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.

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.

To give a practical example, a healthcare professional will need awareness of all the documents related to a particular patient. These documents and records are sorted and managed through their lifecycle as a "Case" even though they may reside in different locations, have different owners, other relationships, and different retention policies.  Other individuals may also need to interact with these documents for the purposes of billing or insurance. Same documents, different purpose. There may also be multiple legal and compliancy requirements to attend to.

In theory at least, Case Management provides you with the tools to pre-define and orchestrate those requirements. Permissions, rules, metadata, and processes all play a part in what can be a highly complex system. 

For some organizations, Case Management applications built from ECM platforms form the core of their business, and more will in the future. The need to better manage the massive volumes of transactional documentation is growing more acute, and Case Management will certainly play an increasingly important role. 

Yet almost more than any other scenario, Case Management demands good information governance and squeaky clean relevant data. Without it everything falls apart. The fact that so many organizations are lacking here is another key reason Case Management is not as widely deployed as it could be. 

Selecting the right software to meet your Case Management needs is difficult, since everyone claims to do it,  but very few do it well.  The nightmare scenario for a buyer of a Case Management system is to buy a vanilla ECM software system and then just bring in a .NET or Java developer. You are not only buying technical functionality you should also be buying deep and very specific domain expertise, and without the right combination of the two you can be in trouble quick.

ECM vendors such as Hyland, Objective, Open Text, EMC, Autonomy and IBM all have deep expertise and knowledge in the particular industry sectors that they design systems for (Pharma, Legal, Government, Intelligence, Healthcare, Insurance,  Law Enforcement, Retail etc). They know (mostly) what works and what does not, and they understand industry specific business processes right down to the task level. You are paying as much for that knowledge, as you are for their software.

Assuming though that you do have your document house in order, and already utilize Case Management, there are some interesting developments on the near horizon -- most notably the use of business intelligence and analytics tools to extract further value from what is already a rich information set.  Consider the possibilities of early fraud and discrepancy detection or new and emerging trend analysis from the very rich data within your documents.  BI has long been locked solely into the 20% of data that is structured in the enterprise, and is a valued tool set. But very large and clean volumes of documentation that have been given a tight structure can be mined these days too, and those documents theoretically at least, represent the other 80% of the data we deal with in business.  In fact some organizations are already starting to use tools like Cognos, Hyperion, and Business Objects in Case Management deployments, and they are liking what they see.

And remember it's our job here to ensure that technology buyers make the right decisions via the use of our research, and one of the best ways for us to do that is to continuously talk with buyers and users who are at the coalface.  So if you are an organization that is using Case Management along with some kind of BI tool, then  I would love to chat with you in confidence to hear more about what works and what does not just drop me a note and we can chat.

Ironically, it's early days for a combination of technologies that have been with us separately for many years. Yet this could prove to be a very good long term marriage.

What is common across them all is the desire to consolidate, and to gain more value from the huge volume of information sitting in documents across their units. Sometimes this is no more than a desire to find things quickly, wile in other cases the goal is to merge and integrate business process tasks with relevant and current information. In still other instances, the enterprise simply needs to reduce costs, do more with less.

Multiple repositories can come in many different forms, be they hundreds of SharePoint sites, a handful of massive ECM systems, or a combination of shared drives and Outlook folders. But they all represent the same basic problem. "I have the information I need, it's somewhere, but I can't access it or find it easily, let alone leverage its full value."

When trying to come up with an approach to improve these multiple repository situations people usually consider the following approaches:

• Migrate everything into an Über Repository
• Federate the management of the repositories in place
• Start an information governance project
• Work on Information Architecture/Taxonomy/Metadata
• Take a federated search approach to the situation
• Utilize API's and/or EAI to integrate at the back-end
• Build a portal/mashup to integrate at the front end
• Use BPM to integrate in the middle
• Go the SOA route to deliver shared ECM services

In fact there are still more approaches you could take, and the options above are not mutually exclusive, but they are the most common.

What is not so common is taking an approach that tries to address the bad practices that created these situations in the first place.  Somebody once said, "It's OK to make mistakes, but not OK to make the same mistakes repeatedly." Yet that is what so many organizations do when it comes to managing information effectively.

Rather than jumping straight into one of the options enumerated above, I would advise you to take a step back and to first consider starting every information management project with a major cleaning exercise. 

For example, if documents have not been accessed in X period of time, let's be honest, they are unlikely to be accessed ever again, and in most cases there is no legal or regulatory requirement for you to hoard dead information. So take the chance to identify deadwood data, and get rid of it, preferably by a formal disposition process, or if you must then simply move it to cheap offline storage and "archive it."  But whatever you do, work toward a situation where only active and relevant information is sitting in your silos. Move or destroy information that is not.

For many organizations such a clean out delivers more value than the rest of the project activities put together. In some cases volumes of content get reduced by 80% plus, and as a result when you are browsing, searching, or mining content you are only accessing current, relevant information.  It also makes the job of consolidating, migrating, or integrating information silos much more worthwhile. 

This should always be your starting point: clean data. Otherwise you'll spend most of your time knitting together in one way or another an awful lot of useless files.

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.

First off, it became clear quite early on that perhaps the regular news from the traditional media (newspapers and TV, but including their online presence) wasn't keeping up anymore. When the eight o'clock news actually mentioned "people on Twitter are saying..." I switched off -- I can get that real time on, well,... Twitter, following the hashtag #ashtag. Several forums kept me up-to-date with the latest news and charts from across the web, and even several blogs were better at keeping track of the latest developments. Also, I'd suggest journalists to at least take the two minutes to read the entry on Eyjafjallajökull on WikiPedia -- it doesn't look good if you know less about the volcano in Iceland than your viewers do.

But that's just the news -- if you really need the information, because you're stuck in an airport or about to leave on a planned trip, you want to know where you're going (if anywhere). Unsurprisingly, here, too, traditional communications were failing. Call centers were flooded and it was impossible to get through to airlines and airports. And many of their websites.

As first the north and west of Europe were covered in the ash clouds, then the center of the continent as well, the various sites started returning 500 "Server too busy" errors (or just no response at all). At times like these, it's immediately apparent who has contingency plans for their website and who doesn't. Some managed by putting up a low-bandwidth replacement (like, for instance, Schiphol airport did). For most of these sites, it should really have been one of the WCM requirements.

In many cases, their role was now largely delegated to Twitter (and some on Facebook), which fortunately kept going just fine. And another advantage was also very apparent -- where the web (if it's working) is still mostly "pushing out" information, Twitter and Facebook allowed interaction. Because people certainly have understanding for the disruption the volcanic ash causes -- as long as they're getting at least the sense that other people are working very hard to help them out. As long as they're getting up-to-date information, they'll be much more forgiving.

There's an excellent analysis of how various airlines responded available on SlideShare. It's the summary of an assignment for a class on Social Media for PR at St.Edwards University. I especially liked this quote: "It seems like every time I'm scheduled to discuss the role of social media in crisis communication some major crisis comes along -- usually just in time for class."

And this certainly isn't limited to commercial companies dealing with paying customers. In fact, EUROCONTROL, the European Organisation for the Safety of Air Navigation, was one of the unlikely stars of the past weeks. Their feed on Twitter shot up in popularity -- it kept up-to-date to the minute, kept going through the week-end and actively engaged with worried travelers. It put a virtual face on EUROCONTROL, which will be an unexpected reward for the normally rather anonymous organization.

And if you still think your industry is unlikely to be affected by volcanic eruptions, so you don't have to prepare for one, that's true. It'll probably be something else you haven't thought of yet. In any kind of industry, you'll have to deal with crisis. It's foreseeable that those will be unforeseeable -- which is exactly why you should make sure you have communications backups when they hit.

So heed these examples. Prepare for crisis in a pragmatic way. Make sure your site can cope and you have other channels available, as well. Think web and social, not phones and signs. In the long run, that's likely to be cheaper and much, much more effective.

At the core, both enterprise and federated search are about accessing, indexing, and querying diverse and dispersed repositories. Enterprise search is very specifically about searching within the enterprise, which may include an externally-facing web site or extranet(s). 

It's often the case that an enterprise search tool can come across repositories that already have their own search engine that's created its own index. Assume for a moment that you elect  not to have your enterprise search engine re-index all that content itself.  Yet you want to expose items from those repositories.  In this scenario, when the initial search engine is trying to return results from those repositories that are already indexed, it can do one of two things:

1. Directly query those indexes created by other search engines in real-time, or
2. Trigger those search engines to provide results, and in turn aggregate what it collects into a single, enterprise-wide results set

That's federation: leveraging the indexes and potentially the query results of other search services within your enterprise.

However, I've heard some vendors use the terms enterprise search and federated search interchangeably -- which creates confusion.  A scenario where an enterprise search tool crawls other repositories itself and builds an index based on that content in all its unstructured glory is classic enterprise search, even if your vendor calls it "federated search." 

Obviously federated search sounds quite attractive, especially in an environment where enterprises have licensed multiple search products or employ various information management systems that embed their own search facilities.

In practice, however, comprehensive federated search is quite difficult. Even more than with “regular” enterprise search, security becomes an important issue, particularly when multiple indexes or engines follow different security models. Also, in scenarios 1) and 2) above, it can become extremely hard to de-dupe, merge, and provide comprehensive relevancy rankings in a reasonable timeframe for the searcher. A bottleneck in one repository can gum up the overall results.

While hosting a search seminar with Martin White of Intranet Focus in London a couple of years ago, he drew an excellent representation of these federated search challenges, and I have since transformed it to PowerPoint and use it often in my presentations about search technologies. 

Here at Real Story Group, we've added more detail to our search vendor evaluations regarding how vendors handle this highly complicated scenario. Despite the challenges of federated search, there is promise in these technologies, especially those approaches that rely on other native-search engines to provide the core results, and serve as basic aggregators.

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.