We had an internal discussion on this topic today and I thought I would throw my response to the question out here for your consideration. So here is the question.
When designing Documentum at the enterprise level – just how many repositories do you really need?
There is no single answer to this question but I have a few considerations beyond the obvious performance metrics. From an enterprise perspective it is no different than deciding how many Oracle databases one should have. There are those that dogmatically assume a single repository is all you ever need but as a practical comparison – no company assumes a single database. Databases propagate based on common data, transaction profiles,user affinity, security and other operational characteristics. Docbases are the same.
While in theory you can go with the monolithic approach and have a single but the best argument against this approach is not any of these but rather the “rate of change” factor in the business.
When you collocate content from multiple business units in a single repository you create a relationship between those units where there may not have been one before. Consequently when you want to change one department’s view or application you must now take into account ALL of the affected business units. Even if the other applications are not directly affected, the cascading approvals of change control in a production environment demands their agreement or input into the change.
This dependency is one of the biggest drags on upgrades across the user base. One department may need an upgrade but coordination across the various constituencies make the logistics very complicated. From an operational perspective it does not make sense to have a 1 to 1 docbase to application relationship and I am not arguing for that. Where possible you should consider following the data governance, change management and approval structure.
Generally speaking these roll up together but there are occasions when you still have to deal with the fact that one group wants to move faster (or slower) than the other and the portfolio must manage the conflicts. In these cases the one with the budget wins. 🙂
As my very experienced colleague Tom Rouse added, Documentum is not alone in this regard as uncontrolled SharePoint site proliferation is one of the biggest challenges facing the managers those systems today. Add to that the challenge of the shared data models, something faced in the relational data world as well.
The message is clearly that there is no shortcut for understanding the data, the customer, and the politics when making enterprise decisions like this. The rate of change challenge is one issue that I think the cloud providers will be struggling with in the years to come. While the dynamics are different because the IT operations component is “in theory” removed, the change control at the line of business level is made even more critical as people try to move ever more important processes to the cloud.