Can you first just tell me what an object model is?
In ECM, your object model is king. An object model is the organization of your digital content into specific types of folders and documents, as well as the attributes that reside on each one. It dictates so much about your system, both in the literal sense (here are the attributes that a type has) and the productivity sense (here is the hierarchy of my types that can make searching easier). That is why it is essential for a business to understand their object model and get it right from the start, especially since having the correct model allows users access to all of the metadata they need on the types they need them on from day one. However, as businesses and data evolve, the need can arise to alter an object model.
Why would I want to change my model?
There are numerous factors that can lead to an object model change, but three are the most common: we have new metadata we need to keep, we have old metadata we no longer need and we need to be able to search on multiple types at the same time.
Let’s tackle the last instance first, what exactly does that mean? Let’s say an insurance client has two major types of documents – claims and policies. Normally, one division handles claims and one division handles policies, and everyone can search for their documents without any problem. However, one claims adjuster has mentioned it would be great if he could see all the claims and policies paid out to a particular claim number, which is a metadata field on both types of documents. Sounds pretty straightforward right?
Well, if the object model was setup in a flexible way, it is very straightforward! You just need a parent type setup (called insurance document for example), it needs a claim number metadata field setup on its type, and both the claim and policy types need to be children of the generic insurance document. Then the claims adjuster can just search for the claim number on the “insurance document” type, and both policies and claims with that number will come back. The only catch is that generic insurance document type needs to be setup beforehand. The same thing applies for attributes that we now want to add on or remove after the fact, they should already be a part of the model.
Ok, but why can’t I change the model? Isn’t it just configuration?
Well yes, the object model is just configuration, but it is a very special configuration that drives your relational database behind the scenes as well. All of the tables have been created with special relationships and columns, and everything that was there from the start needs to be there at the end in order to keep everything working. On top of that, your index for quick searches is also built from your object model and is very particular that it never changes. In order to change those database tables, all of the rows (essentially, your metadata) would need to be removed before you could alter the table. Then all of the relations to the table would need to be redone as well to take into account the changes done to the table. Lastly, you would need to re-index everything in your content store, which normally takes multiple days depending on the content store size.
Fine, I get it, it is really hard to change the object model in place, but I really need to do it. Is there nothing I can do?
Of course you can, it just isn’t as easy as updating configuration. Check out our upcoming blog post on how to change your object model for all of the details!
Leave a Reply