Prior to the new Revit Server, all worksharing in Revit was file-based. When worksharing was enabled for a project to allow multiple team members to work with it, a central file of the project was automatically created on the LAN (local area network) of the office, and it worked as the master copy, storing the current ownership information for all the elements in the project and acting as the distribution point for all changes published to the file. All users worked on a local copy of the central file, made edits to their local copy, and then synchronized with the central file to publish their changes to it. Revit’s transparent element borrowing feature made collaboration easier by automatically assigning ownership of an edited element to a user, which was then automatically relinquished when the user saved their local copy back to the central file.

Worksharing in Revit, worked well when all the team members were in the same office and only needed to work with the model on the LAN; it was when teams from other offices needed to work on the same model that collaboration became problematic, as they were now required to access the central model across a WAN (wide area network), which was noticeably slower. Contrary to the popular assumption that this latency was caused by Revit’s large file sizes, it turns out that this was actually due to the communication protocol between the central model and local copies, which, according to Autodesk, was not optimized and too “chatty.” After the local copy is first created from the central model—which will, of course, take a longer time for larger files—subsequent saves and reloads to and from the central model transmit only the changed model elements back and forth and not the entire file. At this point, therefore, the file size is not a factor—the latency problem caused by the non-optimized communication protocol would be of the same magnitude, irrespective of the size of the file.

The newly introduced Revit Server technology addresses the WAN latency problem through some key new features and changes. To start with, it is introducing the concept of a Central Server located in any part of the world, where the central Revit models of projects would be stored, and Local Servers at each of the office locations, which maintain copies of the models that users in that office are working with. Users will now need to access the Revit model only across a LAN as it is stored on the Local Server, avoiding the latency problems that existed earlier when accessing models across a WAN. At the same time, in the new scenario, the Central Server and the multiple Local Servers are being constantly synchronized to ensure that changes made to the local models are updated in the central model, which are then, in turn, updated in all the Local servers in different locations. Also, even though the synchronization between the Central and Local servers is happening over a WAN, it is using new communication protocols that are much faster than the earlier non-optimized protocols, ensuring that the central and local models stay constantly synchronized. (Of course, if two users save their changes at exactly the same time, there will be a temporary asynchronization.)

Another technological advancement in Revit’s new collaboration technology is that the central model on the Central Server is not stored as a monolithic Revit file but instead as a directory that lists individual data streams in the model. This organization of the model data in a more database-like format makes it faster and easier for the central server to exchange data with the local servers. Revit element permissions are now stored and accessed from an integrated database managed by Revit Server.

From the perspective of the end users of the application, most of these changes are behind the scenes and do not require any significant changes to how they use Revit on worksharing projects. The main interface change is a new “Connect to Revit Server” option on the Collaborate tab, which allows them to connect to the Central Server that their Local Server has been configured to connect to (by their IT administrator or BIM Manager). It should be noted that a Local Server can connect to only one Central Server. Once the connection is established, the user can browse through the projects on the Central Server and open the one they want to work with. If another user from that office has already worked on that project, a copy of it would already have been created on the Local Server; if the project is being opened for the first time, a local copy is created at that time. If a user creates a new project and enables worksharing for it, the central model is placed on the Central Server. Users would typically be unaware of the local server because it is transparent in their daily operations. They would, of course, benefit from the speed enhancements enabled by having the model on a local server, accessible at LAN speeds. Also, having local copies of the model ensures that users can still have access to them if the WAN connectivity is temporarily lost for some reason.

While the new Revit Server technology is available for free (currently for subscription customers only), its implementation does require some additional hardware and software such as Windows Server 2008 and 64-bit servers. There would also be some initial server setup processes, mostly likely by a firm’s IT systems department, and ongoing administration by BIM managers and/or project team leaders (using a dedicated set of Revit Server Administrator tools). However, for a large firm, these additional costs would likely be small part of their overall IT budget and could be regarded as a worthwhile investment if it saves on delays and frustrations when distributed teams have to collaborate on projects. One of Autodesk’s customers, Burt Hill, which was involved in the development and testing of the Revit Server, has been using it in production for three weeks now, and reports that it has greatly speeded up the work on collaborative Revit projects by teams distributed across its multiple office locations.