Settin' Sail with a Centralized Data Model: A BIM Pirate's Guide to Wrangling Data and Reducing Errors

Ahoy, mateys! This weekend, I took a break from buildings and buried me nose in a treasure map of sorts—a data model for architecture, one that’s all about puttin’ the same data in one place to avoid errors and save time.

The Problem: Data Be Slippin’ Through Our Fingers

As architects, we’re surrounded by information, but we’re forever re-enterin' it. Let’s take a plan header—a simple thing, eh? With the project name, client, and revision info, it’s easy enough to create. But here’s the rub: we need that same info across a vast sea of platforms:

• Bookkeeping software
• CRM (if ye have one)
• Modeling tools like SketchUp and Revit
• Plans and headers, the IFC model, and other documents
• The CDE (Common Data Environment)

Manual data entry, mateys, is like patching a leaky hull. Studies show we re-enter critical info an average of 6.5 times per project. Each re-entry risks error, costs time, and sometimes leads to that dread disease of data—misalignment. Now, imagine some of this info changes, and not every system is updated. It’s like sailin’ with a faulty map!

The Solution: A Centralized Data Model (with a Pirate Twist)

Instead of re-enterin' data until we’re blue in the face, I crafted a centralized model where core data is entered once and flows where it’s needed. It’s like a strong anchor at the heart of our ship—a single source of truth, ye might say.

Here’s the approach:

1. Centralized vs. Decentralized vs. Hybrid

   • With a centralized model, everythin' flows through a single database, the master record.
   • A decentralized model lets data float between systems without a single point of control.
   • I went with a hybrid approach: JSON fields manage certain bits, keeping flexibility, while the core data be centralized.
     
     

2. Following the Map: The IFC Schema

   • Most folks see IFC as a file format, but it’s a map—a schema designed to handle every detail an architect could dream up. Followin’ this schema, I created a model that captures essential project details, making it intuitive and covering all bases.
     
     

3. Tech Stack: The Pirate’s Arsenal

   • Workshops: With all the technology the human touch to truly understand the client becomes even more important.
   • SketchUp: For true 3D-first modeling, flexible enough to scale from low-detail to construction-level details.
   • AbstractBIM: To quickly get consistent models for cost calculations
   • IfcOpenShell: To enrich data and maybe connect to Speckle down the line. I’m still testing, as my workflow depends on Space/Room data and deriving geometry for walls and slabs. SketchUp works fine, but IFC recognizes IfcSpace as a "virtual element," meaning no geometry or coloring by property yet. Something to figure out, but the database be prepped, using Speckle’s geometry format.
   • Pragmatic Requirement Manager: Define data models and create IDS.
   • Trimble Connect: A CDE for data exchange, included with SketchUp and API-enabled.
   • MySQL on Azure: Hosted and accessed through a Streamlit app for easy project metrics.
   • Sortdesk Viewer: A future alternative for BIMcollab ZOOM, though for now, I stick with BIMcollab for quick visualizations.
     
     

4. Building the Database, Piece by Piece

   • Tables for:
     • Projects
     • Type Elements: Core elements with geometry, defined by the business logic.
     • Type Attributes: Standardized attributes for each type.
     • Element Instances: These represent actual geometric elements tied to a type and the possibility to overwride the Type value with an Instance one. (So imageine the boss wanting to have another floor material in his room...)
     • Attribute Instances: Specific values assigned per instance.
     • Relationships: Here lies the gold! This table shows how elements and attributes relate to each other. Essential for automating workflows and inching closer to a graph database. For now, MySQL serves, but I’ve got an eye on graph databases.
       
       

5. Stayin’ Flexible with JSON and Graph Databases

   • JSON fields let me store evolving data without overhauling the schema. I also manage relationships in a way that allows hierarchy and complexity, which is essential when we eventually make the leap to a graph database.

What’s Next for This BIM Pirate?

This centralized data model, I’m crafting in the Pragmatic Element Plan, a framework that helps me quickly work as an architect, project manager, and quantity surveyor.

And the next step?

Testing it in real projects! The treasure awaits, but I’m ready to sail into the data-first waters of architecture. I reckon most architects aren’t quite ready to plunge into this approach just yet, but who’s to say?