There seems to be some confusion in the world of federated records management about what exactly is being federated. There are 2 distinct use cases what you might want to consider:

1) Federating just the records/retention policies. The use case here would be where you would manage the master policies in one system - the master policy management system. Each remote system looks at the master policy management system to get the policy information or the master policy management system pushes the policies out to each remote system . In this model, each remote system applies its own policies locally, it is just the policy information that is federated. Note: In this model you do not have centralized view/management of the records, just the polices.

2) Federating the application of retention etc. to the actual objects in the remote systems in place. This is the classic federated records management model that I discuss in this blog. I have just written a 2000 word overview of this use case as an article for one of the ECM magazines which I can send to you if you email me.

Use case #1 is typically less invasive that #2 and does give you a lot of benefits - it is not much easier to set up that #2 though! However, just knowing where the policies exist is useful; let's assume that a regulation changes and you have to find all objects in the enterprise that have that policy applied to it. Use case #1 would at least let you know where the policies exist even though you cannot actually manage it centrally.