From Drawings to Data

HAVARD VASSHOUG: Hello. My name is Havard. I'm a Norwegian engineer. I'm 45 years old, and I run a company called Reope that I founded in 2017. Right after coming home from Autodesk University, actually. So I'm very, very happy to be back. I'm joined here today with my colleague, Harsh Kedia, and I'm going to ask him now to say a few words about himself. Harsh, would you mind?

HARSH KEDIA: Not at all. Hi, I'm Harsh, and I work at a company called Reope that was founded by Havard. I've been working here for about a yard and a half now, actually. And my background is as an architect. So this is actually my second time at AU. Last time, I visited, basically, as a budding technology-driven architect with an architecture firm called NBBJ. And now, I'm helping people like myself from my past life becoming better with this presentation that we're going to talk about, "From Drawings to Data."

But I'm going to hand it over back to Havard to actually introduce you to the topic and what we're talking about here.

HAVARD VASSHOUG: Thank you, Harsh. So you will meet Harsh again a little bit later when we move to the section of our presentation that is called "The Solution." Harsh is a solutions guy. He is the one who handles solutions at the company. And I'm the problems guy, so I'm going to be talking about the problem. People give me problems. I hand them over to Harsh. And it seems to be working quite fine so far.

The topic that we're going to be talking about today is the AEC industry moving from drawings to data. And this is a topic, maybe, that is familiar, or it feels familiar, for a lot of architects and engineers. But it is not very familiar for the people outside of the architecture and engineering industries. But in contractor environments, with building owner organizations and with facility operations and maintenance and development organizations, working with data is not extremely well-known. And a lot of those companies are, today, using drawings. And this presentation will take you through [AUDIO OUT] and our solutions or our thoughts about possible solutions for this industry trend.

That started out, for me, personally, in a little bit of a weird situation where this problem, it crept onto my desk. Actually, the desk that I'm standing by right now. I was working on this project, together with a lady called Veronica. And I was here as the Revit expert, and she's an architect. And she came over to my desk one day, and she asked me something like this-- Havard, we have a gigantic project. And I said, yes, we do, Veronica. We have 16 Revit files. Mm-hmm. In all those 16 Revit files, there's about 3,500 doors.

And you know what? In a meeting the other day, someone asked me or told me that I need to add a bunch of parameters to my doors. Not width, height, and thickness, and threshold and handle and things that you would think an architect is worried about, but actually a lot of metadata. Data. And little did I know that, actually, what hit me that day or what crept up onto my desk from Veronica's oral translation was a gigantic transition for a very, very important and impactful change in the building industry that is impacting a lot of people today in many, many different organizations and disciplines.

And that's how this problem came to me, without me knowing it. I was into parametric design and generative design and programming, blah, blah, blah, with visual scripting tools like Dynamo. And I was not aware that this problem even existed until Veronica told me that day. So I ended up actually helping Veronica solving that problem, building a Revit workflow that made sure that she could spend more time with her kids than her doors, which was great. But it also sent me down this rabbit hole of data in the AEC industry and how poorly it's managed today or the possibilities, the potential for improving these processes today.

So that's the story. I'm going to be talking more about these problems in detail. Now, what actually did change was that Veronica's client, some time ago, decided that we are not just going to mandate that the planning of this building is happening in 3D or in a database and that it's going to be delivered in IFC files, in addition to the original or old formats, and that the team is going to plan this using VDC methods and coalition control and all of this. We are also going to require information connected to the BIM deliverables in this project.

Why, you may ask. Well, a lot of organizations-- as architects and engineers, we're used to working with databases today. I've been using Revit for 15 years. Revit is a database. That's the first thing I say during Revit training. We're used to changing things in one place and searching for things intuitively and building applications on top of data. But that is not what is happening outside of design teams today. Building owner organizations, contractors, people who work with facility operations and maintainance, they also want to do this.

They also want to innovate. They also want to build scalable applications that use data for their innovation. Proptech needs information. And so then, you ask, great. That's good. What's the problem then, Havard? Well, I'll tell you. The problem is that it's really difficult with the tools and the processes that we have today to deliver consistent data. So that's the hypothesis that I'm going to be describing right now, is that the larger industry needs data, but it's not getting quality data. It's actually getting pretty poor data, in many cases.

So the problem is data quality. And the process here looks like the sketch. Every project starts with information requirements. And then, you're going into building information modeling, which is a design, and then delivering that information. And that information is getting validated before it's shipped off to owners and contractors who need the information. So let's break down the problems a little bit, to get into the details. I'll get very hands-on with this, actually.

The big problems-- or the biggest problems, as I see it, during these few years that I was involved with this, after Veronica came to my desk, has to do with a workflow that is, today, existing, going from owner requirements to BIM implementation and deliverable. That workflow is broken. I'll get into the details later. It is also very problematic for a lot of people, a lot of design teams, to deliver consistent data. And that is, maybe, the easiest one to explain. When I say data quality is suffering, it has a lot to do with consistency. I'll get into that, as well.

And then, in the end, we'll talk about validation because nobody knows. I get people calling me every week. Havard, can you check this data? Havard, can you check this data? Nobody knows. And let's dive into that, also. And we will look into this broad from a problem side, but also, from a solution side, as well, where Harsh is going to help me out. All right. Requirements. What is happening, today, with requirements?

To be very clear-- I mean, from a Revit point of view, and in my world, the only way to create BIM information today, as I know it, is from Revit, AutoCAD, Tekla. BIM modeling tools. There's databases like [INAUDIBLE] and other tools that lets you create data in a database. If you are making an IFC, the main tools are Revit, AutoCAD and Tekla. And I'm going to be talking about Revit, but Tekla and AutoCAD share the same problems.

If you're a BIM manager in Revit today and a building owner tells you, well, you need to implement all of these information requirements, well, worst-case scenario, you download a PDF or he sends a PDF to your email. And then, you look at the PDF with your eyes and you open the keyboard and you start creating shared parameters in Revit. Now, that is a problem for many, many different reasons. One of them is that the creation of shared parameters in Revit-- first of all, parameters in Revit are wonderful, but they are not super easy to manage, especially shared parameters.

Creating them, you have to go through all of these different settings and dialog boxes and menus. And there are so many things that you can do wrong. And once you've created a shared parameter, you can't ever change it inside Revit. Have you ever created a shared parameter, put a bunch of information on the parameter, and then, you did a spelling mistake and someone asks you to rename that? Well, good luck. Good luck, buddy. Because that is a job that nobody wants.

And that process, today-- I'm talking about vanilla Revit-- is completely manual. There's no way you can just link to a building owner information requirement database. There's no way you can automate the creation of these parameters from, even, download an Excel spreadsheet. And worst-case scenario, you have a human being reading a PDF and a human being typing on a keyboard. You take a wild guess on how many spelling mistakes are going to be in those parameters. So that is a workflow problem.

It's a broken workflow, from finding out what someone needs, information-wise, and then, creating the system that your team needs to add this data to a project. So this is the process, how it looks today. Downloaded by a human being, typed in on a keyboard, and put into BIM. And that needs to improve. The second problem, consistency. For some reason-- and we can just theorize around the reasons why this is happening. But on every single project that I work on, consistency is suffering for better quality. And that's our most visual way to show the lack of data quality, is the consistency in information deliverables.

The reasons for this mostly has to do with people. But I would say people not having the right tools. So when you have a human being typing a parameter all day long, all day long, on all those 3,500 doors, there's going to be a spelling mistake on the parameter name. There's going to be a spelling mistake on the IFC translation. There's going to be a spelling mistake on the value itself. And so, the person doing this actually needs better tools and more automation.

Today, in Revit, you cannot do any of this. You can click on an element in Revit and then change its parameter. And most of this information is metadata information, which means it's text-based information. Maybe you'll have some booleans, like here, but it's mostly text booleans. Maybe some numbers. But anyone in any Revit file can just type whatever they want into that property. And then, it will go out to your clients. There is no QA process or limiting the amount of option. It's just free text for anyone.

And then, we're moving on to validation, the last point. Nobody knows. The sender doesn't know and the receiver doesn't know. The sender of the information doesn't know and the receiver of the information doesn't know. And why don't they know? And I would say mostly because they don't have the right tools to know. It's possible to know, but they don't have the right tools to know. The sender doesn't know because, maybe, they are-- the only way of checking metadata quality on their native BIM before export is to use the right schedule.

You don't want single-click elements in a plan view or a 3D view and, then, look at the information in the Properties panel. The least amount of intelligence you can use is to create a schedule where you see all the information in your model and, then, look at those properties and the property parameter values. But you're still looking with your eyes, checking. You're seeing values, and you're checking them with your brain to see if they are correct or not. Doesn't sound very smart, does it? No, it doesn't.

And then, of course, we can get into talking about Add-Ins and Dynamo and Rhino.Inside and descripting. And so, there's a bunch of ways this can be done better, but I would say, probably, 90% of every architect and engineer is doing QA in Revit with a schedule. If you're the receiver of information, there's a jungle of different tools you can use.

And one of the most popular ones, probably, Solibri from Finland. There's Navisworks, and there's a bunch of free IFC viewers that you can use to open IFC files, which is usually the BIM deliverable in most projects. And then, creating, in this case, an information takeoff in Solibri and, then, getting this visual schedule where you're seeing colored elements based on the information in the table. You still have to create information takeoff. You can get a BIM expert to make one for you and, then, show you where you click Import. And you still have to open IFC file, IFC file, IFC file, and then, aggregate that information.

To my experience, most of the people who actually need to know this information doesn't want to do that. So maybe they have a benchmark expert who can help them do this. But, most commonly, they don't. So the decision makers-- the managers and the building owner and contractor organization-- who are receiving poor data quality every day, they need a much, much, much lower threshold platform to know that what they are getting, they can actually build and operate on. These are all problems.

And I've said multiple times, when it comes to solutions, I'm going to hand the microphone and the camera and the presentation over to Harsh. Go ahead, Harsh.

HARSH KEDIA: Thanks, Havard. So I guess I'm the theoretical solution guy at Reope. And when Havard came to us almost a year ago with all of these problems that he was facing on projects-- and these were multiple projects-- we had a little bit of a brain fart moment because we had been trying to solve this for quite a while. As Havard mentioned, we have built Dynamo strips to solve this. We've made Add-Ins. But the problem was that we were always managing this metadata information inside of the designer's design application. And when you're doing that, you are constrained by what the application is built for.

And Revit, while it's a great modeling tool-- it's a great design tool and a great drawing, producing tool-- it's not so great at managing properties. And so, we had this little brain fart moment last year, which said that what we really need to solve this problem is a property database that is outside of Revit, ideally, and has built-in automation and validation capabilities. And so, then, if you have this property database, what you do is you design and model and do all of your core architecture stuff inside of Revit. But when it comes to delivering on your requirements, you do it in this property database and you combine them together and deliver a file as the result.

What that looks like is something a little bit like this. Basically, when you get the information requirements from your owner, you use the property database as the primary store of all of your parameters and properties and information and you link it with your design tool, be it Revit or AutoCAD or Tekla. And as you can see, this diagram already removes quite a few steps where errors can occur and takes a lot of time and manual work away from the design teams. And so, if you actually have this diagram and it works well, you end up saving a lot of time and money on projects and you end up delivering the correct data that you were actually paid to deliver.

One quick disclaimer before I go further. We have built this property database. It's called Anker, and we are going to present Anker-- I'm going to present Anker to you, going forward. So it might seem a little bit like a sales pitch, but it's really not. We're just presenting our solution to this problem. I'm sure there's others that are equally as good and that you love and use. But I just want to show you guys what we came up with to solve this problem. So, data quality.

As Havard mentioned, again, there are three problems-- requirements, consistency and validation. We solved each of these with our property database. For requirements, all you really need is easy imports. You don't want a person typing in, by hand, each and every single property requirement by the owner. You just want to import it from their database or Excel spreadsheet or whatever format they give you. Consistency basically revolves around good UX that is built or custom-built to manage properties and automation where, if the property does not need to be managed by human beings, it's better that it's not done by a human being.

And lastly, validation. What Havard showed you previously was people seeing these schedules and going line by line, looking at property values. But that's not really validation. What you want is to know what is right and what is wrong and get and give your teams actionable feedback. So let's dig into the first one, which is requirements. This is a little video of our database, Anker, where, say, you have a bunch of property requirements from a building owner. This is a little Excel spreadsheet with about 100 properties that have been asked of us from the building owner. And you've got string properties, option properties, different kinds of information.

What you do is you go to Anker and you hit Import. And within a span of a few seconds, you have, basically, a whole bunch of different properties that are ready to use and manage in your project. For example, here, I'm managing DMMI value, which is a Norwegian LLD, basically. And you can go and click the Options and actually select the right value instead of having to type it in by hand, like Havard had showed earlier.

And this way, just by having this option and import alone, you can save a lot of time and errors in your team. And so, this way, at least when the team is inputting data, they know that it's one of the predefined owner options, and you're not typing in something that could be a spelling mistake or incorrectly typed. The next thing which we solved was to do with automation and inputting a lot of data together to solve this consistency problem.

And as you can see here, I have this little table with four different properties between 21,000 elements that I need to input. This is what my building owner has asked me. And to input it by hand, again, creates a lot of problems. And so, in Anker, I have just gone ahead and set up a simple population tool, like a Dynamo get set parameter. But the good part is when I run this, it does not throw me errors. It does not throw me warnings. I don't have to open 16 different Revit files. It just works across all of my files and across all of my data in the span of a few seconds and gives me a correct result.

So as you can see here, I have inputted 21,000 rows of data in just a span of a few seconds. And I know for a fact that this data is correct because there wasn't a human being inputting it on a keyboard by hand. And lastly, the final problem that Havard had mentioned, which I think is probably one of the most important of his list, is validation. You've got tools to input this data correctly and you have a database to import these requirements to. But how do you know that what you're delivering is correct? How are you contractually delivering on your client's needs?

Well, we built a validation module into our software, and it works a little like this. You basically import the owner requirements. Again, this is a format called MBD XML that some owners use. And it basically creates this set of rules that you can check your data against. For example, the owner here are saying that, if it's an IFC door entity, it must have these five properties on it. And I can check all of my IFC doors on a project just by hitting Play. And I get this nice, high-level report telling me what I'm shipping to my client.

And, two, this is actual machine-readable validation. I actually get a report from my tool, telling me whether I'm meeting my owner requirements or not. And if I want to actually see a schedule and dig into the values, I can do that, as well. But I usually start with the report. One of our big building owner clients actually has been using these reports pretty often. There was this gentleman on a project who basically received 20 gigabytes of IFC files every Wednesday morning. So this is about 15 to 20 IFC files with 5 to 10 million elements and almost 100 million parameters. And, honestly, I don't want to be the guy checking 100 million parameters.

And he didn't either, so he came to us and asked us if we could solve this problem somehow because it would take him two days to download 20 gigabytes of files, put it into Solibri, run information takeoff. And yet, at the end, he wasn't even sure if the data was correct or not. And so, what we have done for him here is, using Anker, build a one-click solution to actually check all of these properties. And he uses this one-click solution a little like this. He comes into the office. He presses Refresh on Power BI. It automatically takes all of the new files. It runs the validation on it and lets him check it based on discipline. So here, I'm checking just for the architecture model in a specific zone. And I can see, live, what data is correct and what is wrong in my delivery.

And then, I can go down and dig deeper into specific b-sets. I can say, OK, just show me the b-sets that are needed on-site today. And I can go even deeper. Just show me that one property that the contractor has asked for on-site today, without which, they will not be able to do work. And this workflow, this one-click solution, has saved them a lot of time and pain in actually improving the data quality and, therefore, the cost and the site delays and time consumed on the project.

Just one last observation on validation that I wanted to share with you guys is when we're moving from drawings to data, you imagine-- I've worked as an architect on drawing-based projects. And when I was working on a pretty simple building project, we had almost 100 drawings. And when you have 100 drawings and you need to quality assure them and check or validate your drawings, you put them on the wall behind you, and you take a red line and you start going through each drawing to check it. This is a very manual and time-consuming process.

And while it's nice to learn a little bit about your building at a overview, it leads to mistakes. Human beings make mistakes. We all know that. But the moment you start actually having machine-readable properties and machine-readable data, what that lets you do is let you make machines check it for you, as well. So at least, at a very base level, you know that the data you're receiving is the data that is expected. Or you can tell the machine to tell you that it's not. And this way, it saves a bunch of time and saves a bunch of money because you don't make as many mistakes.

But that's it for the solution. Our software, as I mentioned, is called Anker. And go check it out. It's on reope.com/anker. It's in open beta, so it's free for anybody to use if you want to try it out. And honestly, our goal with Anker right now is just to have people like you guys-- people who are like us and face similar issues-- to try it out and give us feedback. And we can have some good conversations around the topic. But that's it for us, or for me. [LAUGHS] And I'll hand it back over to Havard to conclude.

HAVARD VASSHOUG: Thank you, Harsh. The construction industry is the second least-digitized industry on the planet. Below them, I suppose, is agriculture. Isn't it? Yes. If we are going to digitize the construction industry, we need to give the people outside of design teams the ability to work with information, to work with data, to build applications on data, to build the processes on data, to automate on data. If they cannot do that, they will never be digitized

This is happening today based on BIM because BIM is what we have. BIM, there are many, many, many, many different-- you can say what you want about BIM. Some people hate BIM. A lot of people hate BIM. Sometimes, I hate BIM. But a lot of processes are built around BIM today. So we are not doing a revolution. We are doing an evolution-- building processes on top of other processes.

And now, we are building processes on top of BIM to get quality, to get data from BIM to other people than the people who have been using BIM before. And this, now, today, we're talking about contractors, building owners, facility operators, maintenance people, and so on. They need to work smart and fast. And in order for them to do that, they need data. They need quality data. Without quality in the data, everything falls apart. So that is, actually, the main point, probably, that I wanted to do.

On that, I will say thank you for watching this presentation and thank you for keeping up until the end. If you are listening to me now, you are actually at the end. So congratulations, and thank you. And see you soon.