I am going to look at this in two stages. The first is going to focus on the purpose of and foundation for an Enterprise CMS Platform. The second is going to look at what capabilities a CMS needs in order to be a Platform.

Why a Platform

Let’s start by looking at the ECM definition so we can use it as a reference.

Enterprise Content Management (ECM) is a strategy for the coordinated management of all content throughout an organization, allowing for people and systems to find and use content from within any business context.

For the purposes of defining the goal of an Enterprise CMS Platform, let’s pull out a few key pieces.

• Coordinated management: Not all content might be located in the platform, so talking to other Content Management Systems is important.
• All content throughout an organization: If we are going to potentially put everything into one platform, it needs to have scale, security, and enough features to meet differing business requirements.
• Any business context: The system has be able to work with other systems and become part of the everyday business of an organization.

So there are some goals for a Enterprise CMS Platform to meet, but why a platform at all? Why not a specialized CMS for each business specialization and just integrate in the backend. Complexity.

Assuming that they are all CMIS compliant, which isn’t too  risky of an assumption for the current versions of most products, you can have them share information. Of course, if you have a lot of systems, you almost need an Enterprise Service Bus (ESB) to manage it all. Perhaps an Enterprise Content Bus? (Note to self: Stay on target topic)

Assuming you are able to manage the myriad connections, you still have all the different technologies from each CMS. That is a lot of specialized expertise to keep in-house.

Using a platform allows you to maintain one skill-set, reduce integrations because some business solutions can reside on the same system, and you have only one vendor to track down. You also won’t have the Account Manager from each vendor banging on your door telling you why they should handle all your content and not just a subset.

Suffice to say, there are pros and cons. If it is determined that an Enterprise CMS Platform is the right way to proceed, what do you look for from the vendors? Luckily, there are some answers.

Oh the Features!

What I am presenting here are a list of capabilities that are a minimum to look for in a platform. This does not mean that some organizations won’t require more from their platform. I am simply saying that if a CMS cannot provide these capabilities without a third-party add-on or custom code, then it isn’t a good choice to use as a platform to implement your ECM strategy.

1. Be a CMS: Seems obvious, but this is important. Last April I asked, What is a CMS? In that post I covered some basic features. A platform needs to provide every single one of them. No exceptions.
2. Advanced CMS Features: These are features that weren’t covered but would be required in a platform. Simply put: Relationships, LDAP directory support (not just Active Directory), composite documents, and renditions. There are probably more, but those are key.
3. Scale: Every organization has a different definition how much content is a lot of content. For some, a terabyte is a lot. For others, that is achieved several times a month. No system scales without effort, so I’m not saying that you don’t have to plan or architect. There is a simple measuring stick to determine if a CMS will scale. If I have to modify my business-focused logical design in order to have the system scale, that is a failure. For example, if I have a lot of correspondence and I should not have to create a new repository every year to accommodate a physical limitation.
4. Full Application Programming Interfaces (APIs): Simply put, I should be able to access every single function, with the possible exception of some administration/configuration features, through a documented API. Hard to tie the platform into the larger business system if one of the features that I need is missing.
5. Service Oriented Architecture (SOA) Interface: Be it RESTful or Web Services, these days a loosely coupled interface is required. This capability can meet the need for a Full API.
6. Standards Support: Standards are great and they simplify things blah blah blah. You know this. What this also shows is a commitment to play nice with others which is critical. The list of standards includes more than CMIS, such as SAML and XACML for identity management, and evolves over time. The list of standards is a post unto itself.
7. Workflow: This isn’t necessarily full-fledged BPM, but the platform needs to have more than just Lifecycles and simple approval routing. Complex processes with support for automated steps, rejection paths, and conditional routing needs to be out-of-the-box. That means I don’t have to write any code to create a workflow consisting of manual steps. None.
8. Collaborative Interface: This is the tricky part. You need an user interface for people to use for basic collaboration, not one that looks like Windows Explorer. Sure, you can leverage a newer Enterprise 2.0 community-type system for collaboration, but there will likely come a time when people may need to access the system directly. That interface should be collaboration focused, not be overwhelming, and allow access to any/all features of the system. Sounds daunting, but it can be done.
9. Records Management: While I am not suggesting full DoD 5015.2 support (unless you want that easy validation), a platform must  be able to lock content for retention, apply holds, and allow for different dispositions. This also entails complex security models and more audit trail capabilities than your standard CMS.

That is it. It may seem like a lot, but it isn’t. In fact there are more features that I look for in a go-to Enterprise CMS Platform vendor.

The Rest of the Story

There are specialized needs that aren’t uncommon. While you wouldn’t need to have all these capabilities to be an Enterprise CMS Platform vendor, it will limit you in the “ECM” market.

• Digital Asset Management (large file support/content streaming).
• Federated search
• Native XML support
• Forms (built-in or go-to partner)
• Content Analytics (built-in or go-to partner)
• Email Management (store email and attachments)
• BPM including specialized user interface (built-in or go-to partner)

I’ll tell you right now, there are only a few vendors that can really do all of this reasonably well. There are also a finite number of companies that really need everything in the primary list, much less items from this secondary list. For instance:

• If I use Active Directory internally, a vendor that doesn’t support other LDAP systems is still in play.
• If I’m not going to do any complex integrations, I can probably live without the full API.
• I can almost always work around the lack of standards support.
• Scale is in the eye of the beholder.
• I may decide that I don’t need a good user interface because only administrators will use it and they complain about everything anyway.
• As for Records Management, maybe I’ll just take away everyone’s right to Delete, keep everything, and trust upgrades in technology to keep the system scaling well.

The point being that just because a CMS isn’t a complete Enterprise CMS Platform, it doesn’t mean that it can’t serve as one for an organization with less rigorous needs. SharePoint fails on at least two of the basic capabilities, but it is good enough for many organizations.

And that is part of the art of ECM. You have to understand the needs of the market, the capabilities of the products, but realize that what is important at the end of the day is that people need to use the system. Make it too complex, expensive, or hard-to-use, then it will fail.

That is why people are pushing back on ECM as a concept. The problem isn’t the concept. The problem is that while there is a lot of prognosticating among analysts and consultants, the users just needs to get the job done.

• The environment needs to be very flexible and support a wide variety of users and scenarios.
• The Swedish military works tightly with US and NATO forces, so this stuff applies across the world.
• Need to use newer and cutting-edge products in order to gain the agility needed in today’s environment.
• The office is not an “office”, but can be tents, cargo containers…
• Basic perspectives on information
  • Theme,Temporal (includes time span),Spatial (3d), Relationships, User interaction tracking > Components of visualization based upon filters.
  • Many systems cannot store all of this
• Integration Approach
  • SOA with ESB (point-to-point did not work)
  • Message hub using XML (uses Oracle Fusion Middleware suite)
  • Expose out-of-the-box services on the ESB (DFS)
  • Customizations developed as services and expose on the ESB
  • No stove-pipe, same object in all systems (Access things where you need it access it from)
• Logical Data Model and Services
  • Readable and provides a business-level model
  • Transforms to/from legacy systems
  • Lots of interoperability work that was enabled
  • Documentum manages the Relationships
• Use Master Data Management, of which Documentum is one of the systems managing data
• Use Solr for Enterprise Search, InfoGlue portal, IBM SameTime, TIBCO Spotfire
• Using Kerberos SSO for dealing with their authentication across the systems.
• If people forget passwords, they don’t use the system, Smartcards solve that problem (Very nice way to put it!)
• Seeing some cool tools integrated with Documentum using SOA.
• Solr is providing content analytics, creating word clouds and lots of other cool analysis.
• Use Service-side version of xDoc to create DITA-renditions of Word-files
• Customizations of DAM
  • Copy DITA references to Documents and Images
  • Create service requests
  • Still exploring XML capabilities (XDB I think she referred to as exploring)
• More examples using lots of GIS to display information
• Uses XMetaL/Documentum and the legacy XML documents, not using XDB at this time
• Legacy content needs proper attention to be converted to reusable pieces

This has been a very cool presentation and system.  Lots of visualizations and how Documentum can work as part of a larger solution.  I’d tell you where I was going next, but last time I did that, I was wrong.  It will involve coffee and may involve lunch.  Will be at the ECN area in the Expo at 1pm for the meet the Community Experts gathering.  I do need to find people that don’t enjoy pushing my buttons quite so much though. 

Disclaimer

All information in this post was gathered from the presenters and presentation. It does not reflect my opinion unless clearly indicated (Italics in parenthesis). Any errors are most likely from my misunderstanding a statement or imperfectly recording the information. Updates to correct information are reflected in red, but will not be otherwise indicated.

All statements about the future of EMC products and strategy are subject to change at any time due to a large variety of factors.

Why is it that when I talk to people about “CMS”, they are almost always referring to Web Content Management? Seems to be a pretty narrow definition of the use of content. Along the same lines, many “Information Architects” that work with these “CMS” applications seem to be senior website designers. I’ve met Information Architects that I felt deserved the title, but they dealt with things beyond, though including, the web.  Enough of that, for now, on to the main course…

The second, is of course the slight to CMIS. That is the focus today. While I encourage criticism of CMIS as criticism is important for growth, I don’t want misconceptions to perpetuate themselves.

Sticks and Stones

I must say that I was a little disappointed with Kas’ post.  I was expecting a much more in-depth dissection of CMIS. It was mostly focused on nomenclature. In standards, the names of things are picked to be generic and in such a way that no one vendor looks to be the source of all.

That being said, the first observation is dead-on. Why does the CMIS standard have Document Objects and not Content Objects? Seems like a simple one-to-one mapping that should be there. It is just words, but words create the perception.  It is a valid criticism, but only semantically.

The next was folders. This is one that I tried to think through before CMIS was released for a side project. It is just a simple generic term. WCM systems may use other terms, but users of all systems understand folders from a hierarchical storage capability.

What’s more, if a repository supports the capability, CMIS allows for Document Objects to un-filed.  There is no need to throw everything into a folder at all.  This capability is defined by the combination of the repository and the object definition. Conversely, you can put documents in multiple folders, so you can store things however a supporting repository allows.

Beyond the Names

Did I mention that Kas correctly pointed out that WCM is NOT a supported use-case for CMIS. Check out slide 12 of John Newton’s AIIM presentation. Records Management and Digital Asset Management are also not use cases.  There are two things to note here…

The first is that the slide is titled Not This Time. The current iteration of CMIS is designed to reach quick agreement on a baseline standard. I have heard multiple players discuss the “next” version of CMIS. The scope is being kept manageable to get it out the door with basic functionality.  I know from talking to a few vendors that they are intensely interested in adding some of the use cases listed on the Not This Time slide.

The second is that just because they didn’t design it to support the use case doesn’t mean that the use cases listed can’t leverage CMIS. Looking at WCM specifically, there are lots of things that are standard in WCM systems that are not supported by CMIS. There are couple of things that are supported though.

• Relationships: An explicit, binary, directional, non-invasive, and typed relationship between a Source Object and a Target Object. This includes the ability of an object to reference itself.  With the typing, many  relationships can be utilized, depending on the underlying repository.
• Policies: An administrative policy that can be enforced by a repository, such as an Access Control List (ACL) or a retention management policy. Those are two examples, but any policy that the underlying repository designates in their CMIS implementation would work.  While Retention Policies is the usage that I am most excited about, there is no reason it couldn’t be leveraged for other functions.

Compound documents aren’t explicitly supported, but I see the foundation for it already in the specification.  I am hopeful that it will be fully supported in 2.0.

The point is that we are dealing with more than just simple CRUD here.

One Last Point…

Kas mentions the relational model used by CMIS and the resultant CMIS-SQL language based upon SQL-92.  It is a valid point, but it is important to note that the Query component is, itself, an overlay on the CMIS Object Model. The 0.61 specification says:

The relational view of a CMIS repository consists of a collection of virtual tables that are defined on top of the CMIS data model. This relational view is used for query purposes only.

In this relational view a Virtual Table is implicitly defined for each queryable Object-Type defined in the repository. (Non-queryable Object-Types are NOT exposed through this Relational View.)

I’m not sure what alternative approaches that should be used that would work across multiple repositories.  I would love to hear approaches and how they could be applied to all repositories that might support CMIS.

Before I go any further, I want to thank Craig Randall for his sample application that helped me get started. That application is also available on the EDN as well. Read his write-up, Consuming CMIS WSDL in Visual Studio and then go to the EDN for his code.

I also want to thank Thomas Pole for helping to write the User Interface, design the object model,  and leading AIIM’s efforts around iECM and CMIS in general.  Some of the code you will see is his.

The AIIM iECM CMIS Demo code is currently hosted on the EMC Developer Network.  Registration is free, and they have a new Documentum Developer Edition which is also free, so check it out. Down the road this code will also be place in a vendor-neutral location.

I’ll be at EMC World co-presenting on CMIS, so feel free to stop by and talk to me about the demo or anything else for that matter.

The Links

Here are some important links, including the one to the download.

• My entry on the EDN where I talk about the download and you can actually retrieve the code and a couple of supporting files: CMIS Federated Search Code from AIIM iECM Demo.
• My post where I talk about writing the demo: How the iECM CMIS Demo for the AIIM Conference was Made.
• There are two previous posts where I talk about what the CMIS Demo is trying to achieve: AIIM’s iECM Committee, Validating CMIS and Update on the AIIM CMIS Demo.
• The actual live system: AIIM iECM CMIS Demo.
• The recorded webinar I did with Alfresco talking about CMIS and the AIIM iECM Demo.

The Notes

This is just a cut-and-paste of the notes regarding the demo.  You can read this directly on the EDN as well when you go to download the code.  Enjoy.

Attached are all the files you need to get a copy of the AIIM iECM Demo working. As it is configured, it will work against the public Alfresco and Nuxeo sites as well as a local Documentum installation.  It is setup to work against the CMIS v0.50 specification.

For more information on how this system was developed, read my post on How the iECM CMIS Demo for the AIIM Conference was Made. You can also see me co-present on the topic of CMIS at EMC World or watch the recorded webinar on CMIS that I did with Alfresco.  You can find out more information on CMIS here at the EDN or on my blog Word of Pie.

If you don’t have a Documentum system, try the new Documentum Developer Edition.

Updates will be posted over time to match the current standard.  CMIS 0.61c will be the next version supported by this code.  You can currenlty utilize the current version online at the AIIM iECM Demo Site.

Notes:

• The “CMIS_Project.zip” file has the Visual Studio 2008 project. It was written in C#.
• \CMIS_Demo directory has the locally run project
• \iECM-CMIS-Expo-Demo directory has the IIS Deployable project
• SecurityMessageInspector handles the Web Services sercurity and is based heavily on code from Craig Randall of EMC.  His original sample project can be found here in the EDN.
• The web.config file lists the existing services definitions and passwords. To change any of the destination URLs, do a global Search and Replace across all the files in the project.
  • Service URLs can be found in the web.config file by search for #AIIM_Services
  • Passwords can be found in the web.config file by searching for #AIIM_Passwords
• The existing hosts are:
  • Alfresco: http://aiim.alfrescodemo.com/alfresco
  • EMC:http://192.168.1.4:8080/emc-cmis-ea
  • Nuxeo: http://tamise.nuxeo.com:8080/nuxeo
• You cannot retrieve content from the Nuxeo repository as this service is unavailable
• The “iECM CMIS POC.dar” file contains an installable Documentum application that installs the aiim_content type and some sample content to search against.
• The “Object Model.xls” file explains the deployed object model.

If you have any problems or questions, leave a comment, track me down at EMC World, or contact me through my blog.

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.

Before I do that, I want to offer thanks to the following:

• Thomas Pole: Thomas is the chair of the iECM committee for AIIM. He was in charge of this demo and was able to identify a host platform for us to run the system on for no charge.  In addition, he built the User Interface while I focused on the back-end components.
• Betsy Fanning: Betsy is the Director of Standards at AIIM.  She helped keep us on track and coordinated with the various vendors that participated in this effort.
• The iECM Committee: They helped make sure that what we were doing made sense from a business perspective and worked with us to develop the requirements and design.
• The Vendors: This is more than the obvious ones. I’ll go into more details in a subsequent post. I just want to say now that all the vendors involved worked hard in this effort. Just because you don’t see their content right now doesn’t mean that they didn’t participate.
• Harris Corporation and Washington Consulting, Inc.: Thomas’s and my companies, respectively, helped us by allowing us time and additional resources to build and put our pieces together. We both have full-time day jobs and only support from our companies made this possible.

Okay, on to the show…

What Is the Fuss About?

When the CMIS standard was first announced, I mentioned to the committee that we, as AIIM’s Interoperable ECM committee, needed to have some sort of response.  We tossed out a few ideas, and moved ahead with some. I believe it was Thomas who thought of doing a demo for the AIIM show. After some work we came up with an initial idea. All we needed now was content that we could share publicly and vendor participation.

Oh yeah, and we had to have it all built in 2 months.

We got a lot of vendors to show interest and join us on a few calls.  We developed a data model and decided to write this in .NET and use the CMIS SOAP bindings.  The reasons were simple. Our free server was an IIS server, so .NET was the obvious choice. Visual Studio makes it easy to consume Web Services and we had access to a sample CMIS .NET application using the SOAP binding. Considering the tight time-frame, that was key.

During that time, we learned that we couldn’t user the AIIM presentations.  We had to use old articles from AIIM’s E-DOC, now Infonomics, magazine.  Betsy led this effort and got the issues to the vendors for serving to the users.  Vendors were encouraged to supplement the content with their own marketing material.  The tagging was left to the vendors, though we helped as we could with the access to their systems that was provided.

Remember, through all of this, Thomas and I both have jobs and clients.

A Draft Standard Implemented by Beta Software

That pretty much sums up the issues that happened going forward. Whatever a vendor calls it, the CMIS implementations are betas. That isn’t a slight against the vendors as the standard is still a draft.

Vendors began to learn that they couldn’t participate. They had valid reasons.  Some didn’t have mature enough SOAP implementations of the CMIS standard yet.  Others were unable to get a CMIS interface exposed to the Internet in time for the show. Some had both challenges. It was a tight timeframe, so getting more than one vendor to participate was impressive, and all that was needed.

Without going into a blow-by-blow description, let me characterize the issues. Assume each vendor has 80% of the SOAP binding implemented, you can bet only 60-70% overlapped.  I found variations, and bugs.  The bugs were quickly fixed.  When the implementation didn’t match the spec 100%, I let them know for future reference and used their implementation as it was. Don’t get me wrong, working on slight variations of the CMIS standard was infinitely preferable to working on vendor specific interfaces. Visual Studio found most of the differences for me automatically and quick emails to the vendors cleared up any other questions.

Did I mention that all the vendors had mutually exclusive support for WS-Security authentication models? I learned a lot more than I had planned.

You Want a Link?

After reading all of that, I guess you want to see it. For a limited time, you can try the demo here: http://aiim-iecm.org/cmisdemoc. There may be some enhancements over the next several days, but no promises.  In a week or so, it will be gone.

Enjoy and remember.  We could add other vendors in an hour if their implementation supports the standard (and they don’t use another method for authentication).  That’s it. That is the power of CMIS.

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

Emails streamed to me all day alerting me to this announcement, and I was blissfully offline.  Now I wish some people (you know who you are) had told me to pay attention this morning.  As it is, I’ve decided to let everyone of you know about it and give some thoughts to the effort.  I still have to review the actual specification and find out what this means to each of the key vendors.

Who is They?

This standard was developed by the “big three”, EMC, Microsoft, and IBM.  I like those three.  IBM is strong in SOA and a proponent of this architecture as a whole (and it might let their ECM products work together).  Microsoft is the popular gorilla in the room and without them, SharePoint would be left out and it would fail.  EMC, well, implementing their products has been paying my bills for years.  These days, other vendors are helping to pay those bills as well, but EMC still has the lead.

Oracle anyone?  They were at the table.  Also there was Open Text, SAP(!), and everyone’s favorite open source ECM vendor, Alfresco (who has an initial implementation already!).  These companies all bought into the submission.  I would love to know the story of why the three are those three and not four.  That is a whole other train of thought and is something for later.

The important thing is, just about everybody’s list of the top three or four vendors includes the companies in the collaborative seven.  This is important if adoption is ever going to happen.

Learning More

I have only had time to sample some of the coverage out there.  I have a few more posts to write on this topic, including coverage.  In parallel, I’ll dive into the actual specification and provide some real comments on the whole thing.  There are a lot of people to talk to out there.

• Kas Thomas at CMS Watch chimed in with his initial impressions.  He is skeptical and he recalls the JSR standards.  The JSR standards failed because they are a Java API.  That limits its usefulness when communicating with non-java ECM systems.  This is language neutral and going to a broader standards body for approval.
• Chuck Hollis at EMC has a great sales pitch for CMIS on his blog.  It is also well written and reflects many of the themes that I have been harping on for over a year now.  If you’ve been reading my blog for any length of time, none of it is new, but it is GREAT to see it espoused by senior management at an ECM community.  (More on EMC and this standard very soon.)
• The 451 Group has a post on CMIS that is fairly balanced.  It also has a bunch of links that I will be following as soon as I hit Publish on this post.
• Good to see that Bex is in the know.  Once I get up to speed, I’m going to enjoy the back and forth.

Stay tuned.  The next week should have a lot of activity here as I learn more and distill it all for you.  I don’t see a lot of sleep happening until I get a firm handle on everything.  Unfortunately, clients still need attention this week, so it will take me a few days to get everything covered.

I can’t promise what my next post will be about.  I have too much bubbling inside that is trying to come out.  Enjoy the ride before we settle into the reality of approving a standard.

This is just the beginning.  Let’s make sure it isn’t the end.

KM is Dead, Long Live KM!

Everyone knows that KM died. The term became a very scary thing for executives to hear. It meant money and time gone. It meant undelivered promises. It did, and still can with the wrong approach. Let’s start simply with what is Knowledge Management.

Knowledge Management isn’t the Management of Knowledge. That just sounds nice and fits well with all the other buzzwords from the 90s. It is a means of capturing an organizations knowledge and allowing others to access it. You capture it so others can find it. Simple. Everything else is details. So lets look at some details on Capture.

What are you trying to Capture? Well, some knowledge is stored in the content of an organization. Other knowledge is distilled in the many structured systems like CRM. How successful projects and teams work is also knowledge. Let’s not forget what is sitting in people heads and shared over a water cooler. I’m sure there are other items as well.

Storing content is easy, and the bedrock of any good KM, Social Media, and many enterprise applications. Content is distilled knowledge from one or more authors. Once Captured, this content becomes potential knowledge for others if it can be discovered. More on that in a minute.

Data from the CRM system, or other enterprise applications, is even easier to capture than content. Capturing how successful projects work requires them to either write lots of things down, or to have them work online so it can be observed and captured. As for what is in people’s head…still manual and difficult. Discussions, wikis, and blogs can get some of that knowledge captured by turning it into easily contributed content. Incentives can help increase that percentage even more. (Forget the carrot though, I work for either cookies or frosty beverages.)

Now that I have “Captured” everything, how to I find it for use? Assuming you had a smart Change Management plan in place and people use the system at all, this is where things fall down. Search engines are stupid. They are smarter than they were 10 years ago, but they have a long way to go. You can remedy this problem with tagging and metadata, but depending on all users to spend the necessary time can be a risky gamble.

Then there is all of that information in the various corporate systems. It is just information until it is analyzed and placed into reports and charts showing trends and usable tidbits. It needs to be easy to access and it needs to be served-up in context with other relevant information. That information can be anything that has been captured. Mash that stuff together.

As for the last two captures listed, that is what good, advanced, collaboration tools can provide. They work much better when other items are integrated into the whole, like ECM behind a Social Media application or eRoom.

The Challenges of Discovery

This is the biggest problem for Knowledge Management in my book. Solving this also led to the older beliefs of what a KM project entails. Taxonomies, hierarchies, and meta data libraries are the tools that were available to use in the beginning. Users understand putting something into a folder structure, they do it all the time. If a taxonomy is well-defined, then users can find content much more readily.

That wasn’t the only factor that was needed for success, but that is the defining characteristic that people remember about KM systems. The collaborative solutions of today, linked with our re-envisioned ECM platforms (plug for ECM 2.0) can provide new approaches to cataloging information. Ratings, recommendations, tagging, and linking can help identify content in such a way that search engines are almost useful.

KM isn’t dead. KM is evolving. Things have continuously evolved in the capture arena, but the advent of Web 2.0 technologies are allowing KM to be reborn into something that is easier to use. Enterprise 2.0 isn’t the realization of Knowledge Management. Enterprise 2.0 is the next stage in the evolution of Knowledge Management. (Did I just try and define Enterprise 2.0? I thought I wasn’t going to do that? Oh well, back to the main thought…) Like the introduction of the opposable thumb, Web 2.0 technologies are making KM look around and find new and better ways of using the information that was already around us.

As for the discussion about SOA and Enterprise 2.0, the correlation depends. If you accept the premise that Enterprise 2.0 is the evolution of KM, the SOA is right in there. Remember, KM needs information from all sources put together in context. SOA allows that information to more readily be surfaced.

Mashups and Knowledge Management is a beautiful marriage. SOA makes it happen.

Everyone get out your bingo cards, its going to be a wild ride.

The What…

Bex begins by offering a definition of Enterprise 2.0. For handy reference, here it is:

Enterprise 2.0 is an emerging social and technical movement towards helping your business practices evolve. At its heart, its goals are to empower the right kind of change by connecting decision makers to information, to services and to people.

Pretty simple and straightforward. I like aspects of it. I love the word movement as that pushes the effort beyond the technological. It does beg a lot of questions, such as, “What is the right kind of change?” In the end, I think it fails because of its vagueness. Kudos to Bex though for even putting forward a definition, something I’m not willing to attempt.

Bex’s post spends a lot of time on what Enterprise 2.0 isn’t. This part of the post holds great value. I agree with every single of the five points. I have a few comments on each:

1. Too much information can be a problem. Information needs to be transformed into knowledge. With structured data, this can be done through reports and business intelligence tools. With unstructured data, aka CONTENT, this is best done by people tagging and collecting. As search technology matures, it will be able to do this for us, at least better than it does now. This is an old-fashioned Knowledge Management goal.
2. End-users need solid business applications. They may consist of Services, but Users consume Applications which consume Services. It is a food chain. My only problem here is wondering if this is Enterprise 2.0 or just smart Enterprise Architecture design for the SOA world. Like point 1, this isn’t a new concept.
3. This point is Enterprise 2.0 to the core. Let’s face it. I could be connected with 1000 people, but if nobody will collaborate with me in solving a problem, what is the point? If I have 10 good connections, I can filter out the junk and we can focus on solving the problem at hand. The interaction with Bex and Billy is more valuable to me than it is with some senior Documentum architects (not referencing Craig as he is pretty darn useful) because they actually engage in dialog. It isn’t enough to be have things in common, but to contribute to the whole to create something greater.
4. Evolution is always the goal. Change is good. A way to manage the change and allow for change to continue as required is better. In ECM terms, if I implement an ECM system, it will only last as long as the initial initiative if a governance mechanism isn’t put in place to oversee it for the future.
5. This is simple project management. Bex implies an extreme, but it is a valid concept. Take a small pilot and see if it works. If so, GREAT! If not, then learning why has value. The person may not earn a promotion, but they should earn a chance to apply the lessons-learned. Too often, these failed pilots have no follow-on effort where the lessons would be useful.

Hmmmm, not as much Enterprise 2.0 as I thought. Of course, that is just my opinion. Let’s look at…

The Why…

Bex talks a bit about “Why”. It isn’t stated right out, but Mark Masterson asks Why is Enterprise 2.0 is a Good Idea in a post to which Bex links. The fact is that the question, much less the answer, is missing from most discussions that I have read. Why is Enterprise 2.0 good? It sounds progressive. So did the web in the mid-90s. Most of websites sucked. Some were cool, and that led every company to want external sites and web-enable their applications. “Why” was left in the dust.

Now we have the Whe for the web. Internally we can deliver applications to a wide audience without fussing too much with the state of their desktop. The ability to write one application, deploy it to a few servers, and have it work is much better than directing people to a shared network drive and install an application, or pushing it down to each desktop. It was a good time to run a helpdesk.

Nobody asks why you need an external website now or what purpose it is trying to serve. Usually the focus is on which Why to address first.

So let me ask you this, what is the purpose behind Enterprise 2.0? What problem is it trying to solve? Until we hash that out, we aren’t going anywhere. I have a few thoughts, but I want to explore the concept of structural holes in more detail first. I’d also like to see if anyone else is going to play. (That is a hint, Chuck and Gordon.)

Enterprise 2.0 as the Next Phase of Knowledge Management

I’ve seen this theme a few times and I can understand why Bex is not enthused. I’m not ruling it out. Aside from helping frame the “Why” a little better, it is still a good goal. Bex talks about efforts 20 years ago. I remember efforts 10 years ago. There will be more efforts in another 10 years. The thing that Bex points out, but misses at the same time, is that these iterations provide value.

Be it full-text search, ECM, portals, social media, or mashups, these technologies all help to solve the “knowledge problem”. It isn’t just a matter of storing and retrieving knowledge. It is also a matter of enabling the creation of that knowledge. You need people to be able to connect and work together. I learn a lot by stopping by someone’s office and talking to them. What if they are in a different part of the building, campus, country, or world? Swinging by the office can become expensive and time-consuming.

Does Enterprise 2.0 help us address those gaps? Maybe. Is it more than that? I think so. How much of Enterprise 2.0 is Web 2.0? (BINGO!) I would say it is the part that makes it new, but not the foundation as Bex alludes.

That is why we need to work on the Why of Enterprise 2.0.

The funny thing was that when I read the name of his post, Poking the Bee Hive, I was watching a Dr Who episode featuring a giant wasp. Weird stuff.

I’m going to bypass the editorial stuff discussion for the most part. That is a matter of opinion and Billy had a co-author and editorial staff to answer to when writing the article. Like Billy, I want to focus on the intersection of Enterprise 2.0, SOA, and ECM. That is the meat of his article and the part that can actually lead to greater understanding on everyone’s part.

So while I wait for Billy to start his side of the discussion, I will poke the bee’s nest some more.

ECM Supports SOA

This is a no-brainer here, and one for which I think Billy and I are on the same page. If so, then we can just move to the next section. Both SOA and ECM pre-date Web 2.0 and work well without any Enterprise 2.0 applications. There is no dependency in that direction.

I think my initial disappointment with the article was that it was titled ECM and SOA. There is a lot to write about on this topic without any reference to Web 2.0 and Enterprise 2.0. The whole concept of Transparent ECM, ECM 2.0, is built for the SOA world. There is a lot of benefit to be gained from combining these two technologies that doesn’t require any of the new Enterprise 2.0 mind set.

Not to say that Enterprise 2.0 isn’t useful….

Enterprise 2.0 Enhances Knowledge Management

I wrote a while back on how Enterprise 2.0 really enables that old mystical Knowledge Management solution that people have been chasing for years. While the observations are more directly related to Social Media, that encompasses much of the Web 2.0 mind set. All of these new tools enable collaboration with participants that used to be purely consumers.

SOA and ECM can both improve upon this, but neither are required. Yes in an ideal world, they will all co-exist. The only problem is that I have never met anyone living in an ideal world. Let’s look at ECM and Enterprise 2.0…

ECM can heavily benefit from Enterprise 2.0. Better tagging and discussions around content. More dynamic work areas. Life is good.

Enterprise 2.0 can benefit heavily from ECM. Centrally storing blogs, wikis, and discussions can allow for content on public sites to be captured as a record for liability issues. Content generated on a site in one country can be translated and pushed out to a site in another country. Let us not forget any moderating of that content that can take place.

These are great things. No SOA required.

When do you need SOA? Ideally when you want two systems to talk together. You can give any application that Enterprise 2.0 make-over, but what happens behind the scenes is independent of that. The need for SOA exists outside of Enterprise 2.0.

Having all three is nice, but you can have any two without the other. (Note: Enterprise 2.0 and SOA without ECM does seem a little silly.)

Problem?  Yes, problem.  The problem is that nobody knows what to do to make everyone play together.  I’ll tell you right now, playing together is required.

Partner for Your Thoughts?

In the expo area, every other partner had a SharePoint/Documentum solution.  The rest were either storage partners or ones that won’t have a booth next year.  SharePoint was that popular.  I had a heck of a time talking to colleagues and friends working booths with SharePoint solutions.

There are a lot of solutions out there.  A majority of them focus on creating Web Parts and using them to interact with Documentum.  These are basically using SharePoint as a portal.  I was able to throw several requirements at each partner that showed gaps in their solution.

That isn’t to say that the solutions were bad.  Far from it.  Many were innovative and implemented well.  I will be keeping several of them in mind for use at clients.  They are just solutions to aspects of the bigger problem.  They aren’t a true joining of the two technologies into something that can work for the Enterprise.

They are old-school solutions using new technologies to jazz them up.

EMC and SharePoint

EMC’s status was both disappointing and reassuring.  The disappointing part is that there is no architectural improvements to the solutions being offered.  They are basically the same as those last year.  The reassuring part?  Simply put, they looked at what they had been working on as a next step and realized that it wouldn’t solve the problem either.

A lot of what I learned was that the SharePoint team has been trying to determine where they can best add value for their customers.  Trying to do it all would equate to no solutions in the short-term, and people need help NOW.  There are a couple of levels to the help needed, which I, and others, shared with Andrew and Erin.

The biggest need is to take the content out of SQL Server and store it in the Content Server.  It can’t end there though.  If content is just going to be stored there, why not throw the content on a secure file share?  Easier and cheaper.  To store it in an ECM system, you need to add business value.  The act has to “enable” the content for use throughout the organization.

The added value is the crux of the problem.  If you are going to interact with the content through Documentum or in some other interface other than the original SharePoint site, you have to take Identity Management into account.  If someone secures a document in SharePoint, shouldn’t that be reflected in the Content Server?  If a records administrator locks a document down in the Content Server, shouldn’t that be reflected in SharePoint?  These permissions, and the users and groups involved, need to be everywhere.

My favorite challenge presented by Andrew on this thought, and he had an excellent point, was what happens if a user wants to remove it from SharePoint, but they don’t have rights to delete it in the Content Server?  Do you allow the user to delete the shortcut in SharePoint or fail the operation completely?  My answer: YES! It should be configurable by installation and site, and transparent to the end user.

ECM 2.0 is key here.  The SharePoint user shouldn’t know that the content isn’t stored in SharePoint natively.  It should appear as if they were only using SharePoint.

What about throwing Lifecycles and Workflows into the mix?  I can see EMC providing some actions on a document through actions to the document library, but leave the web parts alone.  The partners are ahead on that and they are doing quite well.

EMC should probably play the leading partner solutions up on their website, delineating what they do and emphasizing the value that they provide.  It should be very visible.  The partners and clients would LOVE it.  Thus, it probably won’t happen.

Did You See That?

Yes, I threw in the need for Identity Management up there.  Just because we want users, groups, and access control lists everywhere doesn’t mean I want to go everywhere to administer them.  I want to manage it all in one place.

I hit the DFS people up on this need and told Andrew why he needed it as part of his solution.  SharePoint and Documentum should work together using an ECM SOA standard.  A key aspect of this is the ability for the systems to share Authentication and Authorization sources.  This is a problem that everyone faces.  The first ECM vendor to solve it will have a leg up on the others when it comes to being the backbone of the Enterprise.

Right now, if you lock something down in SharePoint, you have to lock it down separately in the Content Server.  The exception is content exposed in Web Parts.  The content isn’t really in SharePoint, which limits the ability to truly collaborate.

Is web parts the answer?  Kill Document Libraries and just use the web parts?  That solves the problem on some levels, but it isn’t what I would call ideal.  It turns SharePoint into a portal and shifts the focus away from being a collaborative platform. That is its strength and why it has spread so widely.

Take that away and we may as well wait for Magellan. 

I chose poorly…

Billy Cripe has just had an article published in the May/June edition of AIIM E-DOC. I was excited. I usually see one or two articles in each issue that catch my interest, but I am always underwhelmed by the content. I wasn’t this time, I was just disappointed.

It All Falls Apart

I want to start with the simple disclaimer. I respect Billy and I firmly believe that we have the same vision of ECM 2.0 and where it is going. He always has seemed to have a firm grasp on all the relevant technologies. That didn’t really change after reading his article. I am disappointed in the way he delivered the message.

I think the best way to sum-up my thoughts on the article was that after the introductory paragraph, I wanted to yell BINGO! (though I love SOA-izing) to all of my fellow commuters. I got the impression that Billy was trying to cram too much material into too short an article. It felt rushed.

Let’s dive into the content now shall we?

Web 2.0 Gone Wild

Instead of focusing on SOA and ECM, Billy focuses on Web 2.0. Actually, he says he is talking about Web 2.0, repeatedly, but he is actually talking about Enterprise 2.0 for most of the article. That drove me nuts. To be fair, many readers may not know Enterprise 2.0 well, but it was up to Billy to address that early in the article. AIIM has been trying to embrace Enterprise 2.0, which makes great sense, and this was an opportunity for Billy to link it together.

In the concluding section, Billy says Web 2.0 in the enterprise, or enterprise 2.0 if you will. This would have been a great line at the beginning of the article. In a sidebar Billy does define Enterprise 2.0, and I liked it:

Enterprise 2.0 can then be defined as bringing Web 2.0 expectations, technologies, and design approaches to bear on processes, applications, and employees in a managed environment across a business.

Great. When taken in conjunction with the rest of the sidebar, I think it safely lays the foundation for the rest of the article to be framed as a discussion around Enterprise 2.0. Web 2.0 is not Enterprise 2.0 and I’m afraid that some of the readers may get that impression.

Web 2.0 vs Enterprise 2.0 vs SOA

The one thing I did disagree with Billy upon was some of the dependencies that he laid out for some of the technologies. ECM has to work in an SOA environment have to work together independent of the whole Web 2.0/Enterprise 2.0 world. Storing Content in an ECM system so that it can be accessed in a CRM system or SharePoint is a great idea that is facilitated by a SOA environment.

On the other hand, you can have Enterprise 2.0-style solutions in environments that utilize no SOA technologies. Let’s face it. If every organization waited to have a Service-Oriented Architecture before implementing Enterprise 2.0 technologies and solutions, then Enterprise 2.0 isn’t going anywhere. There are lots of platforms out there that can assist in delivering an Enterprise 2.0 environment that can stand-alone or integrate into an ECM system.

Yes, ECM and SOA make Enterprise 2.0 better, but in no-way are they required.

Final Warning

In the article, Billy says, the risk of adoption is less than for brand new technology. I disagree. The technology may be more proven, but there is a lot of organizational change required. I would even argue that as Enterprise is a new way of doing business that the mind set change is much more dramatic than implementing a CRM or ECM system.

Enterprise 2.0 isn’t just a new way to do a job, but a new way to think. It changes the job description, not just the execution of the job. This change isn’t easy. It can’t be rushed. Throwing it all at an organization at once could backfire. It depends on the technological maturity of the organization.

The maturity isn’t based upon what applications are running behind the firewall. It all boils down to the exposure that the people have had to technology in general. If an person doesn’t use the technologies in the Internet, having them see the benefits in the Enterprise is difficult.

I’m not saying that it isn’t worth it. I’m just saying that it is just as risky as any technology deployment. It just needs a deeper focus on the Organizational Change Management to make it work.

The Myth of the iECM Effort

There is a belief circulating around the ECM world that the AIIM‘s iECM (Interoperable ECM) committee is developing an ECM SOA standard. Having been a member of this committee since the fall, with various levels of activity, I would like to say that it does not appear to be the case.

From what I can tell, iECM started working towards an ECM SOA standard, but before my involvement, it seemed to get sidetracked into developing Best Practices. Cornelia Davis was part of the earlier efforts and I would love some more history of the transition.

This is not to say that the iECM committee won’t step-up, but waiting for them is not wise given the ever-increasing need. I stood up and stated this in a public forum at EMC World. I plan to step-up my level of participation with iECM, but it is difficult to justify the time when the efforts don’t seem to be moving forward in the needed direction.

The Non-Announcement

In two different sessions, it was revealed that there is an effort by several vendors to develop an ECM SOA standard and that an announcement was expected this September. Like all forward-looking statements, things can change. EMC did share their vision for this, or any ECM SOA standard and what was required during their Standards session. They did this in the context of pointing-out all the weaknesses of the existing standards.

There is progress out there and it was strongly hinted-at that at least one other major vendor was involved. There is hope. I’ll have a detailed post on this stuff later.

I May Have Mentioned a White Paper

I, and a couple of colleagues, are finalizing a White Paper on ECM in a SOA environment. It talks about standards quite a bit and stresses the need for an ECM SOA standard. I am leading this effort, so this could be the lead part of the rumor.

Looking at James’s post, it points out the needs for several things. I agree with the need for all of them and I am doing what I can to support those efforts where I find them. One thing I am doing is pushing for the documentation of ECM Design Patterns, at least in the context of Documentum . I may even take a leadership role there, if one develops in the community.

Oh, one last footnote to James…I will be talking about your questions you wanted me to ask at EMC World in the near future. You just have to be patient.