Revit Server. Let's review quickly what it was meant to do and the problems that it solves. Then we'll take it to the next level.
Revit Server was designed to help a SINGLE company with distributed, satellite offices work on a single model. In that scenario, everyone is on the same wide area network with no worries about security or other IT issues to get the server up and running. In the traditional model to the left, we are using some sort of VPN for synchronization, or an FTP site to share a model that has been sliced into pieces so that each office can work on their piece of the project. This can work, but only if the pieces of the puzzle are cleanly delineated, which is very rare on a project of the size and magnitude that would require
multiple offices' involvement. The offices are also having to re-link updated models or having to wait for a s-l-o-w synchronization via VPN to a central file housed at Office A.
Now, Revit Server, in the image to the right, uses two central files. A main one (C) at the home office and another localized central file (L) at the satellite office. These two files are constantly talking to one another and updating data. So the person at Office B is quickly synchronizing to a localized central file and not having to wait for an extended period of time as they sync via a VPN connection directly to the central file at Office A. Things like object locks are directly communicated to the main central file at Office A as well, so you still get immediate communication of who is working on what. Problem solved.
The next level: Now, what about those pesky projects where multiple firms are involved? Sometimes it requires TWO firms to do the project. So how do you distribute a Revit design between multiple COMPANIES? Not just satellite offices, but different firms. It can take a little bit of IT knowhow, but it can (and has) been done. It takes a couple of firewalls and an encrypted VPN tunnel so that neither company can see the other companies' other projects. A word of warning though. Most companies are only using a T1 connection to the internet and it will take more than that to make this successful. There are still bursts of data during synchronization and when the files are opened and closed. Therefore the office that houses the main central file (Office A, in this diagram) will need a much larger internet connection. That office will also have additional IT burdens, and BOTH companies are stranded if there is a power outage at Office A. But there is another option. . .
We have found that if the main central file is housed in a data center, then each office has a localized central file and is only responsible for its own connection. Data centers are designed to have large connections, fast access, and reliable up-time. The process is similar to setting up a connection between the two offices, there just happens to be a "third leg." It would also be easier to add another team member to the project because the local IT group wouldn't have to worry about additional permissions or concerns at Office A. Management of the central file at the data center can be delegated to a support company.
Those are just the basics. There is more to discuss but that can wait for later, or you can give us a call.
Pretty interesting post! Thanks it was interesting. FSD
ReplyDelete