Content-Enabled Applications in the Age of CMIS

Craig Randall recently posted how he was presenting on Building Content-Enabled Applications at EMC World, at least until he was downed by injury.  Regardless of his injury, this is a topic of great interest to me and I had a few conversations over the past year with him on the topic.  I wanted to chime in on his post to both amplify it and see if we can get some dialog going in advance of the conference.

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.

10 thoughts on “Content-Enabled Applications in the Age of CMIS”

  1. Lee Smith says:

    Nice post Pie. I wonder if we’ll see the BPM products such as Pega starting to see their opportunity more here. After all the business value is not gained from having a content repository per se but more from the improvements in processing and the improvements in information visibility. Yes unstructured content is common within Case Management but there is also a need to bring this information together with structured information on the Case. By having the integration with the content repository standardised the BPM players could start to provide the front end and processing and not have to worry about the repository where the contracts, for example, are held. This could lead to an interesting development in the ECM industry where the products become a support service for the main application, thus moving them down the value chain somewhat, but it would increase sales opportunities for the products as they can be used to support more and more verticals.

    Like

    • Definitely. I worked on a project for a client a couple years ago that used Pega and Documentum for case management. It’s had a huge impact on the business. Essentially, the data in the BPM system is used to launch a custom client that displays the case information stored in Documentum. it’s nice, simple, and effective.

      Like

  2. I think answering these three questions is not as difficult as it seems.

    You ask…
    Am I ever going to move this to a new back-end?

    If you are truly writing a Content-enabled application, you likely have several back-ends. In fact, you may be pulling archived content from one system and more active content from another. It is a best-practice to build an abstraction layer for data-access to isolate your front-end app from the data. Ideally, this means any back-end changes only need to be addressed in the data abstraction layer. This may sound difficult and confusing, but the company I work for has implemented it several times with a set of web serverices or a code library. All with positive results. It is also the easiest way to isolate the front-end app developers from having to know the nuances of the back-end API.

    Do I want to package the solution for another deployment?

    In the time of being green and reusing application components you should definitely be considering which parts, if not all, of your app can be repurposed. Perhaps its by different departments, business units, or a globally distributed app. If you build a successful application the business will undoubtedly find other ways to use parts of it. So build it with configurability in mind.

    Do I have time and resources for a proper development process?

    I sure hope so. It seems everyone has time to do things over but never the time to do it right in the first place. If you can’t build a solid app to deliver you might as well get out of the business. There are a ton of methodologies that one can follow to build solid solutions without spending a lot of time and money. And anyway – what do you mean by a proper dev process???

    Thanks for the thoughts.

    Like

    • Great thoughts. I’m with you all the way here. The questions were more for the audience at EMC World that are developing applications in general, maybe just for their company, not necessarily for re-sale. Developing an application for sale as a product is quite different than creating one for a specific solution for a specific client. I want people to look at the differences, which these questions highlight, and think accordingly.

      I managed the AnnoDoc product way back and we architected it to work with Documentum and IBM’s Content Manager. Adding Content Manager was challenging because the product was originally from a consulting gig and the answers to those 3 questions were No at the time. We went and abstracted the data layer. It wasn’t difficult or confusing, but it took time to do it correctly. We did have more code to manage, but it was isolated and worth it at the time.

      As for “proper development process,” that was for developing a front-end application mostly from scratch versus modifying something that exists. They take vastly different amounts of time. If I have 2 months, I’m probably going to modify something that exists. If I have 12 months, making a custom app might be a possibility. Obviously a lot rides on the complexity of the requirements and the resources on-hand. A “proper development process” is dependent on what you are trying to accomplish. So the point of the third question was that if you don’t have a lot of time, you’re going to be modifying something and not building something.

      Like

      • Thanks for the reply Pie!

        I agree. There are a lot of factors to consider when developing an app like you say; and if you are not experienced doing it 2 months is a short time. What’s interesting on that point though is that I’m seeing our client projects average around 2-3 months in length so I think the design/development/system testing effort is possible in that time frame. But of course we can’t forget to include that requirements definition, user testing, and deployment tack on additional time.

        Like

  3. I can see where all the major search vendors should jump into CMIS, but I think Lee’s comment ref the BPM vendors is an interesting one. There are plenty of standards in the BPM space, but with the abstraction of the CMIS layer, why would’nt they want to take advantage of it.

    See my latest posting ref OpenText Content Day, I found it quite surprising that OpenText had developed a fat client that connects to LiveLink, eDocs AND Sharepoint. I guess the fat client route is because thats what eDoc’s users are comfortable with. So if you dont mind managing the client side infrastructure of fat clients, do OpenText, a CMIS supporter, have a big future selling a content management fat client that connects to any repository at all via CMIS ????

    Like

  4. Pingback: Leveraging CMIS to Create Strong Business Applications | Word of Pie

Comments are closed.