Standards and Content LifeCycle

For a lot of organizations, the content lifecycle includes much more than what typical ECM systems have to offer. Consider this scenario of an insurance company that offers different insurance products (life, auto etc) to their customers. People go to the website, compare products and select the one that they want to buy. They then enter their details etc which is fed to the backend systems where based on profiles and information, a quote is generated and an offer is made. This is obviously a simple scenario and things are much more complex. Now consider the number of applications that are required for this:

1. A form based front end. In order to differentiate form competition and take advantage of so called “Web 2.0” RIAs, most companies do not want to use simple html based forms. So there is a whole new area of e-forms (also called smart forms etc) which are basically rich UI forms for capturing information. These forms are dynamically generated based on requirements and offer a superior user experience. Products from IBM, FileNet and Microsoft lead the pack here.
2. Most of this is also dynamic because you might need to generate a different form based on answers to questions. So for example the insurance application can have an application with multiple forms and each subsequent form is generated based on the answers given in the previous form. So you need some kind of a rules engine to implement the logic. You can obviously implement a complex “if..then..else” logic in your code but you will need a rules engine for any sophisticated application.
3. A business process management application to manage the process behind the scenes. So after a person has applied for an insurance product, there is a process of approval etc. Sometimes you could use ECM’s workflows for this but often a BPM is much more than content specific workflows.
4. A Document Generation system to generate policies and quotes often in PDF or some other printer friendly formats. You also need to be able to generate mailers and send bulk mails.
5. Often customers send faxes or physical documents. So an interface with imaging and faxing systems is also required.
6. Obviously an ECM system if you want to manage all the content so generated.
7. And finally a Portal or a delivery environment to expose this functionality.

There could be more applications in the play but this gives you an idea. In my opinion, all the above things are about managing content and in that sense they should form a part of content ecosystem. The way things currently stand is that most of the products above have similar and overlapping features. For example, most eform products have some kind of workflow and BPM capabilities and most ECM products have some kind of forms management capabilities. If an organization needs to have all these features, they need to invest in many products and there are many integration challenges apart from the fact that there is a lot of unused functionality as well as duplication of effort. Wouldn’t it be nice if content generated by eforms product could directly go thru a business process and get archived in the ECM product and then the document generation product could directly access the ECM repository to generate quotes?

I think there are two ways to overcome these challenges. As i wrote before, most of these things are related to content management and ECM vendors should expand their offerings to offer these features as well (eforms, document composition, rules and BPM). Standards can play a big role here. James has often asked ECM vendors about lack of standards. I think it’s not just the ECM vendors but a whole lot of others who need to think about standards because if all these products have to speak with each other, each of them should implement some basic standards at the very minimum.