We have been working on a SOA document for a large customer (300K internal users) for a while now. That document has gotten large (12 MB). We were having two major issues with it:

1. Just the act of saving the document to SharePoint periodically would take 30 seconds or more.
2. As the document evolved through multiple people (including contractors) editing it, we realized that although we would tell someone to edit a particular section, many times the person would edit other sections as well. This became problematic because the changes would not get tracked properly and were often errors. That led to some embarrassing situations when the client noticed the errors upon document delivery.

We tried a few methods for dealing with the issues with limited success.

1. First we tried having each person edit the complete document and use the Word merge feature. This worked about ½ the time, but was time consuming and error prone. It required a person who knew Word and the particular document pretty well in order to be able to merge the changes and deletions properly. Eventually the person doing the merge became the bottleneck in the process.
2. Then we tried splitting the document and combining the sections manually. This gave us better results, but because the process was manual the master document was always a few days out of date with respect to the sections, and it took some time away from the person who was doing the merging.
3. Then we wrote an automated tool to do the merging. The tool worked very well but it required that Word was installed on the SharePoint web servers. Over time the tool would periodically stop working. We tracked this down to Windows updates interfering with security and DCOM settings on the SharePoint server.
4. Finally, we isolated the main engine of the tool onto a separate server that would only communicate with the SharePoint farm through web services. Now that the main engine was on an isolated hardware and software platform, we could stabilize the environment and make sure that all processes were operating properly. The engine was now considerably more stable and easier to manage. Also, we no longer needed Word on the SharePoint servers. This configuration eventually became the docBlock.

We now have a docBlock attached to our SharePoint farm running our intranet and extranet. The previously mentioned document is being converted into a virtual document so we can more easily scale up the size of the team working on it while not increasing the overhead needed to manage the document. We will be using the docBlock to continue work on the document in the next phase of the contract. Users logging in with Active Directory accounts on the intranet, with Windows Live ID’s from the extranet, and users working from a Groove workspace connected to the document library will all be working on the document concurrently.

Download the Enhancing SharePoint Document Management with Virtual Documents black paper (registration required). The black paper discusses several key document management usage scenarios enabled through docBlock Ascend's virtual document enhancements to the SharePoint platform.

For more information on the docBlock Ascend, please download the docBlock Ascend product brochure or contact sales@blackbladeinc.com / +1-703-260-1111 . See the docBlock Ascend in action by scheduling a live web demo, or attend a public webinar, Tuesdays and Thursdays at 2pm EST.