Content services platforms enable multi-context records

Content has context

Content does not exist alone. It has a context and is typically part of a larger business object. It isn't just a tax return; it is a financial document for a person. It isn't just an invoice; it is an invoice for a project. Whether you manage business objects in your content services platform or not, those objects exist within your organization.

Oftentimes, content services implementations store only the unique identifiers for a piece of content. The API may have the word invoice in the URL, but underneath, the content services platform executes a simple query for document No. 1910. That design is little more than a traditional file store.

What if you need to know all the invoices submitted by Excelsior Corp. while reviewing a new, multi-document proposal submission? You would need to query the invoicing system to find all prior invoices, then query your content services platform for each individual document.

This multistep process might seem workable, but you've just tightly coupled yourself to two different systems to provide a single piece of functionality. What about other pieces of content, such as contracts or correspondence? How many additional systems and API queries would you need to make? It becomes much easier to link all the content in your content services application to the unifying context of the company -- in this case, Excelsior Corp.

Sharing context

What is the next step after you assign each piece of content to the appropriate context? Take the bank, for example. When you apply for a mortgage, there are many documents -- and if you've ever had a mortgage, you know how quickly they pile up. Those documents belong both to the mortgage application context and to the applicant context -- in this case, you.

When properly modeled and executed, content services enhance information reuse and provide businesses with the most contextually relevant information.

However, you aren't always simply an applicant. You may already be a customer. And if you aren't, when the bank approves the application, you will become a customer. Regardless of the stage of your relationship, you are always a person. Your relationship to the application or account provides the specific label for that business context.

When you apply for a car loan, you can use your existing customer content, linking the necessary documents to support your application without submitting them again. The system will associate the existing documents with the new car loan. That same tax return that is linked to the mortgage application is now also part of the car loan application. The loan officer can use this same process to review and connect additional documents.

Note that linking documents across contexts is selective. You wouldn't link a home inspection or site survey to a car loan. Those aren't relevant in the new car loan context, though they remain relevant to your mortgage account.

Behind the scenes

How this is done will depend upon your content services platform's modeling capability. For a single context repository, such as billing, adding identifiers for the primary context, such as a customer ID, is enough. However, you may need to augment your implementation as the model becomes more complex. Examples of more complex models include a person purchasing multiple vehicles or a joint mortgage application.

You need to model the contextual business objects and the links between those objects and the documents that live within them. When designing your initial model, consider your most obscure scenarios. While you do not have to implement those obscure scenarios in your model on day one, you need allow for it to eventually exist in your model. The situation only has to happen once to break your system. If you create a flexible design from the beginning, you won't have to make complex model changes down the road.

Though you should plan now for added complexity, it is likely that your content services platform may not be able to readily handle the full content model. But the use of content services enables you to use multiple systems to provide that functionality. If necessary, you can use a database to manage additional business data if your content services platforms do not support complex content models. Your content services implementation will hide that complexity from those using the APIs.

You do not have to have all the answers before you start. You simply need to think about the possibilities so you can make decisions based upon what you need today and tomorrow.