Collaborative Work in Renga: from Theory to Practice

If you are a building architect and a member of a team distributed across sites, cities, and countries, you have probably experienced delays caused by outdated input data. The most effective way to keep project knowledge up-to-date is to stay in contact with your team 24/7, ensuring you are aware of any changes they make to the project.

For Renga Professional users, the design process feels as if all team members are sitting in the same room and at the same desk, even if they are separated by oceans.

How is that possible?

The software supports three types of user interaction.

First, the easiest and most accessible is communication. We are all familiar with communication technologies such as phones, messengers, and email.

The second type of collaboration is transaction. It refers to the exchange of something according to certain rules. A transaction alters the relationship between its stakeholders. Example: one person becomes a seller, and another one, a buyer. Any software that supports transactions must securely store the new statuses of the transaction stakeholders. These are transaction management systems such as SAP.

Finally, the third type is collaboration: people work together to achieve common goals, share their knowledge, learn, and agree. Examples: promoting a new idea, or creating a new design. There are no clear collaboration rules. Therefore, the technology must be sufficiently flexible. The tools should provide data management, virtual discussion rooms, revision history management, and more.

Well, now we know about the three types of interaction. We believe that architectural design is all about collaboration.

But do we need collaboration, if we can work sequentially?

One team member completes their task and passes the project to another, and then to another. If any of them are dissatisfied, the project goes back to the first stakeholder, creating multiple loops. This slows down the process. It is called “teamwork” for a reason. We want every team member to work on the project concurrently.

Concurrently? Let me elaborate on that. When people work concurrently on a task, the worst that can happen is an access conflict: multiple users attempting to modify the same data simultaneously. That is why the primary challenge for software developers is conflict resolution.

To address this challenge, three main collaboration strategies have been developed:

1. Optimistic concurrency control (OCC). Optimistic concurrency control (OCC) assumes that multiple transactions can typically be processed simultaneously without conflicting with one another. Therefore, no data is locked. Before committing, each transaction verifies that no other transaction has modified the data it has read. If the check reveals conflicting modifications, the committing transaction rolls back and can be restarted.
2. Pessimistic concurrency control (PCC). PCC assumes that two or more users update the same data simultaneously, resulting in a conflict. To prevent it, the application locks the data to be updated. The lock is on until the first user finishes editing so other users cannot access the data.
3. The last writer wins. This strategy resolves data conflicts by considering the most recent update as the definitive version.

Let’s see how to use these strategies.

Sure, the easiest one is Last Writer Wins. We can use the file system for collaboration. The project file is stored on a network disk to be opened from multiple workstations. When several users make changes, the final project will be as it was edited by the last user, i.e. the changes made by all other users will be lost. Agree, it does not seem a good approach to teamwork.

How about Pessimistic Concurrency Control? To prevent data loss, the application locks the file. Whoever opens the project first can save it, while everyone else can open it read-only but cannot make any changes. In this way, data are saved, but the work is not sequential rather than parallel. In terms of collaboration, the drawbacks are:

• Only one user can make changes at any given moment. The larger the project and the more stakeholders are involved, the more pressing this issue is.
• Every change should be propagated across the entire system and to the network drive (e.g., a designer repositions a column, and a new file version emerges).
• No offline operation: to edit a file you have to lock it which requires access to the server, or the network folder.
• If you forget to unlock it, no one can edit the file.

This strategy is used in MCAD systems because every part is stored in an individual file. If a project is stored in a single file, it can be divided into multiple data sets.

Let’s see how it works. Someone opens a project and locks the part they are working on. There are pros and cons. Pros:

• Multiple users can make changes simultaneously, but only to the part of the project assigned to each of them.
• You can keep working even if someone forgets to unlock their part.

Cons:

• No offline operation: to edit a part of the file you have to lock it which requires access to the server, or the network folder.
• There may be many relationships between the project objects, so locking one object may require locking its related objects.
• Such a collaboration requires careful planning. You need to determine how and when to lock the data.

This strategy is common in AEC systems. Considering the cons, let us continue the research.

Software developers need to collaborate, too. Their collaboration tools have evolved alongside advances in information technology and a deeper understanding of the strengths and weaknesses of each strategy. As a result, the Optimistic Concurrency Control strategy has become the golden standard.

Advantages:

• Multiple users can make changes at the same time.
• No need to care about locks and other formal conventions.
• Offline operation is supported: you don’t need to notify the server to lock the data.
• Small synchronization datasets are exchanged with the server.

However, there is one significant drawback.

• When changes are made to the same file, they have to be merged while preserving the input of each stakeholder. Suppose, two users have changed the same line of code. It is a conflict to be resolved. To preserve the input of each user, we may need to add a new version, not just merge the changes. The more conflicts occur, the more time and effort are spent analyzing and resolving them.

The advantages look great, but what should be done about this disadvantage? There are two ways we can reduce the probability of a conflict:

1. Synchronize the stakeholder data as often as possible to make sure that the data used for decision-making is always up-to-date.
2. Divide the data into as small fragments as possible to eliminate overlaps between the fragments being changed.

To compare software development and architectural design in Renga, we can assume that one line of code is similar to one property of the object. It means that a conflict occurs only when two designers change the same property at the same time. Merging such data is hardly possible, so the property value stored on the server remains unchanged. If the design process is properly managed, the probability of such a coincidence tends to be zero.

For this reason, Renga uses the Optimistic Concurrency Control strategy. It gives Renga users the following advantages:

• Data are always up-to-date.
• They can make changes at the same time.
• No locking.
• Offline operation.
• Minimum amount of synchronization data exchanged with the server.

Tired of the theory? Time to practice!

1. To enable collaboration, the administrator starts the Renga Server and sends the access credentials to the users.
2. A team member creates a project in Renga Professional, configures it, and possibly creates a building model. When they are ready to share the result with the team, they click Publish and then share the project file with the team members in any convenient way.
3. Each project stakeholder saves the project file on their computer at any location.
4. Then they open this file and do their design tasks using the up-to-date data.

For convenience, there are two synchronization options: manually (F5) or automatically (set it up in the Settings).

Project logs are saved on the user workstation and the collaboration server to track changes. You can view the logs in any spreadsheet application or business analytics tool to generate real-time user action reports and resolve conflicts.

Instant synchronization and discussions with colleagues make collaboration as efficient as possible. Many Renga users have already experienced this. Give it a try!