After all, if they want their vision of SkyNet to come true, they need to get to work.

Why Web Publisher Sucks

I talked recently about how there are many ECM vendors out there that have sub-par applications, like Web Publisher from Documentum, that shouldn’t be required to be an ECM vendor.  It isn’t that they aren’t capable of writing good applications.  It is that the landscape changes faster than the release cycles for the platform.

This isn’t to say that they need to speed up the release cycle of the core platform.  After all, that would mean more versions of Records Manager to get certified, and that would suck.  It means that there needs to be an ECM platform that releases separately from the applications teams.

I am talking about EMC’s Documentum here, these comments apply to many of the established ECM vendors.

Keep the Core Intact

I listed some on the last post.  This needs to be met and many components could use a freshening.  There are too many things that haven’t changed since I started using Documentum, and that wasn’t yesterday.

The core server for any ECM vendor should be able to act as an ECM platform and support any type of Content Application, be it written by themselves or any third party.  This means functionality and sufficient interfaces to support them.

The Content Server doesn’t need a rapid release cycle, just its own cycle with robust testing for scaling and for the interfaces, DFC, DFS, and CMIS.

Oh, and take a look at how security is managed. Support for different Identity Management architectures is paramount.  If authentication and authorization can’t be streamlined at a higher level, then it all falls apart.

Spin Off the Apps

Right now, this appears to be occurring to some extent.  CenterStage is on a separate version line. Of course, this may just be because it took so long to get out that management got tired of relabeling the version number.  The WDK started out separately and then jumped from 1.0.1 to 5.1.

The point is that CenterStage is a good model for how applications should be designed to work with Documentum.  It is loosely coupled through DFS, allowing the latest version of CenterStage to work with multiple versions of the Content Server.  Properly managed, CenterStage 1.0 should work with Documentum 7 and 8.

Of course, you would want to upgrade CenterStage before that, as you would most likely upgrade CenterStage frequently and the platform every now and then.  The more important thing is that CenterStage 3.0 would still work with Content Server 6.5.

If Web Publisher was managed like this, it might actually have a shot of competing.  They could rapidly develop and release every six months or so.  The only testing would be the actual application.

If Web Publisher and CenterStage used CMIS instead of DFS, they could be sold to work with other systems as well.  Wouldn’t that be something, at least for CenterStage?

The key here is that the applications are optional. Oh, it would be silly not to have any applications, but you wouldn’t need them to be considered an ECM vendor.  EMC could give up on Web Publisher and focus on things that work well but could be better.

Three Product Types

From this, we get about three product types.  They are:

• Core Server: This is the Content Server and the default application, be it Webtop or CenterStage Essentials.  You either buy seats or CPUs for the Content Server and you get it all.
• Applications: This is the old CEVA and new Component Content Application (CCA). By product: TaskSpace, CenterStage, Web Publisher, DAMtop, and xPression. These applications get their own version numbering system and communicate to the Content Server via DFS or CMIS. Records Manager would fall into this category, but I would throw Retention Policy Services under the core.
• Tools: This is the transformation engines, thumbnail servers, and imaging applications.  They are optional parts of any number of solutions.  Take imaging. You could be scanning for archiving, records, or as part of a transaction.  Tools could be integrated more tightly using the DFC for more precise optimizations.

Now if I want to use Documentum with SharePoint, I buy the Content Server for 400 users and plug SharePoint in using CMIS.  If I wanted, I could write custom web parts.  If I decided I wanted a tighter integration, I could buy one of the offerings from EMC or a third party vendor.

The applications now compete on merit, but I never question the repository.

Of course, there are things that the repository needs to do to merit this consideration, and I’ll cover that in my next post in this series.

To facilitate understanding of the use cases, I have created a presentation which I have placed up on SlideShare.  You can go directly to The Point Of The Content Interoperability Services (CMIS) Standard, or view the embedded version here and read the elaboration of the use cases below.

The Three Fundamental Use Cases

Here are the three use cases described in the presentation with some specific examples.  These are just a starting point for the discussion. Cases added after the initial post are in italics.

• Repository-to-Repository (R2R): This is where content repositories talk directly to each other.
  • Managing Records centrally that are stored in other repositories.  This is typically called Federated Records Management but is different than the Federated use-case.
  • Publishing content from one repository to another. A common scenario is publishing content from a collaboration/ECM system directly to a WCM system for publication to the Intra/Internet.
• Application-to-Repository (A2R): This is where an application that uses content is plugged-into a content repository to handle all content services.
  • SharePoint as a front-end.  If implemented, SharePoint can become the front-end and any other repository can be the back-end.  This would address the existing SharePoint scalability issues without impacting the user experience.
  • Collaboration systems. All the new Enterprise 2.0 systems, and existing collaboration applications, could use a robust back-end to provide more features such as de-duplification and records management.  This is the same as the SharePoint use-case, just generalized.
  • Enterprise Software Applications. Be it BPM, CRM, or any number of applications used by companies, content is becoming a larger part of those systems.  Having a central place to manage the content and apply consistent rules is becoming critical.
  • Content Enabled Vertical Applications (CEVAs). As I’ve discussed before, CMIS can really make life easier for CEVA vendors.  Let the domain experts build a solution for the industry and let them plug it into any content system to manage the content.  This frees the CEVA vendor from having to worry about the content or maintaining so many interfaces.  That means more R&D money for real features.
  • Productivity applications. Why not link Word, Excel, Open Office, or any desktop application to a repository using CMIS? Sounds lika a good way to write a portable integration, similar to the ODMA days. [Added 8/17/2009 thanks to Twitter comment from @billtrippe]
• Federated Repositories: This is where an application talks to many different repositories while presenting a singular interface to the user.
  • Federated Search. This is basically what the iECM demo demonstrated.  One search hitting multiple repositories.
  • Federation instead of migration. Any application can interact with multiple repositories.  Instead of migrating all content from an old repository immediately, just have the interface interact with the legacy repository(s) until they are migrated or out-of-date.  The application can store new content in the latest repository by default.

Collecting CMIS Use Cases

AIIM’s iECM committee is collecting use cases for CMIS.  We are looking for specific examples, not just the generalized use cases documented here.  If you have one that you would like to add, please add a comment and I’ll make sure that it is captured and share it with everyone.  Any and all feedback is welcome.

This is going to be our standard, so let’s make sure that we document what we need it to do, both with 1.0 and in the future.

What is a Content-Enabled Application?

There are too many names for them, and most are dull.  The Big Men (recently in this post) and I have talked about CEVAs (Content-Enabled Vertical Applications) previously and I’ve tossed around the term Content Rich Applications.  Craig refers to Forrester and their concept of Content-Centric Applications. It is all enough to make your head spin.

I think Craig simplifies it all down to one core description that will work for our discussion. Content-enabled applications should facilitate the convergence of content, collaboration, interaction, and process. Applications that do that are going to be successful.  Content is an aspect of the application, not the center.

Let’s take my favorite generic Content-Enabled Application, Case Management, as an example.

• Something triggers the creation of the case, typically at a central location.  For correspondence this could be the front-office. In other case management systems, it could be anywhere in the organization.
• Following defined business rules, the case is routed around until the person that is going to primarily work on the case is assigned.  Note that this step can actually occur multiple times with defined routing in-between.
• The case officer, for want of a better generic term, collaborates with colleagues and researches past cases that were similar to the current one in order to prepare the response.  This is where Enterprise 2.0 technologies and “traditional” collaborative spaces (like eRoom and SharePoint) would be leveraged.
• Once completed, it enters another defined route to either the next case officer, through an approval process, or a combination of the two.  Electronic signatures are key in this process (as is eNotarization).

An application to support a case management system needs to be designed around this entire process to make it as easy as possible for people to perform their tasks.  Content plays a big part, but the processes and user interface is what till determine if this application will be a success or failure.

This holds true for ANY Content-Enabled Application. Users want to do their job.  They want to do it well, if for no other reason than to keep their job and get a raise.  They don’t want to have to spend time figuring things out or adapting their work patterns to an application.  The application should be shaped to work with and enhance the process the users use to perform their work.

Building the Application

Traditionally, providers of CEVAs (for want of a shorter term) have had to write to the API of a specific ECM vendor to leverage their repository.  That meant that they had to either package that particular ECM product as part of the system or sell to companies that already had the needed ECM back-end.  When an ECM market leader in a vertical might only have 20% of that vertical, that leaves a lot of uncovered territory.  Decisions on which vendor to support are never easy.  Then comes the decision of which vendor to support as a second platform, and the challenges of managing the resultant larger code base.

The Java Content Repository standard made this easier, but with uneven support among vendors and the technology requirement of Java, this didn’t solve the problem.

Vendors started to implement Web Service interfaces.  This was a very uneven effort, but it did simplify things for the CEVA vendor.  There were still multiple code bases, but they were smaller as many of the details, like session handling, were hidden behind the scenes.  Better, but not there.

The proposed Content Management Interoperability Services (CMIS) standard (you had to know this was coming) solves that problem. Now a vendor only needs to support that standard and the CEVA vendor can support it.  Simple.  Still a year away, but a nice solution for the problem.  One code base, multiple repository support.

The only need is to write a script to create the necessary object model in the target system, and you are done.  Contractors can build and test that in a week.

All the money that the CEVA vendors save by using CMIS will lead to better products developed by more financially stable companies. More Content-Enabled solutions means the more ECM systems that will most likely be needed which won’t install themselves (Yet). What’s not to love?

Back to the Show

Let’s put the EMC spin on this in order to provide some more feedback to Craig. If I was building a new Content-Enabled application, with Documentum as my (first) repository, what questions would I need to ask to design it?  Here are just three.

1. Am I ever going to move this to a new back-end?
2. Do I want to package the solution for another deployment?
3. Do I have time and resources for a proper development process?

If those answers are all No, then find a close-hit Documentum front-end and be done with it.  Expect users to occasionally complain and plan for lots of training.  You could spend a lot of time customizing/configuring the front-end to solve that, but upgrades may be daunting. None of these issues are Documentum specific.  All vendors need better interfaces.

If the answer to the first question is No, and the third answer is Yes, then you can build a custom application.  You could use DFC or DFS. If you want to front into an existing application, like SharePoint, DFS is probably the way to go.  While DFC could perform faster in many situations, there is a lot more room for poor coding that would offset that natural advantage.  DFS would be faster to develop and shove lots of the niggling details to EMC. If you know what you are doing, fire away with the DFC and watch it sing.

If the answer to all three is Yes, then get thee to CMIS.  This is the sweet spot.  Basic Content Services and great search, more than enough for most Content-Enabled Applications.  Plus, no vendor lock-in.

This decision process is a lot more complicated than what I just portrayed, but you get the overall feel.

I figure within two years of the finalization of the CMIS standard, Content-Enabled Applications will be entrenched in the mainstream.

Updates and Announcements

First, in case you missed it, the 0.61c version of CMIS is currently out.  A lot of little things, but some solid progress.  I haven’t dived in very deeply, but some changes include:

• [CMIS-18] – Rename REST-Bindings to “AtomPub Bindings” or “AtomPub Extensions”: Now called “ReSTful AtomPub Binding”.  Solid change as ReST is an architectural style, not a protocol.
• [CMIS-45] – “base type” vs “root type”: Base type is the answer. Was some confusion between some of the implementations as the spec used both terms.
• [CMIS-48] – Replace cardinality:enumCardinality with multiValued:boolean: Minor but not something to be overlooked.
• [CMIS-54] – Content Stream MIME type: mandatory or not?: Was some confusion between documentation and the schema. The answer is “YesNo” [See Florent's comment below.]
• [CMIS-85] – enumPropertiesDocument does not contain a string value for “Name”: Love typos.
• [CMIS-86] – Provide a new service that will allow search crawlers to efficiently navigate a CMIS repository.: Cool.

Second, if you think you missed my presentation on CMIS with Alfresco, you are wrong.  There were audio problems and we are making a second go of it this week, April 22nd at Noon12:30pm EDT.  I am hoping for a strong Q&A portion of the webinar, so come with your questions on CMIS and the AIIM iECM Demo. If I say that I’ll have to get back to you on something, then it is a great question.

Finally, I have been invited to co-present at EMC World on CMIS. Not the best time-slot, 10am on Thursday, aka get-away day. If you show, I promise to make it worth your while.  More details as I get them.

CMIS, The Right Choice?

Saw a bunch of posts stream out from Stéphane Croisier about CMIS. They offer a fresh perspective, but I’m not sure that he fully gets it, yet. He doesn’t appear to have been living ECM for ages, but has a strong WCM/web viewpoint, and he likes CMIS so I am inclined to like him. They are good viewpoints to read though because, agree with them or not, he represents part of the audience for CMIS.  One post talks about CMIS being disruptive.  I don’t think it will be for ECM, but possibly for WCM and portals.  I think the Drupal/Alfesco integration using CMIS is just the first example of how things might change in the WCM world.  Disruptive is a strong word, but it could be that big to WCM.

Think of the impact to other content-focused applications.  Take SharePoint.  The next version, SharePoint 2010, will be out in the first half of next year with the tech preview in Q3 2009.  As they already have CMIS examples with the current version, I see great things in the future. If you can tie SharePoint into a back-end repository with CMIS, the scalability concerns are almost gone.  Who needs RBS or EBS?  Disruption is almost the opposite of what may happen with SharePoint support, which may not be a bad thing.

Then there is the whole CMIS versus the old guard, WebDAV, JSR-283, and ODMA. All have their uses, but none are ideal or do what CMIS does.  Let’s take this in reverse order.

When ODMA became fully supported in Office 97, I danced the happy dance.  Less than a year later, all my clients wanted web interfaces with no FAT clients deployed.  ODMA kind of requires a FAT client, so it withered.  Some repositories still lean on it, and it is awesome.  It is user application to repository standard, not system-to-system.

JSR-283 requires a Java interface. Not everyone, vendors and clients, use Java, so it fails. Even some of those that do, *cough* Documentum, don’t support it.  Nice concept, but limited in full practicality.

Then there is WebDAV.  If you look strictly at the AtomPub binding of CMIS, you get confused as to what the point may be.  Remember, this is not just for applications to save and update content in a repository.  CMIS has advanced queries and, as a whole, is able to function as a standard interface in a Service-Oriented Architecture.  WebDAV does not have object typing, schema, folder navigation, or querying.  WebDAV is a useful way to save content from your desktop applications to an ECM repository, but it won’t link-up to your ESB or serve as the basis for an integration like the aforementioned Drupal/Alfresco blending.

Yes, CMIS is missing a lot of things. Transactions is one thing that we need badly. I am depending on the statements of the TC, the people, that say this is going to be version 1.0 of several versions.  If this is true, then life is good. It isn’t even at 1.0 yet, so small changes can occur (though Kas, I think the “folder” object is a neutral and broad term).  Policies are interesting and could be great depending on how each vendor unitizes the object.  We’ll see.

It is spring, so it is a time of hope. After all, who would have seen Microsoft, IBM, and EMC band together to create it, much less invite Alfresco, Oracle, SAP, and Open Text to play? I plan on dating, seriously, CMIS 1.0.  When version 2.0 comes out, I’ll know that CMIS is serious and I can truly commit.

• Should EMC/Documentum dump their [Edit: Removed adjective] DFS implementation once CMIS support is released?

I’m torn here.  I believe that CMIS should be 100% supported, but it does not cover everything.  There will always be some vendor specific features that will need to be listed.  My general thought is that it will not.  CMIS will coexist so that changes made to incorporate new features in Documentum will not impact the CMIS implementation which must match the standard.

Plus, telling those that have invested time into DFS, correctly or not, that they need to completely overhaul things instead of making minor changes seems unlikely.

• Will CMIS implementations support important security standards such as SAML?

Unknown on SAML at this point.  I am fairly confident that it is, or has been, under discussion.  The presentation that drove the whole security discussion can be found online.  They are working to refine the process based upon the meeting and work to be done before the next meeting.

As for XACML, it is out and it doesn’t appear to have been close.  I’m guessing it has to do with simplicity.  I got the following note from the Minutes of the First  Face-to-Face Meeting: Policies vs. ACLs: We agreed that if we can directly incorporate an ACL model into CMIS, we should consider removing the “Policy” object entirely for v1.

• While we understand that ECM systems should store content, not users, do the ones that store users require junking up the specification in order to accommodate?

I don’t think that this is going to happen.  The issue of authentication needs more addressing, but I don’t think they are going to junk it up to solve it.  The standard doesn’t care how you manage users and I don’t see why it would.

• How should ECM incorporate? Do you prefer content server –> CMIS or content server –> DFC –> DFS –> CMIS?

I think James means “EMC” and not “ECM”.  I think the proper implementation would be Content Server — > DFC –> CMIS.  All of the Documentum clients interact with the Content Server through the DFC, so I feel good about this.  I see no reason to insert DFS in the middle.  The current implementation does this, but I believe this was more for speed of development than anything else.  I feel that taking DFS out of the loop would make for a more efficient implementation.

Let’s all keep in mind that all implementations are not necessarily indicative of how the final implementations will look.  I’m happy to have implementations at this point.  In theory, if anyone changes how it works before the final release, it should be a smooth transition.  After all, that is the point of a standard, you don’t care about how the interface is implemented, only that it is there.

• Once an implementation of CMIS is released, should vendors make it work with prior versions or should they force upgrades?

I think a minimum version would be reasonable.  After all, there is only so much regression testing that they will perform.  My guess is the EMC will support back to D6.  James does raise a GREAT point here in having vendors test against old version.  That would be another reason for EMC to base things on the DFC.  The core commands needed to support CMIS haven’t changed much since 5.x, or 4.x even.  5.x support would be great.

• How self-describing should the WSDL be? For example, should each element have a choice type or should we resort to less optimal “helpers”?

This needs to be easy.  There are pros and cons to every choice here.  Clear documentation is what will help, regardless of the choice.  I prefer more self-describing, but I would rather other’s chimed-in on this one.

• Should CMIS support WS-Transactions?

YES!!!  I would expect this to be a subsequent version of the standard and not the 1.0 version.  I can see debate on this topic delaying the standard and I would rather see a solid standard released that can the be expanded upon, rather than wait an extra year.  This should be in the roadmap for the standard and debate should start as soon as the 1.0 standard is released for comment.

• The conversation to date has been all about producers. Any thoughts on how consumers will embrace? Thoughts on how Siebel, SalesForce, etc could leverage?

I’ve been in this conversation on both sides.  I recently said good things about Microsoft making SharePoint a consumer of CMIS.  This will work great for CEVAs as well, potentially pushing a few players into more expansive roles in the marketplace.  Exalead, a participant in the CMIS discussions, is a search vendor, and presumably a consumer.

I think that this provides great potential for consumer applications.

• How should compression be handled within an ECM SOA?

Carefully?  This is actually a concern of mine.  Simple use-case, a scanned image sits in a repository.  It has been decreed that at the stored resolution, it meets the requirements to be a record.  Now you compress it for transmission to the consumer application.  Is it still an official copy, or just a referential copy for research purposes?  I don’t know the answer to that question.

I do know that as long as both ends of the CMIS equation are inside the firewall, this issue can be delayed.  It will become important, and may be important enough now.  Opinions?  Thoughts?

There are two primary factors to standard adoption:

• Is the standard technically sound?  It has to actually solve the stated problem.  It is okay if a standard is limited in functionality in initial drafts as long as it evolves to accomplish everything required.  At the same time, it must be easy enough to use.  These are not small technical challenges.
• Is there vendor support?  Let’s face it, if the vendors don’t support it, then it will fail.  The JSR-170 and JSR-283 standards are perfect examples.  They aren’t supported by a critical mass of vendors.  The reasons range from the technical (we work in Java), to the philosophical (it is a bad standard, let’s focus elsewhere), and to the lazy (nobody cares so let’s ignore it).

Customers are important, but it takes a large mass of them to force the vendors to act.  I would qualify them as a secondary factor.  While I digest the technical aspects, take a look at the Vendor Support factor.

How Many Vendors Can Change a Light Bulb?

If you ask that question at an AIIM seminar, the answer is simple, The one that built the lamp.  That answer won’t work for the interoperable SOA world that we are trying to build.  The answer needs to be like it is now with lamps, anyone with the correct wattage.

The problem with that answer is that it is too big to be a realistic starting point.  If we need every vendor to support CMIS out of the gate in order to be effective, then we are doomed.  Luckily for us, we don’t need that level of support.  What we need is a critical mass of ECM platform vendors and Content Rich Application including CEVAs providers.

The number of platform vendors required depends more on the customer base of the supporting products than a raw corporation count.  Microsoft provides more weight than Alfresco.  Open Text gets full credit if they only have one of their products support the standard.  While they may get killed in a sales competition, it is the PERCEPTION of adoption and support that is important.

This is where the application vendors step into play.  Many develop an application with either their own back-end or built on-top of an existing application.  Sometimes they write multiple versions to support multiple ECM platforms.  If they perceive support for CMIS among the platform providers, the application leaders will invest the time and money to change their application to connect through a CMIS interface.

This will reward the ECM platform providers by enabling the sales of the Content Rich Applications and CEVAs to drive sales of their platform.  The lagging platform vendors will see the money being lost and implement support for the standard, sell-out quick, or fade away.

The leaders for successful adoption of CMIS need to be the ECM Platform vendors.

Will the Leaders Please Step Forward

I figure we need a 75% seat rate, existing and growth, for a locked-in success of CMIS.  50% would be a challenge.  There are scenarios that throw those numbers off, but I’ll get to those in a minute.

If we look at the list for CMIS, we are already there.  Unfortunately, it isn’t that easy.  The JSR standards had that level of “support”.  We need to measure support by actual released product and public, ongoing, commitment to CMIS in the Vision of each company.  We need to judge the vendors by their actions over the next six months.  Will they continue to talk about CMIS and will they implement a supported interface layer?  That is the criteria, not press releases and web sites.

The one thing that could speed things up is if some open source vendors implement the standard and the user community responds.  The ECM platform vendors will then scramble to draw even.  Alfresco has started down that path, but more on that in another post.

Next, I’ll look at the depth of initial vendor support and see if we can guess who the leaders might be for CMIS down the road.

Shall we set sail…

The Rigging

Before setting sail, let’s take a very quick look at what we know of the the rigging. It is using DFS for all of its communications with the Content Server. By default, it is using a local instantiation of DFS and communicating intra-JVM. This is because DFC is still faster and more efficient. All APIs are faster than the services that they are built upon. It is configurable to use a remote DFS service though, so I wouldn’t consider it an issue.

In the front, we have Ext JS (The new rich media user interface is Flex). I’ve just taken a quick gander, but I liked what I saw. The phrase 508 compliant does tend to float across my mind though. Hopefully it is in the rigging somewhere.

All this means is that there is no WDK framework. This is okay. They have stated that the WDK is not going away, at least not in D7. Webtop is going to remain as an interface for the power user and for provided heavily customized interfaces.

I like Webtop these days, when you keep the above focus and purpose in mind. Magellan is being provided as a collaborative CEVA built to work with an ECM system through services.

I think I’ve heard that architecture before.

The Easy Course

Okay, now I am now leaving port and I couldn’t be more excited. Like everyone else I think Magellan is incredibly cool and sexy, especially for an ECM-based interface. It offers a simple interface for all of the basic library services with the addition of the Workspace paradigm and the pervasive use of discussions and comments.

The vision for Magellan is quite simple:

• A Web 2.0 Client: Check. Had that. Very pretty.
• Information Intelligence: Saw the introduction of a Folksonomy with tagging and a nice search filter. They may be getting that correct, given current technology.
• Anywhere Access: There are plans for a mobile version that will be location aware, I think in the D7 release cycle. Don’t hold them to that as that isn’t written down and my memory could be off. With it built on DFS, I don’t see why it wouldn’t be achievable in that timeframe.
• Web 2.0 Platform: Personally, I think this is just an excuse to say Web 2.0 twice. It is important, but the entire application is Web 2.0. Another reason for the split? A four part Vision seems more robust than a three part vision.

It is a good vision and EMC seems well on its way to delivering it. Once the Enterprise version of the client is delivered in Q1 of 2009, if not sooner, it is planned that Magellan will surface all of the Collaboration components that are currently in the Content Server and part of the Collaboration Edition (DCE). I can almost feel the eRoom vibe from here.

Once you get away from the coast, you enter the part of the map labeled “Here there be Dragons!” For EMC, it more likely reads, “Here there be SharePoint!”

SharePoint vs. Magellan

This isn’t a blow-by-blow comparison. After all, I don’t have Magellan to play with and it isn’t even out in Beta. Once it is in Beta, I hope to be in the program and sworn to secrecy. I’m not very good at Beta applications, so we’ll see if that happens.

Until then, I did note the following features not in the Magellan Essentials, the “free” version of Magellan, that is in SharePoint Services, the “free” version of SharePoint: wikis and lists/data tables. Now I understand the data table as that could be considered an advanced eRoom feature. The EMC data table is, in many ways, more flexible and easier to use than the SharePoint list. No problems there with leaving that out.

As for the wiki, I think that this is a potential missed opportunity. A simple, non-moderated, wiki would be a great asset in the Essentials client and would help increase the Web 2.0 feel of the interface. Provide an advanced moderated version of the wiki in the Enterprise client for differentiation. I think that if it properly packaged, it will drive adoption of both clients.

The goal shouldn’t be to stop people from switching to SharePoint. The goal should be to reverse the trend.

Paradise Found

Just past the dragons, we come to the South Pacific and see beautiful islands. This place is the stuff of dreams and why we started in the first place. Of highest interest to me is the fact that Magellan represents the first new User Interface for collaboration in many an age (DCE doesn’t count). We now see the next generation of collaboration with a roadmap that feels tangible and a destination that is in sight.

The goal is that by D7, all the features of eRoom will be in Magellan Enterprise. Not all of them are in the Content Server yet, so there is still a little more work on that end.

What makes everything feel tangible? How does this feel more real than last year’s eRoom 8, aka Phoenix, announcements?

• How about the announcement that they have engaged Crown Partners to build a migration tool to go from eRoom to the Content Server-based Magellan?
• How about their desire to take those on eRoom maintenance and just port their licenses and give them the tool?

That is money out of their pockets. A lot can change, but it sounds like they are committing to saving their comrades in the eRoom world.

Magellan is a priority for the CMA group. This is obvious from talking to multiple people on multiple levels. This isn’t just a side project or just a token attempt to stop losing market share to SharePoint. This is a strategic commitment to creating a versatile, mobile, and flexible user experience in the Enterprise. There is a sense of urgency to get it out there and let people see it, feel it, and experience it. This is their Enterprise 2.0 interface into their ECM 2.0 platform.

Will it come in time? Will the SharePoint dragon become so bloated that it can’t handle the potentially nimble Magellan ship? Time will tell.

This was prompted by a reading OpenText’s Enterprise 2.0 Content Management strategy. Note the placement of the 2.0. We’ll be getting back to that.

ECM 2.0, Coming Soon to an Enterprise Near You!

Well, if you look at my definition of the next generation of ECM, ECM 2.0 for fun, you’ll quickly see that we aren’t there yet. Even Bex chimes in on the Identity Management support in Oracle ECM and says that it isn’t there, yet. It is a great post and all concerns and issues there are true for Documentum as well.

Let’s take it as fact that all ECM systems are currently lacking in open support for Identity Management systems. Most can leverage external authentication, but fall short for external authorization.

Documentum can handle external groups, but not security policies. Those have to be created inside of Documentum using the external, or internally managed, groups. Documentum, like many systems, cache the external information for various performance reasons. That is fine, except that if something changes, you are out-of-date until the next synch job runs.

As if my critical eye wasn’t enough, EMC themselves aren’t at ECM 2.0 yet by their own reckoning. Way back at EMC World 2007, they defined their vision of ECM 2.0. They stated that D6 was just laying the foundation for ECM 2.0 and that it wouldn’t be realized until at least D6.5. That is this summer, so we can’t even evaluate it until then.

D6.5 will either be the Beta 2 release of ECM 2.0 or the “gold” release. It depends on who you ask and what is delivered.

ECM 2.0 and Enterprise 2.0, Not Even Related

Aside from the flashy 2.0 attached at the end, there is little relation as far as I am concerned. ECM as it currently stands can support Web 2.0 artifacts. Some user interfaces may need some updating, but the back-ends of almost all Content Management systems, Enterprise or not, can store any type of content. Being able to store a wiki isn’t that impressive. Sounds more like a new feature for either a Collaborative CEVA or a Web Content Management CEVA.

ECM systems can support Enterprise 2.0. It is the interfaces that need to be updated. Clearspace, from Jive, supports Enterprise 2.0 activities. Infovark, once released, will support Enterprise 2.0 activities. Neither are ECM systems or based upon them. I bet that I could take Documentum 5.2.5 and use it as a back-end for content for Clearspace. It may take a little development, but it could be done and nobody will EVER confuse that old version of Documentum with ECM 2.0.

OpenText is updating their user interface. That’s it! Big deal. If they have to make a lot of changes to their back-end to make this work, then they are in worse shape than I ever imagined.

Everyone, Look Outside the Traditional 2.0 Box! (Traditional 2.0? Funny.) ECM 2.0 is the next generation of Enterprise Content Management. It is not a slave to any other technology. It is a servant for the emerging Enterprise Architectures in the SOA world. It isn’t dependent on Web Services or REST. It is dependent on an undefined SOA Standard.

Look, databases have ODBC and JDBC. ECM needs an equivalent. CEVA providers shouldn’t have to write different interfaces to interact to different systems. They need one interface and ECM system will then only need one interface. Then we can get back to features and not pick a vendor because they are at least average in everything that we need.

Jed Cawthorne gets it. Billy Cripe gets it. Lee Dallas is getting it. Do YOU get it? If not, tell me why and I’ll see what I can do to help you along. Please chime in and share your thoughts. I’d love to hear from someone at EMC like Cornelia, Craig, Mark, Chuck, or someone new.

Before I get any further, kudos to them for actually taking the time to begin developing these “patterns”, starting last fall. There is a definite need, and their choices for the first two are ones that are encountered quite frequently, at least by myself. All I am doing here is offering some feedback, most of which I have already shared.

If you develop Documentum solutions, you need to check them out if you haven’t already. They are:

• When to use registered tables versus object-types with no super type: I talked about this issue myself shortly before this was posted and there are some interesting comments. There is a discussion on the topic as well.
• When to connect as a Named User or as a Gateway User: This speaks to the problems currently faced when interfacing between ECM and CEVAS as envisioned in ECM 2.0. You can read the discussion and see the precursor to this post.

I also want to add that if I hadn’t read Patterns of Enterprise Application Architecture, I wouldn’t be able to make comments that are, I hope, constructive.

Defining ECM Design Problems

The first step in formally defining a Design Pattern is to define the problem/domain. Let’s take the 2nd example. The problem, as given, is as follow:

Developer wants to build an application on top of Documentum Content Repository to create/update/read/act on content stored in Documentum Repository. They have two available options. They can either connect to Documentum Content Server as Named User or Gateway User. Click here for a diagram that explains Named user and Gateway User mechanisms.

In the named user access, the application connects to Documentum as a user it is performing action as, where as in Gateway user access, application connects to Documentum as a application user that performs actions on behalf of the users that is interacting with the application.

Only the first sentence actually talks about the problem, even though both paragraphs are in the section Problem. The description needs to define the problem in more detail, giving the business case and an example or two.

Only by defining the problem in detail can the reader truly understand the different solution patterns and see which situations that each may be required. It is a fair to list the Patterns in this domain and/or to define any Pattern groupings.

In the example that we are looking at, Named Authentication and Gateway Authentication are actually the name of two groups of Patterns, and not two patterns themselves. The Patterns that I know (proposed names in bold) are:

1. Named Authentication with Shared Authentication (Single Sign-On)
2. Named Authentication with Stored Credential Authentication (user id and password stored as separate values in the 3rd party solution)
3. Named Authentication with Generated Credential Authentication (Connection maintained by gateway user that spawns user sessions as required for the named user)
4. Multi-Level Gateway Authentication (Different Gateway Users for different authorization levels in the 3rd Party System)
5. Single-Level Gateway Authentication (As described in the article.)

Check out the post for my thoughts on these patterns.

Defining the ECM Design Pattern

For each Pattern, there are several things that need to be elaborated upon in order to fully define it. They are (tip of the cap to Martin Fowler):

• Description: Describe the Pattern. Include a diagram to illustrate the concept more clearly.
• Functional How-To: Give a description of how it actually works. Describe how different components interact to implement the Pattern.
• When to Use It: Give the Pros and Cons. Comparing and contrasting to other Patterns in the domain would be beneficial. (Ex. Single-Level Gateway Authentication doesn’t track requests in the ECM system by user. Use a Named Authentication approach, or pass the requesting user as a parameter, to achieve auditing).
• Examples: Where applicable/available, code snippets and other items that may assist people in implementing the Pattern.

I’m not going to go into defining any of the Patterns at this time. I may do so here if there are requests. Patterns are going to become a larger part of the Developer Network in the near future, probably after the hinted-at arrival of wikis. At that time, I will be taking time to write these out for all to share.

If you have any other Patterns that may fit in this domain, add it in the comments, add it to the Discussion thread on the Developer Network, or just wait for the wiki to arrive.

Remember, Share and Enjoy!

I have come back to this topic through multiple avenues. One is the concept of Invisible ECM from Billy and crew over at Oracle. It resonated very strongly with my previous discussions on Transparent ECM. We can debate terminology later, but what is important now is the shared concept.

A second avenue comes from my need to explain where ECM is going, ECM 2.0, in a simple and concise way. I can explain it and speak passionately on the topic. The need to get the concept out there in one breath has become more important as I talk to more people.

I have developed a proposed definition for your consideration. I would love feedback. I will approve all constructive comments for sharing, though I may not respond until a subsequent post. I’ll throw it out there and then discuss it briefly. Remember, I want this definition to have a soul.

Enterprise Content Management is the empowerment of all content within an organization. This is accomplished through the centralized management of content, allowing for people and systems to access and manage content from within any business context using platform agnostic standards.

Enterprise Means Everything Managed Together

The Enterprise in ECM started as being able to support various Content Applications throughout the organization with the same tool. This led to WCM, RM, DAM, and Collaboration applications all being developed or acquired by each major vendor.

The growing problem now is using content in applications not provided by the ECM vendors. These are applications that I have previously referred to as Content Enabled Applications, but Gartner and others refer to as Content-Enabled Vertical Applications, or CEVAs. (Gartner’s term pre-dates mine so they win the terminology battle.)

For example, documents in a case management system (a solid example of a CEVA) should be retained in a central repository. From here, records management policies and archival rules can be systematically applied.

Traveling the Road to ECM 2.0

When ECM was first coined, you would have been hard pressed to find a vendor that could actually deliver on the definition. The biggest hurdle these days is finding a proper project manager and plan that leads to a successful ECM implementation. People often blame the vendor, but usually it is the integrator, or lack thereof, that dooms an ECM project.

ECM 2.0 tries to make that easier. It’s very nature is to support other applications. Using supported standards, the ECM system is plugged into the back of a CEVA. If needed, a WCM or collaboration solution (RedDot and SharePoint respectively) can be plugged in as well. Organizations shouldn’t have to use the Content Applications from their ECM platform vendor. There are advantages to doing so, but it shouldn’t be required of the organizations.

Delivering an ECM 2.0 platform is a tall order. It isn’t just about scaling for volume or handling all types of content. Those things are important, but not what separates old ECM from new ECM. What is different is the way the ECM platform acts as a platform supporting the Enterprise. To get there, at least two things need to happen.

1. A standard for the ECM world needs to be set and implemented: Like ODBC and JDBC with databases, ECM systems need a standard interface. In today’s world, a SOA standard makes the most sense as it would loosely couple the systems together. If I had to pick a technology, I would go with something built on Web Services, but mostly because so many ECM vendors allow communications in that manner.
2. ECM Platforms need to leverage external user stores for authentication and security: A classic example of this is as follows…I have a Word document in SharePoint. It has a set of access rights assigned to it which is mirrored in the ECM system. When the security is changed in one place, it needs to automatically change in the other. All the users and groups that exist in one system should exist in all systems. Ideally, there is only one instance of the access control lists and users that both systems leverage.

This isn’t going to happen over night. I know several organizations, in different verticals, that are facing the problems that ECM 2.0 addresses now. Their solutions are functional, but far from ideal. They are locking themselves into a set of technology and putting themselves into a position where they cannot upgrade one piece without upgrading the whole.

The requirements are forming in the heads of the users. The first vendors that get there with a robust solution will flourish. I suspect that at least one of IBM, Oracle, or EMC will fail to deliver in time and will drop from the top three. The question is, who will rise up to take the vacated spot?