Technology of Content

I noticed that content enabled vertical application recently became the top search entry point to my blog. Now as I have only written one article about this, and it rapidly rose up the Google rankings, I reckon there must be a dearth of content on this subject. I guess that may not be too surprising, as it was initially a Gartner attempt to describe a path people wanted to follow rather than a generally used description. Gartner have also decided that the content enabled vertical application (CEVA) is now called the composite content application (CCA), possible to confuse everyone even further. But they do matter to your content strategy.

So what are these, why do you want them, and what do they mean for your content strategy?

Toby Bell at Gartner says

Smart companies have begun linking more of their content to industry-specific, human-centric processes, such as insurance claims handling, or supporting research on new drug development. This approach usually means building or modifying the content-enabled vertical applications (CEVAs) on top of ECM environments. CEVAs typically help to automate complex processes that previously required workers to manually sort through paper documents and other forms of content (in effect, a way to manage down costs of exception handling) and optimize the remainder of the work.

This seems to be not a great summary though. Look at it from another view. Your enterprise content was disorganized, living on network shares, random websites, legacy systems, all over the place. Your ECM strategy was to first to consolidate to reduce costs of multiple systems, and to improve findability, get to a base enterprise content management position. But what next? Where is the next value?

Content strategy starts here. There are many parts to this, covering creation, lifecycle and reuse, audit, consolidation quality and so on. The CEVA part is about the delivery and interaction with content within other non content focussed areas of the business. Content management often seems to be about specific content focussed parts of a business, such as, historically, technical documentation and, more recently, online marketing material. Plus a load of unstuctured stuff like emails and generic office documents. The areas such as technical documentation have had high value often for legal and regulatory reasons, so structured processes were created early; these effectively created the content management industry initially. Web content historically had different solutions because it turned up and became important when the general purpose tools (Word!) could not usefully author it.

But all the stuff classified as “other” does have underlying processes, content processes. Some are formalized in systems, the original paperless office systems, the roots of the document management industry in forms and scanned paperwork processing. This stuff generally sits more on the “data” not “content” side of business processes. Long term this distinction is not such a useful one, and data and content resources will merge together into a single enterprise resource architecture. The majority of processes with content though take place through informal channels, particularly email with Microsoft Office documents. These are the document types you tried to take control of through ECM.

So ECM took the documents that were behind many processes and made them findable and organized them. But at the base level a content repository is just that, a repository. It deals with basic issues such as versioning and permissions, search and findability, and some organization, but it does not really deal with process and processing.

Process and processing are the valuable parts in the lifetime of most content. Imagine the lifetime of an insurance contract say, with payments and claims and disputes, or an employees personnel file, or a technical manual over the lifetime of a product. A CEVA or CCA is an application to support these lifetime processes.

It is also an application to support the relation of a document’s lifetimes processes to other systems. Your CRM system may need to know about insurance claims, your sales department may need to know about expiry, your website may need to know about new documentation releases, content changes do not happen in a vacuum.

One class of CCA that is common but is rarely perceived as that is a software application with embedded content. Once that was just embedded “help screens” with content tools to manage them, then came internationalization, with a different set of tools. But these desktop applications are being rapidly replaced by web applications. Web applications are much more content driven, they may live in an SEO facing world, they may live in a customer facing world that may consider usability, they may be multilingual, and they are not driven by the developer-centric ideas of help screens and manuals. Content and application can live together, but this requires new ways of using, reusing and versioning content, and pulling content out of application release cycles so it can reflect non application changes, such as the marketing environment, usability improvements, corrections and enhancements. These applications were historically development led but as they mature the content aspects become key business drivers, needing content management integration.

So what do you need to build this type of application, and what should your decision criteria on platforms be?

Stéphane Croisier says in a good survey “So rapid raw composite assembly, fast integration and ease of use are the three new pillars of next generation content solutions.”

The first thing to bear in mind is that you need more than a repository, you are looking for an application platform too. The ease of use issue is important. Long term you need to be looking for something that staff can build simple tools from, even if you are hiring specialists for the complex projects. Ease of use is a two way thing, as you need an easy to use platform that lets you build easy to use applications. And ease of modification and maintenance is equally important as these applications may need to be fluid. You are likely to need external support to build more complex applications on the same platform, so availability of this is important too. Ignore the jargon of portlets, widgets and mashups: none of these so called standardisations have much traction; we are talking application development, use what you have or can hire developers to do. Ask the vendors what their platform strategy is.

Stéphane identifies a trend towards solutions, ready to go solutions for common problems; these may be useful but I would not choose a development platform on the basis of the availability of particular solutions or you may end up buying a platform for every solution. A longer term view of the viability of a platform for other solutions is necessary too.

Long term, remember that content application strategy is part of content strategy, and comes after that. You need to know what your content applications are and will be, and have built an underlying respository, authoring and reuse strategy first. Applications are where developers need to interact with this to achieve the long term goals.

Tagged: applications, CEVA, content