Read more about the eight reference architectures.

I represent the previous three architectures as being “unification” however technically they do not actually unify SharePoint with the ECM system. The first architecture simply recognizes the problem, the loosely coupled solution provides movement of content and the Web Parts specific solution just creates a simultaneous view of the two disparate systems.

This fourth architecture provides a level of real unification albeit only at the client level. There are a number of content types that might benefit from this client-level unification depending on the actual functionality needed. For example you might unify data between discussion threads, datasets, messages, inbox entries, etc. However, we will take the most frequently use-case which is the unification of documents between systems. (I'll Blog about those other structured and semi-structured data types later.)

The objective of this architecture is to create an environment where the end user is not aware of where an object actually resides. If the end user needs to see three documents in order for her to do her job then she should see all three documents in a single Web Part; we should abstract their actual physical location from her. If she does need to know where the data resides physically then that should simply be a value in a column – we certainly should not insist that she navigate three separate systems or even three web parts in order to get access to the data.

In this reference architecture, a single SharePoint Web Part is used that is able to federate queries out to many disparate systems. In laymen's terms, the Web Part grabs information about documents in 'x' different systems but shows the results in a single list. 

If the end user simply needs to search lists of relevant documents and then view the content then this reference architecture is relatively simple. If the user needs to perform more complex operations then we start to see serious technology issues, (Note that Reference Architecture 5 will address that scenario.)

How does it work?

The SharePoint Web Part contains logic that “binds” it to predetermined data in the disparate systems, for example, it might be mapped to folders 1 & 2 in the ECM system, folder X in one SharePoint system and folder Y in another SharePoint system. When the user invokes the web part it queries each of the systems and returns the results in a single unified results set. Other uses for this architecture include displaying a search results set; in that case it would take a cross-system query, federate the search across systems and then consolidate the results.

Convenience Begets Problems

One point to note as we move through these architectures is that as we increase the functionality we also increase the technical challenges. This will become very apparent in the next architecture but just consider a single subtlety in this one relatively constrained case. Mapping user security...Consider this example; I am logged in to SharePoint, I invoke this Web Part which queries 4 other ECM systems and 2 other SharePoint Document Libraries. I don't mean to be existentialistic but who am I in these other systems? Do I need to have credentials on those other systems? Do they need to be mapped to my home SharePoint account? Can I rely on SSO for this? Who will maintain this? Where will the mapping between systems be held? Should I just act as sysadmin in the remote systems and throw security and data confidentially out the window?

Conclusion

If you can deal with the cross-system issues then this approach starts to show some promise. Users should not care where their data lives - they just want access to it and this approach offers that. Be aware, this approach addresses only the 'passive' use case. I don't mention check-out/in, lifecycle management, workflow, BI, etc... Add those to the equation and...well you'll see in the next reference architecture!