Learn about NexusCon!
âWe canât try to bring them all [ontologies] together. We canât make them all one. What we need to do is really focus on delivering the outcomes and delivering the use cases, and then have data engineers worry about how to normalize that data. Because at the end of the day, the ontology doesn't deliver any outcome. It only enables, right? It's not an outcome.â
-Brian Turner
Welcome to Nexus, a newsletter and podcast for smart people applying smart building technologyâhosted by James Dice. If youâre new to Nexus, you might want to start here.
The Nexus podcast (Apple | Spotify | YouTube | Other apps) is our chance to explore and learn with the brightest in our industryâtogether. The project is directly funded by listeners like you who have joined the Nexus Pro membership community.
You can join Nexus Pro to get a weekly-ish deep dive, access to the Nexus Vendor Landscape, and invites to exclusive events with a community of smart buildings nerds.
Episode 34 is a conversation with Brian Turner, CEO of Buildings IOT.
You can find Brian Turner on LinkedIn.
Enjoy!
Music credit: Dream Big by Audiobingerâlicensed under an Attribution-NonCommercial-ShareAlike License.
Note: transcript was created using an imperfect machine learning tool and lightly edited by a human (so you can get the gist). Please forgive errors!
James Dice: [00:00:00] hello friends, welcome to the nexus podcast. I'm your host James dice each week. I fire questions that the leaders of the smart buildings industry to try to figure out where we're headed and how we can get there faster without all the marketing fluff. I'm pushing my learning to the limit. And I'm so glad to have you here following along.
This episode of the podcast is brought to you by nexus pro nexus pro is an annual or monthly subscription where members get exclusive writing podcasts and invites to members only zoom gatherings. You can find info on how to join and support the Without further ado, please enjoy this episode, the nexus podcast.
Episode 34 is a conversation with Brian Turner, CEO of buildings, IOT. We talked about all the topics we love here on the podcast, including analytics, advanced supervisor control, data modeling, integration, why buildings are behind and much more. We took a deep dive into the role of the master systems integrator that I think all you building owners out there and need to wrap your head around without further ado, please enjoy.
Next is podcast episode 34. All right. Hello, Brian. Welcome to the nexus podcast. Can you introduce yourself?
Brian Turner: [00:01:22] Yeah. Hi James. Thanks for having me. I'm Brian Turner CEO with buildings, IOT.
James Dice: [00:01:27] All right, cool. You've been around in the industry for awhile. Uh, can you take us through the history? and then how you got to up to today.
Brian Turner: [00:01:35] Yeah, sure. Um, started, you know, out of college, I worked at controllers, we'll go through college control pill is a value add distribution company that serves, the commercial building space. Uh, when I started at control co we also serve the industrial space. So I'm 100% focused on controls, and control products, not really service.
So there was always, uh, a bit of value add to the business. and just, you know, over the years, you know, adding different pieces of value to that business, throughout, my college careers, it was interesting to see how the different products got applied. When I graduated college, I. Decided to go work at Johnson controls, as a field tech and actually deploy and figure out really how these systems go in, what kind of software has to be done?
What kind of programming, what commissioning is all about? you know, what, uh, what a 30 story building looks like versus a two-story, you know, pharmaceutical type facility. So that was good experience. following. That I came back to control co to start sales. I felt like I had a pretty good understanding of how these systems and controllers get deployed.
Um, and I wanted to really help contractors and integrators, do that properly. So, and then from there, over the years, we've done lots of different things, you know, from trying to solve an analytics problem. We built one of the first, analytics platforms on top of the Tridium. That we ended up selling to Tridium ultimately, and you know, as we continued to migrate kind of out of distribution alone and more into kind of contracting and master system integration, we then recognize that, you know, four or five years ago, there weren't a lot of good platform choices to really.
Provide a real integrated, solution for clients. And so we spun up another software dev team up in Ottawa and, now we have a full, platform as well. which is interesting. Uh, we'll several talk about platforms and emphasize here later in the conversation, but, but that's been a labor of love, over the last four years.
really developing that to, to meet the needs as we see them. Needing to be met, from a, from an integrator's perspective and from an operator's perspective. and, and so that takes us where we are today. and, there's a lot of change, a lot of, uh, A lot of growth in this industry. it's exciting to see all the influence coming from overseas as well, whether it's Asia, PAC or Europe or, or South America.
I think that global kind of confluence and innovation, is really starting to impact this industry in a good way. Cool.
James Dice: [00:04:03] Yeah. And we were talking a little bit before we hit record. You said your team is mostly remote. Are you guys working all over the country, all over the world or where do you guys
Brian Turner: [00:04:13] hang out?
Yeah, so I would say we're, uh, we're headquartered in California. and we, I would say the biggest. Group of people is actually in Northern California in the Bay area, but almost all of those people are working remote. Now I'm in the office today, but, of our 30 employees that are, I guess, assigned to this office only four are here with any kind of regularity.
And everyone else is working remote. and yeah, we've been a remote workforce for several years now. We've got people throughout North America. you know, as far North, as Vancouver and I don't consider Ottawa that far North, although it's a lot colder than Vancouver. and then it's, all the way over to New York and then another little group of people in North Carolina and then just people kind of smattered throughout the U S That work remote because as an MSI, remote work was, was a real thing even before the pandemic.
And then the pandemic just kind of reinforced that. That was the only way we were going to get to work. So.
James Dice: [00:05:11] Okay. cool. So I want to talk about all that stuff that you just kind of introduced for us first. I want to ask you, so I've been doing my favorite question fall of 2020. I want to kind of tweak my favorite question for 2021 since this is the first interview on the podcast, for the new year.
So. 2020. It was all about, okay.
Brian Turner: [00:05:30] why are we behind?
James Dice: [00:05:32] And now I want to kind of flip that and you feel free to answer the 20, 20 question if you want. But the new question is more around. What's Like the number one thing you think needs to change to sort of unlock, the potential we have here.
Brian Turner: [00:05:45] Well, it's a, it's a tricky question because there's a lot more than, one thing. But, honestly I think the, the focus of a tenant. And understanding their environment and, and how much importance they put on their employees, comfort, safety, health, and wellbeing, and how that is a very big, positive influence on their productivity.
I think once organizations really understand that. Then our industry is going to get completely unlocked. and so it's, sounds cliche a little bit, and it has nothing to do with the technology we have or the manpower we have, or the education in our industry. It's really about the tenants and the people who occupied our building and how important it is to them.
That the buildings that they're in are safe, comfortable, healthy, you know, and, and all the things that we can actually contribute to. And, and when that becomes a top level priority, and it becomes the same level of priority as the marble and the Starbucks at the corner. And the really good cafe that's in the place then will be unlocked.
Um, I think it's as simplistic as that and yet also as complex.
James Dice: [00:06:58] Yeah, I agree. There's so many different factors, but that's a great one to kick us off with. I appreciate that. Um, do you think that's changing, these days?
Brian Turner: [00:07:07] I do I think, uh, I think it was already changing pre pandemic, honestly. Um, I think, the tech firms, building really innovative spaces was already moving, the population that way globally.
but then, you know, when you get to a pandemic and now, people are suddenly back in their homes suddenly wondering about if their building or their. Place was going to be safe to go back to suddenly exposing themselves to, Oh my God. you know, their best me and my saw the other day was that, you know, a year ago, go to a bowling alley and put our hands in some holes and a bowling ball, then eat French fries right afterwards.
Right. And yesterday we're like, that's mortifying. We would never want to do something like that. And so I think the pandemic has just has really escalated that, that awareness. and I think the longer the pandemic is around the longer and the more in graded this awareness will be that we won't just forget about it.
If, if we had gone three months and. Gone back to normal. I think we would have largely gone back to our own normals. but today I think, we're going to see a lot more people being a lot more aware of their environment, the cleanliness, the safety, the air quality. I think people are just more aware and I think that's going to stick.
James Dice: [00:08:23] Yeah. The example I like to use on this one as the book healthy buildings. Which was very popular this year, for good reason in the last year. but it was written before the pandemic. Right. It just was released slightly before that. So like these sort of undertones
Brian Turner: [00:08:37] were happening,
James Dice: [00:08:38] the shifts were happening already.
Yeah. Cool. So let's dig into what you guys do at buildings, IOT a little bit deeper. so I want to save the whole MSI piece. Let's talk about
Brian Turner: [00:08:51] the software
James Dice: [00:08:51] side
Brian Turner: [00:08:52] of things first. So
James Dice: [00:08:52] you mentioned you had a software development group of Banawa take us through the different
Brian Turner: [00:08:57] types of software
James Dice: [00:08:58] you're
Brian Turner: [00:08:59] developing.
Sure. so  I'll kind of start with the most basic thing. So the most basic thing is really I call it the ontology Wars. It's like the clone Wars and star Wars. we've got all these different, Really big thought leaders out there competing for how to classify data, how to name data, how to relate data at the end of the day, it's all solving the same problem though.
Right? It's it's about creating that data and letting the data understand its relationship to other data. Right. Um, and there's lots of different data sets in a building that can benefit from being aware of, other datasets. so that's. Kind of core. So we started our OAP, which is ontology alignment project.
you know, not a cool name, but that's really what it is. And we created that as a service. And because we can make that as a service, it allows our plans form really to ingest these ontologies automatically. So as soon as we inform the service about the ontology and how it relates to like how Google relates to haystack, how BrickX relates to haystack, then it really allows us to.
a lot faster and a lot more consistent how they're applied. Right. and that really doesn't matter. So that's the first piece then that informs our, jet stream project, which is worldly, that middleware layer, that connection layer that allows us to connect different API APIs. And you know, whether it's data that's coming in through Niagara or through sky spark or through a cloud centered API, you know, we've got all these sensor clouds that are out there.
We don't need to bring those into Niagara or to. sky spark in order to get them into our environment. And so we needed a way to bring that data in without having to go through these other platforms first. And then we also wanted to make sure that that data was then exposed to other technologies out there that want access to all this data out of buildings, because getting data out of buildings as an easy, but we can make that easy and we provide a full graph, QL interface, outbound.
Okay. And then the cool part about that is because that's the core. Our OnPoint product are on-point professional and on-point enterprise both use that platform as well. So all the data that's available to us, we use that graph QL API to get it out. So then if we need to serve up data to power BI or to Klipfolio or some other, platform that we have nothing to do with, but our clients want to use it.
They can do that. Using the same tool sets we're using same API as res. So that's kind of the core. Uh, we do sell that as a service. but really for us, it's about getting to on point at that point. Right? So now I have OnPoint, which is a consistent user experience. that was first just analytics as a service.
you know, I already told you, we use sky spark as our core analytics engine. We didn't want to rebuild an engine. We really wanted to build that ubiquitous interface to really allow an operator to really understand everything that's going on in their building, not just the analytics. So we, connect things like.
Like sky spark, like build space, like HubSpot, like Salesforce into our platform. You get lots of different data, lots of different information about how your building was operating and allow that user to really understand it right there from a single page. And then recently we're launching in Q1. we added OnPoint enterprise, which gives us the ability to do full command and control from that interface.
So the first part was really getting all of that data, normalize consistent, related to each other. Right. And allow it to be exposed to different platforms. and then the next phase was allowed all those platforms to read. Right. So now anybody with the proper credentials into JetStream. From their interface, whether it's a power BI or a sky spark or on-point can now write back.
And so it really empowers and enables a lot of the automation, you know, things like demand management and, you know, chill, water reset if you want. But it also allows an operator just do something simple as change, a set point, or override a fan for a little while or do something that's more, No BMS related.
Right? So, so that's really the technology and the solution. we go to market with it a couple of ways. And in North America, we go to market with it as our, MSI, solution. and then in other parts of the world, we have partners that, that deliver that solution. So, um, So that's our platform.
James Dice: [00:13:12] Cool.
wow. So many different directions I would like to take this. so what you described, let me just sort of restate back to you. What I think, I just heard you have
Brian Turner: [00:13:22] a bunch of different sort of levels
James Dice: [00:13:24] that can be purchased. So the, the first one you mentioned was the IOT jet stream, which is kind of like what I call
Brian Turner: [00:13:30] and what I've written
James Dice: [00:13:30] as the independent data layer.
Right. So, just basically an integration and data modeling engine where anybody could plug into essentially. And then if you want to go one step above that you would add in the analytics. And then once to above that, you would add on the enterprise layer, which is gives you the supervisor control aspect of it.
Brian Turner: [00:13:50] Correct? That's it.
James Dice: [00:13:52] So I want to start with the data layer piece of it.
Brian Turner: [00:13:55] Um,
James Dice: [00:13:56] so there's a bunch of different data layer, only companies popping up, over the last say, I don't know, two to three years. what are you seeing with your clients as far as what value are they seeing in that sort of separate layer?
That's independent of everything else, because what we have as sort of the antithesis to that, would be these full stack solutions that it's really difficult to sort of break them up into these layers, like you've described. So. Yeah, I guess, what are you seeing as the value and what are your clients seeing as the value to that being separate?
Brian Turner: [00:14:29] Yeah, to me, it's really the approach. So with the way we've approached that data layer is. It's not unique, you know, we, can find similar, um, it, more business level data layers like that, like a Sligo or even a Zapier or something like that that are really more about IOT solutions that are cloud.
Right. And when we reviewed those, we were like, this is really cool, but they don't really connect to on-prem anything. Right. Right. and the reason is because on-premise heart. Getting data out of backnet or lawn works or Modbus or KNX or any of these field bus protocols is really difficult, especially if you're a cloud development company and all of your core understanding and knowledge is building really cool web technologies that physical layer down the building really sucks for you.
and then, it really kind of hit home. We had a, we have a big tech firm client. A few years ago, they said, Hey, uh, thanks for completing that data center for us. We want you to now give us the API. And so we turned over the haystack API because everything was there, it was all in sky spark. And they said, we don't want anything to do with this.
This is garbage we're not going to learn your industry specific API. We need a professional cloud. You know, web developer, API. Got it. And, now fortunate and that we already had good amount of our software leadership team up in Ottawa. And so they looked at that they laughed because they understood and they said, well, what happens if we give you a graph, QL, API, that's very domain specific that's around data centers and we allow you to navigate your API and something like, um, I can't remember the little tool they use, but just to graph QL.
And they said that would be perfect. That's exactly what we want. Okay. So we're like, okay. So we built that for them. And within literally a couple hours of turning it over, they were already pulling thousands and thousands of rows of data. Right. Because now we gave them something that they didn't have to spend time learning.
We gave them something they could just ingest and really build their own application, they could use the data for what they wanted to use it for. They weren't spending time understanding the security model of the haystack API. They weren't spending time understanding the different constructs and tagging, and they don't care about the haystack.
You know, it's like that's meaningless to them. And so we were able to abstract that layer for them. And when we did that and we saw the success of that, I was like, there's something here. You know that there are so many companies that just want data. They don't want to learn the intricacies of them.
And the other thing they don't want to do is actually cut around the big ring of keys for all the API APIs that you would need to know in order to connect all these sensor clowns. You know, I don't want to do that. I want something, somebody who does that for me, give me one spot to get them. I want to go into this building into this space.
I want to see all the data available in that space, whether it's HVAC, lighting, metering. Maybe it's people counting, maybe it's indoor air quality, whatever it happens to be, to be coming back and something I can understand, I don't want to have to be a facility engineer in order to understand the lingo that you're bringing back to me.
I want to be able to understand it as a web developer, and, and allow me to do what I want to do with the data. And so when we, when we found that out, it was like, okay, a couple of things we need to do. One is I don't need to be the source of truth for data. All of these different platforms have their database.
So I don't need to worry about scaling up huge data lakes and, you know, being data stores. But what I do need to do is maintain the relationship of how all of these pieces of data relate to the facility that they're in to the spaces they serve and to each other ultimately. And so that's where like, okay, so if we can do that, so now we've solved access to the data, the historical data.
We sold relating the data. And then there's a couple other little intricacies that we can solve, like make a domain specific. No data coming from a commercial office building is fairly different from data coming from a data center. The web developers looking at data from a data center are going to be different, different levels of expertise and interest than people looking at data coming from commercial office.
And so that's one, we've talked about domain specific. It's really, what is your building domain? What is your frame of reference for the data and how do we make sure that API fits and Sue journeys? To make your development cycle much faster. So that was really the goal around it. And that's the value proposition that, uh, that IOT gesturing can bring.
James Dice: [00:19:02] Got it. I have so many follow-up questions that you ended up just answering as you went on. So that was awesome. Uh, did want to key in, on one thing. So you mentioned that your client looked at the haystack API. Maybe they didn't even look at it. Maybe they just said, I'm not even going to look at it, but what were they, what were they missing?
I don't want to start picking on haystack. That's not what it's about, but is a sort of domain specific API missing compared to what you. Guys are building that is sort of like if I could put it as just one API for the building.
Brian Turner: [00:19:32] Uh, so just the, the methodology for securely connecting to haystack.
Okay, is, is a little bit different from pure web technology. And when this was happening, this is a few years ago. So haystacks, you know, evolved since then. This was maybe three years ago. So, back then I think the description was that haystack was rest like. Okay. Rest, like is not restful. So this client at that time was looking for a restful API connection.
and Brian, Frank would even say at that time, Russ, like, it didn't need to be restful. Well, that was his opinion. And he's right in a lot of ways, but for a lot of web developers, they don't want to hear that. They didn't want to hear that at the time. Uh, graph QL was certainly a. new entry. It's also not a restful API.
It's a different type, but in our opinion, it's a better solution from an API perspective. Um, and when we offered that, it was like automatically, yes, what they knew is that their team, they could give it to their most junior level developer and they could get something going with it versus having to learn a very specific.
Industry level API. If, if they learn haystack, if they teach their team, the haystack API, how transferable is that? Um, I've even had that with some of my own software engineers over the years. when we hire them, we bring them on that really excited by our industry. And then the first thing I have them learns Niagara or sky spark, and they're like, I'm learning something that's going to live and die right here.
I don't get, I'm not learning anything that I get to take to the next. Do you know if I'm going to go and work for somebody unrelated this industry? How transferable is this knowledge that I just took? So when you just think of that in the context of the bigger world, that's a big reason why I know it's IOT gesture that exists.
Got it.
James Dice: [00:21:22] That's awesome. Uh, I think that one people think about this independent data layer concept. They struggle with there's this myth around, I'm going to put all the data in the data Lake. I'm going to throw some tags on it, and now it's ready for any use case you want. Right. And so how do you guys handle the fact that the, the data layer sits.
Below the use cases that are going to get built on top of it. So how do you make sure that the data model can accommodate the use cases that your clients
Brian Turner: [00:21:52] want to build? So yeah, you start with why, so before we have to act, I mean, you're talking about the end, right? So once we understand why the use case exists, it really informs what that domain is.
Right. So I know who they use cases for. I know what value they think they're getting out of it. And then what that then informs me on is when I make my domain specific API, I'm really targeting it at that solution set. I'm not just saying, Hey, I have a data Lake API available to you. You can do whatever you want with the data.
As long as you understand my specific domain. It's really more understanding their use case, why they're doing it, what their domain is, and then catering the data to them because we might have 27 connections coming into IOT, jet stream. But the specific operator we're talking about, the use case, we're talking about needs three of them, and they don't necessarily need to navigate the entire API set.
The entire data set in order to get their use case solved. And so we can create that small API for them. Now, the cool thing is it's all backed by haystack. That's all backed by, you know, the spaces in the building and the sites and all of those cool things. It's really just how we're exposing it to them.
And then we have another client or another use case in that same thing that says, no, I need all of the data. Well, great. Here's the entire. Uh, API that's the domain is the building or the enterprise or whatever the top level mode is for them. And you can have access to everything, but this guy over here only needed access to these three little pieces of it.
Got it. And then a lot of that is also driven. Uh, you know, Okta is, the primary identity management platform and it's inside of our tool set so Okta allows us to create as many roles and as many, Unique users of that data. So we can really, you know, articulate the access at each data set.
It's not just sitting there once you get in you're in it happens at jet stream. So even our users up and on-point all get authenticated through jet stream first, and then that allows them to see what data sets they can see up in the UI.
James Dice: [00:24:07] Very cool. All right. let's move up one layer.
Well, let's actually move up two layers. So I think the analytics layer, I actually just don't have a lot of questions, maybe that's because I feel like I got that layer. Let's go up one more. So
Brian Turner: [00:24:22] 2020, I did a
James Dice: [00:24:23] ton of. Deep dives around supervisor control and like the future of where
Brian Turner: [00:24:28] that's going.
James Dice: [00:24:28] And, I'm wondering what you're seeing as far as you said, that's, solution is launching this quarter,
Brian Turner: [00:24:34] uh, the
James Dice: [00:24:35] enterprise.
So what caused you guys to launch that? is it more of just like the next progression?
Brian Turner: [00:24:41] Okay. I have analytics and now I want to do some command and control stuff. Or are
James Dice: [00:24:45] clients out there asking for that? Um, or is it a little bit of both? Uh,
Brian Turner: [00:24:51] so the, the most innovative clients are certainly asking for, but our industry.
And we've talked a little bit about this before we started recording this industry has been around so long and people are just, they're accepting of it. So if I'm a contractor and I go in and say, no, your interfaces in this server, Under your desk and you have a 17 inch monitor. Maybe now I'll give you a 30 inch monitor.
People are still very happy to accept that today. so it's not so much driven by our clients with the exception of the enterprise clients, the people who really own a lot of real estate or either owned and operated, or maybe they just operate it for third parties, like a CVRE or JLL, and they understand.
That, that they need to get better with data and they understand they need this data into their enterprise so they can operate more efficiently. Right. So, so those kinds of customers are asking for it, but really this is just the next step. you know, we've spent a lot, the time you put Niagara in the cloud and suddenly you've got enterprise being a master of connecting multiple things, buildings, but that doesn't, solve the real problem to me.
Yeah. And the nice thing about analytics, and I know you spent some time in there, you know, the promise was if you could model it right, the analytics just started working well, shouldn't that be the way our experiences with our entire enterprise platform. If I model it right, I should be able to commission it now.
I should have an interface that's completely operational. That's completely understands the domain that allows me to, to navigate to my chiller plant. My VAVs my fan coils, my VRS, my cooling towers. And I should be able to look at real data right now. Not worried about demographics person configure, right?
No, it's, wasn't modeled. Right? And then you get that replication, that repeatability in the enterprise. That's the stuff that enterprise software promises. But our industry has been afraid of enterprise software. In reality, like you said, they just rebuild it every single time. And, and our own company was, uh, you know, whereas guilty of as anybody else, you know what it is, continuous improvement, right?
So no project ever looked like the last one because we're making it better. Every single time I was making a better chiller plant. Every single time I was making a better air handler with a better spinning fan every single time. And that didn't really improve anything for anybody. At the end of the day, all that did was give somebody a better show piece on a, screen.
And so, you know, my, my own team hates this, uh, example, but I always talk about, you know, from a usability standpoint, I used to hate that and I still do hate that we would document 40 or 80 hours or 120 hours of training, on the user experience. It's like, Why am I doing that? I mean, how many hours of training did your bank give you to use your mobile app?
I mean, I don't remember seeing any right. Um, but I figured out how to use it because it's relatively intuitive. the other thing about the banking industry that I like, and it's kind of it's correlation and what's driving a lot of thought leadership around here is. The money is the data. Right. I can take that data and extrapolate it and put it in another bank.
If I want, I can have that money in multiple banks. I can use my Wells Fargo app and I can actually see my accounts and other banks if I want to. And the early versions of this only allowed us to just read it. Right. But now we're depositing checks this way, you know? So, to me, we're just following the technology evolution, right?
So yeah, we started with analytics. No data model feeds the analytics, analytics just work. They just run. Oh, well now it just feeds the UI. The UI just works. It just runs. And now the combination of those analytics in the UI with the rewrite. Now I can actually have my analytics interact with my data in real time and affect my building operation in real time.
And I can have a man in the middle concept if I want, or I can completely eliminate the man in the middle concept. So to me, it's just the evolution and we're not done. Like, this is just one more, you know, step to where we really get to that concept of autonomous buildings. And I'm sure you've seen other platforms that claim they can do that today.
But you find out with a lot of those platforms. It's very large. A low cost, labor force, somewhere else in the world. That's kind of pulling the strings behind that autonomous feature set, but that's just a step we're going to get there, where software is going to be a lot more intelligent and be able to do this.
And you need platforms that can, you know, visualize it, analyze it, allow operators to interact with it, and then also interact with other things. you know, our built space. partnership is it's a hundred percent just like it was with, uh, sky spark. We don't want to rebuild work order management.
Right. Right. But what I do want to do is give my operator that interface to understand what work is being done in their spaces, their equipment, their assets, what. I want analytics to be able to analyze, I want analytics to be able to inform the work order. I want the work order to be able to let the analytics know that it's been done so that it can, actually test that has been done.
Uh, you know, there's a lot of things, a lot of things to unpack there, but once you create, and this goes back to that IOT jet stream need, once you have this relationship created, it opens up so many of those use cases that. Before it had to be custom built every single time. And so our, hope and our, you know, desire is to not build that every time it's to identify these use cases, normalize use cases, You know, just like you have, haystack for data and normalizing data and relationships.
Who's out there normalizing use-cases for commercial office because they're all the same. And yet we have a brand new set of use cases and a brand new format and a, you know, a little bit different spin from every single project team. But reality, when you really analyze them, they come back to the same.
And there's probably 80% crossover and every single one of them. And then you might have some unique ones, but if we get to spend our time on the unique ones, because the 80% are. Well understood. And I'll automatically work then, you know, we're gonna be able to take that next step, right? Yeah. This is
James Dice: [00:30:51] one of the struggles of my course that I've created and we're one of the huge improvements I'm making for the next cohort is that the technology design process, you have to have some sort of.
Like design and creativity to it. But then with smart buildings, there are only so many things that we need to worry about doing right. We have use cases and those use cases probably can get built for one building and used for all the other buildings like it. Right. So it's not like we. Need to go through this, like blue sky ideation process, right?
Where you can easily pick from a set of use cases that have been done elsewhere. And you picked up on something from a past episode that I've sort of ranted about, which is our industry likes to do things. Over and over and over again and not talk to the other guy, doing that same thing over there.
Cause it's some sort of intellectual property or something. And you take every layer of the stack that we've talked about here today. And like we're all just doing it over and over again.
Brian Turner: [00:31:48] So anyway. Yes.
James Dice: [00:31:49] Um, that's fascinating. I want to, key in, on the data modeling piece because, You know, it's, down lower in the stack, but you're like, you're saying once you have it modeled, you're enabling all of this stuff to happen at higher levels of the stack.
Brian Turner: [00:32:03] So.
James Dice: [00:32:04] You know, you've heard the podcasts that have come before you in the last couple of months. Right? So we have Google, which is, I think you're familiar with what they're doing. There's Microsoft here, familiar with what they're doing as well. Um, obviously you guys are
Brian Turner: [00:32:17] sky's bark
James Dice: [00:32:18] shop, so you understand haystack.
So can you kind of just like level set with where we're at for us, those of us that haven't been around as long, like
Brian Turner: [00:32:27] where are we
James Dice: [00:32:28] at as an industry? On this data modeling, journey we're all on together because I think a lot of people in the nexus audience have been a little bit disillusioned lately when I've been coming out with these episodes, interviewing Google and Microsoft and whoever else.
And there are new, efforts that people haven't heard of, or maybe they have heard of them. I didn't realize. That they're separate from the other efforts that we've been working on together, haystack and whatever else. Right. Um, now we have all these separate efforts and so Where are we at in 2021 with this to you?
Brian Turner: [00:33:04] So we're, we're at, uh, I think I told you before we started recording it's I call it the ontology Wars. Like we're, we're literally in the middle of them. Um, but the way we approach it. is to basically consider that noise. and my client for the most part is not choosing an ontology. They're buying a solution.
They're buying a set of use cases. Now, if the use case happens to be, Normalizing data for like an IOT jet stream. Let's say that's the use case. My client is buying from me. We're going to show them how we're doing it. Now, if they said to us, that's great. I love haystack, but we're, really bought in to this new Microsoft thing.
Then, then it's incumbent upon me to figure out how to align. Haystack with Microsoft. And so this, came up a little bit, you know, we talked a little bit about Monday live and they were talking about this specific thing around manpower. So. And you've got what makes an MSI here later.
We'll talk just about the kinds of manpower that you would need in order to solve that problem. Right? So now instead of a HPAC controls technician or a, or a lighting engineer, I actually need data engineers, and I'm not talking about software developers. I'm talking about people who went to school and actually love data.
And they love relating data and they love identifying data. And those kinds people inside your organization don't have a problem with this topic at all. And no problem saying I'll line it to haystack and a brick. And for that client for Google, I gotta, I gotta spit out the Google ontology. And for this client, I've got to spit out the, Microsoft ontology.
I don't care. Right for them, they're data engineers. That's what they do. And so I think, in order to level set it, as you said, it's, it's just, you know, make sure you have the right expertise delivering that use case because when you don't, it becomes very scary for an owner. Who's gone. I know. I want, do I have to choose?
Do I have, you know, I just spent three years investing in haystack because John petsy convinced me. That was the way. And now I've got Google convincing me. It's a different way. You know, what do I do? Well, no, you just keep. Going and if you want to also do some Google because you think their ontology is a little bit cool, then great.
Go do it. That shouldn't stop your integrator from being able to still give you that ubiquitous interface, that enterprise experience. Right. Um, so it's just a matter of making sure you're choosing the right partners and, that the data doesn't scare them. if the data scares everybody in the value chain, Then you've got a problem.
The good news is there's plenty of companies out there that data and the ontology worse. They're not scared of the running headlong into it. Yeah.
James Dice: [00:35:50] Technology Wars. I think that might be the title of this episode. A lot of it, I mean, that's certainly a new, like a fresh take from my perspective. So where does this decoder ring concept come in?
So. I've been interviewing people. And I don't know where I got this. Maybe I've made it up and then I put it on LinkedIn and you were like, commented immediately. Like we're building it, like, so can you explain kind of what you guys mean by the Dakota ring and maybe you just did.
Brian Turner: [00:36:18] Yeah, it's that it, so we call it OAP ontology alignment project and were doing it for ourselves.
We're making available to anybody that wants to participate. We don't really care back to your point about IP ontology. Alignment is not our IP. It's something we have to do in order to solve the ultimate problem, which is the use case for, for these owners and these operators. Right. and we also aren't, um, We don't think we're the smartest people in the room.
We know that there's a lot of intelligent people out there that are trying to solve these problems. And so we want the contribution, where the real problem happens right now. James is we have this site, it's a, it's a public site. Anybody can go there. We have a mechanism to contribute manually.
I will say we're looking to get it more onto, um, Onto an open domain so that people can actually contribute through GitHub, uh, but then the reason it's not on GitHub yet, just because it's the management of that, right. So somebody says, Hey, here's something or to contribute. Somebody has to then review it, go, it's already here.
Here's where it is. Here's how to use it. Or it's not here. This looks right. This looks like a good approach. Let's let's go ahead and make it part of the standard. You know, Brian, Frank's been doing this kind of stuff for years with was haystack. And so I'm very close to the problem that can create. And then, you know, also watching, um, the Google DVO is also on GitHub and watching the process that they're having to do when somebody from Malaysia contributes something.
and it's already there, but you have to actually know it well enough. To know what's there. And, and then if it is something new, you have to know it well enough to make sure that it fits into the context and, and the modeling of the overall ontology. And so that means I have got to have really experts of the ontology and the ontology.
So our ontology plus the overall industry and how this data actually relates. And those people are very expensive. And so it becomes very, very difficult to really make this ubiquitous without an industry effort, which is what haystacks been trying to do for, I don't know. I think John said the other day, 10 years, you know, I've been trying to get the industry to come together because this isn't, this isn't my IP or your IP.
This is our collective IP and it is necessary. Um, And the other thing that we did is we set up, but just having that static get hub database isn't enough. I need my tools to actually access that database as a service. So I know that, Hey, I've identified this thing as a fan coil. You know, what does that mean?
How does it get identified if it's a fan coil? What's it look like in haystack? What's it look like in brick? What's it look like and in Google's DBO and then what else do I need to know about that fan coil in order for it to fit one or more of those ontologies? And I need that to happen automatically, cause to expect that I'm going to scale manpower.
At a fast enough rate to be able to have teams that can deliver that model consistently. It's just, fool's gold, right? It's not going to happen. and so that's really why it needs to be a service. So those are the two fundamental reasons we started to build our own. and that comment on your post.
It was amazing how many comments I got? Hey, come join us. We're doing that too. Come join us. And that's right now. And I, I would say we're guilty of it as well. Right? I'm not an independently wealthy company who can just go, okay, we'll take all of our stuff and we'll go join you. At the end of the day, we have to deliver solutions.
And so it's expensive for me to uproot what I've done and go join somebody else. Just like it's expensive for them to approve what they've done and come join us. So I don't, think there's arrogance or anything else out there that stops the industry as a whole, from really coming together. I think it's just.
A confluence of people didn't jump on haystack as a global phenomenon. Like we should have, right. Several of us did, but there's still people out there thinking that they could be a better way. And I, and I've heard many, many times, you know, why did Google do this? I've been asked that question. I dunno, probably a thousand times what you have to understand.
It's really easy to look at what Google did right now and say they could have just done it with haystack, but the fact is they couldn't have, when they started doing what they were doing, haystack was a naming convention. It was not a real ontology. It wasn't a real ontology until a couple of years ago.
And even yet, Haystack four still isn't fully released. Right, right. It's it's released for public comment. so it's, it's a little bit unfair to say that Google did something completely outside the realm. They didn't. They needed to solve a problem and they did. And now what on release, it looks like it's a competing technology to haystack for rather than really understanding kind of how this stuff happens.
And I would say that's probably the same with the Microsoft one. It's probably the same with what the guys in South America, there's like three or four ontologies in South America. And we still don't even talk about up here.
James Dice: [00:41:29] I didn't even know about that. They're all not afraid to admit it. Cause it's like a lot of people don't.
Yeah.
Brian Turner: [00:41:36] Okay. So, there's a big problem and that's why I say we can't try to bring them all together. Yeah. We can't make them all one, but we need to do is really focus on delivering the outcomes and delivering the use cases. And then have data engineers worry about how to normalize that data. And if your owner has a specific affinity to one of them, great, let's just deliver that one for that owner, but otherwise deliver the one that is best of breed for you core to your heart, whether it's Google or Microsoft or haystack really shouldn't matter that shouldn't be what's driving really anybody's decision today.
And I know right now it's hot because it keeps coming up. But it, it really shouldn't be the discussion because at the end of the day, the ontology doesn't deliver any outcome. It only enables right. It's not an outcome. So I really love that
James Dice: [00:42:27] answer. So if that's like level setting where we're at and January 20, 21, where are we going to be at in January, 2022 with this?
What's like the next phase in your mind.
Brian Turner: [00:42:39] I think you're going to see just more people lining. More people coming together. Um, I think you'll see Google actually contributing to that alignment a lot more because in, in 1918, 1920, they were a hundred percent inward focused making sure that they could do what they could do for their own buildings, making sure they could manage their own portfolio.
Um, but I know it's an initiative for them to get alignment to they're certainly not of the mindset to force everybody into there. Domain or their ontology. Um, they recognize that alignment is a critical piece of success for them, even, you know, if, if the Google building ontology is going to be ubiquitous outside of the Google realm, then it has to be aligned with the other leading ontologies out there.
And I think that's what 21 and going into 22 is really going to see start to happen. Which hopefully will provide some comfort to the owners and the facility managers and all the people that are trying. They're thinking they have to select and choose. And, and I'm much more on the side. You don't have to choose, you know, choose partners, choose outcomes, focus on your use cases, focus on getting things done.
And make sure they use one of those ontologies. Like, I I'd hate to see somebody start, like just going off on their own and saying haystacks to restrictive Googles to whatever we made our own. That, that to me is more dangerous than, choosing one of the big names. Got it. All right.
James Dice: [00:44:09] And if anyone wants to dig deeper into this conversation, this is probably the fourth episode that has talked about ontologies.
There's number 12 with Corey Moseman. And then what we're talking about right now is Google, which was at the sewed 29. So put those in the show notes for anyone that wants to dig deeper into that. All right. let's kind of shift gears here. To the MSI. So the master systems integrator, I think this is a confusing topic for a lot of people in our industry.
And you're the perfect person to kind of ask some of these kind of, questions around sort of clarifying what is an MSI and what did they do and what are the, some of the myths around it. So let's, start with, uh, how do you guys define and describe what an MSL it is?
Brian Turner: [00:44:55] So an MSI is a little bit.
Consultant a little bit, project management, quite a bit of project management, a trainer and educator, and then ultimately an integrator and then a service provider. So, the thing about an MSI and what they're delivering is, is really a cloud enabled. building operations platform at the end of the day.
And that means that they're going to be with you as a partner for a long time, Â you know, think about when you buy enterprise software, like an Oracle or a net suite or something. You're not buying that for one year and then bidding it out again next year. Right. You're selecting a technology as something that you're going to use as part of your business, as a partner in your business for.
You know, five years minimum. I mean, realistically it might be 10 or 15 and that's really how people need to be looking at MSIs. This isn't something that you're bidding out year after year, although that's, what's been happening. And you can imagine the amount of, inconsistency and deliverable that building owners get or building operators get when they take that approach and that natural for that approach to happen.
Because so many of my size. Came up from a controls contracting world. Right. And those people were bid out every single time. Right. All I have to do is say, you have to be Niagara. All I have to do is say you have to be Allerton or ALC or Honeywell, or fill in the blank. I'll get competitive bidding.
Everybody will be great. And we'll be good. And then you get inconsistent delivery, you know, kind of the, you think logically that model didn't work in controls. For a good inconsistency, right? Certainly isn't going to work and master system integration. and so now here's the, here's the problem, the fundamental problem.
So many MSIs came up through controls, contracting or lighting integration or somewhere, right. And with one of the building systems and they struggled to give up that revenue because. An MSI scope for an 800,000 square foot building might be 700,000, might be a hundred thousand, but the scope for the controls contractor might be two and a half million.
Right, right. And the scope for the controls contractor has a lot of labor subcontractors. a lot of material, a lot of commissioning, a lot of programming, and they've built their whole environment to support that kind of revenue model. Then an MSI comes in and it's a lot of just intelligent labor. A lot of smart people, a little bit of material, maybe on the networking side, you know, maybe you've got some, some firewalls, maybe you're part of the, depending on the building layout, you might be the technology vendor also, but at the end of the day, you shouldn't be responsible for the controls or lighting controls or the elevators or any of that, because those all are systems in and of themselves that need focus and the MSI, you have to be aware and knowledgeable.
At least a little bit of all of those systems that you're integrating in order to really understand the use cases and the outcomes. And that should be your whole focus on the project. Um, so often, you know, if you think about a controls contractor, that is an MSI also they, they come in and they've got, you know, five chillers, you know, five towers, 57 pumps, and.
That plant has huge amounts of complexity and that they're sitting here trying to interact with, you know, the elevator system. That's got a little bit of problem, and now that best technician has to go run over because the chiller plant just shut down and they don't know why. And now they've got to, unscrambled tons of code to figure it out.
And so many MSIs, their best integrators, also their best controls technician. And, then that best controls technician might also get called to another project. And so you just end up with these real conflicts of interest and so much of the MSI. So really a real MSI is somebody who is hired specifically to be an MSI and not hired specifically do any of those other things.
And it, it doesn't mean they couldn't have that expertise in house. I have several clients that we don't do any controls for, even though I have controls expertise in house. But I just am there MSI and I work with what used to be my competitor. I mean, you brought this up a little earlier, right? That, that we're an industry that culturally has hated our competitors for years.
Right. You don't ever want to talk to him. You don't want to share ideas. You don't want to do anything. You'll avoid them at conferences. If they walk into the, to the bar that you're sitting at, you know, you make sure that they're not sitting at the table next to you because they might overhear some competitive advantage you have.
And that's all really BS. you know, if, anything, the tech industry has shown us that you can be very, good friends and, and in fact, you might be working for that one. Yeah. In two months or three months. Right. and so the sharing of knowledge, and I'm not saying that everything should be shared, there's certainly some competitive things that we try to keep in house, but for the most part, what we're talking about today, there's nothing new, right?
As you said, that you've had 29 episodes covering many of these things, many of the ideas that I've talked about, I'm just supporting what other people have already said on the show. So it's, it's. Once we can get past that and that we're not the smartest people in the room. I think we'll really be able to understand what MSI is and emphasize work with other partners.
So I'm teaching, for example, Johnson controls, branch, how to be a good citizen on a system. That's part of an MSI smart building platform, right? I'm teaching them how to write your programs, how to model your data, how to prepare. Your system to be part of something bigger. Right? Right. That's something new for them.
Every other job they've done before they've been the master of their domain. They didn't have to worry about anybody else. They didn't have to worry about designing their architecture to support passing data and moving data upstream. They just didn't care. So that's why I say it's part of educator when you're an MSI, you're spending time with people that used to be your competitors and you're teaching them.
How to be A good contractor on that, job. How to make the most money on that job, how to limit the callbacks and the rework effort that they might have to do. So, you know, so now it begs the question. When's an MSI, come on as soon as possible. So we, you know, we work a lot with the smart building consultants out there.
Um, and some of those consultants are becoming MSIs, which is kind of weird. And so it's forcing some MSIs to start consulting, even though I have no idea how to make money as a consultant. so the, thing is if, if a consultant works for a year or two with an owner and developing concepts, use cases, et cetera, the MSI needs to be brought in.
Basically on groundbreaking so that they can start putting a reality check to those use cases and technologies and help them understand what they actually need to install in the building to get these outcomes. Got it. Cause a lot of times the consultant will we'll work with them and they'll come up with theoretical outcomes that should be available.
They don't necessarily know exactly how to make that happen, where the MSI does have that. So, so there needs to be a good handoff. From that. And then other consultants I've seen in some parts of the world, actually stay with the job till the end, which I think is also smart because if the consultant came up with a theoretical idea that they thought would be available in three years, when the building comes to life, But as they're working with the MSI that find out that, Hey, the technology that's available as either a too expensive B too experimental or C just not available, they can reframe that for the owner, right?
Because they're the ones who worked with the owner to create that. And too often, the MSI is left holding the bag while XYZ consulting said, this could be done and we're going, but it really can. If you look at. The way, what we'd have to do to make that happen. It's just too expensive and way too expensive to maintain.
Like, why, do I want to build Frankenstein? If I wait two more years, I can put it in an elegantly and add it to your platform versus bolting something in right now that you won't want to support over time and ultimately you'll consider a failure. So, so the consultants and the MSIs have to be hand in hand, throughout that process.
Got it.
James Dice: [00:53:21] This is one of the reasons why I wanted to start with the software first and ask you about that because. I find that the projects I'm on the MSI, like you said, is, is used to, or came from this specific silo in the building. And now we're talking about breaking down the silos and that's where you sort of lose people, I think.
And so I love that answer. I don't, really have any followup questions. I feel like, again, you, you answered all of them. so talk to me about the. Service aspect of this. So I think one of the issues I see in MSIs is that our industry has a construction mindset. So we view buildings and smart buildings as a one-time event.
Right. Whereas really a smart building is an ongoing event. it's a way of life, essentially. And so when people say MSI, You go from there to MSI, to like a contractor and for your, at a contract, you need to do a construction project. Right. But, so how do you guys approach the ongoing aspect of the MSI role?
Brian Turner: [00:54:29] Yeah. So I'll pay on back to my dad. I always say we were born from distribution, so we didn't have any concept of one time. Right. So for a distributor to be successful, I needed people to keep coming back to me. Right. I couldn't just sell one project to a contractor, never see them again, or else I was dead.
Right. So I had deliver that service over and over and over again. The other thing, and we've talked about this a little bit already. It's it's this concept of, um, I want to charge. For something over and over and over again. So I want to build that use case for you. And then I want to sell it for the same price to the next guy and to the next guy, the next guy.
And when you look at what cloud services and as a service model has done, it's completely extrapolate that away. You know, you pay me a monthly fee or an annual fee and you get whatever I develop. Whether I developed it for this client or that client, it now becomes available to you because you're paying a recurring fee.
And now, because I'm getting that recurring fee from a lot of people, I don't have to charge everybody the full price to create that solution. so creating a use case for one person might be too expensive for that one person to buy. But if you're creating a use case for 20 people, then everybody buys it.
Right. And, the mentality of get in and get out. This is a construction process. Everybody's motivated and incentivized to make as much money on that one instance as possible. So that means will do as little to get signed off as possible, you know, and whether people like that reality, or want me to say it, you know, that's what keeps me popular in the media, I guess.
But that's the reality, right? I get a job for a million dollars. I have a cost of. $800,000. I want to try to make my cost seven 50. I want to make my call seven 25 because the chances that I'm going to get to increase my top line are lower than the control I have of the bottom line. And so then we start seeing people under delivering an making you catch them.
So, this is why we have commissioning agents. So I don't want to deliver everything, make your commissioning agent catch me. And then because of the nature of construction, especially in the controls industry controls, typically isn't done till after the occupancy anyway. And so everybody's under the gun to just get done and rarely do we have a hundred percent project.
And then now, then they get into service. And if you're a big organization had service contract, you love it. Turn it over to service and spend the next five years. Hopefully. Maybe bringing that building to a hundred percent, but the industry is broken. It's been broken in that way for a long, long time. and data is going to fix it because data doesn't lie when the sensor is not moving.
You know, it doesn't matter that it's physically there. It doesn't matter if it's physically wired. What matters is, is the data changing? Is it moving back? Is it getting there consistently? Is the refresh rate. Good? You know, all of those things are going to now drive those underlying systems to be better.
It's going to drive those underlying contractors to be better. It's going to drive the manufacturers of these controllers and these systems to be better. And so now we talk about service. It's no longer it's about servicing the mechanical electrical equipment. It's now about servicing those integrated systems and making sure that if I need a refresh rate of 60 seconds in order to make my enterprise a strict control strategy work, then.
That refresh rates key to now an integral piece of the system. So if that refresh rate starts to degrade, I need somebody who actually knows how to come fix that or knows how to find it, and then work with a third party to actually go do the steps to fix it. Cause the other thing is an MSI is not all things, right, but this is one mistake.
I think a lot of owners make. Is the MSI is like the all, knowing everything. That's not the case. A good MSI is really good at that domain of data. Really good at the domain of integration, really good at the modeling, really good at presenting and platform and understanding the security model and how to, secure all of that aspect.
But they're not necessarily experts in why the controller on the elevator is not operating, right? Yeah. You got to inform the elevator company like, Hey, these are the things we're seeing. These are the symptoms we're finding. Can you figure out how to resolve it based on what I can give you right now, the more, the longer I interact with elevators.
The more intelligent information, we'll be able to give the elevator company to be more proactive or, precise with their, with their troubleshooting. Um, like in mechanical, I feel we can be fairly precise with the amount of knowledge we have, about mechanical systems and what's going on from the data we get.
But on an elevator, I I'm less precise. Right. But over time, As a good MSI, we'll get more and more precise and helping these service providers really impact the buildings. Um, and I think that's where if you look at what's an MSI and NSI has all of those things, but a key part is that service provider, if you're delivering a platform, that's going to be there for a long time.
You should also be expecting that you're going to be delivering a service to help them maintain that platform, understand the data that's coming out. Add additional. Use cases kind of cultivate that dataset. Um, you've been in the industry for 10 plus years. The first data set that you came in and the amount of actionable information you rolled to create from that.
Is greater today than it was 10 years ago. And so if you can imagine that we're kind of at the infancy of really bringing all these data sets together and aligning them strategically within the building and the spaces they serve, the amount of information that we're going to be able to create from that over the next 10 years is, is unknown.
Right. And so if you think that you're going to do a construction project and just. Buy a smart building and set it and forget it. Get through the warranty period and disappear as an operator that you won't need that MSI anymore. And as an MSI, you have the culture of no, I'm moving on to what's next.
I'm not going to take care of what I've done. It's going to fail and it will just, the industry itself won't fail, but the sooner we can rationalize that the faster it will grow.
James Dice: [01:00:40] Beautiful. All right. All right. Let's let's wrap up here. What are you excited about? This is the first interview on the podcast for 2021.
Uh, what are you excited about
Brian Turner: [01:00:49] for this year? I'm excited to be first in 21. That's awesome. So, uh, yeah, I'm optimistic. I feel like 2020 was full of doom and gloom. You know, from our personal perspective, 2020 Q1 was the biggest Q1 we'd ever had in the history of our business.
And, and then, you know, pandemic hit shut downs. our two biggest, markets that we're in California, in New York, effectively, completely shut down. So, um, yeah, it was kind of doom and gloom. You know, we had to go through a period of, you know, salary reduction and then.
workforce reduction, you know, in Q3. And then we started to see that come out. Right. And so it was a, it was a rough rough year. And fortunately we came out, we came out okay. And, and profitable. And those are, those are all great things. When I look at at 2021 is we now have been level set.
the market is what it is, we've accepted it. we're hoping that, the pandemic will start to ease and the restrictions will start to ease. But at the end of the day, we now have strategies to help buildings become better to help the healthy buildings initiative actually take action.
And we're seeing a lot of momentum there. So I'm excited that You know, what was going to take probably five to seven years to really take off, that's just been moved forward. Um, and so we're, we're excited about all the opportunities and. Real building owners, real people are looking at this the way they used to Juul over marble, um, on their entryways.
And, and so I think, yeah, we're now top of mind, we do a lot of retail. Yeah. And I feel like our business has been moved from back of house to front of house. so it's pretty exciting from that perspective. Um, it's a conversation every day rather than every week. yeah, so it's exciting.
James Dice: [01:02:35] Awesome.
Well, thanks Brad. I appreciate you coming on the show and, uh, we'll talk to you soon.
Brian Turner: [01:02:41] All right. Thanks James.
James Dice: [01:02:42] All right, friends. Thanks for listening to this episode of the nexus podcast for more episodes like this, and to get the weekly nexus newsletter, which by the way, readers have said is the best way to stay up to date on the future of the smart building industry. Please subscribe@nexuslabs.online. You can find the show notes for this conversation there as well. Have a great day.
âWe canât try to bring them all [ontologies] together. We canât make them all one. What we need to do is really focus on delivering the outcomes and delivering the use cases, and then have data engineers worry about how to normalize that data. Because at the end of the day, the ontology doesn't deliver any outcome. It only enables, right? It's not an outcome.â
-Brian Turner
Welcome to Nexus, a newsletter and podcast for smart people applying smart building technologyâhosted by James Dice. If youâre new to Nexus, you might want to start here.
The Nexus podcast (Apple | Spotify | YouTube | Other apps) is our chance to explore and learn with the brightest in our industryâtogether. The project is directly funded by listeners like you who have joined the Nexus Pro membership community.
You can join Nexus Pro to get a weekly-ish deep dive, access to the Nexus Vendor Landscape, and invites to exclusive events with a community of smart buildings nerds.
Episode 34 is a conversation with Brian Turner, CEO of Buildings IOT.
You can find Brian Turner on LinkedIn.
Enjoy!
Music credit: Dream Big by Audiobingerâlicensed under an Attribution-NonCommercial-ShareAlike License.
Note: transcript was created using an imperfect machine learning tool and lightly edited by a human (so you can get the gist). Please forgive errors!
James Dice: [00:00:00] hello friends, welcome to the nexus podcast. I'm your host James dice each week. I fire questions that the leaders of the smart buildings industry to try to figure out where we're headed and how we can get there faster without all the marketing fluff. I'm pushing my learning to the limit. And I'm so glad to have you here following along.
This episode of the podcast is brought to you by nexus pro nexus pro is an annual or monthly subscription where members get exclusive writing podcasts and invites to members only zoom gatherings. You can find info on how to join and support the Without further ado, please enjoy this episode, the nexus podcast.
Episode 34 is a conversation with Brian Turner, CEO of buildings, IOT. We talked about all the topics we love here on the podcast, including analytics, advanced supervisor control, data modeling, integration, why buildings are behind and much more. We took a deep dive into the role of the master systems integrator that I think all you building owners out there and need to wrap your head around without further ado, please enjoy.
Next is podcast episode 34. All right. Hello, Brian. Welcome to the nexus podcast. Can you introduce yourself?
Brian Turner: [00:01:22] Yeah. Hi James. Thanks for having me. I'm Brian Turner CEO with buildings, IOT.
James Dice: [00:01:27] All right, cool. You've been around in the industry for awhile. Uh, can you take us through the history? and then how you got to up to today.
Brian Turner: [00:01:35] Yeah, sure. Um, started, you know, out of college, I worked at controllers, we'll go through college control pill is a value add distribution company that serves, the commercial building space. Uh, when I started at control co we also serve the industrial space. So I'm 100% focused on controls, and control products, not really service.
So there was always, uh, a bit of value add to the business. and just, you know, over the years, you know, adding different pieces of value to that business, throughout, my college careers, it was interesting to see how the different products got applied. When I graduated college, I. Decided to go work at Johnson controls, as a field tech and actually deploy and figure out really how these systems go in, what kind of software has to be done?
What kind of programming, what commissioning is all about? you know, what, uh, what a 30 story building looks like versus a two-story, you know, pharmaceutical type facility. So that was good experience. following. That I came back to control co to start sales. I felt like I had a pretty good understanding of how these systems and controllers get deployed.
Um, and I wanted to really help contractors and integrators, do that properly. So, and then from there, over the years, we've done lots of different things, you know, from trying to solve an analytics problem. We built one of the first, analytics platforms on top of the Tridium. That we ended up selling to Tridium ultimately, and you know, as we continued to migrate kind of out of distribution alone and more into kind of contracting and master system integration, we then recognize that, you know, four or five years ago, there weren't a lot of good platform choices to really.
Provide a real integrated, solution for clients. And so we spun up another software dev team up in Ottawa and, now we have a full, platform as well. which is interesting. Uh, we'll several talk about platforms and emphasize here later in the conversation, but, but that's been a labor of love, over the last four years.
really developing that to, to meet the needs as we see them. Needing to be met, from a, from an integrator's perspective and from an operator's perspective. and, and so that takes us where we are today. and, there's a lot of change, a lot of, uh, A lot of growth in this industry. it's exciting to see all the influence coming from overseas as well, whether it's Asia, PAC or Europe or, or South America.
I think that global kind of confluence and innovation, is really starting to impact this industry in a good way. Cool.
James Dice: [00:04:03] Yeah. And we were talking a little bit before we hit record. You said your team is mostly remote. Are you guys working all over the country, all over the world or where do you guys
Brian Turner: [00:04:13] hang out?
Yeah, so I would say we're, uh, we're headquartered in California. and we, I would say the biggest. Group of people is actually in Northern California in the Bay area, but almost all of those people are working remote. Now I'm in the office today, but, of our 30 employees that are, I guess, assigned to this office only four are here with any kind of regularity.
And everyone else is working remote. and yeah, we've been a remote workforce for several years now. We've got people throughout North America. you know, as far North, as Vancouver and I don't consider Ottawa that far North, although it's a lot colder than Vancouver. and then it's, all the way over to New York and then another little group of people in North Carolina and then just people kind of smattered throughout the U S That work remote because as an MSI, remote work was, was a real thing even before the pandemic.
And then the pandemic just kind of reinforced that. That was the only way we were going to get to work. So.
James Dice: [00:05:11] Okay. cool. So I want to talk about all that stuff that you just kind of introduced for us first. I want to ask you, so I've been doing my favorite question fall of 2020. I want to kind of tweak my favorite question for 2021 since this is the first interview on the podcast, for the new year.
So. 2020. It was all about, okay.
Brian Turner: [00:05:30] why are we behind?
James Dice: [00:05:32] And now I want to kind of flip that and you feel free to answer the 20, 20 question if you want. But the new question is more around. What's Like the number one thing you think needs to change to sort of unlock, the potential we have here.
Brian Turner: [00:05:45] Well, it's a, it's a tricky question because there's a lot more than, one thing. But, honestly I think the, the focus of a tenant. And understanding their environment and, and how much importance they put on their employees, comfort, safety, health, and wellbeing, and how that is a very big, positive influence on their productivity.
I think once organizations really understand that. Then our industry is going to get completely unlocked. and so it's, sounds cliche a little bit, and it has nothing to do with the technology we have or the manpower we have, or the education in our industry. It's really about the tenants and the people who occupied our building and how important it is to them.
That the buildings that they're in are safe, comfortable, healthy, you know, and, and all the things that we can actually contribute to. And, and when that becomes a top level priority, and it becomes the same level of priority as the marble and the Starbucks at the corner. And the really good cafe that's in the place then will be unlocked.
Um, I think it's as simplistic as that and yet also as complex.
James Dice: [00:06:58] Yeah, I agree. There's so many different factors, but that's a great one to kick us off with. I appreciate that. Um, do you think that's changing, these days?
Brian Turner: [00:07:07] I do I think, uh, I think it was already changing pre pandemic, honestly. Um, I think, the tech firms, building really innovative spaces was already moving, the population that way globally.
but then, you know, when you get to a pandemic and now, people are suddenly back in their homes suddenly wondering about if their building or their. Place was going to be safe to go back to suddenly exposing themselves to, Oh my God. you know, their best me and my saw the other day was that, you know, a year ago, go to a bowling alley and put our hands in some holes and a bowling ball, then eat French fries right afterwards.
Right. And yesterday we're like, that's mortifying. We would never want to do something like that. And so I think the pandemic has just has really escalated that, that awareness. and I think the longer the pandemic is around the longer and the more in graded this awareness will be that we won't just forget about it.
If, if we had gone three months and. Gone back to normal. I think we would have largely gone back to our own normals. but today I think, we're going to see a lot more people being a lot more aware of their environment, the cleanliness, the safety, the air quality. I think people are just more aware and I think that's going to stick.
James Dice: [00:08:23] Yeah. The example I like to use on this one as the book healthy buildings. Which was very popular this year, for good reason in the last year. but it was written before the pandemic. Right. It just was released slightly before that. So like these sort of undertones
Brian Turner: [00:08:37] were happening,
James Dice: [00:08:38] the shifts were happening already.
Yeah. Cool. So let's dig into what you guys do at buildings, IOT a little bit deeper. so I want to save the whole MSI piece. Let's talk about
Brian Turner: [00:08:51] the software
James Dice: [00:08:51] side
Brian Turner: [00:08:52] of things first. So
James Dice: [00:08:52] you mentioned you had a software development group of Banawa take us through the different
Brian Turner: [00:08:57] types of software
James Dice: [00:08:58] you're
Brian Turner: [00:08:59] developing.
Sure. so  I'll kind of start with the most basic thing. So the most basic thing is really I call it the ontology Wars. It's like the clone Wars and star Wars. we've got all these different, Really big thought leaders out there competing for how to classify data, how to name data, how to relate data at the end of the day, it's all solving the same problem though.
Right? It's it's about creating that data and letting the data understand its relationship to other data. Right. Um, and there's lots of different data sets in a building that can benefit from being aware of, other datasets. so that's. Kind of core. So we started our OAP, which is ontology alignment project.
you know, not a cool name, but that's really what it is. And we created that as a service. And because we can make that as a service, it allows our plans form really to ingest these ontologies automatically. So as soon as we inform the service about the ontology and how it relates to like how Google relates to haystack, how BrickX relates to haystack, then it really allows us to.
a lot faster and a lot more consistent how they're applied. Right. and that really doesn't matter. So that's the first piece then that informs our, jet stream project, which is worldly, that middleware layer, that connection layer that allows us to connect different API APIs. And you know, whether it's data that's coming in through Niagara or through sky spark or through a cloud centered API, you know, we've got all these sensor clouds that are out there.
We don't need to bring those into Niagara or to. sky spark in order to get them into our environment. And so we needed a way to bring that data in without having to go through these other platforms first. And then we also wanted to make sure that that data was then exposed to other technologies out there that want access to all this data out of buildings, because getting data out of buildings as an easy, but we can make that easy and we provide a full graph, QL interface, outbound.
Okay. And then the cool part about that is because that's the core. Our OnPoint product are on-point professional and on-point enterprise both use that platform as well. So all the data that's available to us, we use that graph QL API to get it out. So then if we need to serve up data to power BI or to Klipfolio or some other, platform that we have nothing to do with, but our clients want to use it.
They can do that. Using the same tool sets we're using same API as res. So that's kind of the core. Uh, we do sell that as a service. but really for us, it's about getting to on point at that point. Right? So now I have OnPoint, which is a consistent user experience. that was first just analytics as a service.
you know, I already told you, we use sky spark as our core analytics engine. We didn't want to rebuild an engine. We really wanted to build that ubiquitous interface to really allow an operator to really understand everything that's going on in their building, not just the analytics. So we, connect things like.
Like sky spark, like build space, like HubSpot, like Salesforce into our platform. You get lots of different data, lots of different information about how your building was operating and allow that user to really understand it right there from a single page. And then recently we're launching in Q1. we added OnPoint enterprise, which gives us the ability to do full command and control from that interface.
So the first part was really getting all of that data, normalize consistent, related to each other. Right. And allow it to be exposed to different platforms. and then the next phase was allowed all those platforms to read. Right. So now anybody with the proper credentials into JetStream. From their interface, whether it's a power BI or a sky spark or on-point can now write back.
And so it really empowers and enables a lot of the automation, you know, things like demand management and, you know, chill, water reset if you want. But it also allows an operator just do something simple as change, a set point, or override a fan for a little while or do something that's more, No BMS related.
Right? So, so that's really the technology and the solution. we go to market with it a couple of ways. And in North America, we go to market with it as our, MSI, solution. and then in other parts of the world, we have partners that, that deliver that solution. So, um, So that's our platform.
James Dice: [00:13:12] Cool.
wow. So many different directions I would like to take this. so what you described, let me just sort of restate back to you. What I think, I just heard you have
Brian Turner: [00:13:22] a bunch of different sort of levels
James Dice: [00:13:24] that can be purchased. So the, the first one you mentioned was the IOT jet stream, which is kind of like what I call
Brian Turner: [00:13:30] and what I've written
James Dice: [00:13:30] as the independent data layer.
Right. So, just basically an integration and data modeling engine where anybody could plug into essentially. And then if you want to go one step above that you would add in the analytics. And then once to above that, you would add on the enterprise layer, which is gives you the supervisor control aspect of it.
Brian Turner: [00:13:50] Correct? That's it.
James Dice: [00:13:52] So I want to start with the data layer piece of it.
Brian Turner: [00:13:55] Um,
James Dice: [00:13:56] so there's a bunch of different data layer, only companies popping up, over the last say, I don't know, two to three years. what are you seeing with your clients as far as what value are they seeing in that sort of separate layer?
That's independent of everything else, because what we have as sort of the antithesis to that, would be these full stack solutions that it's really difficult to sort of break them up into these layers, like you've described. So. Yeah, I guess, what are you seeing as the value and what are your clients seeing as the value to that being separate?
Brian Turner: [00:14:29] Yeah, to me, it's really the approach. So with the way we've approached that data layer is. It's not unique, you know, we, can find similar, um, it, more business level data layers like that, like a Sligo or even a Zapier or something like that that are really more about IOT solutions that are cloud.
Right. And when we reviewed those, we were like, this is really cool, but they don't really connect to on-prem anything. Right. Right. and the reason is because on-premise heart. Getting data out of backnet or lawn works or Modbus or KNX or any of these field bus protocols is really difficult, especially if you're a cloud development company and all of your core understanding and knowledge is building really cool web technologies that physical layer down the building really sucks for you.
and then, it really kind of hit home. We had a, we have a big tech firm client. A few years ago, they said, Hey, uh, thanks for completing that data center for us. We want you to now give us the API. And so we turned over the haystack API because everything was there, it was all in sky spark. And they said, we don't want anything to do with this.
This is garbage we're not going to learn your industry specific API. We need a professional cloud. You know, web developer, API. Got it. And, now fortunate and that we already had good amount of our software leadership team up in Ottawa. And so they looked at that they laughed because they understood and they said, well, what happens if we give you a graph, QL, API, that's very domain specific that's around data centers and we allow you to navigate your API and something like, um, I can't remember the little tool they use, but just to graph QL.
And they said that would be perfect. That's exactly what we want. Okay. So we're like, okay. So we built that for them. And within literally a couple hours of turning it over, they were already pulling thousands and thousands of rows of data. Right. Because now we gave them something that they didn't have to spend time learning.
We gave them something they could just ingest and really build their own application, they could use the data for what they wanted to use it for. They weren't spending time understanding the security model of the haystack API. They weren't spending time understanding the different constructs and tagging, and they don't care about the haystack.
You know, it's like that's meaningless to them. And so we were able to abstract that layer for them. And when we did that and we saw the success of that, I was like, there's something here. You know that there are so many companies that just want data. They don't want to learn the intricacies of them.
And the other thing they don't want to do is actually cut around the big ring of keys for all the API APIs that you would need to know in order to connect all these sensor clowns. You know, I don't want to do that. I want something, somebody who does that for me, give me one spot to get them. I want to go into this building into this space.
I want to see all the data available in that space, whether it's HVAC, lighting, metering. Maybe it's people counting, maybe it's indoor air quality, whatever it happens to be, to be coming back and something I can understand, I don't want to have to be a facility engineer in order to understand the lingo that you're bringing back to me.
I want to be able to understand it as a web developer, and, and allow me to do what I want to do with the data. And so when we, when we found that out, it was like, okay, a couple of things we need to do. One is I don't need to be the source of truth for data. All of these different platforms have their database.
So I don't need to worry about scaling up huge data lakes and, you know, being data stores. But what I do need to do is maintain the relationship of how all of these pieces of data relate to the facility that they're in to the spaces they serve and to each other ultimately. And so that's where like, okay, so if we can do that, so now we've solved access to the data, the historical data.
We sold relating the data. And then there's a couple other little intricacies that we can solve, like make a domain specific. No data coming from a commercial office building is fairly different from data coming from a data center. The web developers looking at data from a data center are going to be different, different levels of expertise and interest than people looking at data coming from commercial office.
And so that's one, we've talked about domain specific. It's really, what is your building domain? What is your frame of reference for the data and how do we make sure that API fits and Sue journeys? To make your development cycle much faster. So that was really the goal around it. And that's the value proposition that, uh, that IOT gesturing can bring.
James Dice: [00:19:02] Got it. I have so many follow-up questions that you ended up just answering as you went on. So that was awesome. Uh, did want to key in, on one thing. So you mentioned that your client looked at the haystack API. Maybe they didn't even look at it. Maybe they just said, I'm not even going to look at it, but what were they, what were they missing?
I don't want to start picking on haystack. That's not what it's about, but is a sort of domain specific API missing compared to what you. Guys are building that is sort of like if I could put it as just one API for the building.
Brian Turner: [00:19:32] Uh, so just the, the methodology for securely connecting to haystack.
Okay, is, is a little bit different from pure web technology. And when this was happening, this is a few years ago. So haystacks, you know, evolved since then. This was maybe three years ago. So, back then I think the description was that haystack was rest like. Okay. Rest, like is not restful. So this client at that time was looking for a restful API connection.
and Brian, Frank would even say at that time, Russ, like, it didn't need to be restful. Well, that was his opinion. And he's right in a lot of ways, but for a lot of web developers, they don't want to hear that. They didn't want to hear that at the time. Uh, graph QL was certainly a. new entry. It's also not a restful API.
It's a different type, but in our opinion, it's a better solution from an API perspective. Um, and when we offered that, it was like automatically, yes, what they knew is that their team, they could give it to their most junior level developer and they could get something going with it versus having to learn a very specific.
Industry level API. If, if they learn haystack, if they teach their team, the haystack API, how transferable is that? Um, I've even had that with some of my own software engineers over the years. when we hire them, we bring them on that really excited by our industry. And then the first thing I have them learns Niagara or sky spark, and they're like, I'm learning something that's going to live and die right here.
I don't get, I'm not learning anything that I get to take to the next. Do you know if I'm going to go and work for somebody unrelated this industry? How transferable is this knowledge that I just took? So when you just think of that in the context of the bigger world, that's a big reason why I know it's IOT gesture that exists.
Got it.
James Dice: [00:21:22] That's awesome. Uh, I think that one people think about this independent data layer concept. They struggle with there's this myth around, I'm going to put all the data in the data Lake. I'm going to throw some tags on it, and now it's ready for any use case you want. Right. And so how do you guys handle the fact that the, the data layer sits.
Below the use cases that are going to get built on top of it. So how do you make sure that the data model can accommodate the use cases that your clients
Brian Turner: [00:21:52] want to build? So yeah, you start with why, so before we have to act, I mean, you're talking about the end, right? So once we understand why the use case exists, it really informs what that domain is.
Right. So I know who they use cases for. I know what value they think they're getting out of it. And then what that then informs me on is when I make my domain specific API, I'm really targeting it at that solution set. I'm not just saying, Hey, I have a data Lake API available to you. You can do whatever you want with the data.
As long as you understand my specific domain. It's really more understanding their use case, why they're doing it, what their domain is, and then catering the data to them because we might have 27 connections coming into IOT, jet stream. But the specific operator we're talking about, the use case, we're talking about needs three of them, and they don't necessarily need to navigate the entire API set.
The entire data set in order to get their use case solved. And so we can create that small API for them. Now, the cool thing is it's all backed by haystack. That's all backed by, you know, the spaces in the building and the sites and all of those cool things. It's really just how we're exposing it to them.
And then we have another client or another use case in that same thing that says, no, I need all of the data. Well, great. Here's the entire. Uh, API that's the domain is the building or the enterprise or whatever the top level mode is for them. And you can have access to everything, but this guy over here only needed access to these three little pieces of it.
Got it. And then a lot of that is also driven. Uh, you know, Okta is, the primary identity management platform and it's inside of our tool set so Okta allows us to create as many roles and as many, Unique users of that data. So we can really, you know, articulate the access at each data set.
It's not just sitting there once you get in you're in it happens at jet stream. So even our users up and on-point all get authenticated through jet stream first, and then that allows them to see what data sets they can see up in the UI.
James Dice: [00:24:07] Very cool. All right. let's move up one layer.
Well, let's actually move up two layers. So I think the analytics layer, I actually just don't have a lot of questions, maybe that's because I feel like I got that layer. Let's go up one more. So
Brian Turner: [00:24:22] 2020, I did a
James Dice: [00:24:23] ton of. Deep dives around supervisor control and like the future of where
Brian Turner: [00:24:28] that's going.
James Dice: [00:24:28] And, I'm wondering what you're seeing as far as you said, that's, solution is launching this quarter,
Brian Turner: [00:24:34] uh, the
James Dice: [00:24:35] enterprise.
So what caused you guys to launch that? is it more of just like the next progression?
Brian Turner: [00:24:41] Okay. I have analytics and now I want to do some command and control stuff. Or are
James Dice: [00:24:45] clients out there asking for that? Um, or is it a little bit of both? Uh,
Brian Turner: [00:24:51] so the, the most innovative clients are certainly asking for, but our industry.
And we've talked a little bit about this before we started recording this industry has been around so long and people are just, they're accepting of it. So if I'm a contractor and I go in and say, no, your interfaces in this server, Under your desk and you have a 17 inch monitor. Maybe now I'll give you a 30 inch monitor.
People are still very happy to accept that today. so it's not so much driven by our clients with the exception of the enterprise clients, the people who really own a lot of real estate or either owned and operated, or maybe they just operate it for third parties, like a CVRE or JLL, and they understand.
That, that they need to get better with data and they understand they need this data into their enterprise so they can operate more efficiently. Right. So, so those kinds of customers are asking for it, but really this is just the next step. you know, we've spent a lot, the time you put Niagara in the cloud and suddenly you've got enterprise being a master of connecting multiple things, buildings, but that doesn't, solve the real problem to me.
Yeah. And the nice thing about analytics, and I know you spent some time in there, you know, the promise was if you could model it right, the analytics just started working well, shouldn't that be the way our experiences with our entire enterprise platform. If I model it right, I should be able to commission it now.
I should have an interface that's completely operational. That's completely understands the domain that allows me to, to navigate to my chiller plant. My VAVs my fan coils, my VRS, my cooling towers. And I should be able to look at real data right now. Not worried about demographics person configure, right?
No, it's, wasn't modeled. Right? And then you get that replication, that repeatability in the enterprise. That's the stuff that enterprise software promises. But our industry has been afraid of enterprise software. In reality, like you said, they just rebuild it every single time. And, and our own company was, uh, you know, whereas guilty of as anybody else, you know what it is, continuous improvement, right?
So no project ever looked like the last one because we're making it better. Every single time I was making a better chiller plant. Every single time I was making a better air handler with a better spinning fan every single time. And that didn't really improve anything for anybody. At the end of the day, all that did was give somebody a better show piece on a, screen.
And so, you know, my, my own team hates this, uh, example, but I always talk about, you know, from a usability standpoint, I used to hate that and I still do hate that we would document 40 or 80 hours or 120 hours of training, on the user experience. It's like, Why am I doing that? I mean, how many hours of training did your bank give you to use your mobile app?
I mean, I don't remember seeing any right. Um, but I figured out how to use it because it's relatively intuitive. the other thing about the banking industry that I like, and it's kind of it's correlation and what's driving a lot of thought leadership around here is. The money is the data. Right. I can take that data and extrapolate it and put it in another bank.
If I want, I can have that money in multiple banks. I can use my Wells Fargo app and I can actually see my accounts and other banks if I want to. And the early versions of this only allowed us to just read it. Right. But now we're depositing checks this way, you know? So, to me, we're just following the technology evolution, right?
So yeah, we started with analytics. No data model feeds the analytics, analytics just work. They just run. Oh, well now it just feeds the UI. The UI just works. It just runs. And now the combination of those analytics in the UI with the rewrite. Now I can actually have my analytics interact with my data in real time and affect my building operation in real time.
And I can have a man in the middle concept if I want, or I can completely eliminate the man in the middle concept. So to me, it's just the evolution and we're not done. Like, this is just one more, you know, step to where we really get to that concept of autonomous buildings. And I'm sure you've seen other platforms that claim they can do that today.
But you find out with a lot of those platforms. It's very large. A low cost, labor force, somewhere else in the world. That's kind of pulling the strings behind that autonomous feature set, but that's just a step we're going to get there, where software is going to be a lot more intelligent and be able to do this.
And you need platforms that can, you know, visualize it, analyze it, allow operators to interact with it, and then also interact with other things. you know, our built space. partnership is it's a hundred percent just like it was with, uh, sky spark. We don't want to rebuild work order management.
Right. Right. But what I do want to do is give my operator that interface to understand what work is being done in their spaces, their equipment, their assets, what. I want analytics to be able to analyze, I want analytics to be able to inform the work order. I want the work order to be able to let the analytics know that it's been done so that it can, actually test that has been done.
Uh, you know, there's a lot of things, a lot of things to unpack there, but once you create, and this goes back to that IOT jet stream need, once you have this relationship created, it opens up so many of those use cases that. Before it had to be custom built every single time. And so our, hope and our, you know, desire is to not build that every time it's to identify these use cases, normalize use cases, You know, just like you have, haystack for data and normalizing data and relationships.
Who's out there normalizing use-cases for commercial office because they're all the same. And yet we have a brand new set of use cases and a brand new format and a, you know, a little bit different spin from every single project team. But reality, when you really analyze them, they come back to the same.
And there's probably 80% crossover and every single one of them. And then you might have some unique ones, but if we get to spend our time on the unique ones, because the 80% are. Well understood. And I'll automatically work then, you know, we're gonna be able to take that next step, right? Yeah. This is
James Dice: [00:30:51] one of the struggles of my course that I've created and we're one of the huge improvements I'm making for the next cohort is that the technology design process, you have to have some sort of.
Like design and creativity to it. But then with smart buildings, there are only so many things that we need to worry about doing right. We have use cases and those use cases probably can get built for one building and used for all the other buildings like it. Right. So it's not like we. Need to go through this, like blue sky ideation process, right?
Where you can easily pick from a set of use cases that have been done elsewhere. And you picked up on something from a past episode that I've sort of ranted about, which is our industry likes to do things. Over and over and over again and not talk to the other guy, doing that same thing over there.
Cause it's some sort of intellectual property or something. And you take every layer of the stack that we've talked about here today. And like we're all just doing it over and over again.
Brian Turner: [00:31:48] So anyway. Yes.
James Dice: [00:31:49] Um, that's fascinating. I want to, key in, on the data modeling piece because, You know, it's, down lower in the stack, but you're like, you're saying once you have it modeled, you're enabling all of this stuff to happen at higher levels of the stack.
Brian Turner: [00:32:03] So.
James Dice: [00:32:04] You know, you've heard the podcasts that have come before you in the last couple of months. Right? So we have Google, which is, I think you're familiar with what they're doing. There's Microsoft here, familiar with what they're doing as well. Um, obviously you guys are
Brian Turner: [00:32:17] sky's bark
James Dice: [00:32:18] shop, so you understand haystack.
So can you kind of just like level set with where we're at for us, those of us that haven't been around as long, like
Brian Turner: [00:32:27] where are we
James Dice: [00:32:28] at as an industry? On this data modeling, journey we're all on together because I think a lot of people in the nexus audience have been a little bit disillusioned lately when I've been coming out with these episodes, interviewing Google and Microsoft and whoever else.
And there are new, efforts that people haven't heard of, or maybe they have heard of them. I didn't realize. That they're separate from the other efforts that we've been working on together, haystack and whatever else. Right. Um, now we have all these separate efforts and so Where are we at in 2021 with this to you?
Brian Turner: [00:33:04] So we're, we're at, uh, I think I told you before we started recording it's I call it the ontology Wars. Like we're, we're literally in the middle of them. Um, but the way we approach it. is to basically consider that noise. and my client for the most part is not choosing an ontology. They're buying a solution.
They're buying a set of use cases. Now, if the use case happens to be, Normalizing data for like an IOT jet stream. Let's say that's the use case. My client is buying from me. We're going to show them how we're doing it. Now, if they said to us, that's great. I love haystack, but we're, really bought in to this new Microsoft thing.
Then, then it's incumbent upon me to figure out how to align. Haystack with Microsoft. And so this, came up a little bit, you know, we talked a little bit about Monday live and they were talking about this specific thing around manpower. So. And you've got what makes an MSI here later.
We'll talk just about the kinds of manpower that you would need in order to solve that problem. Right? So now instead of a HPAC controls technician or a, or a lighting engineer, I actually need data engineers, and I'm not talking about software developers. I'm talking about people who went to school and actually love data.
And they love relating data and they love identifying data. And those kinds people inside your organization don't have a problem with this topic at all. And no problem saying I'll line it to haystack and a brick. And for that client for Google, I gotta, I gotta spit out the Google ontology. And for this client, I've got to spit out the, Microsoft ontology.
I don't care. Right for them, they're data engineers. That's what they do. And so I think, in order to level set it, as you said, it's, it's just, you know, make sure you have the right expertise delivering that use case because when you don't, it becomes very scary for an owner. Who's gone. I know. I want, do I have to choose?
Do I have, you know, I just spent three years investing in haystack because John petsy convinced me. That was the way. And now I've got Google convincing me. It's a different way. You know, what do I do? Well, no, you just keep. Going and if you want to also do some Google because you think their ontology is a little bit cool, then great.
Go do it. That shouldn't stop your integrator from being able to still give you that ubiquitous interface, that enterprise experience. Right. Um, so it's just a matter of making sure you're choosing the right partners and, that the data doesn't scare them. if the data scares everybody in the value chain, Then you've got a problem.
The good news is there's plenty of companies out there that data and the ontology worse. They're not scared of the running headlong into it. Yeah.
James Dice: [00:35:50] Technology Wars. I think that might be the title of this episode. A lot of it, I mean, that's certainly a new, like a fresh take from my perspective. So where does this decoder ring concept come in?
So. I've been interviewing people. And I don't know where I got this. Maybe I've made it up and then I put it on LinkedIn and you were like, commented immediately. Like we're building it, like, so can you explain kind of what you guys mean by the Dakota ring and maybe you just did.
Brian Turner: [00:36:18] Yeah, it's that it, so we call it OAP ontology alignment project and were doing it for ourselves.
We're making available to anybody that wants to participate. We don't really care back to your point about IP ontology. Alignment is not our IP. It's something we have to do in order to solve the ultimate problem, which is the use case for, for these owners and these operators. Right. and we also aren't, um, We don't think we're the smartest people in the room.
We know that there's a lot of intelligent people out there that are trying to solve these problems. And so we want the contribution, where the real problem happens right now. James is we have this site, it's a, it's a public site. Anybody can go there. We have a mechanism to contribute manually.
I will say we're looking to get it more onto, um, Onto an open domain so that people can actually contribute through GitHub, uh, but then the reason it's not on GitHub yet, just because it's the management of that, right. So somebody says, Hey, here's something or to contribute. Somebody has to then review it, go, it's already here.
Here's where it is. Here's how to use it. Or it's not here. This looks right. This looks like a good approach. Let's let's go ahead and make it part of the standard. You know, Brian, Frank's been doing this kind of stuff for years with was haystack. And so I'm very close to the problem that can create. And then, you know, also watching, um, the Google DVO is also on GitHub and watching the process that they're having to do when somebody from Malaysia contributes something.
and it's already there, but you have to actually know it well enough. To know what's there. And, and then if it is something new, you have to know it well enough to make sure that it fits into the context and, and the modeling of the overall ontology. And so that means I have got to have really experts of the ontology and the ontology.
So our ontology plus the overall industry and how this data actually relates. And those people are very expensive. And so it becomes very, very difficult to really make this ubiquitous without an industry effort, which is what haystacks been trying to do for, I don't know. I think John said the other day, 10 years, you know, I've been trying to get the industry to come together because this isn't, this isn't my IP or your IP.
This is our collective IP and it is necessary. Um, And the other thing that we did is we set up, but just having that static get hub database isn't enough. I need my tools to actually access that database as a service. So I know that, Hey, I've identified this thing as a fan coil. You know, what does that mean?
How does it get identified if it's a fan coil? What's it look like in haystack? What's it look like in brick? What's it look like and in Google's DBO and then what else do I need to know about that fan coil in order for it to fit one or more of those ontologies? And I need that to happen automatically, cause to expect that I'm going to scale manpower.
At a fast enough rate to be able to have teams that can deliver that model consistently. It's just, fool's gold, right? It's not going to happen. and so that's really why it needs to be a service. So those are the two fundamental reasons we started to build our own. and that comment on your post.
It was amazing how many comments I got? Hey, come join us. We're doing that too. Come join us. And that's right now. And I, I would say we're guilty of it as well. Right? I'm not an independently wealthy company who can just go, okay, we'll take all of our stuff and we'll go join you. At the end of the day, we have to deliver solutions.
And so it's expensive for me to uproot what I've done and go join somebody else. Just like it's expensive for them to approve what they've done and come join us. So I don't, think there's arrogance or anything else out there that stops the industry as a whole, from really coming together. I think it's just.
A confluence of people didn't jump on haystack as a global phenomenon. Like we should have, right. Several of us did, but there's still people out there thinking that they could be a better way. And I, and I've heard many, many times, you know, why did Google do this? I've been asked that question. I dunno, probably a thousand times what you have to understand.
It's really easy to look at what Google did right now and say they could have just done it with haystack, but the fact is they couldn't have, when they started doing what they were doing, haystack was a naming convention. It was not a real ontology. It wasn't a real ontology until a couple of years ago.
And even yet, Haystack four still isn't fully released. Right, right. It's it's released for public comment. so it's, it's a little bit unfair to say that Google did something completely outside the realm. They didn't. They needed to solve a problem and they did. And now what on release, it looks like it's a competing technology to haystack for rather than really understanding kind of how this stuff happens.
And I would say that's probably the same with the Microsoft one. It's probably the same with what the guys in South America, there's like three or four ontologies in South America. And we still don't even talk about up here.
James Dice: [00:41:29] I didn't even know about that. They're all not afraid to admit it. Cause it's like a lot of people don't.
Yeah.
Brian Turner: [00:41:36] Okay. So, there's a big problem and that's why I say we can't try to bring them all together. Yeah. We can't make them all one, but we need to do is really focus on delivering the outcomes and delivering the use cases. And then have data engineers worry about how to normalize that data. And if your owner has a specific affinity to one of them, great, let's just deliver that one for that owner, but otherwise deliver the one that is best of breed for you core to your heart, whether it's Google or Microsoft or haystack really shouldn't matter that shouldn't be what's driving really anybody's decision today.
And I know right now it's hot because it keeps coming up. But it, it really shouldn't be the discussion because at the end of the day, the ontology doesn't deliver any outcome. It only enables right. It's not an outcome. So I really love that
James Dice: [00:42:27] answer. So if that's like level setting where we're at and January 20, 21, where are we going to be at in January, 2022 with this?
What's like the next phase in your mind.
Brian Turner: [00:42:39] I think you're going to see just more people lining. More people coming together. Um, I think you'll see Google actually contributing to that alignment a lot more because in, in 1918, 1920, they were a hundred percent inward focused making sure that they could do what they could do for their own buildings, making sure they could manage their own portfolio.
Um, but I know it's an initiative for them to get alignment to they're certainly not of the mindset to force everybody into there. Domain or their ontology. Um, they recognize that alignment is a critical piece of success for them, even, you know, if, if the Google building ontology is going to be ubiquitous outside of the Google realm, then it has to be aligned with the other leading ontologies out there.
And I think that's what 21 and going into 22 is really going to see start to happen. Which hopefully will provide some comfort to the owners and the facility managers and all the people that are trying. They're thinking they have to select and choose. And, and I'm much more on the side. You don't have to choose, you know, choose partners, choose outcomes, focus on your use cases, focus on getting things done.
And make sure they use one of those ontologies. Like, I I'd hate to see somebody start, like just going off on their own and saying haystacks to restrictive Googles to whatever we made our own. That, that to me is more dangerous than, choosing one of the big names. Got it. All right.
James Dice: [00:44:09] And if anyone wants to dig deeper into this conversation, this is probably the fourth episode that has talked about ontologies.
There's number 12 with Corey Moseman. And then what we're talking about right now is Google, which was at the sewed 29. So put those in the show notes for anyone that wants to dig deeper into that. All right. let's kind of shift gears here. To the MSI. So the master systems integrator, I think this is a confusing topic for a lot of people in our industry.
And you're the perfect person to kind of ask some of these kind of, questions around sort of clarifying what is an MSI and what did they do and what are the, some of the myths around it. So let's, start with, uh, how do you guys define and describe what an MSL it is?
Brian Turner: [00:44:55] So an MSI is a little bit.
Consultant a little bit, project management, quite a bit of project management, a trainer and educator, and then ultimately an integrator and then a service provider. So, the thing about an MSI and what they're delivering is, is really a cloud enabled. building operations platform at the end of the day.
And that means that they're going to be with you as a partner for a long time, Â you know, think about when you buy enterprise software, like an Oracle or a net suite or something. You're not buying that for one year and then bidding it out again next year. Right. You're selecting a technology as something that you're going to use as part of your business, as a partner in your business for.
You know, five years minimum. I mean, realistically it might be 10 or 15 and that's really how people need to be looking at MSIs. This isn't something that you're bidding out year after year, although that's, what's been happening. And you can imagine the amount of, inconsistency and deliverable that building owners get or building operators get when they take that approach and that natural for that approach to happen.
Because so many of my size. Came up from a controls contracting world. Right. And those people were bid out every single time. Right. All I have to do is say, you have to be Niagara. All I have to do is say you have to be Allerton or ALC or Honeywell, or fill in the blank. I'll get competitive bidding.
Everybody will be great. And we'll be good. And then you get inconsistent delivery, you know, kind of the, you think logically that model didn't work in controls. For a good inconsistency, right? Certainly isn't going to work and master system integration. and so now here's the, here's the problem, the fundamental problem.
So many MSIs came up through controls, contracting or lighting integration or somewhere, right. And with one of the building systems and they struggled to give up that revenue because. An MSI scope for an 800,000 square foot building might be 700,000, might be a hundred thousand, but the scope for the controls contractor might be two and a half million.
Right, right. And the scope for the controls contractor has a lot of labor subcontractors. a lot of material, a lot of commissioning, a lot of programming, and they've built their whole environment to support that kind of revenue model. Then an MSI comes in and it's a lot of just intelligent labor. A lot of smart people, a little bit of material, maybe on the networking side, you know, maybe you've got some, some firewalls, maybe you're part of the, depending on the building layout, you might be the technology vendor also, but at the end of the day, you shouldn't be responsible for the controls or lighting controls or the elevators or any of that, because those all are systems in and of themselves that need focus and the MSI, you have to be aware and knowledgeable.
At least a little bit of all of those systems that you're integrating in order to really understand the use cases and the outcomes. And that should be your whole focus on the project. Um, so often, you know, if you think about a controls contractor, that is an MSI also they, they come in and they've got, you know, five chillers, you know, five towers, 57 pumps, and.
That plant has huge amounts of complexity and that they're sitting here trying to interact with, you know, the elevator system. That's got a little bit of problem, and now that best technician has to go run over because the chiller plant just shut down and they don't know why. And now they've got to, unscrambled tons of code to figure it out.
And so many MSIs, their best integrators, also their best controls technician. And, then that best controls technician might also get called to another project. And so you just end up with these real conflicts of interest and so much of the MSI. So really a real MSI is somebody who is hired specifically to be an MSI and not hired specifically do any of those other things.
And it, it doesn't mean they couldn't have that expertise in house. I have several clients that we don't do any controls for, even though I have controls expertise in house. But I just am there MSI and I work with what used to be my competitor. I mean, you brought this up a little earlier, right? That, that we're an industry that culturally has hated our competitors for years.
Right. You don't ever want to talk to him. You don't want to share ideas. You don't want to do anything. You'll avoid them at conferences. If they walk into the, to the bar that you're sitting at, you know, you make sure that they're not sitting at the table next to you because they might overhear some competitive advantage you have.
And that's all really BS. you know, if, anything, the tech industry has shown us that you can be very, good friends and, and in fact, you might be working for that one. Yeah. In two months or three months. Right. and so the sharing of knowledge, and I'm not saying that everything should be shared, there's certainly some competitive things that we try to keep in house, but for the most part, what we're talking about today, there's nothing new, right?
As you said, that you've had 29 episodes covering many of these things, many of the ideas that I've talked about, I'm just supporting what other people have already said on the show. So it's, it's. Once we can get past that and that we're not the smartest people in the room. I think we'll really be able to understand what MSI is and emphasize work with other partners.
So I'm teaching, for example, Johnson controls, branch, how to be a good citizen on a system. That's part of an MSI smart building platform, right? I'm teaching them how to write your programs, how to model your data, how to prepare. Your system to be part of something bigger. Right? Right. That's something new for them.
Every other job they've done before they've been the master of their domain. They didn't have to worry about anybody else. They didn't have to worry about designing their architecture to support passing data and moving data upstream. They just didn't care. So that's why I say it's part of educator when you're an MSI, you're spending time with people that used to be your competitors and you're teaching them.
How to be A good contractor on that, job. How to make the most money on that job, how to limit the callbacks and the rework effort that they might have to do. So, you know, so now it begs the question. When's an MSI, come on as soon as possible. So we, you know, we work a lot with the smart building consultants out there.
Um, and some of those consultants are becoming MSIs, which is kind of weird. And so it's forcing some MSIs to start consulting, even though I have no idea how to make money as a consultant. so the, thing is if, if a consultant works for a year or two with an owner and developing concepts, use cases, et cetera, the MSI needs to be brought in.
Basically on groundbreaking so that they can start putting a reality check to those use cases and technologies and help them understand what they actually need to install in the building to get these outcomes. Got it. Cause a lot of times the consultant will we'll work with them and they'll come up with theoretical outcomes that should be available.
They don't necessarily know exactly how to make that happen, where the MSI does have that. So, so there needs to be a good handoff. From that. And then other consultants I've seen in some parts of the world, actually stay with the job till the end, which I think is also smart because if the consultant came up with a theoretical idea that they thought would be available in three years, when the building comes to life, But as they're working with the MSI that find out that, Hey, the technology that's available as either a too expensive B too experimental or C just not available, they can reframe that for the owner, right?
Because they're the ones who worked with the owner to create that. And too often, the MSI is left holding the bag while XYZ consulting said, this could be done and we're going, but it really can. If you look at. The way, what we'd have to do to make that happen. It's just too expensive and way too expensive to maintain.
Like, why, do I want to build Frankenstein? If I wait two more years, I can put it in an elegantly and add it to your platform versus bolting something in right now that you won't want to support over time and ultimately you'll consider a failure. So, so the consultants and the MSIs have to be hand in hand, throughout that process.
Got it.
James Dice: [00:53:21] This is one of the reasons why I wanted to start with the software first and ask you about that because. I find that the projects I'm on the MSI, like you said, is, is used to, or came from this specific silo in the building. And now we're talking about breaking down the silos and that's where you sort of lose people, I think.
And so I love that answer. I don't, really have any followup questions. I feel like, again, you, you answered all of them. so talk to me about the. Service aspect of this. So I think one of the issues I see in MSIs is that our industry has a construction mindset. So we view buildings and smart buildings as a one-time event.
Right. Whereas really a smart building is an ongoing event. it's a way of life, essentially. And so when people say MSI, You go from there to MSI, to like a contractor and for your, at a contract, you need to do a construction project. Right. But, so how do you guys approach the ongoing aspect of the MSI role?
Brian Turner: [00:54:29] Yeah. So I'll pay on back to my dad. I always say we were born from distribution, so we didn't have any concept of one time. Right. So for a distributor to be successful, I needed people to keep coming back to me. Right. I couldn't just sell one project to a contractor, never see them again, or else I was dead.
Right. So I had deliver that service over and over and over again. The other thing, and we've talked about this a little bit already. It's it's this concept of, um, I want to charge. For something over and over and over again. So I want to build that use case for you. And then I want to sell it for the same price to the next guy and to the next guy, the next guy.
And when you look at what cloud services and as a service model has done, it's completely extrapolate that away. You know, you pay me a monthly fee or an annual fee and you get whatever I develop. Whether I developed it for this client or that client, it now becomes available to you because you're paying a recurring fee.
And now, because I'm getting that recurring fee from a lot of people, I don't have to charge everybody the full price to create that solution. so creating a use case for one person might be too expensive for that one person to buy. But if you're creating a use case for 20 people, then everybody buys it.
Right. And, the mentality of get in and get out. This is a construction process. Everybody's motivated and incentivized to make as much money on that one instance as possible. So that means will do as little to get signed off as possible, you know, and whether people like that reality, or want me to say it, you know, that's what keeps me popular in the media, I guess.
But that's the reality, right? I get a job for a million dollars. I have a cost of. $800,000. I want to try to make my cost seven 50. I want to make my call seven 25 because the chances that I'm going to get to increase my top line are lower than the control I have of the bottom line. And so then we start seeing people under delivering an making you catch them.
So, this is why we have commissioning agents. So I don't want to deliver everything, make your commissioning agent catch me. And then because of the nature of construction, especially in the controls industry controls, typically isn't done till after the occupancy anyway. And so everybody's under the gun to just get done and rarely do we have a hundred percent project.
And then now, then they get into service. And if you're a big organization had service contract, you love it. Turn it over to service and spend the next five years. Hopefully. Maybe bringing that building to a hundred percent, but the industry is broken. It's been broken in that way for a long, long time. and data is going to fix it because data doesn't lie when the sensor is not moving.
You know, it doesn't matter that it's physically there. It doesn't matter if it's physically wired. What matters is, is the data changing? Is it moving back? Is it getting there consistently? Is the refresh rate. Good? You know, all of those things are going to now drive those underlying systems to be better.
It's going to drive those underlying contractors to be better. It's going to drive the manufacturers of these controllers and these systems to be better. And so now we talk about service. It's no longer it's about servicing the mechanical electrical equipment. It's now about servicing those integrated systems and making sure that if I need a refresh rate of 60 seconds in order to make my enterprise a strict control strategy work, then.
That refresh rates key to now an integral piece of the system. So if that refresh rate starts to degrade, I need somebody who actually knows how to come fix that or knows how to find it, and then work with a third party to actually go do the steps to fix it. Cause the other thing is an MSI is not all things, right, but this is one mistake.
I think a lot of owners make. Is the MSI is like the all, knowing everything. That's not the case. A good MSI is really good at that domain of data. Really good at the domain of integration, really good at the modeling, really good at presenting and platform and understanding the security model and how to, secure all of that aspect.
But they're not necessarily experts in why the controller on the elevator is not operating, right? Yeah. You got to inform the elevator company like, Hey, these are the things we're seeing. These are the symptoms we're finding. Can you figure out how to resolve it based on what I can give you right now, the more, the longer I interact with elevators.
The more intelligent information, we'll be able to give the elevator company to be more proactive or, precise with their, with their troubleshooting. Um, like in mechanical, I feel we can be fairly precise with the amount of knowledge we have, about mechanical systems and what's going on from the data we get.
But on an elevator, I I'm less precise. Right. But over time, As a good MSI, we'll get more and more precise and helping these service providers really impact the buildings. Um, and I think that's where if you look at what's an MSI and NSI has all of those things, but a key part is that service provider, if you're delivering a platform, that's going to be there for a long time.
You should also be expecting that you're going to be delivering a service to help them maintain that platform, understand the data that's coming out. Add additional. Use cases kind of cultivate that dataset. Um, you've been in the industry for 10 plus years. The first data set that you came in and the amount of actionable information you rolled to create from that.
Is greater today than it was 10 years ago. And so if you can imagine that we're kind of at the infancy of really bringing all these data sets together and aligning them strategically within the building and the spaces they serve, the amount of information that we're going to be able to create from that over the next 10 years is, is unknown.
Right. And so if you think that you're going to do a construction project and just. Buy a smart building and set it and forget it. Get through the warranty period and disappear as an operator that you won't need that MSI anymore. And as an MSI, you have the culture of no, I'm moving on to what's next.
I'm not going to take care of what I've done. It's going to fail and it will just, the industry itself won't fail, but the sooner we can rationalize that the faster it will grow.
James Dice: [01:00:40] Beautiful. All right. All right. Let's let's wrap up here. What are you excited about? This is the first interview on the podcast for 2021.
Uh, what are you excited about
Brian Turner: [01:00:49] for this year? I'm excited to be first in 21. That's awesome. So, uh, yeah, I'm optimistic. I feel like 2020 was full of doom and gloom. You know, from our personal perspective, 2020 Q1 was the biggest Q1 we'd ever had in the history of our business.
And, and then, you know, pandemic hit shut downs. our two biggest, markets that we're in California, in New York, effectively, completely shut down. So, um, yeah, it was kind of doom and gloom. You know, we had to go through a period of, you know, salary reduction and then.
workforce reduction, you know, in Q3. And then we started to see that come out. Right. And so it was a, it was a rough rough year. And fortunately we came out, we came out okay. And, and profitable. And those are, those are all great things. When I look at at 2021 is we now have been level set.
the market is what it is, we've accepted it. we're hoping that, the pandemic will start to ease and the restrictions will start to ease. But at the end of the day, we now have strategies to help buildings become better to help the healthy buildings initiative actually take action.
And we're seeing a lot of momentum there. So I'm excited that You know, what was going to take probably five to seven years to really take off, that's just been moved forward. Um, and so we're, we're excited about all the opportunities and. Real building owners, real people are looking at this the way they used to Juul over marble, um, on their entryways.
And, and so I think, yeah, we're now top of mind, we do a lot of retail. Yeah. And I feel like our business has been moved from back of house to front of house. so it's pretty exciting from that perspective. Um, it's a conversation every day rather than every week. yeah, so it's exciting.
James Dice: [01:02:35] Awesome.
Well, thanks Brad. I appreciate you coming on the show and, uh, we'll talk to you soon.
Brian Turner: [01:02:41] All right. Thanks James.
James Dice: [01:02:42] All right, friends. Thanks for listening to this episode of the nexus podcast for more episodes like this, and to get the weekly nexus newsletter, which by the way, readers have said is the best way to stay up to date on the future of the smart building industry. Please subscribe@nexuslabs.online. You can find the show notes for this conversation there as well. Have a great day.
Head over to Nexus Connect and see whatâs new in the community. Donât forget to check out the latest member-only events.
Go to Nexus ConnectJoin Nexus Pro and get full access including invite-only member gatherings, access to the community chatroom Nexus Connect, networking opportunities, and deep dive essays.
Sign Up
Nexus Labs exists to move the smart buildings industry forward, without the fluff.
On Wednesday, we send out the renowned (and free) Nexus Newsletter.