The Oracle Australia and New Zealand Middleware and Technology Blog.

Friday, November 21, 2008

ECM - 'One' Repository or 'Three'?

Quick question, which looks simpler to you in the following diagram....?
If you answered A then you are probably from another ECM vendor organisation claiming efficiency, scalability and all the usual reasons quoted to your customers. Whilst it is true that during the 1980's and 1990's this was the ONLY architecture available that would work for an enterprise organisation - things have moved-on in the world!

Oracle's 11g technology allows any information to be managed in a single database architecture. You really, and truly don't have to deploy and manage a separate filestore and index in order to manage your unstructured information separately from your structured data and to the IT department - you can use the same management tools and methodologies you love to look after the 85% of information your organisation generates outside of the database. Think about a world where you don't have to worry about persistence of backups in order to prevent data-loss when recovering a system.

Doesn't the diagram to the right look simpler? We'll be covering more around the 11g architecture and time progresses but for now - consider simplifying your lives and providing richer functionality to your users through a single ECM solution.


Information Security

Oracle has a great capability in this area using 11G to store all three of the core data sets inside one instance ( Text, metadata and objects) this makes tracing illegal access both viable and practical which to us is the key to good security policy. The single-repository approach promotes this and provides some obvious benefits.


Kate Carruthers said...

Paul - I'm looking forward to hearing about how easy the migration process will be!

Paul Ricketts said...

Hi Kate

with the single repository model leveraging the database for metadata, content and indexing - the migration from an existing ECM solution is far easier than to a 3-component repository. This is because you are simply building rows of data and not trying to model complex objects in one system, store a file on another system and then index everything using a different product.

The challenge is actually modelling the content in such a way that export and subsequent import can be achieved - this is true regardless of the source or destination ECM solution.