A Spoonful of Content Makes BIM Exchange Absurd

The absurdity for me began back about a decade ago — I can’t remember the exact year, but I’ll never forget the sequence of events. A client reached out to have me send a bunch of content from the drawings we had prepared for them over the years to a guy at Autodesk. After what I can only assume based on personal experiences was a full-court-press sales job, the client had decided to migrate their design criteria from AutoCAD to Revit and Autodesk was going to build them a template and a library of content on top of signing them up for rent-a-license annual fees.

In a rational world, this would be no big deal for me as my firm had already been producing this client’s projects using a BIM authoring tool for several years at that time. They would be catching up to me and maybe they actually start using the ever more powerful BIMs my team was producing. In turn, I could help them out with sophisticated content that was already up and running. Side note: since our contract obligated us to provide what some well-meaning, but ultimately poorly informed attorney wrote in as “AutoCad R.12 files” we simply exported our beautiful, smart BIM to dumb DWG files for the client’s records up to this point. The BIM was really just a more efficient design and production tool for us at that time.

But 21st century BIM practitioners do not operate in a rational world; we work in a world of daily absurdity. My offer of BIM content was rebuffed, most likely because Autodesk had mostly walled off any of Revit’s potential model geometry sharing capabilities ever since it acquired the software from its original developers. All they wanted was some DWGs, and to this day it still makes me laugh that my content went from Archicad to AutoCAD to gawd-knows-what to Revit. That. Is. Absurd.

I don’t mean to make this all about Autodesk walling off the rest of the industry either — even though that’s exactly what they do. The real point, the real absurdity, is the basic approach to BIM collaboration happening here.

My area of practice as an architect focuses on working with chain concepts on rollout development, especially with restaurants and retailers developing dozens or even hundreds of locations nationally here in the US every year, so that’s the perspective I’m writing from with this article. In conversations with other BIM practitioners, I’ve found that we chain architects share the same absurdity with those who work on larger one-off projects like campuses, stadiums, and high-rise buildings where the client has an extensive and very specific EIR.

Back to that BIM collaboration approach. Basically, every chain that’s migrated from CAD to BIM in the US takes the same approach, which is, “hey, we’re using Revit (insert specific version number here) to make a shit-ton of content for you, so you have to use Revit (insert same specific version number as client here) and use all of this content as-is — oh, and that’s super easy ’cause Autodesk said so. So get it done faster and cheaper too.”

This. Is. Absurd.

If I approached someone (maybe not you, as if you’re reading this you’re probably thoroughly tainted by the absurdity already) and said they would be spoon-fed a bunch of stuff for their job…

…and this stuff was often cumbersome or counterintuitive to their workflows, (imagine fixing the same errors with each new version of the content, or reformatting the same stuff over and over with each new design made from the content) but they couldn’t do anything about that because this stuff had to stay in the same format and version it came in even if the rest of their company was working in a different format and/or version since the content had no backwards or cross-platform compatibility…

…and receiving this stuff, and working for the client would tether them to really expensive and often flawed software — the only software that can use this restrictive format — and that software stops working if they stop paying in every year — even though other software does all the same stuff and more and better for less money, oh and it has perpetual licenses…

…and despite all that nonsense, everything they create for their client will be useless in a few years because this software will be unable to open the old files, so they’ll have to do the old work all over again in a newer version of the same shitty software if the project ever gets revisited by the client…

…they would probably stop to think and say, “well, how much am I making off this?”

FAIR QUESTION! The answer is certainly no more than you did already and there will be pressure to do it all for less since the client is investing so much effort in spoon-feeding you, even though their content is slowing you down. Also, what is your sanity and freedom to operate as you see fit worth to you?

…they would then agree to do the work anyway! Why? Remember: ThIs iS aBsUrD¡

Getting back to us, the tainted-by-absurdity BIM community now. A/E firms sign up for this — we line right up to participate in the absurdity. We need the work and we don’t want to let down our clients, even if they’re headed down an ill-advised path that will fuck over our G&A budget while giving our staff (especially BIM managers) migraines. There are also people amongst us who think this is a good idea because they don’t know better, so they’ll sign up for the work too. This is what we do as poor sap architects after all, this is our lot in life. Embrace the absurd!

When Did It Become Absurd?

The story of how it became absurd is a brief one. It’s not complicated. Autodesk acquisition-ed itself into the BIM paradigm and used that change to avoid the mistake it made with AutoCAD in not having a locked-down proprietary file format. Then Autodesk seasoned that shit stew with some restrictive versioning and a shift to renting instead of owning the software licenses. We poor sap architects made like Tennille and told our Captain, “do it to me one more time!”

But here’s the real kicker, in our (I’m using this possessive determiner to be nice, keep me otherwise out of this) rush to Revit, most made the same mistake that always happens at paradigm shifts in our profession and in this case, didn’t really change their CAD workflows for the BIM world they were living in now. A few users found their way to little bim and enjoyed new levels of production automation over CAD, but not much more than that. And here in the US there was virtually no Information in BIMs early on (and it’s not much better today).

This brings us back to chain concepts (and clients with large-scale one-off projects). Autodesk sells these corporate entities on flashy BIM doing fancy Information-driven shit, but they only get to little bim (the content I’ve seen made by Autodesk is, well…crap) and settle for getting automatic elevations and basic stuff like that. Keeping those old CAD workflows on top of all this, the corporate entities (our clients) push out templates and libraries to their consultants, but it’s not like it was with DWGs where people could use a variety of versions of AutoCAD or even other CAD tools (looking at you, Microstation and Vectorworks lovers, or any of the multitude of other software that can run with DWGs), you have to use the exact same version of Revit now as your client and absolutely nothing else. Side note: the acrobatics these companies and their consultants go through when the company decides it’s time to use a new version of Revit since it’s not backward compatible are truly something, and bring plenty of unintended consequences with them. Another thing the client doesn’t realize is that unlike DWGs or DXFs, eventually these RVT files will age out, and unless you have and old computer sitting around that can run that old version of Revit, you’ll be sitting on gigabytes of worthless files…unless (per Autodesk support) you also happened to save out an IFC file with that RVT back whenever (warm up that time machine). But no one reads that part. I know because no one involved in the decision making about using Revit at these corporations seems to know much about IFCs at all in the conversations I’ve had with them over the years.

We don’t stop to consider what you actually need for legacy BIMs, which is just the friggin’ BIM itself and not all the CD set content that proprietary formats include (at least not the editable original versions of it); and that these BIMs may not be needed for ten years or longer (ten years is a common lease term for the retail industry and that’s often when old designs get revisited). Who’s to say what we’ll be using to do our work in a decade? I certainly don’t want a bloated legacy file, as all that bloat guarantees a crash on open. Thus far Autodesk hasn’t done jack shit to make sure their customers can use those RVTs that many years later. It’s enough to make an openBIM advocate roll their eyes so hard they get stuck in the back of their head.

What Keeps Us Embracing the Absurd?

Fear, for one thing. We’ve been in the walled garden long enough to be worried that if we step outside we may not be able to get back in again. But on a more technical level, there’s the divergent objectives of openBIM that create confusion and frustration for people new to it that are just trying to be free to author BIMs using the tools and workflows and content that they control. This part is where some of the openBIM folks will get irritated with me, and that’s okay. We’re not letting perfect, standards-driven, Information-loaded deliverables get in the way at this point (though I do earnestly want us all to get there someday). Let’s just get ourselves decoupled from proprietary files and dumb CAD workflows for now.

If you dive into IFC, you’ll quickly get that it’s all about the ‘I’ in BIM — the Information. But in the beginning when you’re starting out with it, you really just want to be able to share model geometry with another party because that’s all anyone’s been doing to this point in time with all their RVTs and RTEs and RFAs and whatever else. This graphical side of the conversation is largely ignored in conversations about openBIM because those convos are conducted by the more advanced BIM practitioners who are simply focusing on their interests. Yes, these early exchanges will be messy and could be better with some Information coordination, but we’ll get there, just hang on. While we all need to be doing Information-driven BIM, we have to start by just making sure we can share the damn model geometry, even if it’s not perfect (it wasn’t perfect in the RVT either, so there’s that too). That’s step one for this particular project type and it’s the impure, ugly truth.

I’ve had the…uh…joy of being on both sides of the model geometry exchange: as the client’s architecture consultant and as the corporate entity, AKA the client. I’ve written extensively about the proper way to set up design criteria, which is not handing over a proprietary template and library based on your personal way of doing BIM, so I won’t go into that too much here. My client-side methodology is driven by the organizational structure I wrote about as well as rigorously documenting the Information in ways that allow for easy exchange and importation into the consultant’s BIM. The process I’ve described is definitely critical to open workflows, but it’s equally beneficial to any kind of chain rollout development efforts as it just works better for conveying design intent, and that leads to better outcomes.

This is an example of one of the client-side workflows I’ve used with great success

On the consultant side of things, I find that you need to keep things short and sweet with the client, as you’re lucky just to get a moment to talk about a different way of doing things. What I’ll do is discuss the IFC format and IFC viewers, then we’ll exchange some small, simple test IFC geometry that we can each look at the test geometry in the viewers and our BIM authoring tools. Now we understand how the geometry translates across platforms and make adjustments as needed. There’s often frustration for the client when they don’t see something exactly like the RVTs they’ve been looking at for years. I equate these feelings to the frustration one feels when initially learning a BIM authoring tool at that moment when they feel like it’s all too much work, too many settings to fiddle with, and it was just easier with CAD (but substitute RVT files for CAD in this case). I’ll explain to the client that it’s just different and that the BIM tools have settings to better control/automate imports and exports to make the software do the work for them. Like when initially learning BIM, just keep at out and you’ll grow to appreciate it for what it is: a better way of working because it lets all of us work the way we choose that’s best for us. There’s another conversation to be had with the client about the forward compatibility and reliability of the IFC format over time, and this convo goes pretty smooth as people don’t want to lose that work due to the passage of time.

I’ve found you need to give the teams doing IFC model geometry exchange time to get comfortable before you get into the Information part of those IFC-based BIMs, and some of those Information conversations will just start happening naturally when they realize the Information drives the model. After exchanging IFCs for a while, people start to make requests of each other with regard to model elements and maybe even some properties of the elements. From there, people see possibilities in working together to customize the BIM via IFCs neutral exchange and then you can start talking about including (or more accurately, cleaning up the mess of) Information embedded in that model geometry. People are shocked to find out that all the Information they’ve ever wanted from their BIM has already been asked for a zillion times in the past and that someone invented a system for reliably exchanging that Information (why hello, COBie!) and that there’s software to automate the movement of that Information between parties. It’s all baby steps to make sure we don’t lose anyone or anything along the way.

Will We Ever Not Be Absurd?

You can see how it’s easier when the client just does things openly from the start, as that trickles down to the consulting professionals and then everybody’s on board. It takes longer and requires more effort to push uphill with change from the consulting professional side of the content exchange.

The same mindset that resists adopting national CAD and BIM standards kind of applies here. For example, we all know our personal standards are best, so we don’t pause to think about a world in which we never have to spend time configuring and troubleshooting software for our own standards because the national ones are baked right into the default settings. It’s a similar kind of resistance that says it’s easier if I spoon-feed everything to those who work for me and we all do it my way in my software using my content — take all the thinking and choice out of it, you know…

Another obstacle to these efforts is the software and its limitations (mostly this is Autodesk, but not exclusively). A lot of Information exchange is hindered when developers don’t implement reliable import/export methods for standards-based information. I see Autodesk joined ODA, so maybe this will change, but I won’t hold my breath. Right now, Autodesk does a lot to muddy or just outright block the road for imported geometry to become a Family, which is a constant source of frustration and wasted time in my efforts to work openly amongst teams using a variety of BIM platforms. We find workarounds that allow us to support our openBIM efforts, but it’s clunky and inefficient. There’s no question that we need something slightly less shitty from Autodesk here.

Anyway, back to converting RFAs for use outside Revit just to be able to do some architecture. Have an absurd day!

A Quick How-To on Data Transfer Between Archicad and Smartsheet

In my twopart series on distributing design criteria via Smartsheet I explained how the heart of the process was a direct pipeline of information between Smartsheet and the architects’ and engineers’ BIM authoring tools. In my example of this I used Archicad and I wanted to share some more detail about how to make Archicad’s property import/export functionality work with Smartsheet.

Archicad has been able to import and export property data via Excel spreadsheets for several versions now and it’s a very slick way to use information to drive your BIM workflows with external vendors, subcontractors, and anyone else who communicates product and design specifications via spreadsheets. Since Smartsheet is spreadsheet-based and can import/export Excel files (among other file types), it too can be used to communicate property data with Archicad with just a couple extra steps to help all the data make the journey.

If you haven’t already used this feature of Archicad, read about it here in the Help Center before you dig into the Smartsheet workflow.

Now, here’s how property information transfer between Archicad and Smartsheet works:

  1. Just like you normally would, set up your properties and schedules in Archicad and then export them from each schedule you want to share with Smartsheet. This will give you XLSX files for each export.
  2. You can open the exported XLSX file and notice that row 1 in the spreadsheet is collapsed by Archicad. This row contains the GUIDs, which are the Midi-Chlorians of Archicad, who in this case are working behind the scenes to make things from outside of Archicad match up with things inside. You shouldn’t alter row 1 or do anything with it, so close the file without saving. It’s just important to know for later on that row 1 is there, and to note that row 2 is the headers from your Archicad schedule.
  3. Next launch Smartsheet and import the XLSX file. When you do that you’re prompted to select a row from the XLSX file to make the Column Headers in Smartsheet. You want to select row 2 here. In Smartsheet the header row doesn’t have a row number, which is different from Excel. This difference means the old Excel row 1 with all those GUIDs is row 1 in your newly imported sheet in Smartsheet.
  4. During the import process you’re also prompted by Smartsheet for which column to make the Primary Column in Smartsheet (Primary Columns have special functions that we don’t need here, but you’ll need to select one nonetheless). Select column 1 from the Excel spreadsheet, which is the column containing the GUIDs for each row in the schedule.
  5. Lock the Primary Column and row 1 in your new sheet in Smartsheet so no one messes with those while working on the rest of the schedule. Then go about filling out or changing cells as needed.
  6. When you’re ready to export the sheet from Smartsheet back into an XLSX file, do so like you normally would from Smartsheet’s File pull-down menu.
  7. Open the exported XLSX file in Excel. Here, we’ll need to move that GUID row that we made the Column Headers in Smartsheet from row 2 in the XLSX file back to row 1. Once we do that, the XLSX file is ready to be used by Archicad.

These are some images of the steps in the process noted above that may be helpful in understanding the workflow.

That’s it! A switcheroo of row 1 as it goes from the XLSX file into Smartsheet and then back into an XLSX file again is the key to this workflow. Hopefully we see a Smartsheet plug-in for Archicad someday that just does this for us automatically, but until then, this is how it’s done. Happy data-transferring!

Searching the Soul of Your Software Developer

The juiciest story in the BIM community at this moment is the open letter to Autodesk complaining about how shitty Revit is in terms of cost, licensing, feature set, interoperability, and day-to-day use. The letter came from a bunch of British architecture firms and was published in AEC Magazine. If you haven’t read it, you should. Autodesk is a (consistently) poorly-led company that uses acquisitions, restrictive proprietary technology, and marketing to return shareholder value instead of innovation and keeping customers happy. This is an important reminder that when looking for a new software solution, we should look at the companies behind the software first — why do they do what they do? Why do they exist? Who’s running the show? Then, we can look at the software itself, which is a lesson I learned very early in my career.

The BIM wars are tired because they focus on comparing features and functions of one BIM authoring tool against another — and rarely do they involve architects who have used both of the software titles being compared. In 2020 it’s safe to say that any BIM authoring tool out there is probably quite capable. They all have their strengths and weaknesses, they all have their blind spots that will shock and appall those who use different software. They all do stupid shit from time to time that will have architects ready to throw their BIMs out the window. No one of them is perfect, but they’re all capable. From there it’s more subjective in terms of UI and the intuitiveness of the experience, so whatever floats your boat.

It’s more interesting to look past the software itself and into the company that develops and sells that software. I’ve always thought this was an important thing to do when it comes to software that drives your practice (obviously it’s not as important for software that plays a bit part in your workflows). In school, I learned AutoCAD, which in the early 1990s ran on DOS or System 7. I liked it and it was exciting to be learning CAD. When I started working, I continued using AutoCAD on DOS. Version 12 was current at that time with version 13 coming out soon. My coworkers were excited about that new version, which made me excited as well. Then AutoCAD 13 came out. I still remember the firm’s IT consultant deploying its multi-diskette installation and changing out digitizer pad templates. AutoCAD 13’s UI looked noticeably different and ran on DOS or Windows only. Those were dark days for Apple and I wasn’t surprised that Autodesk dropped support for the Mac, but it still sucked: strike one. Anyone who’s used AutoCAD 13 remembers that it was a notoriously horrible version full of bugs, incomplete or missing features, and it was a frequent crasher at a time when recovery of lost work was overtime hours instead of restoring a recent past file. This was still in the first half of the ‘90s and it took the piss right out of everyone who was so excited about CAD technology in architecture. From then forward, getting excited about new releases of AutoCAD was strictly the realm of the CAD managers and tech nerds — the average production person at an architecture firm was just going to use whatever version of AutoCAD the firm had to get their job done and that was, more or less, it — no passion or excitement about CAD anymore.

AutoCAD 13 changed the way I looked at software in general and at Autodesk. I went from loving AutoCAD to hating it in rapid succession. I would read the CAD industry magazines and see Autodesk staff brush over the troubles they brought with AutoCAD 13 (though they did fix some things with AutoCAD 14, which took years to finish and release after the 13 debacle) and make promises about new versions. When it came out a while later, I tried AutoCAD Architectural Desktop and felt like blah-blah-whatever — it was too cumbersome for its own good. During this time, our Autodesk reseller hosted some training sessions to help expand people’s knowledge of AutoCAD’s feature set — they were mostly awful, and the last of these sessions was so bad we got a refund. By this time, the Autodesk promises were coming out hot and heavy, but with no substance and little in the way of delivered product. I began looking to get away from Autodesk. I was met with doubts and resistance, as people were scared that we wouldn’t be able to work with engineers, or be able to open DWGs from clients.

It was the late ‘90s when I heard about Graphisoft Archicad and its “virtual building” concept, which seemed really intriguing. But at the same time I was researching Graphisoft, I got a CD-R of a 3D drawing tool called SketchUp dropped on my desk. SketchUp was fast and easy; and even though it was dumb and disconnected from AutoCAD, just bringing 2D work to life in 3D so quickly without having to deal with AutoCAD’s clunky 3D bullshit was exhilarating for us AutoCAD users. I look back on those SketchUp years as a complete waste of time though. SketchUp was an enabler of Autodesk dependency in a weird way, as it was really just a shortcut to 3D from AutoCAD (for the record, I thought the people of @Last Software, who made SketchUp, were great and very, un-Autodesk-y).

It was 2006 when I got back on track and purchased licenses of Archicad for the firm to try out. This was after Graphisoft sent an actual architect to show us their software instead of some slimy Autodesk reseller. They offered training coupled with template and content development provided by an architect as well. The experience with the company behind the software was noticeably different from the Autodesk racket. Not to start pitching Graphisoft here either, as the point I’m trying to make is that your experience with the developer of your software is vitally important and it tells you something about their motivations. What I got from Graphisoft was a community of architects who were passionate about virtual building, which was quickly being rebranded as BIM…

…Long side-story short, I used Autodesk Revit at the same time that I was rolling out Archicad. I got to work with some talented Revit users and we learned and grew our BIM knowledge together. In retrospect it was nice to be able to use these two tools side-by-side. Revit made good progress during the early aughts and got more stable and useable. But for me at least, it was not nearly as nice to use as Archicad…and of course there was still Autodesk behind Revit being unbelievably shitty about support, licensing…everything…

…I was young and still learning the industry during Autodesk’s rise to a billion dollar company in the 1990s, but I could clearly see that their CEO at the time, Carol Bartz, was more interested in pushing new versions out the door and charging us for them even if they didn’t work well, than she was about making sure we were happy customers. Now, the shareholders on the other hand, were very happy during this time and made Autodesk a superstar on Wall Street. It took me a while and I got distracted along the way, but even in the early years of my architecture career, I eventually made the change away from Autodesk. This is why I’m always amazed that people still use Autodesk’s crapware and tolerate the abuse of this company’s licensing practices. Nothing — not one single thing — has changed since Carol Bartz set the tone back in the ‘90s. So, if you started a firm since that time and still got into bed with Autodesk when it came time to buy software, it’s hard for me not to laugh after reading the open letter in AEC Magazine. Those firms aren’t even contemplating leaving as they try to fix an unfixable relationship. There’s plenty of other great choices out there and no one will die if your firm no longer uses Autodesk software to get the job done, we “outsiders” all manage to grow beautiful designs in our own little plots of heaven-on-earth outside of Autodesk’s walled garden.

As for the software developers that didn’t just get written up by an angry mob of users? Remember what brought us to you in the first place: the fact that you weren’t Autodesk and didn’t act like Autodesk. Keep it that way or your next.

Information-Driven Design: Distributing Design Criteria via Smartsheet – Part 2

In Part 1 we looked at how Smartsheet can serve as a tool to help organize and disseminate design criteria for companies doing rollout development of their concept. We discussed how vitally important it is for the design criteria being referenced by external consultants like architects and engineers to be current and accurate.

In Part 2 we’ll cover how to build a pipeline of current and accurate design criteria between Smartsheet and the BIM authoring tool used by the architects and engineers. This pipeline of information is the automated magic that makes this workflow superior to everything that came before.

You’ll recall from Part 1 that we loaded up sheets with specifications in a schedule format where each row represented an individual fixture, furnishing, or piece of equipment. BIM content corresponding to each row was attached to that row. Smartsheet’s push notifications let external consultants and vendors know that changes have been made and are ready for download and export. With this functionality in mind, we’ll establish the information pipeline to the BIM. In the example of this workflow, we’ll use the architect as the external consultant and Archicad as the BIM authoring tool, but the workflow is essentially the same for other consultants and other BIM authoring tools.

The Workflow

Step 1: Notifications & Downloads

Once the organization makes changes (including additions and/or deletions) on a given schedule sheet, the architect receives an email notification highlighting the change from Smartsheet. The architect then opens the sheet and goes to the changes (if desired, the company can even have Smartsheet highlight the changed cells in the sheet itself for ease of identification) to download the new BIM content if applicable. If the change is to the specifications, the architect exports an XLS file of the schedule from Smartsheet as well.

In this example, we see a simple schedule entry with an Archicad Object attachment to download
Next, we can export the Smartsheet schedule to an XLS file, now we have model geometry and scheduling data for our Archicad PLN

Step 2: Updating the BIM with Changed BIM Content

The architect will add the BIM content to the library for their BIM, retiring old content if applicable. The updated library is reloaded and the new content gets verified in the BIM, including aligning the new content’s ID and classification with the corresponding schedule in the BIM. Next, the architect can then begin updating the scheduled specifications for this new BIM content.

Here, the architect brings the new Object into their PLN file and prepares it for receiving scheduling data automatically

Step 3: Updating the BIM with Changed Specifications

The architect imports the data from XLS file from Smartsheet into the BIM to update the properties of the BIM content with the changed scheduling information. Schedules in the BIM then automatically update with the changes, with no manual data entry required

This image shows the XLS file’s data being imported by Archicad to automatically update the corresponding Object and schedule in the BIM
Here’s the schedule in Archicad, all matched up with the original from Smartsheet and ready for CDs

This workflow is the same whether the architect is updating their template or a live project. The three step process can be completed in just a few minutes as well.

Another great feature of this workflow is that the company can allow the vendors who provide the stuff in the Smartsheet schedules to update those schedules and their attachments directly which effectively extends the information pipeline from the architect directly to the source of the information, further reducing opportunities for errors and omissions.

All Done!

Let’s be brutally honest here, no one likes doing prototypical updates — it’s boring af — so the more of it that we can leave to technology like we see in this workflow, the better off we all are. Having it be more accurate and timely is an added bonus. Distribution of a chain company’s design criteria is just one use of this workflow, so I’m hopeful that as more jump on board with it, we can begin leveraging Smartsheet APIs to have the workflow be even more automated than what’s shown here — like a plug-in for the BIM authoring tool that grabs all the content and data straight from Smartsheet. Bring it on!