Ask a client team how the common data environment talks to the maintenance system and you will usually be told it is on the roadmap. There is a steering group, a middleware discovery phase, and a field-mapping workshop pencilled in for the autumn. Meanwhile a maintenance planner is typing the plant list into the CMMS by hand, because planned maintenance starts on Monday and nobody is waiting two years for a work order to find a unit that has been running since taking-over.
Three joins already sit in that gap. A shared asset identifier. An export of the asset information model. A scheduled sync. None needs a named product or a programme to try, and each fails in a way you can describe in advance — which is the useful part, because you can go and look for the failure before you commission the fix.
It helps to be blunt about what the two systems are for. The CDE holds what delivery issued, reviewed and archived: containers, revisions, transmittals, the trail of who was told what and when. The CMMS holds what operations will maintain — the asset, the job, the spare, the history of work done to the thing. Those are different purposes rather than two views of one model, which is why a join built on the assumption that they mirror each other rarely survives its first winter. What has to travel between them is much smaller: a key both sides will still recognise in year five, the short list of fields operations have ever queried, and a document that still opens.
One string, written on the thing
The cheapest of the three is a shared identifier, and the one most jobs skip, because it does not look like work. Both systems use the same key for the same installed thing: the tag stamped on the casing, the row in the asset information model, the asset number in the CMMS. A stranger can walk to the unit and find the row, or read the row and walk to the unit. No middleware anywhere in that. It needs a convention, a stamp, and somebody senior enough to refuse a second number when one is offered.
It works when the key is chosen before the first inspection, written on the physical asset, and reused in every record that follows — hold point, certificate, operation-and-maintenance extract, work order. Identity is the join, not a column added at handover to satisfy a checklist. AHU-03 on the casing and on both rows will carry you into operations. A model element identifier that dies the next time the file is upgraded will not, and a CMMS auto-number generated the week after practical completion is a second register with a head start.
The usual failure is two keys and a spreadsheet pretending they are one. Delivery keeps the identifier it needed in order to build: a family name, a type mark, a GUID, a package code, a gridline. Operations keep whatever the CMMS already knew how to generate — a location-based asset number, a barcode printed in week one of mobilisation, a room code from a superseded schedule. Somebody is appointed to map them. The map turns out to be a workbook on a shared drive, and then its author demobilises. Rooms get recoded during fit-out. Packages close. The plant has not moved a millimetre. The following winter the unit that failed is not the unit in either row, and the argument about which workbook is current takes longer than the repair.
The second failure is quieter, because the convention was agreed and simply never tested. A BIM execution plan promising that unique asset identifiers will be used is a sentence in a document. Five maintainable assets you can walk to, carrying the same string on the casing, in the CDE and in the CMMS, is a join. If you cannot produce those five, the maintenance system will invent its own numbers within a fortnight, because the work cannot wait for a convention to mature.
Identity also gets confused with grouping. A classification code, a system name, a room number: those sort rows, and they belong in the register, but they are not keys. If the only thing an operator can search on is a location that will be renamed at the first reconfiguration, nothing was really shared.
Export the register, not the model
The second pattern is a bounded extract, done once, on purpose. Somebody accepts an asset information model — not a project information model with a fresh folder name on it — and exports the maintainable assets operations will actually run: identity, type, space, the fields the facilities team asked for, documents that still open. That extract goes into the CMMS as the opening register. COBie is one disciplined way of serialising the cut; a filtered table the maintenance planner recognises is another. What you want at the end is a register the operator can query on day one.
The pattern is cheap because it happens once, and because it makes no promise that the two systems will stay in conversation afterwards. It goes wrong in four recognisable ways.
The project model goes out wearing the asset model's coat. A federation renamed "as-built", a CDE archive published to the client, a forty-thousand-row dump of every wall and placeholder family. Those are delivery artefacts. The cut from PIM to AIM is separate labour and somebody has to be paid to do it. If nobody accepted the model the operator will query, the export is a crate with a schema on the spine.
The extract is a dump. Unmaintainable objects travel. Required fields sit blank, because they were never the purpose of the model. Document references are paths on a laptop that has since been wiped. Types and instances collapse into each other. Then somebody tidies the file — which is to say reconstructs it — and the tidy version gets loaded. Facilities find out in the first planned-maintenance week, when the filter size on the row is not the filter in the unit. Much of the reason registers get rebuilt from scratch is that handover data did not survive the trip.
Received gets filed as loaded. The owner asked for a structured extract because a standard said so. The maintenance system cannot ingest the wrapper, or nobody mapped the five fields that matter, and acceptance quietly becomes a transmittal. The planner carries on retyping. As a file, nothing failed. As an exchange, everything did.
Once is treated as forever. An export is a snapshot of something that keeps moving. The CDE will change again — a late certificate, a substitution, a warranty letter that turns up months after taking-over. The CMMS starts changing the hour the first work order is raised. If nobody has said which later facts travel, and who sends them, the export is honest for about a week, and after that there are two plausible registers again.
A good export is boring, and the people who do it well tend to be faintly apologetic about how boring it is. Maintainable assets only. The fields operations have asked for — location, make and model, warranty, spare, isolation, one document that opens — not the museum of delivery metadata. A document controller should be able to fail the drop against a written test: missing type, blank required field, dead pointer, a row with no tag on the thing. "Looks like COBie" is not a test.
The nightly job, and who reads it
The third pattern is a job that copies changed rows on a clock: nightly, weekly, at period-end. Kept narrow, it is the closest thing to integration most estates will ever get for free. Kept broad, it is a silent overwrite with a calendar behind it.
It works when the match key already exists, when the travelling fields are few and named, and when a real person is paid to read the exceptions. A location correction in the CDE updates the CMMS row. A late warranty date follows it across. A document revision replaces a dead pointer. That is a long way short of a twin, which is fine, because nobody in operations asked for a twin.
It fails first when the identifier was skipped, which is most of the time. A schedule cannot invent a key. If the two rows share nothing, the job matches on name, or location, or some fuzzy string comparison — and then it matches the wrong unit, creates duplicates, and skips the asset a night-shift technician is standing in front of at two in the morning. A sync that mismatches quietly is worse than no sync at all, because from the outside it looks maintained.
It fails next when nobody wrote down who wins. A technician corrects the location in the CMMS, because they walked there and read the plate on the wall. Document control updates the asset information model in the CDE, because a late as-installed drawing arrived. Both edits are true on the Tuesday, and Wednesday's job overwrites one of them. Saying the source system wins is not naming a source; saying the latest timestamp wins names a clock. One direction matters more than the general rule: delivery leftovers, a design-stage parameter or a superseded room code, must never overwrite operational history. Work orders, condition notes, the last isolation that actually worked — those facts were born in the CMMS and there is nowhere else to recover them from. A schedule that treats the CDE as master of every column is a weekly demolition of the operating record.
It fails when it syncs the wrong object. Folders, files, a model, a transmittal log are CDE objects, and no maintenance planner raises a job against a folder. Copy containers instead of asset rows and what you have built is a backup. Exception reports nobody opens are the same failure with a dashboard on top.
It fails, finally, when it syncs everything — every parameter the authoring tool stored, every custom column, every classification a consultant invented years ago that nobody has dared delete. Volume reads as diligence in a steering pack. A facilities planner cannot query volume; they query the short list they use.
So the schedule needs a name against it — a person, not a team, and preferably one who complains when the list gets long.
| Join | What it is | Cheapest failure to check first |
|---|---|---|
| Shared identifier | One string — on the casing, in the AIM, in the CMMS | Two keys and a spreadsheet pretending they are one |
| Bounded export | Maintainable assets only, the fields operations asked for, documents that open | The project model exported wearing the asset model's coat |
| Scheduled sync | Narrow, named fields, a named person reading exceptions | Nobody wrote down who wins when a field diverges |
The order is the trick
The three sit in an order, and the order does most of the work.
- Share the identifier first. One string: on the thing, in the asset information model, in the CMMS. If you cannot write it on five assets this week, stop there. Do not export, do not schedule, and do not go out to tender for middleware whose job would be to reconcile two numbers you invented yourself.
- Export a bounded asset information model. Maintainable assets only, the fields operations asked for, documents that open from either project or owner custody. Load it or reject it against a written test. Nobody has ever successfully cleaned forty thousand rows the night before mobilisation.
- Sync only what will keep changing, and only after the first two. Name the fields. Name who wins when they disagree. Name the person who reads the exception list. If nobody is paid to read it, leave the clock switched off.
That is labour a document controller and a maintenance planner already know how to do, and none of it requires a certified connector between named products. A key, a short extract, one sentence about conflict. Commission the two-year programme when those three have failed for a reason you can write on a single page — not because a slide had the word integration on it.
A programme that opens with field mapping, before anybody has agreed the identifier, fails all three patterns at once. Somewhere around month fourteen it discovers that the plant never carried a tag — a discovery that was available on the Monday, for the price of a walk and a torch.
Five assets and an hour
None of this needs a consultant. It needs a morning.
- Walk to five maintainable assets that will still need attention in two years. Read the string on the casing. Find it in the CDE, in the asset information model rather than somewhere on a drawing. Find it in the CMMS. A miss on any one of the three is your finding, and it should be recorded as a miss rather than reported upward as mostly aligned.
- For those five, produce location, make and model, warranty window, spare, isolation, and one document that opens. Give yourself an hour. Blanks are the export you do not have yet.
- Ask who loaded the last extract, and whether the planner is still retyping. "File received" is not loaded.
- If a sync already runs, ask for last week's exception list and the name of the person who closed it. The pause before the answer tells you more than the report would.
- Write one sentence: when a field diverges, who wins, and who is told. If that comes back as "the systems will handle it", you are about to buy a programme to avoid writing a rule.
Five is enough. You are not integrating an estate in a morning; you are finding out whether the cheap join exists, and which of the three is missing.
Where the standards stop
None of these joins arrives switched on. ISO 19650 tells you an information exchange should be specified, accepted and archived. ISO 55000 tells you asset information should serve the asset management objectives rather than the delivery team's convenience. The Construction Design and Management regulations and the Building Safety Act tell you certain information must be handed over and stay findable, and for higher-risk buildings that it survives into occupation. NEC, FIDIC and JCT govern when and in what form. COBie describes how to serialise the cut. Not one of them will walk out to the air handling unit and stamp a tag on it, or decide that operations wins on location while delivery wins on warranty date. That part is local, it is cheap, and it is almost always the part left undone.
Leave the steering group off the calendar. The client or estate owner is the one who can impose that: five maintainable assets carrying the same string on the casing, in the asset information model and in the CMMS, and one named person who has written who wins when a field diverges. A document controller and a maintenance planner already know the labour. It costs a morning and a stamp, not a two-year programme. Commission the programme only when those three joins have failed for a reason you can put on a single page. An asset manager three years after taking-over will not care which platform delivery preferred; they will care whether the row on the screen is the machine making the noise upstairs.
Read next: Why facilities teams rebuild the asset register from scratch, Condition data: designing the feedback loop back to design, The digital twin nobody updates.