shelidonMarch 31, 2018Leave a Comment

Post originally authored for the blog of Strategie Digitali, on March 31st 2018.

As you probably know, we’ve been strong advocates of the concept behind Flux.io: share data, not models. We firmly believe this is the future of collaborative BIM: stop all this madness of poorly converted files, bad import and worst export; just let the data flow.

Unless you’ve been asleep for the past month or so, you also know the bad news: today’s the last day of Flux, the platform is shutting down and the developers are moving on to other projects.

The official reasons behind this decision are, as we’ve been told, also the truth and you can read all about it in their press release here: the industry was simply not ready.

«until the industry is ready to revolutionize its processes, relationships, and contracts,

it may be too soon to offer an end-to-end data sharing solution».

Jamie Roche, CEO

Goodbye Flux, then: you’ll be dearly missed and some workflows that were taken for granted will have to be tweaked around to make them work again. See for instance our post on how to connect Revit and Google Sheets: it’s a workflow that’s four years old. Or, if you’re Italian speaking, see this article on how to bring Open Street Map Data into Revit with the Elk package of Dynamo, something we didn’t have to do anymore because the Site Extractor was around (and we wrote about it, for instance, here). It’s three years old.

Regardless of the impact on our everyday life, the closure of Flux is a cornerstone in the development of a data-driven culture in the Construction Industry and it should give us pause. I’m not going to get into their business model: I’ll leave this kind of speculation to others. What I’m going to say is simply trying to bring some issues to your attention and I hope a productive discussion on our future will come out from this.

Why use a plug-in, when I can script?

This I’ve heard a lot. Some people were not using Flux simply because you can script the hell out of your models and shoot data from one software to the other without any additional means. Well, of course. That was never the point.

The use of a cloud-based platform has, historically, two main reasons behind it (and a bonus):

• work from anywhere: you want to access your data from anywhere in the world, instead of being chained to your desk like a little nerd;
• work with anybody: you are not working alone (and BIM is about collaboration, or so I’m told) and your data needs to be shipped to somebody else, who ideally is doing a different job than you and might be using a different software than yours, one more suitable to his/her own needs;
• BONUS REASON: be Godzilla-proof. A cloud-based platform often offers backups and disaster recovery services that are far more efficient than your paranoia-driven NAS redundant storage.

Also, there’s another reason to use a product instead of your own in-house scripting and I’ll let you know it from a guy who knows a little bit about scripting. The whole thread has a lot of nice inputs on the issue.

Every engineering firm I’ve visited in the last few months has built their own data interoperability “platform.” There are companies like @teamkonstru who make it their business to solve this problem…

— Ian Keough (@ikeough) 24 febbraio 2018

If we all agree on this, then why don’t we seem able to do it?

Also, just try and remember that technology needs to be, to quote a client of ours, inclusive and not exclusive. The fact that you can script (and can you, really?) doesn’t mean that everybody in the Firm can or even should be taught how to script in order to gain access to those kind of workflows. Tools such as the Scheduler or the Dashboard allowed you to include in those workflows even people with a very low level of digitization.

Isn’t there enough money?

One reason that might come to mind is: Companies are not investing in this kind of data management solutions because they are lacking funds. In my experience this is not true. Money is being spent in all sort of things. Sometimes the issue is simply that Firms are lacking the necessary structure to even draft up a budget that goes beyond what we can manage to spend on this specific project. And bear in mind that our industry considers “projects” things that technically are not. A project by definition is:

• uncertain;
• doesn’t last forever;
• requires the involvement of different specializations and departments;
• is unique;
• implements a change at a corporate level.

Lots of irony can be done on this (starting from the “shouldn’t last forever” part) but I would like to focus on the last point. Each and every project the Firm undertakes, expecially in these exciting times we’re living in, should be taken as a chance to implement a change in the Firm. Now I understand that you might not have found profitable using a data exchange platform such if you tried and use it to transfer parameters from the drawing list of one consultant into a Revit model done by your grandmother. Have you tried to use a data exchange platform to centralize all parameters of all the drawings that are being produced across multiple software throughout all projects in your Firm? You might answer that you can’t, because all projects are different. And that’s the issue. Tailoring processes all the time is expensive. Automation, on the other hand, requires structure and standards.

And here lies the problem

You can’t just go ahead and implement a performing data exchange and interoperaility platform. Just as much as you can’t go ahead and buy a third party script expecting it to work perfectly on all situations. You need a managed infrastructure. You need a manager. Call him/her BIM Manager, call him/her VDC Manager. Call him/her Gigi. Call him/her however you want but you do need a manager who does the manager. Not on projects. Not working just on research and development. You need someone who has a clear picture of the whole firm, managing and implementing the infrastructure so that workflows are smooth and projects don’t have to reinvent the wheel each time. You need someone to turn data management in your projects into business as usual, instead of it being a project in itself each and every time. You need culture, across your whole organization, and people to understand that data is important and needs to be structure. Then, and only then, you can tell me that you tried a third party platform and you found it not to be performing. Until then I will stand by my opinion.

We were simply not ready for something as Flux. And in few years, when we will be ready and we will be working with a product that will be extraordinarily similar, I hope we will take a minute to remember and admit that those guys were right. Until then, all we can do is withing them the best of luck for their next endeavor.