Re: the difference between WCM,ECM,LCM,MCM

> Robert Koberg wrote:

> hey Joe,
>
> (I also read your blog) Interesting. But, you are talking about systems
> that are going to cost extreme amounts of money -- for the system and
> the consulting -- right? When you talk about storage management are you
> talking about relational databases or something new and different
(Tamino?)?

Where to begin...hmmmm.  As always cost is relative.  It's going to varey
widely depending on the individual business.

Storage management has been described as the application of procedures and
processes to ensure the availability, accessibility, performance, and
protection of stored data and storage devices.  Storage management includes
such things as backup, recovery, data migration, replication, provisioning,
virtualization, archiving, etc.  Storage management products can have an
enormous impact on any asset management environment simply because they
operate outside the visiblity of most other applications, include CMSs.
These tools enable users to move, replicate, delete and migrate data outside
the control of any CMS.  Because today's CMSs are not storage-aware, and
because [most of] today's storage management tools don't communicate with
CMSs, IT users can indavertently wreak havoc.


> And, is it really where the industry is going?

If you mean are we going to see the convergence of storage management and
content management, my answer is yes, without a doubt.  In fact, it has
already begun.  EMC acquired DCTM. IBM has been busy acquiring several small
vendors including the most recent, Green Pasture. And several other large
storage vendors are on the prowl to first partner with, then acquire CM
vendors.

Probably the most amusing part is that the large CM vendors didn't see this
coming.  They were so busy competing with each other they completely missed
what's been going on in the storage industry. After the Documentum
acquisition was announced, FileNet issued a statement that it has no intent
to be acquired. And FileNet is trying its best to hold out...Lee Roberts
thinks he's invulnerable to acquisition.  Stubborn though he may be, I
believe FileNet's fate is sealed. His competition goes well beyond the walls
of content management now.

As for the products, there's already some overlap which is beginning to
cause confusion.  Some CMSs include crude storage management features, and
some storage management products include crude asset management features.
Worse, they both use policy engines to drive processes, and the engines do
not communicate with each other.  Vendors really need to begin integrating
these two environments to avoid trampling on each other's policies.

One example, digital rights. Your CMS may know that a specific image cannot
be duplicated, and that the right to use the image expires next week.  But
does your storage mgmt app know that? In most cases, no. Thought you deleted
the image from your CMS weeks ago?  Think again.  There could be a half
dozen copies on your network created by various replication and backup
applications that don't communicate with the CMS.  Expecting a human being
to know these things in an environment of tens or hundreds of thousands of
assets is unreasonable.

In an article in the April issue of InfoStor Magazine I discuss some of the
issues we're now facing as the two environments draw closer together.

>Many times large organizations can use much less expensive and simpler
solutions at the
> department level. If it it needs to be integrated into a grander scheme,
> then it can be transformed up (or down, depending on your point of view).

There's no rule that says this is an enterprise only solution.  In
orgranizations that manages storage at the department level it is reasonable
to assume that they'll want a solution scaled down to meet their needs.  And
then there's mix-n-match. Enterprise level virtualized storage shared by
multiple departments each running their own flavor of CM.  Nonetheless, the
environments need to communicate.

> maybe it is a philosophy thing -- centralized or decentralized?? (maybe
> it is just the clients/situations we deal with)

This is a question for each customer to decide.  There are no hard and fast
rules here. I tend to favor centralization because it's easier and less
expensive to manage assets when they're in a centralized storage
environment. But in some cases decentralization is simply unavoidable. (Btw,
by centralized I'm not implying storage devices in close physical
proximity).

>
> When dealing with binary things, I believe (ideally...) they should be a
> result of content/data rather than storing and managing the thing
> itself. There are, of course, limits. But things like Word, PDF, Vector
> graphics, ?? can have component pieces stored in XML and managed there
> and rendered to some final result.

Could you clarify a bit.  You switched gears here so I'm not sure how to
respond.

> Do you see XML as something that can accomplish some of the things you
> write about (e.g. going from one system to another)?

With regard to long term data rentention and forward compatibility, sure I
think XML can help for some of the text content.  But there are dozens of
file formats where XML does not apply. And I haven't even touched upon the
applications

As for going from one system to another, short term XML is as good a
solution as any.  But, the problem is not so much the individual content.
The problem is the metadata that defines, describes, interrelates, and
controls the content, the policy engine, and the repository.   The industry
needs to agree upon and develop a standard way to store and manage content
on the backend (which is going to take years at best, never at worst).  Then
and only then can we avoid the ridiculous complexity and cost of swapping
CMs or sharing content between different CMs. This is a lengthy discussion
in itself -- I'd be happy to write about it in a future blog entry.

>
> best,
> -Rob

Hope I've answered your questions.  If anything I've written is unclear just
let me know.

Cheers,

Joe



_______________________________________________
CMS mailing list
[email protected]
Subscription controls:
http://lists.cms-forum.org/mailman/listinfo/cms
Netiquette FAQ and related CMS lists - [CMS-Forum], [CMS-Meta], [CMS-PR], [CMS-Develop]
http://www.cmsreview.com/NetiquetteFAQ.html