Putting project files in one place doesn’t guarantee different systems can use them. Interoperability depends on agreed meaning, preserved status and a tested route for moving information when the project or supplier changes
A contractor exports a coordinated model from one platform and opens it in another. The geometry looks correct, so the exchange appears successful. Later, the receiving team discovers that equipment identifiers have changed, some properties are missing, and the comments explaining unresolved issues remain in the original service. The building is visible, but some working information has been lost.
This is why common data environment procurement needs a more demanding test than whether files can be uploaded and downloaded. People need to know what information means, which version they are using and what they may rely on it to do. Those conditions have to survive exchanges between organisations as well as moves between software products.
For a client, the consequences extend beyond coordination. The information may be required after the delivery team has dispersed or the original subscription has ended. A low-cost platform can become expensive if retrieving a usable record requires specialist reconstruction, continuing licences or help from a supplier with no agreed obligation to assist.
Separate the shared process from its software
A common data environment combines an agreed way of managing information with the technology supporting it. In practical terms, the project must distinguish information being developed from information shared for coordination or authorised for a stated use. It also needs an accessible history of what changed and when. A folder shared by everyone does not establish those controls on its own.
The IMI Framework guidance emphasises defining information-management requirements for individual appointments. Applied to a shared environment, this means the software configuration should follow agreed responsibilities and exchanges. It is difficult to configure an approval process reliably when the project has not decided who can approve a particular issue or what that approval signifies.
Multiple applications can participate in the process. Designers may author in specialist tools, site teams may use a field application, and the client may retain records elsewhere. The useful question is how information crosses those boundaries without losing meaning or control. Requiring every participant to use one interface may simplify administration, but it does not remove the need to manage the boundaries.
Open standards address different parts of the exchange
buildingSMART describes Industry Foundation Classes, or IFC, as an open international standard for sharing building information model data. It includes a schema, documentation, property and quantity definitions and exchange mechanisms. This provides a common structure for information; it does not require every application to export and import every required feature identically.
A useful exchange specification therefore identifies the supported IFC version and the information needed for the receiving task. An architectural coordination view and an asset information exchange can have different requirements. Describing both simply as an IFC deliverable leaves too much room for a technically readable file that is operationally incomplete.
The BIM Collaboration Format addresses communication about model issues. Its role differs from transferring the model itself. This distinction matters when a project wants to preserve a discussion, viewpoint or issue reference alongside the relevant objects. A model export alone should not be assumed to include the conversation that explains the design decisions.
Test the task the recipient needs to perform
The strongest test uses representative project information and the actual receiving workflow. A supplier demonstration with a carefully prepared sample establishes that the demonstration works. It does not establish that the buyer’s object structure, classification, revisions and attachments will behave the same way. A small but difficult sample can reveal more than a large, visually impressive model.
For an asset exchange, the receiving team could select several maintainable items and trace their identifiers, locations, properties and associated documents. For coordination, it could reopen an issue against the correct model revision and confirm that the intended objects are still identifiable. The purpose is to test whether someone can complete a real task after transfer.
The test should include an update. If an item is revised, split into two objects or deleted, how does the receiving system distinguish that change from a newly created item? Stable identification and explicit change handling help prevent duplicated assets and detached issue records. The team needs to understand the actual behaviour rather than infer it from a general claim of compatibility.
Automated checking has a defined reach
buildingSMART’s Information Delivery Specification, or IDS, expresses information requirements in a computer-interpretable form and supports checking IFC models. Requirements can address objects, classifications, materials, properties and values. This can make some exchanges more repeatable by defining what the receiver expects before the sender exports the information.
A successful check still has a specific meaning. It can establish that a required property exists and satisfies the encoded rule. It cannot independently establish that the property accurately describes the installed product, or that the design is safe and suitable. A plausible value can pass a completeness test while remaining factually wrong.
Making requirements machine-checkable also has a cost. Someone has to define the rules, resolve ambiguous terms and maintain them when requirements change. That effort is worthwhile where it replaces repeated manual work or catches consequential omissions. It is less useful when a complicated checking regime is built around information that no recipient needs.
Preserve the record around the document
A drawing’s content and the record governing its use are connected but distinct. An exported PDF may preserve the design while losing the platform’s review comments, distribution history or suitability metadata. If the team later needs to establish what was available at a particular date, the standalone document may not answer the question.
The export requirement should identify which surrounding records matter and how they will remain intelligible. That may include revisions, issue dates, approval actions, comments, attachments and links between records. An archive is more useful when a person can navigate those relationships without reconstructing the original application’s internal structure.
Permissions also need attention during transfer. An unrestricted bulk export can expose information that was previously available only to selected roles. Conversely, an over-restrictive export may omit records the client is entitled to receive. The exchange process needs an agreed recipient and scope, especially where information concerns commercially sensitive designs or identifiable individuals.
Price an exit before it becomes urgent
The government’s guidance on technical lock-in recognises that switching has costs and that integration can also provide value. It recommends balancing the cost of switching against the benefit of staying and points software-as-a-service buyers to open standards and formats. This is government technology guidance, rather than a mandatory rule for private construction procurement, but it exposes a relevant commercial choice.
The buyer needs to know whether bulk extraction is included, which formats are provided, how long access continues and whether supplier support is chargeable. An application programming interface may offer a route for automated extraction, but access limits, documentation and the cost of building the connection still matter. An available interface is not a completed migration.
Exit testing should happen while the service is working and the relationship is constructive. A representative export can be stored independently and opened by the intended recipient. The result reveals both technical omissions and the internal effort needed to move. That evidence helps the buyer decide whether a deeply integrated service offers enough benefit to justify its switching cost.
Treat interoperability as continuing work
A successful exchange at mobilisation is a useful baseline. It can be undermined by later software updates, changed property names or new participants with different export settings. Repeating a focused test after material changes is more proportionate than assuming that one early demonstration guarantees compatibility for the project’s lifetime.
The commercial objective is a usable information record with a known cost of keeping it usable. Open standards help create that possibility. Agreed requirements, maintained identifiers, and tested transfers make it real. A common data environment earns its place when project knowledge remains dependable as it moves between the people who design, build and eventually operate the asset.
The post A common data environment is only useful if the information can move appeared first on Planning, Building & Construction Today.
