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

Well said/written. more comments inline

joseph martins wrote:

>>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.

Let me address the points regarding storage management in relation to
our CMS. I suppose these are crude, but would like your opinion.

> 
> Storage management has been described as the application of procedures and
> processes to ensure the availability, 

through the web using apache and Caucho's Resin servlet container


> accessibility, 

if you mean section 508 compliance, then yes :)

if you mean access to the content/data, then it is 24/7 though the web


> performance, 

OK... we use XML text files to achieve maximum interoperability, so
performance might be an issue. We have not hit a limit yet, since large
  clients get their own server. Small clients use it like some people 
use a health club :). The 'live' version of the site most
likely would be somewhere else.

> and
> protection of stored data and storage devices.  

We simply use CVS to store incremental versions of the project's files. 
The CVS repository can be on the same or different machine as the project.

> Storage management includes
> such things as backup, recovery, 

Handled through CVS

> data migration, replication, provisioning,
> virtualization, archiving, etc.  

since the content/data is stored in text files (versioned through CVS)
it is simply a matter of (xsl)transforming, copying, zipping, ftp'ing,
scp'ing 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.
> 

I would like to know of products/system that could be used more
efficiently than what we currently use/do. I am considering a switch
from CVS to Subversion once it has more java tools.

> 
> 
>>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.

we will consider all seriously large offers :)


> 
> 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.

It is my opinion that large, expensive CMSes are on their way out. I
don't know about others, but since the first of the year we have seen a
large increase in customers -- both large and small organizations.

> 
> 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.


This is something I have not thought about and do not handle, hmmmm...

> 
> 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.

(versioned) xml text files seems easiest to me

> 
> 
>>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.


yea, sorry. I am writing about managing binary things. CVS does not
handle versioning binary assets well (Subversion is supposed to do a
much better job). I would /prefer/ to manage XML text descriptions and
render the binary from it.

> 
> 
>>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.

I'd read it :)

> 
> 
>>best,
>>-Rob
> 
> 
> Hope I've answered your questions.  If anything I've written is unclear just
> let me know.

All clear and well said/written.

best,
-Rob

> 
> 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