Model Audits, Checks, and More: The Current State of Affairs with Big Brother and Model QA

ROBERT MANNA: All right. Good afternoon. You're all here. Congratulations, because, I don't know about you, but it's an awfully long week. Thank you for coming. Hopefully, you find our topic interesting and enlightening, or at least we provide entertainment, whichever one fits the bill.

So I'm Robert Manna. I work at Stantec, which is a very large global engineering and design company. We also do architecture. I like to say that I am a member of a 450,000-person architecture and engineering firm with 18,000 of our closest friends that do a whole lot of other stuff.

But I guess, maybe more interestingly, techie by accident. That actually-- I was signing up for non-profit access to some Microsoft software, and they do it through a clearinghouse-type thing. Of course, they want to know about you, and you have to create an account. And the first option for what do you do was, Techie by Accident. I thought that was a really good description of how I got to where I am.

Other random fun fact, the green was summer vacation with the seven-year-old and the three-year-old this year. And we did survive and made it back. I went to Kansas City for barbecue. Oh, wait, no, there was a conference I went to, too. I'm probably not supposed to mention other conferences' names here, or something like that. You want to introduce yourself, sir?

AARON MALLER: You did it again, didn't you?

ROBERT MANNA: Where did--?

AARON MALLER: I get no slide. That's OK.

ROBERT MANNA: He watched me make it.

AARON MALLER: I watched you make it.

ROBERT MANNA: It's probably somewhere else in the deck.

AARON MALLER: You're probably in the wrong presentation. My name's Aaron Maller, if you don't know me. If you know me, I apologize. I work for Parallax Team. We are a, like Stantec, a super, super, super large company. There's two of us.

There it is.

We do all sorts of things related to BIM implementation-- template development, content, making teams more efficient. And for the last year, we've also been working on model audits both for design teams and general contractors, which I think is why Robert and I thought this would be fun to just have different perspectives on this topic.

ROBERT MANNA: Absolutely.

AARON MALLER: I did not road-trip with my family across the country. I got on an airplane, because I'm normal.

ROBERT MANNA: It's like that commercial for the Kia or something. Has anybody seen that commercial? Anyways.

So there's been a lot of classes about model health and performance checks in the last two or three years. I think I've-- went to a high percentage of them. And I always felt there was some-- a piece missing that I thought was missing and I thought might be interesting to an audience.

So what we're really going to talk about today is the things you need to think about if you want a system that does this for you. So I'm not going to stand up here and tell you, this is the exact things we're measuring, and this is how we captured this exact piece of data. This is more broadly conceptual about, what do you need to think about if this is what you want to do, and you want to do it at scale.

So if that's not what you came for, I will not be insulted if you walk out the door right now.

AARON MALLER: I will.

ROBERT MANNA: But I promise to be entertaining. Well, he'll be insulting. It's Aaron. He's always insult--

AARON MALLER: The speaker feedback is his bit, so that's fine.

ROBERT MANNA: As part of this course, as well, I did query the four vendors that I'm aware of that are delivering solutions in this area. Because you might decide, after I go through it all, that you'd much rather buy something from somebody than try to do it yourself.

So part of this is the voice of experience, because we have rolled our own solution in Stantec. And we continue to work on that, but it's not an easy task. Again, 4,000-some-odd people, 18,000 of our closest friends, we've got a slight scale issue. So it also depends on who you are and what you're trying to achieve. So anyways.

Why is anybody doing this, right? I thought this was cute. It didn't quite fit architecture, but I just crossed that out and put BIM manager in there.

So we've got these models with a big eye in them. So, hey, maybe we can make use of that eye to tell us interesting things. Because if you look at other industries, what do they do? They analyze their data to figure out what's going on. Whether you're trying to sell something or make something, they're analyzing the data to improve their processes.

So, well, we probably should do the same thing as architects or engineers. And we actually finally have a platform where we can do that. When we were just drawing lines in AutoCAD, yeah, you could run an audit check on the CAD file. That didn't really tell you a lot about what was going on in that file.

On top of that-- And I, 10 minutes ago, realized I should have had an image of the A Team here, maybe. But what we-- When we all started out-- I've been doing this for a few years-- we had the A teams working on our projects. You've got the best, the brightest, the most motivated. And everything worked.

And then you started implementing it across your firm. You've got more people doing it across your firm. And suddenly, it's like, well, why isn't it working for you? We never had any problems. Well, the fact is, there's good teams, bad teams, people with different motivations, talents.

So we quickly realized, across the industry, that we need to do something about keeping things clean, keeping things running. This was not, again, AutoCAD where we could just audit a CAD file and move on with our day most of the time. But we had to do more.

So as far as I know, a lot of people have some sort of checklist. We can go in, and manually audit the models, and look at things, and try to decipher what's going on. Where do we need to maybe fix stuff? What issues should we be looking for? But again, there's been a lot of courses about this. I think everybody realizes that this does not work at scale. We don't have enough people who are talented enough to actually go through this, and know what to do, and what to assess.

And this is always reactive. So we're always reacting after the fact. Are there opportunities to be proactive, to assess what's going on, and figure out where the problem spots are before they become house fires? Or maybe a forest fire or something. That's probably a bad joke, given California. I apologize.

So really, pieces of the puzzle. If you want to do this, what are the things you need to be thinking about about how you actually achieve collecting data en masse from your models so that you can analyze it?

There's three major pieces. You've got to get it, you've got to put it somewhere, and you've got to show it off to people. Because data by itself is not really informational or useful. You've got to take that data, analyze it, and present it back coherently to the people that are going to consume it. And you might have different audiences.

So the person, your BIM Manager or your day-to-day user who is working in Revit, the information they need or the analysis they need is very different from a chief executive or some other executive that is maybe making decisions about the company and what to do to help the company continue to be successful.

Yet, the data that we can capture and collect from our models can help inform both those audiences. So we've got to make sure that we're presenting it appropriately to those audiences. And so showing it off, storing it, getting it.

So getting it. There are really two approaches to this. You can do user exported or you can do automated.

User exported is effectively on demand. So we're relying on the users to push a button and export the data out. Popular way to do this is with Dynamo. Write up a little Dynamo script, export out some data, probably to a CSV file or Excel spreadsheet, and then you can do something with that data. You can do that independently on individual models if you want to.

If you're doing that independently on individual models, you are not in a position to really aggregate that data in a useful way. So, yeah, you might be informing your individual audience, and maybe that's sufficient. But if you're looking for data aggregation so you can present something useful to your executive officers or your executive leadership, then you need to get beyond this, most likely.

Again, with Dynamo you can connect it to a database. I think there is a package for MySQL or something like that.

AARON MALLER: I think there's a few.

ROBERT MANNA: Which may or may not work. And fundamentally, the problem with Dynamo is, as much fun as it is, as useful as it can be, it does not scale very well. So if you say, oh, we're going to run this Dynamo script, and we'll just have people push the player button, it might work in the office. It might work across three offices. When an update comes down, something's going to break.

AARON MALLER: Now that he said how bad it is, that's what we use.

ROBERT MANNA: But you can fix it yourself. Again--

AARON MALLER: Part of we're going to talk about a little later is that it's also for a different purpose. So you're talking about at scale to get consistent results, and mine is more of a reactionary audit. And that's why Dynamo works great for that.

ROBERT MANNA: What I will say is, this is a great place to start. So if you want to do your own or you just want to start to experiment, starting with Dynamo, starting with an Excel spreadsheet, good place to start. Figure it out, and then figure out scale.

So the other option would be some sort of add-in application that's basically going to generate a similar output to what you would get from Dynamo. So there's multiple applications out there.

The ones that came to the top of my head and Aaron's was BIMLink, RDBExport. You've got Model Checker, Model Reviewer, both from-- actually, all three of those are from Autodesk. There's other flavors similar to BIMLink out there. RushForth Tools. I think IMAGINEiT has something similar as well, if I remember correctly. CTC has something similar. So yeah.

You can go buy something. You can do that. Again, those tools are going to generate some sort of static format, by and large. Some of them may have some connection to a database.

Again, you're relying on that user to push a button. So they've got to do it when they feel like it. You can say, please push that button every night. Please that push that button once a week. Are you going to get consistent results? I don't know. Maybe your users are better than mine.

It takes time away from the users, too. So if you're going to export any amount of data, short, simple data is going to export very quickly. If you're trying to export large amounts of data from the model, it takes time. And so again, if the user's got a second computer, great. They can go do that.

If they've got to do it on their primary workstation, now you're taking them off-task. And nobody likes to hear that you're taking them off-task, even if it's for the betterment. For some reason, people just don't see that. No, I've got to get my job done. Which is OK.

So automated. So when and how you like it. That's the beauty of automation. I think the keynote was all the automation. I didn't go. I was working on my PowerPoint.

So there's two flavors to automation.

Flavor A, basically does the same thing as user exported. So, we figure out some way to automate that plug-in, that add-in, whatever. As an example, IMAGINEiT's Clarity product, you can tell it to export data. Clarity is actually a bit more complicated than that, but that was the best image I could come up with for this one here.

So when you automate it this way, where you're sort of replicating what the user would have done anyways, you're talking-- generally, it's going to be a single point of time in the day. I mean, you could automate it over and over again, but you're probably not going to.

What's nice is you can capture an extensive amount of data. Because you've offloaded that somewhere, it's going to just run on its own. So if you say, hey, get the whole model, and transcribe it into a database, or something like that, you can do that. You don't care. It's off running by itself, doing its thing. And then--

But again, you need-- you've got to have a solution to automate that process, whatever that solution is. Is it a BAT file and a Windows Task? I suppose maybe you could do it. Do you, again, get a product that will do it for you? Whatever. You've got to solve that problem.

AARON MALLER: Yeah. One of the things about this method that it always struck me as a difficulty back when I was at a company bigger than two of us was, there has to be a device that's doing this task. And in the examples Robert's giving, if it's a user's device, it means that device has to be around to run that task. If it's a device that's hosted in the office, now there's a question of how many of these devices do you need, for how many projects do we want to be exporting on any given night?

When I was trying this at my previous company, I actually ran into a situation where we were suddenly just out of resources unless we leveraged all the users' machines. And that's why some of the later techniques Robert's going to talk about are more fitting, I think.

ROBERT MANNA: Right. So I said there were two flavors to automation.

Other flavor is you do it on some event silently in the background. The most common and most logical event is the Sync With Central. But I guess, if you were a firm that, for some reason, most of your models are not work-shared files, then you'd have to do it on File Save or something like that.

So again, you're looking for some event you can say, oh, hey, that event has triggered. I'm going to go and export the data in the background behind the scenes. The user is not aware of it.

But the key there is you do need to be aware of how much data you're pulling, because depending on what you want and what you're looking to get, that may take time. It's not a magic silver bullet. Sometimes the data you want takes time to extract out of the Revit model and get formatted properly.

So in that case, particularly if you're doing it on a Sync With Central operation, you probably don't want to double the amount of apparent time the Sync With Central takes just for the fun of it. So if you're going to go down this path, you just have to be cautious of that.

And this is the path we've taken at Stantec, because we capture on Sync With Central. But we also monitor the duration that it takes for our data capture to run versus the duration of the actual Sync With Central. And we have a couple of bugs we need to work on right now.

So you've got to be aware of that. It is a solvable problem, for sure. But again, you've got to be thinking about these things, particularly if you want to do these things at scale in some way, shape, or form.

So again-- Oh, yeah. Flavor C. So this is coming. I can talk about it, because they talked about on Monday. So again, editing the PowerPoint on the fly. Hey, can you give me some images?

So if you're not aware, the Revit development team has been working in conjunction with the Forge development team to, basically, put headless Revit up in the cloud, where you can do everything that API can do, generally speaking, on your Revit models using cloud compute resources versus tying up local resources.

Sounds great. There are some caveats that come with this. First of all, your data has to be in the cloud in some way, shape, or form. That doesn't mean that it has to be a cloud-based central model. It doesn't have to be cloud workstream-based.

In fact, at launch for this product-- which, of course, they wouldn't hold themselves to a specific date. But when they launch, you will actually not have direct access to cloud work-sharing files. So you've got that silo over here. You're going to have this thing over here. They will not talk to each other. You'll actually have to pull the data down and put it back if you want to. Or pull it sideways or something.

So the point being that this sounds really great, and I think that long term there's some possibilities here. But if you're saying, oh, well, I'll just extract from all my models, no matter what, in the cloud, that means you've got to get them up there in some way, shape, or form. And that's very likely an upload process.

So again, depending on what you're trying to achieve, depending on how you want to do that, maybe you don't care. Maybe you've got a really big internet pipe. You've got one office, and you're going to upload everything at 10:00 at night and then run extractions after that.

Because the other beauty of this, this is scalable. So you don't run into that issue of, oh, I'm tying up a computer. I've got to finish processing one thing before I process another. You can submit a massive job, and you will just use a lot of cloud compute tokens when you do that.

So again, that's coming. But I want to-- They're talking about this, and I think it's worth talking about and making sure that people are aware of where it's headed.

So again, automated. It's frankly easier when you're dealing with automated solution, in my opinion, to then deal with getting the data into some sort of structured database. You can do it with the manual method. But if you're going to go down the road of automating in the first place, it's not a big leap to then say, oh, hey, let's just get this data into some sort of database.

But it's also now become a potential failure point. Because when you're relying on that user to push a button, well, you know the user's pushing that button or not. And if it fails, the user says, hey, it didn't work. When you automate stuff, you need some way to know, hey, it is working or it's not working. So again, there's always trade-offs in terms of the option you select and how you go down the road.

So in fact, this is where we are lacking right now in our system, where we don't really have any real good monitoring to tell us what's going on. But it becomes a little tricky, because if it fails, how do you know that it failed because it failed? It's a chicken and the egg kind of thing.

So there's no perfect answer, but again, something to be thinking about. That's kind of the theme of this class, if you haven't picked up on that.

AARON MALLER: I know when the Dynamo one fails, because it takes Revit with it.

ROBERT MANNA: All right. So this is the really big topic, and-- Oh, I automated all that? Oops.

This is the really big topic that I am personally interested in and, hopefully, will broaden your horizons a little bit about what's going on. And again, if you opt to purchase something, you may then want to be saying, well, what are you guys doing about this? Or are you thinking about this at all?

So file server, probably-- Whoops, that's the wrong button. Now it works. No, go back. Whatever. I give up.

File server, probably not a great option. Particularly if we're trying to aggregate data. Again, if you go back to, I just want to solve the problem for this project team. They can export the data, and they're going to look at it in Excel, fine. File servers work really well.

But again, if you want to aggregate the data, probably you're talking about some sort of database at that point. Because there's actually a bunch of data that I got for something else that it needed to analyze in Power BI. And it's kind of a pain. I mean, Power BI makes it relatively easy, but it's got all these files, and it gets really messy.

So databases, hopefully everybody is aware that, they're really good for multiple users to easily access, centralization, standardization in terms of how the data is being stored. Again, multiple people can get to it. It's easy to relate databases to other databases. Does anybody here not have a financial system?

AARON MALLER: Two of us.

ROBERT MANNA: You don't even have QuickBooks?

AARON MALLER: We have an accountant.

ROBERT MANNA: Well, that's kind of like a financial system.

AARON MALLER: His name's Mike. He's great.

ROBERT MANNA: The point being, your financial system is very likely a database. And again, as you start to aggregate this data, you might want to tie some information to your financial information. No, I'm not saying we're going to go and say, oh, he spent 20 hours on this project. What's going on? Or maybe 100 hours, or whatever.

But it may be just, like your financial system is also, probably, the end-all be-all of project numbers. I don't know about you, but in our firm, you don't do work if you don't have a project number. And you don't have a project number unless it's in the financial system. So hey, look, we know what projects we have or don't have. And we can start to correlate and be like, wait, what project is this model associated with? Because it doesn't seem to be associated with any project.

So again, if you put your data in a database, it becomes very easy to talk to other databases. And you may have other databases depending on who you are and what you do. Contractors have ERP databases. And there's any number of other data sources, marketing databases. So opportunities, things like that.

There's a lot of it. There's a lot of data out there. That's why we're talking about data.

But the big question is, which one?

So SQL. How many people know what SQL is, or have at least heard of it? Yes. So yeah. Everybody knows SQL, or most people know SQL-- Structured Query Language. So that's really about the standardization around how you query the database.

What you were actually talking about is a Relational Database Management System, RDBMS, and that's all your tables and the relationships between the tables. So this is a snapshot of a portion of our database that we're using to track all of our model health data. If you think that looks complicated, you don't see the rest of it.

And you can start to see things here, like Sync With Central, Users, Location. What's that? Model over there, Business Regions, Date, Time, Imported Content, Imported Objects, File Tapes, Warnings. Warnings gets its own relational map just for all the tables that are related to warnings. Doesn't-- it's not even on this one.

So point being, it's complicated. You need to think about it. A big thing with what we normally refer to as SQL databases is data normalization, so trying to avoid repeating data. That's why you end up with so many tables, so you can extract that stuff out. And you have it once for consistency. That's great. It's important.

Denormalization is actually OK. You talk to anybody who really works on databases, and denormalization, OK?

Great example, again, from our perspective, is I have Model Size in the SWC table, and I have Model Size in the Model table. And you might say to yourself, why would you do that, Robert? Well, Model Size over here is really great if I want to see the history of the model size. Because I'm capturing on every sync, so I can see what it did every time somebody syncs.

But if I'm writing a query, and all I'm interested in is, how much space are we consuming for all the models in the organization, it's way easier to write a query against the Model table and just get the column for model size from the Model table versus getting all the models, then saying, well, I only need the last Sync With Central. That starts to get complicated.

So denormalization, OK. But you have to think about these things. You have to think about, again, what is it you want to present back to your end users? What kind of analysis are you trying to do? Because that's going to drive how you organize this data, because you want to organize this data in a way that's going to be useful to query.

So again, Structured Query Language. So the real benefit, one of the major benefits of SQL, is the data has to fit into that schema. So you can't just create a new column because you feel like it. You have to get the data into that schema, so that you can write a query against that schema.

So you're writing the query against the schema, which means if I say, give me all the models of type Apple, I know that I'm going to get all the models of type Apple, assuming that I've done everything else correctly. So if I screwed up on my data schema, if I screwed up on my tools that are putting the data in there, yes, I may not get correct results.

But assuming that all of that is working properly, then I know when I write that query, I'm going to get all the valid results. There's no question there. Again, unless something has gone horribly wrong. And then you have to check it.

In fact, one of the biggest challenges we've had is with our Model table, because we want to make sure that we uniquely identify every single model in the organization. And then if we see a model, we can say, aha. We've seen this model before, and it is this one. Or nope, this is a new model that we've never seen before.

Sounds really easy, right? Not so easy when you have file paths that're both either drive letters or UNC, you have models in the cloud, you have models in Revit server, you have models that people copy and put other places, you have models linked to models, you have models linked to models with relative paths, absolute paths, models might not be loaded but they're still there. It gets kind of interesting when you collect all that data and try to put it back together.

So again, things to think about if this is what you want to do. Or then, again, maybe by the time I'm done, you're like, we're not doing that. We're out of here.

So what about other options? So there's this thing called NoSQL, which is Not Only SQL. Not like, no, no, we don't want SQL. We'll talk about that in a moment. So basically, alternate approaches to data storage. And a lot of these have been popularized thanks to a few small companies like Facebook, Twitter, Google, a few others.

So there's basically four flavors of these.

So the first one is what's referred to as key value pairs. Basically, you've got a Key column. You've got a Value column. That's what you've got.

I don't really-- I've rattled around my brain where this might be helpful for us in this problem set. I couldn't really come up with any good uses for key value pairs. Well, there's maybe one, but it's kind of esoteric.

So if you're doing key value pairs, it's really up to you, from an application standpoint, to be able to know how to put this data back together into something that's useful. Because if you don't, you just have a bunch of data that you can't do anything useful with. So you can see here, all the fours are related to Straw House, all the sixes are related to Stick House, maybe. Again, I don't see a lot of use for this in our world or our domain.

Another one you have is what are referred to as column databases, or columnar databases. So this is basically taking your traditional SQL or relational database and standing it on its head. Instead of worrying about rows, now you're worried about columns.

This is really good for stuff that you're trying to do at scale, where maybe you're only interested in a couple of columns. So if you're only interested in a couple of columns, when you're looking at it from a columnar standpoint, it's very easy to then just query Model Size and Models. And you just get that data.

And from a performance perspective, it's a lot faster than SQL. Again, I don't think any of us have to worry about performance issues. This is really a question about what's going to be best for us and, quite frankly, what's going to make it easier for developers or other people who are having to work with the data or use it.

So that's column databases. Again, useful in our domain? Maybe, maybe not. Again, nobody's going to approach scale at this unless you're a company that's doing this for lots of people. And then, they care about this, and we don't have to worry about it.

Another one, this is probably the most popular NoSQL option, is a document database. Because you can go on AWS and start a document database in five minutes or less. Give them your credit card number, and you're off and running.

What's kind of cool is, the way that AWS is does their pricing tiers, is that-- Again, if you want to use a document database on AWS and you're a relative, reasonably-sized firm-- not Stantec, probably. Even Stantec might be able to stay under the caps. You can probably stay under the caps and store all your data and not pay Amazon anything.

There's a developer here, Steve Faust-- Keynote Manager, if you're aware of Keynote Manager. He uses AWS, and his monthly Amazon bill is like $20 a month or something for all his customers that he's serving. So you can get some mileage out of that if you want to.

And the most-- outside of AWS-- the most popular document database, from what I can tell from my research, is MongoDB. It has a large following, and people use it quite a bit.

But what is a document database? Basically, a document database is saying, OK, I'm going to take a document. So this is a document, basically. In this case, what's referred to as JSON. So that's basically structured text format for storing data.

And so we can just say, we've got this document, and we're going to store it in the database. We've got document one, document two, document three. And again, we can see we've got Straw House, Stick House, Brick House. And then this is all the data about that thing. You can start to break this down as granular as you want.

But it's up to you to make sure you know how to relate these different documents to each other, because the document database isn't really going to provide you any relational information. So you have to know how to put the pieces back together if you start to break this up into smaller pieces.

But the problem or weakness with document databases is this. You recall when I talked about SQL databases, assuming everything's working correctly, we can query for all Apples and we get all apples. The document database, if we query for a number of views, and we want to total all that up, well, we're going to be missing 150. Because for some reason, this got stored as Total Views and not Number of Views. So with document databases, you have to make sure you've got your data structured properly, otherwise you might miss something.

So again, it has its use. Because what's nice is, as you can see here, we don't have to have all the same data. So where is it? Yeah. Last user, middle brother. There's no last user in either of these. So we don't-- now we're not stuck to that rigid schema that a relational database forces on you. You have flexibility to store some data and other data.

It's actually really useful for Revit, because Revit, frankly, is more like this in a lot of ways than like a SQL database. Because Revit, we can create parameters. We can put whatever data we want that parameters. There's no way to enforce consistency.

Well, you can-- Data Type, you can enforce consistency, but you can't really enforce consistency of what people get to choose from when they put data in there. And Sean's smiling, because he does have some techniques for that. But they're a little esoteric. You have to admit that.

So again, it's useful. And in fact, this is probably one of the ones that is most useful to us if we start to look at storing data. And again, what happens when the data starts to change? A new feature comes out in Revit 2020 that didn't exist. New data type, new information. Do you really want to mess with that complex set of tables and columns so you can add a new piece of data?

Or again, this becomes advantageous, because we'll just add that new piece of data. And we know that data is only in 2020 models, and there's no point in asking for that data from a 2019 model. Because it's not going to be there.

So we've had-- run into this ourselves as well, where we've started to get into-- getting the data from the cloud models. And again, I talked about, we want to be able to say, this model is this model is this model.

So when you start dealing with cloud models, there's like four IDs. So there's a GUI ID for the model from a BIM 360 perspective. There's a GUID for the model from a Forge perspective. And then, if you look at the project, there's a project GUID from the BIM 360 perspective. And there's a project GUID from the Forge perspective.

In my model table, I have one column for GUID. Where do I put the other GUID? Because I need that GUID, because that's going to help me know that this model is this model. Same with project. Do I really want to put a GUID column in my project? My Project table right now is Project Number, Project Name, maybe the Date it was Created, Client.

Nobody cares about querying the GUID for that project. I just need that GUID to know, oh, yeah. I know what this project is. It's unique. This model is related to that project. So then, you start to say, well, how do we start to combine this stuff together? I'm getting ahead of myself. Bad me.

There's one more database type that's talked about in the land of NoSQL, and that is graph. Graphs are fun. Graphs are cool.

The most popular one, as far as I know, is Neo4j. You can download it, spin it up, throw some data in it. It makes a cool representation that looks kind of like this. It's fun to play with. But it's like, how do you start to actually implement and use it? That's still a little bit questionable.

The cool thing about graphs is that you have these nodes. So here, we've got the model node, we've got the server node, we've got the office node. And we can start to relate these nodes together. These nodes can contain data.

So we can say, OK, yeah. We've got the Straw House node. That model is 10 megabytes. But then, we can have a relationship, and that relationship can have data as well.

So this becomes really interesting if you want-- if you're interested in traversing this whole thing very quickly to find out that Stick House and Straw House are both in the Lowlands office, but on different servers. So graphs make it really easy to traverse that kind of structure quickly, efficiently, and flexibly, I guess is the best way to put it.

So graphs are very popular in social media. He's my friend of my fr-- Who are my second-tier friends, or third-tier friends, or who do I know through who? Graph databases help make that all happen.

So again, kind of interesting. How applicable is it? That remains to be seen. Because it doesn't really do well if I just say, well, I want to know all the sizes of all the models, because that's not a relationship. So querying that information starts to get really tricky, and it's going to be slow compared to a SQL database or some other solution.

So what do we really do with this? Probably start to combine things. So here we've got a document database. We've got the model ID. We've got some information. But we still have a Model table that has a relationship to a Server table.

So starting to combine these different things together, going back to my vignette about the GUIDs from Forge, you can start to put the data in appropriately and organize that data so that you have flexibility as things change over time.

All right. Showing your data off. This, literally, gets only one slide, and I'll explain why in a moment. So visualization analysis.

You've got the gorillas out there-- Tableau, Power BI. Power Query and Pivot are for Excel, but fundamentally, if you're trying to do stuff en masse, that's not going to be a good solution for you. QlikView is another one that I hadn't heard of until I went and started doing some research. It's out there. So they're there.

If you're interested in having a developer just create a dashboard for you using HTML5 or something like that, there are all sorts of toolkits out there that developers can use to quickly build visualization so they're not coding from the ground up. But fundamentally, you're going to pay for it no matter what.

So a lot of people like Power BI, because they say, oh, it's free. I can download Desktop, and I can create a visualization. Great. Except if you want to share that visualization with anybody else, it's not free. So if you are interested in just looking at the dashboards yourself and not sharing them with any other, yeah, Power BI's great.

If you want to start sharing your data and analysis with anybody, you're going to pay, whether you're paying Tableau's upfront licensing or you're paying Microsoft's licensing to be able distribute and share the data. QlikView, I frankly don't know how they structure their pricing, but it probably doesn't matter. I'm quite confident they cost money that is similar to these other two.

Toolkits. Yeah, the toolkits might be free. I'm sure there's some toolkits you have to pay for, but you still have to pay your developer to do something with those toolkits. So again, not free. So again, however you want to do this, there's a cost there. So don't think that because you can download Power BI it's all roses.

Anyways. That's what I've got to say about showing your data off, because there's not much more to it. I'm not here to teach you how to use Power BI. There's, I'm sure, courses out there that teach you how to do that.

So what? What are you trying to accomplish? So again, going back to that question of, what is it you want to show to your users? What kind of analysis do you want to provide to your firms to help benefit them, help move them forward? If you don't answer this question, you're either just going to keep going back and forth, or you're going to get something that you didn't ask for in the first place, because you didn't answer the questions when somebody asked.

So you need to sit down and really figure out, what is it I want? Model health and performance? Model quality? Firmwide analysis? Aggregating things? Trends? Historical data?

Because it's really easy to do these things. If you start to get into historical data and averages, that starts to get a little complicated. But it can be done, but you just have to think about what it is you want to do.

So this is where I will show off a little bit of the work we've done at Stantec, both on our own and thanks to some consultants.

So you can start to aggregate data. So this is sort of a firmwide analysis of stuff. So we can, how many models do we have in different versions? Yes, if you can read that, we still have models in 2013 at Stantec. But apparently, 2016 is the most popular.

Or we can say, well, what are the health scores in a certain region by office? So that's showing you the relative health scores for offices in a specific region. We can do overall charting. So hey, there's all our locations-- Dubai, London, all over Canada, the US.

AARON MALLER: No models in 2019?

ROBERT MANNA: When this data snapshot came from.

AARON MALLER: Sad.

ROBERT MANNA: We do have models in 2019 now.

AARON MALLER: It's your slide. Sorry.

ROBERT MANNA: So that's all great, right? That's useful. You can do other things. We have an extensive Revit server network. So this is telling us that these are problem caches in the Revit server network. So that can be useful if you rely on Revit servers, still. I'm trying to get away from that, but I have 55 Revit servers, so I don't think they're going away anytime soon.

Or you can start to do project out. This is straight out of Power BI. I have no idea how reliable this is. But you can actually start to do future trends, like how many Sync With Central's will we continue to have into the future, if that's something useful for you. So again, it's fun stuff.

I'm not going to sit here and tell you this is what you need to do. You need to figure out for yourself what it is you want to do. That said, I do have a notebook full of fun sketches from going to all these various classes and saying, oh, that's a good idea. I should do that. I haven't done it yet, but it's on the list.

As you dig in further, you can do things like compare disciplines and projects, look for outliers. So this little whisper graph-- basically, the longer these lines are, the bigger question mark that raises. Because that means you have some really big outliers, and you can say, what's going on? And the tighter that becomes, the better it is, because that means everything's sort of similar. So you can start to do that.