CSI has been the steward and producer of the MasterFormat, UniFormat and OmniClass standards for decades. CSI now makes these available digitally through an API. Rick takes us through the value of the API and its unique "crosswalking" functionality, as well as what it takes to make a truly world-class API.
Hugh Seaton: [00:00:00] Welcome to Constructed Futures. I'm Hugh Seaton. Today, I'm here with Rick Bawcum, chief technology officer of CSI. Rick, welcome to the podcast.
Rick Bawcum: [00:00:12] Hello Hugh!
Hugh Seaton: [00:00:14] Thanks for joining. I want to start with a couple of things. Let's start with who CSI is. And then we're going to talk about what Crosswalk® is. Let's start with CSI.
Rick Bawcum: [00:00:25] So CSI is the construction specifications Institute. CSI has been around since the forties and in that time they have been and become the de facto standard for organizing principles around a construction site. So basically every construction site has a sequence in which things are delivered and built, and CSI puts forth the standards, several of them actually, for helping to organize the job site, how things are delivered, how things are specified and how things are organized around the construction environment.
Hugh Seaton: [00:01:02] And that brings us to the next piece. Among those standards, the one almost everybody's heard of is MasterFormat®. Right? What is MasterFormat used for?
Rick Bawcum: [00:01:12] So MasterFormat is an organizing principle and the design phase of a construction project. And it's essentially about specifying, tying together design intent with the specifications that say, here's what we intended. And here's how we're going to do something. In terms of things like products that are selected and safety standards that are involved, all of the standards that are brought together in terms of delivering in a constructed environment. So it's an organizing principle. MasterFormat is specifically targeted at the design phase.
Hugh Seaton: [00:01:45] And the reason I wanted to get into that, cause we're going to talk later about how MasterFormat gets served up digitally. But the key thing to kind of make sure listeners understand is MasterFormat has been used by the industry for decades.
And in fact, for a lot of folks, it's almost intuitive what some of these divisions are and it's kind of a hierarchical , organizing, not just principal, but, almost database where if something is an opening, you have, , a numerical, specification or classification rather that allows you to understand where to go find the thing.
So people use this to, to pass data back and forth, to figure out where to go look for "okay, what are the doors we're using? What are the door knobs? What are the chillers and so on and so forth." So the reason I wanted to start the podcast with laying that baseline is MasterFormat's kind of baked into the industry at all levels.
Rick, what does UniFormat® do? That's one of the other big ones.
Rick Bawcum: [00:02:41] So, if you think of the standards as being applicable to various phases of a construction project, I said earlier, that MasterFormat is focused on the design phase. UniFormat is focused on the operations phase or things like the facilities managers and property managers and people who have to take care of the construction of the facility, of the building after it's been constructed.
So UniFormat at the operations end, MasterFormat at the design end.
Hugh Seaton: [00:03:12] It's interesting. I was just speaking last week with somebody who's a friend of CSI, and I think she's been involved in CSI for a bunch of years. And she talked about how they use UniFormat to organize all of the facilities of an airport.
Which is amazing if you think about it, but when you get into a facility that's of any size, you've got dozens and hundreds of things to keep track of and understand the maintenance schedules of... she even talked about something amazing that across a capital facility like that, the way you depreciate things is going to be different.
So you want to be keeping track of whether I can depreciate that million dollar HVAC unit faster than, you know, the elevators or something else. I hadn't thought of that, but yet another way that these standards help people to manage the complexity of both building something, but then operating and owning it.
Rick Bawcum: [00:04:00] UniFormat is very targeted at that end of the operation side, because it gets down to the assembly level. Not just I have a pump, but I have a pump with certain kinds of "O" rings and things like that in it. So two ends of the spectrum.
Hugh Seaton: [00:04:13] Yeah. So let's talk a little bit about... these things have been around for, for decades. And for a lot of people, they think about standards in terms of a binder that, when they were early in their career, they'd have upon the wall and you and Mark Dorsey, the CEO of CSI, and some other folks have been thinking about how to modernize that. Talk to me a little bit about the process that went into the creation of Crosswalk.
Rick Bawcum: [00:04:39] Well, so Crosswalk came about because we had a big problem that needed to be solved. Because these standards are not static. They don't stand still. Anytime some new technology or some new process comes into play there, it needs a new standard, or it needs an improvement to the existing standards.
So you can't think of the standard as being a specific point in time that never changes... it changes. For example, MasterFormat changes roughly every two years in terms of updates, it doesn't change wholesale, but what happens is we make minor tweaks and modifications to it. When you think of that as the standard, it gets involved in a construction project that takes 10 years, for example, you might have standards that are evolving even during the lifespan of a single project.
So the fact that these standards become the organizing principle for the way that people talk to each other and the standards evolved. I think I think of it as kind of two dimensional. There's the standard as it evolves over time. So every two years or three years, and then we'll talk later about how it Crosswalks into other standards like UniFormat, which is a topic we can get into in a bit.
Hugh Seaton: [00:05:50] So that brings us to what I promised to do five minutes ago, which is defined what Crosswalk is. So let's, let's do that. Let's talk about what is Crosswalk.
Rick Bawcum: [00:05:58] So in the past, the standards have been publications. So you buy a book you read the book, you apply the material, right? In terms of organizing your construction project.
More and more, now especially, the job sites are digital. So the tools that we're using are digital and we found the problem that we needed to solve was how do we facilitate embedding the standards along with all of their versions and Crosswalks into software. So in the past, Software providers have had to take that book and manually curate any of the changes to the standard into their software product, or if they're starting from scratch, they're implementing the entire taxonomy or the entire standard into their software product.
And as you can imagine that becomes pretty burdensome over time, given the fact that it does change. So the idea for Crosswalk was how do we express these standards digitally in a way that software providers, portal providers, people who live in the digital space, which is certainly what's happening in the constructed environment these days. It's becoming more digital, people who live in that space can take advantage of an application programming interface or an API. So Crosswalk is fundamentally a way to express the standards digitally through an API that can be embedded in software and portals and anything, any of those digital environments.
Hugh Seaton: [00:07:27] That's a great way of setting this thing up, right, is that CSI, you and mark and the team realized that the way projects are getting designed, delivered and handed over is changing.
It's becoming much more digital. It's becoming much more Software centric. So that kind of led to the decision that great, you know, we're going to support that and create something that makes it not only possible to easily integrate the standards, but to do it in a way that's abstracted out as an API.
So, and again, you mentioned what an API is, it's an application programming interface. And for those who spend a little bit of time with this, essentially what the product does is allow Software to go in and basically query what matches with what and what standard or what, what kind of title is what?
So we talked before that MasterFormat is an organized, well all of the standards are taxonomies, that allow you to keep track of quantities and specifications and all sorts of things that relate to the bits of the project. And what the API does is allow you to have that in a highly available easily queryable format. So you don't have to handle that. You don't have to worry about that. You can focus on what the software itself does.
Rick Bawcum: [00:08:39] Well, I always think of the analog version of that. Everybody's been to a library, right. And in the old days, when you went into a library, you went to the card file right in the middle to figure it out where a certain book was located on a shelf, right? The card file itself as the taxonomy, or it's the API, if you will, in the digital space. And that's where people go to find out where various things that they need in a construction environment exist.
Hugh Seaton: [00:09:02] And you do the same now on Amazon. I mean, you know, the Dewey decimal system was a little hard to figure out, but really analogous to what these standards do. But even now, if you go to Amazon, if you're not just going to search, which you know, you can do, you can also go and say, I want to look under books and then I want to look under business and then I want to look under entrepreneur.
And that's very similar to what MasterFormat does, right. As you say, I want to look into openings. I want to look under doors. I want to look under, you know, brass doors or something. So it allows you in kind of a hierarchical way from the biggest category down to the category you care about.
So that when someone's saying, all right I need to go estimate this job. Let's make sure I know all of the drywall and I know all of the doors and I know all of the, whatever. So it, it allows people to organize this stuff so that the next person that comes along doesn't have to go and tally it up themselves. Right. It keeps, it allows you it's essentially like also like accounting codes.
Rick Bawcum: [00:09:56] Yeah. Yeah, exactly. The other place I think of it is one of your questions earlier on, was that, where did this come from? Where did the idea come from? And I'd spent a lot of years in connecting standards to various things.
Like before I worked on Crosswalk, I worked in the health information exchange industry or so in healthcare right. And if you're not a physician, you may not know what a PDR is, but the book that tells you how to code a specific procedure or diagnosis comes from the PDR. Well MasterFormat, OmniClass, UniFormat are all kind of the PDR for the construction space.
Hugh Seaton: [00:10:31] That's now metaphor number four, by the time we're done, people are going to be able to talk about this in their sleep. So let's talk a little bit about, so the decision is made to create this API, this digital expression of the standards. Talk to me about how you thought about it. I mean, you just mentioned your background in technology, obviously as the CTO, you have a long background in technology, but specifically, you know, you brought with it some expectations of quality and all that. Talk a little bit about the process of building it and what you thought would be required.
Rick Bawcum: [00:11:02] Well sure. As you said, I came out of a number of industries, but the telecommunications was the one that was probably the most influential here because when we started thinking about building an API, I'd had some previous experience about, you know, really getting focused on scalability, right?
Will this thing actually operate at scale because when you start connecting all the software products out there that are operating in the constructed environment that, you know, that can be hundreds of thousands of connections in terms of using the API. So we really focused on making sure that what we built was scalable and the underpinnings of that you know, it depends on how geeky you want to get, but the underpinnings there are very scalable in terms of the way we put it together.
It's not sitting on a server under somebody's desk. It's actually deployed in the cloud and we're using Microsoft's technologies for deploying APIs to manage it, but we decided we wanted it to be very scalable. We also focused a lot on the API is just working. Anybody who comes from the technical background knows that most people will say, yeah, of course I got an API for that.
And then when you start trying to use it, sometimes they don't work as well as you might've expected. So we really focused on making sure that the API did what it said it was going to do, that it was robust and that it was easily implemented, and just the uptake into your product development life cycle was very easy and you can see that if you go to the website and you can get onboarded very easily, there's lots of material out there, including videos about how to get started with the API. So we focus a lot on scalability, quality of the product itself, and then how do you onboard it into your software products.
Hugh Seaton: [00:12:41] And that middle piece about making sure that it works, and it does what it says. What was the process you went through last year to really make sure that that's true.
Rick Bawcum: [00:12:49] Well, again, you always start with the, at least in our world, what we did is we started with building a minimum viable product that did the things that we knew it needed to do. For example, we knew that you needed to query, you know, based on certain parameters, like the example I always use is something as simple as saying, I want to get all the classifications for brick.
Right. And so, you know, if you just say to the API, give me everything that you know about brick in terms of classification, it'll return all the classifications for brick. And the reason things like that are important is because, you know, there's different kinds of brick and that's true of every product in the construction environment.
If I'm building a blast furnace, I probably don't want paving bricks. I probably won't fire brick of some sort. So you can get that kind of information from the API. So we built that minimum viable product, knowing that's what we needed, that kind of integrity in the data. So we, we focus very intensely on the data quality, the database that lives underneath this.
And then the API on top of that has a very targeted kind of querying structure. So you can go wide or you can go narrow to put it maybe simplistically in terms of the kind of things that you want to get brought back from the API.
Hugh Seaton: [00:14:06] And that speaks to a really important decision that is not always obvious when we're talking about Crosswalk, right.
It's an API that is powering other people's software. So instead of being narrow in how the queries come back, You purposely designed it so that you can bring back everything related to the thing you asked for, brick in the example you just gave and then the software can do whatever the software wants to do.
And all you're doing is parsing a file. Right? You're getting a JSON file. Really pushed the geeky envelope here. You're getting a JSON file that the software can then pull out of what they want. It's a light little payload, so it's not like you're overloading people that, but it was designed as an ingredient.
It was designed as a way to make other people's software more efficient, more reliable, more available. And as a result, the ability to query , like I just mentioned everything related to that comes back, but you also looked at using, in addition to restful API APIs, we also looked at graph QL. Do you want to talk about graph QL briefly?
I do want to, we do want to draw the geeky line around that one, but what's the graph QL broadly.
Rick Bawcum: [00:15:12] Graph QL i s a relatively new standard for querying the results of your API and narrowing the focus. The original design was using JSON and XML payloads, which you really had the parse is the way you described it earlier. And some pretty specific ways to get the information out of it. In some cases, Graph QL helps you narrow that down without having to do all the parsing programmatically. So we've put the graph QL interface on top of what we already had with the JSON and XML payloads.
So you can get really narrow in terms of what you want out of the information that you've gotten back. And you're not making all these trips back and forth to the server to make that happen. So it's an efficiency and effectiveness mechanism to really kind of narrow in your search results from the payloads.
Hugh Seaton: [00:15:56] That's great. So kind of wrapping that one up is between the way the searches are queried and brought back, and the fact that, you know, we've added this graph QL on top, really, it's a focus on providing this information to software makers in the best possible ways, so that people can get out of it what they need and not have to worry about it.
Rick Bawcum: [00:16:16] Yeah, exactly. And I think it is important, as you said earlier, to emphasize that this is not a, an engine user product. We're not building the end user interface. We're relying on the software manufacturers or providers out there to do that. So we're, our business is delivering data. It's delivering payloads and we think of ourselves as kind of middleware for data in the constructed environment.
So, you know, what we're about is how do we organize that data and the most current ways using the most current standards, and then delivering that to the software providers and a business to business model, we're not building an end-user interface. That's that's up to them to use it, the material and the information they get back in the ways that are most appropriate for their user interface.
Hugh Seaton: [00:17:00] Yeah, our job is to stick to our knitting and make sure that the ability to serve this stuff is robust. And I mean, the number of tests that are run against the database on a daily and weekly basis makes it so that if anything ever goes wrong, we can figure it out quickly. And of course, nothing has yet.
I want to switch gears now to that the word of the day. So to speak Crosswalk. When I joined, I didn't realize that Crosswalk is actually a term of art. It gets used a lot. When you have databases and classifications that are similar to each other, you want to talk a little bit about what Crosswalk means.
Rick Bawcum: [00:17:35] Yeah. So cross walk fundamentally came from the concept of there are multiple standards. Lots of them are actually out there. CSI is famous for three of them MasterFormat, which you mentioned earlier. OmniClass, which is really oriented around BIM or, or building information modeling, and then UniFormat which are kind of different aspects of where they're, where they're implemented.
So each of those standards represents a phase of a project. So again, MasterFormat at the beginning, a UniFormat kind of at the end of the facilities management, I think of them as a lens.
They're all describing the same constructed environment. So if you think about the end point, let's talk about a pump with MasterFormat. It may have one set of classifications that describes it as a pump in a certain way that a designer is interested in. UniFormat may look at the same pump, and as you go through the process of constructing the facility, every role in the in the construction process has a little different lens.
So folks who are in facilities management, look at UniFormat folks in the design phase, look at MasterFormat, but they're all looking at the same pump or a brick or chair or window or door in the constructed space. They're just classifying it a bit differently. So Crosswalk comes from the need for the folks in the facilities management phase or the operations phase to be able to use the same data that was used by the designers on the front end of the phase that are building it with MasterFormat.
So Crosswalk does that work for you. It used to be that you would have to either manually do that translation, if you will, in terms of the organizing principles to organize it by systems and components, which is what UniFormat does versus kind of the let's go from the ground up through the, through the you know, radio tower on top of the building, which is more how MasterFormat looks at it.
So cross-walking does both the horizontal and the vertical translations. So when I say, when I say vertical, I mean the version to version so if MasterFormat gets updated every two years, then we're going to be able to cross walk you up and through those versions, then similarly on the horizontal, we can walk you over to all the versions of UniFormat.
If you're a facilities management or operations person and you need to take the same data and classify it and organize it by those principles. So Crosswalk comes from that organizing principle of, I need to do translations horizontally among the standards and vertically among the versions of the standards, at least that's my visual in my head.
Hugh Seaton: [00:20:20] Yeah. Sort of X and Y axis. I've been, I've been known to use. And to put that into kind of examples, as you might imagine, that somebody comes to you with a bunch of specifications for the roof, let's say and they're using MasterFormat 1995, which, which is in a lot of people's. Especially folks, obviously it had been around a little bit that's they almost have an intuitive, I have knowledge of what MasterFormat 95 was.
So, so there's, there's still a number of people that use some of the earlier standards. And that long ago, there is a difference there, there can be some, some areas where you're going to need to almost reclassify it, to bring it to one of the more modern versions of it. So kind of, example number one would be someone, as I say, comes to you with a bunch of specifications that are classified with something that's, you know, over 20 years old, that you can then translate into the most modern version.
And the second one that we hear a lot of, actually is more of the horizontal you mentioned, and that is the specifiers and the design phase uses MasterFormat to, spec out the whole building. So you've got, a hundred door knobs, 10,000 tiles and 400 windows, all of them now are these quantities and the specifications are classified by MasterFormat.
So people can figure out where they are. They can go say, all right, how many windows do we have? So on and so forth. What often happens is that then gets translated into UniFormat during the estimating phase. So now all of a sudden, you have this new lens of looking at it by how things get built in the process and the places and so on, Crosswalk allows you to take all of those quantities from the MasterFormat classification, where they're in buckets, that MasterFormat classifies, and then turn it into UniFormat so that you can use it the most efficient way for the estimating process.
Then that keeps going on through, through each of the phases, right. All the way through to facilities management.
It does. And, you know, we're seeing more and more applications of BIM and today's digital space where, you know, we're connecting things to VR and AR and artificial intelligence and all kinds of things there in terms of the way that BIM then starts to organize the constructed environment.
So OmniClass is, is the target for that. And OmniClass has been around for a few years, but it's really coming into its own.
In fact, some of the, some of the coolest integrations we're seeing are, are in BIM, in Revit plugin specifically. We just did something with a company called Collectus where they're using Crosswalk to keep track of their own families, as well as bring in specifications and so on as part of the, just workflow straight in Revit, which is really exciting to see.
And that, you know, that really pays off the vision and idea of Crosswalk, right. Is how are we upgrading and, and, and supporting the ongoing digitalization of construction and the built environment.
Rick Bawcum: [00:23:09] Yeah. I used to own a construction company and this was kind of personal for me because we saw the inefficiencies on the job site of handoff, you know, misclassifications or not having the most current information about something.
So, you know, if you can compress all of that inefficiency on the job site, by making sure that the data quality is of the highest possible standard, which is really kind of what Crosswalk and the standards are all about. It's fundamentally about data quality and everybody having the same material and speaking the same language, if you will, about what they're trying to accomplish.
Again, it goes all the way back to design intent.
Hugh Seaton: [00:23:48] One of the things I like to point out with software generally in construction, there's a lot of talk about productivity and that's fine, but, it is very often the case that technology helps productivity, but it also opens up entirely new possibilities. So the economic look at productivity may or may not change as much as you wish it did, but the quality of what gets created is often where the benefits show up.
So, you know, you see this in as I say, productivity numbers of across the economy all the time is we spend all this money on computers. How come we're not quote, unquote, more productive. And yet I have a supercomputer in my pocket.
Rick Bawcum: [00:24:22] You get competing imperatives, right?
So we're, we're digitally connected now, which means that we have an opportunity to make the data quality much higher. Yeah. The challenge is that we have much more data.
Hugh Seaton: [00:24:32] That's right. And you can do a lot more with it. I guess the point I was getting at is, you know, for, for listeners that are thinking about their software and the processes that they're in the middle of, imagine if data, quality was a lot less of a question. imagine if you weren't worried about whether the design intent was maintained, or if you weren't worried about whether the quantities that came from one phase were accurate transitioned into the next phase.
Imagine if that wasn't a question.
Suddenly you can start to say, yeah, well, let's try a few things. Let's, let's try this out. Let's iterate a little bit more. Let's have a discussion because we know we're not going to lose things in the paperwork. And I think more than anything else, that's where some of the promise of products like Crosswalk really starts to shine is, it allows buildings to be better, safer, faster, and more efficient in ways that we didn't think of because we didn't have the tool in our hands yet. But now that we do, we realize, wow, if I don't have to worry about that, I can do more and spend more time on, on the fun stuff and the hard stuff of thinking about the building and thinking about how we're going to build it.
And what's the most effective and efficient way to do it.
Rick Bawcum: [00:25:38] Yeah, it's for me, it always goes back to the, I'll use some quasi geeky terms. It's the velocity, and veracity of the data. So how fast can I get it and how good is the data that lets me move on beyond the basics to now really analyzing what I'm seeing in terms of the data flows and the process efficiencies that are happening there.
Hugh Seaton: [00:26:00] Let's round out our conversation with how does Crosswalk, we've sort of talked about this, let's summarize how Crosswalk helps and what companies need to do to, to get Crosswalk. So, so how does, how does the API get integrated?
Rick Bawcum: [00:26:15] So the API, is an API, an application programming interface.
It's a licensed product that software providers can come to us and talk about how to, how do they license it for their products. It allows them to have access to all three of the CSI standards currently, and we're looking to add actually non-CSI standards to the mix. I believe we just added the ASTM E1557 standard, which is a kind of our first non-CSI standard.
And we're looking to add more. To accommodate how things are built around the world. So, you know, how do they integrate it? They go to the Crosswalk.biz website and start talking to the team about how to get it licensed for their software product or portal.
Hugh Seaton: [00:27:01] And then every step from there on is what would API is always do, right.
We agree on what we're going to do together. And then we send you a key and, you know, bob's your uncle.
Rick Bawcum: [00:27:10] Absolutely. So, I mean, yeah, there's a key driven. So you get, when you buy the license, you, then you have a key that lets you access it. And the key is how we both give you access and, and encrypt and, and manage the security of the connection.
Hugh Seaton: [00:27:24] That's fantastic. So Rick, thank you for this. I think this has been a great introduction to Crosswalk, obviously as the guy that runs Crosswalk it's near and dear to my heart. So I appreciate your you're helping me to explain it to the listeners.
Great
Rick Bawcum: [00:27:37] happy to be here, Hugh, and looking forward to doing more with this product as we take this thing forward.