Structure in BIM & Coordination

The core idea of BIM is deceptively simple: instead of drawing lines that represent a beam, you place a beam - an intelligent object that carries its real geometry, material, size and position, and from which plans, sections and schedules are generated automatically as views of one underlying model. Change the beam once and every drawing that shows it updates, because they are all windows onto the same data. This alone eliminates a whole class of the coordination errors that plagued paper drawing, where a change made on the plan was forgotten on the section.

The deeper shift is that BIM is a database as much as a drawing. Every object carries information - a column knows its concrete grade, a duct knows its airflow, a door knows its fire rating - so the model can be queried, scheduled, costed and analysed, not just drawn. This is what the Information in Building Information Modelling means, and it is why BIM is a process and a way of working, not merely a 3D drawing tool.

Crucially, the disciplines do not all work in one giant file. Each authors its own discipline model - the architect an architectural model, the engineer a structural model, the services designer an MEP model - and these are periodically combined into a federated model for coordination. This division of labour matters: each team owns and controls its own model and remains responsible for it, while the federation lets everyone see how the parts fit together. Getting this workflow right - who owns what, how often models are shared, and to what level of detail - is the real discipline of BIM, and international standards such as ISO 19650 exist precisely to organise it.

The structural engineer's BIM model has a special dual nature that architects should understand, because it explains a lot about how they work. It contains two linked views of the same structure. The physical model is the real thing - columns, beams, slabs and walls at their true sizes, with reinforcement and connections, from which the fabrication and construction drawings come. Sitting inside it is the analytical model - a simplified skeleton of nodes and line-and-surface elements representing the structure's centrelines and stiffness, which feeds the structural analysis software that calculates the forces and sizes the members.

This dual model is why the structural engineer flinches when you casually nudge a column: moving it changes the analytical model, which changes the load paths, which may resize members far away in the building. In a well-run BIM process the physical and analytical models stay linked, so a change is checked for its structural consequences rather than just redrawn. It is also why the structural model is often less visually detailed than the architectural one early on - the engineer is thinking in load paths and stiffness, not finishes.

Models also carry a stated level of development (LOD) - a shorthand for how much you can trust an element at a given stage. An early-stage column might be modelled only as an approximate size and location (a low LOD), while a construction-stage column carries exact dimensions, reinforcement and connection detail (a high LOD). Reading the LOD tells you whether that beam position is a firm commitment or a placeholder still likely to move - vital knowledge when you are deciding how hard to coordinate against it. Confusing a placeholder for a commitment, or vice versa, is a classic coordination failure.

The single most visible payoff of federated BIM is clash detection - software that automatically searches the combined model for places where two elements occupy the same space or sit too close to be built, and flags each one for resolution. Run on a federated model, it will find the duct passing through the beam, the sprinkler pipe hitting the column, the drainage stack colliding with the stair, and the thousand smaller conflicts that used to be discovered one at a time by trades on site. Catching them in the model, weeks before construction, is the difference between a mouse-click fix and a jackhammer.

Clashes come in useful categories. A hard clash is two solid objects physically overlapping - a beam and a duct in the same place - which simply cannot be built. A soft clash (or clearance clash) is where objects do not overlap but violate a required clearance or access or insulation zone - a pipe too close to a wall to be lagged, or a valve with no room to be maintained. There are also workflow or time-based clashes to do with construction sequence. The team triages these: many are trivial and quickly reassigned, but the ones involving structure are often the most consequential, because structure is the hardest thing to move.

The healthy discipline around clash detection is regular, scheduled coordination meetings where the federated model is reviewed, clashes are assigned to whoever should resolve them, and decisions are recorded. The goal is not zero clashes in the raw model - that is unrealistic mid-design - but a controlled, shrinking, tracked list resolved in a sensible order of priority. As an architect you should expect to be an active participant here, defending the spaces and clearances your design needs and helping decide, when a duct and a beam want the same volume, which one moves.

Services have to pass through structure constantly - a drain through a slab, a duct through a beam, cabling through a wall - and how these openings and penetrations are handled is one of the truest tests of a coordinated project. The undisciplined way, and sadly still a common one, is for services to be run first and holes to be cut into the structure afterwards, on site, wherever they happen to be needed - which can weaken a beam or slab in exactly the wrong place. The disciplined, BIM-enabled way is to agree every significant penetration in the model, so the structural engineer can design the opening properly - reinforcing around it, sizing it, and placing it where the structure can tolerate it.

The governing principle is that structure decides where it can be pierced, not services. A beam can often accept a modest opening near its neutral axis (the middle of its depth, where bending stress is low) but not a large hole near the top or bottom where the tension and compression live. A slab can take a small penetration but a large opening needs trimming beams or extra reinforcement around it. When services need to pass a beam and there is no acceptable opening, the answer is usually to reroute the service - drop the duct below the beam, or coordinate the ceiling zone to accommodate it - rather than to compromise the structure.

A mature project runs this through the model with a penetration or sleeve schedule and cast-in sleeves and openings agreed before the concrete is poured or the steel fabricated, so nothing is chopped later. For the architect, the payoff is a ceiling void and service strategy that actually works, coordinated with real beam depths, agreed openings and honest clearances. The failure mode - services cut into finished structure to make them fit - is both a structural risk and an aesthetic disaster of exposed patches and dropped bulkheads, and it is exactly what coordinated openings exist to prevent.

The reason BIM matters beyond the software is a change in how a team holds the truth about a building. On a paper project, the truth was scattered across many sets of drawings that inevitably drifted out of step, and reconciling them was a constant, error-prone chore. In a BIM project the federated model is meant to be the single source of truth - the one place where the current, coordinated state of the building lives, that every discipline reads from and contributes to. When that discipline is real, everyone is genuinely designing the same building.

Making it real takes governance, not just software. Someone - a BIM manager or coordinator - has to steward the shared environment: setting the standards for how models are built and named, scheduling when each discipline uploads its model, running the clash detection, chairing the coordination meetings, and keeping the federated model current and trusted. International practice organises this through the ISO 19650 information-management standards and a project's BIM execution plan, and increasingly through open BIM exchange using the neutral IFC file format, so that models authored in different software can still be federated. The technology is only as good as the process wrapped around it.

For an architect, the practical lesson is to treat the model as a shared commitment, not a private drawing. Model honestly and at the agreed level of development, keep your model current, show up to coordination, and use the federated model to test your design against the real structure and services before it is built. The reward is enormous: fewer nasty surprises, ceilings and shafts and service zones that actually work, and a building where the coordination fights were fought and won on screen. Structure is usually the least movable discipline in that model - so the architect who understands how structure lives in BIM is the one who designs with it from the start, rather than discovering it, immovable, too late.