Read more about the eight reference architectures.

In the previous reference architecture we unified SharePoint and the ECM system at the Web Part layer and provided a limited subset of functionality, specifically passive operations. There's no doubt that this "passive connectivity" provides a huge amount of value, uses a nice, familiar paradigm and can constitute a complete solution in some cases. However, there are many times when you need to be able to act more fully upon the content in the disparate systems rather than just browsing and viewing the documents.

For illustrative purposes, let’s simplify the underlying architecture and then look at some typical problems with performing more active actions on content. Assume that behind our unifying Web Part we have two separate SharePoint sites. Our web part displays a unified view of all of the documents in the “Standard Operating Procedures” folder in one site and all of the documents in the “Corporate SOPs” folder in the second site.

Take a use-case where Standard Operating Procedures in the company need to be routed for approval before they can be published for general consumption. Approval of documents such as these is performed via a workflow process; let's look at this process from an end-user's perspective.

Active Unification Part Use Case

Matilda has two standard operating procedures that need to be updated. She finds the two documents in her unifying Web Part and checks each of them out of their respective SharePoint sites. She marks up the necessary changes in the documents, checks them both back in, re-selects them both and starts the “Route SOP for Approval” workflow.

So what's the problem?

This seems like a particularly simple and highly efficient scenario but it makes some gross assumptions. Assuming that one SOP lives in the first site and the other lives in the second site then Matilda was actually starting one workflow in one system and another workflow in the second system. What if one of the SharePoint sites did not have a workflow called “Route SOP for Approval” implemented? What if it existed but the name of the workflow was subtly different? What if it existed in both locations but Matilda had access to the workflow in one system but not in the other?

The problem is made worse if the underlying architecture consists of different types of systems. What if one SOP was in SharePoint and the other was in Documentum?  Do you have single sign on implemented between these systems? Would Matilda even have an account in the Documentum system? You get the idea - even when both systems support the same operations the implementation and invocation of those systems will be significantly different.

In order to resolve this issue the unifying web part has three options:

1. Expose the lowest common denominator. Only expose operations that can be guaranteed to work across all systems that might contain content displayed in the Web Part; that might just be view properties, view content, check out/in and view version history/audit trail - those operations that I label as being passive. You are certainly going to have to suppress the more complex operations like virtual document management, XML manipulation, digital asset management, multi-channel publishing, retention application, etc.
2. Assume that the functionality exists in both systems. When I say assume I really mean ensure. Through a process of checks and balances you would have to ensure that the same configuration and functionality exists and is available in all systems in the federated environment. Having a centralized policy management system would be a huge help in this scenario.
3. Dynamically decide what capabilities to display in real time. As you select the document(s) and invoke the right-click menu the Web Part would have to determine the available functions in real time. For example, if you select two documents that happen to reside in the same repository, you can display any capabilities supported by that repository. If the documents reside in disparate repositories then you might expose the "start workflow" option for ll documents but then only display workflows that exist in all repositories and have exactly the same name.

Don't get me wrong, these options are not without merit, option #1 is actually a fine solution if the end user can do her job with the "dumbed down" functionality. If you run a tight IT operation then #2 might work but if someone points the unifying Web Part to an incorrectly configured repository then it could cause wholesale chaos. Option #3 on paper looks like the preferred solution but it takes a lot of work to build this functionality and a lot of cycles to perform this real-time look up, resolve and display, (aka it will be slow).

Conclusion

Under the right circumstance I believe that this architecture can provide a very attractive solution for well defined problem areas. If you have control of your repositories, a well run IT department and a fairly competent development team then you are probably a fictional organization but in a good position to use this approach.

Next week tune in for the first in the series of data aggregation as an approach...in the spirit of Harry Potter movies I am thinking about making reference architecture #8 in to two blog entries - not to make more money but to ensure artistic integrity - honest.