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.
Lee Dallas
Marko Sillanpää
The LARGEST challenge to multiple repositories is that it isn’t always seamless to switch back and forth. If you don’t have SSO implemented, it is far from seamless. That is even before you start talking about managing the logins.
If you throw the word Federation out there I may have to drive down I-85 and strangle you.
Right now, barring miraculous changes in D7 (which I won’t believe until curmudgeons in the field validate), a single repository is the best way to collaborate barring a seamless, SSO, experience (with federated search implemented) where the separation is invisible to the consumer.
Barring that, I would consider separate repositories for:
1) Separate business units that don’t collborate very often, or when they do they have a central collaboration platform they are using. (eRoom?)
2) International considerations have to be considered. If you have to worry about data privacy rules in different countries, separate repositories make sense.
3) Scaling issues. Like any system, sometimes the annoyance of 2-3 repositories is offset by not having to create systems to scale.
As for the challenges you indicate, they are readily managed if consideration for those challenges are considered in the beginning. Of course they aren’t, changing the whole construct.
I know one client that create a new repository per project. That actually worked for their business profile. So while, as a rule, I prefer one repository, reality may dictate multiple.
-Pie
PS: Lee Smith had some thoughts related to this a few years ago: http://ecmobservations.wordpress.com/2010/02/18/one-repository-to-rule-them-all/
That’s a lot of “barring up” there Mr Words – take 1 too many “little blue pills” this morning??
Sorry. There are so many different variables that go into the decision, you just can’t give a definitive answer. Barring a complete list of the business and technical requirements, the best you can do is guess.
-Pie
awww man-now I have to change the title – can’t have two lee’s with two posts with the same title… I remember that thread now – buried in my subconscious I guess .
not sure if I agree with either pmonks or Pie – they seem to support and contradict each other in the same post. Tweedledee and Tweedledum? *smile*
Trying to fit everything in a single docbase can be expensive. Scalability, HA and DR impose a tax which may not be necessary for all applications. (Who else uses Exadata as a backing system?) Also shifting any of those dimensions after the fact after an upgrade can be prohibitively expensive – ever try partitioning the dm_sysobject tables after the fact? Not fun! Also not fun is trying to coordinate changes/outages with two or more incompatible business units.
Generally, IMHO, the best approach is to create a set of docbases organized along the lines of SLA and/or usability concerns and assign applications accordingly.
W-
For the record, I’m not Tweedledum. 😉
I believe you have answered your own question when you said that “change” is your biggest stumbling block. You are not required to think about docbases as square blocks. Why not assign docbases by level of change management anticipated? So, the whiz kids get as many frickin docbases as they want, but they have to deal with them. The scan/index accounts payable can have the slowest docbase they desire, hell give them version 5.25 and they’d be happy. Think of docbases as fluid, the bottom layer a lot slower some divide them up.
Good discussion, and not unlike those that we have everytime we go into a client. If there was always a single solution, why would they pay us to figure it out? I tend to agree that usually repositories are aligned with business units and business functions…except when they aren’t. 😉