In this episode of the Smart Buildings Academy Podcast we look at seven key concepts that every building automation professional should know about information technology.
Click here to download or listen to this episode now.
Resources mentioned in this episode
Show notes
Phil Zito 00:00
This is the smart buildings Academy podcast with Phil Zito Episode 227 Hey folks, Phil Zito here and welcome to Episode 227 of the smart buildings Academy podcast. And in this episode we are going to be talking through seven things every VA s professional should know about it. All of the resources mentioned in today's podcast can be found at podcast at smart buildings academy.com Ford slash two to seven once again, that is podcast at smart buildings academy.com Ford slash two to seven. And this week's podcast is brought to us by our it for bs professionals course if you're looking for a fully online course that will teach you everything you need to know about networking databases, cloud server, cybersecurity API's and much more, then be sure to check out our it for bs professionals course you can find out more information about it at podcasts smart buildings academy.com, forward slash two to seven. So Lately, I've been seeing a lot of questions coming around information technology. And this is a topic we haven't talked about in a long time on our podcast. So I thought to myself, what are some of the common misconceptions and misunderstandings that we as an industry seem to have around it, I came up with seven things that I believe every building automation professional should know about it. So I'm going to take you through each one of those things. I'm going to talk about why it's important. And I'm going to talk about what you can do to remedy or use that thing to your advantage. Alright, so the first thing that I want to talk about number one is it speaks a different language. If you have ever been working with someone around building automation, or hpac, and they didn't speak the building automation or HVC language, it became readily apparent that they didn't know what they were talking about. Or at least that was the perspective you had. I would argue that there are plenty of people who maybe they understand thermodynamics, maybe they understand psychometrics, maybe they understand controls theory, but because they are not a building automation professional, they may not have the exact same language. So for the longest time, and this is kind of embarrassing, but it is what it is, for the longest time even holding a PMP certification, which is a project management certification. Even having ran a very large ops team, I would say point of completion instead of percentage of completion for PRC. And so even though I can explain project management, even though I can teach people in minutes how to go about forecasting and scheduling labor, people would hear me say point of completion instead of percentage of completion. And they would automatically dismiss anything else that came out of my mouth. It was just a habit, I don't even remember where I got this habit of saying point of completion, even though I knew it was percentage of completion, I would still say it. And I think I did that. Also with hva. See if I remember, I called it heating, ventilation and, and cooling instead of air conditioning, if I remember correctly, I would say heating, ventilation and cooling instead of heating, ventilation, air conditioning ers, one of those I had it crossed, whichever way, I don't remember exactly what I was doing. But the thing is, is even though I've written books on building automation, even though you can listen to 227 episodes of me talking about building automation, and controls theory, folks would hear that and they would dismiss everything else I had to say, even though I'm a subject matter expert on those topics. So it becomes very important that if you are talking to it, that you speak the same language as them, this is the most important thing that our students can take out of our it course, I know some of you would say, well, wouldn't subnetting or IP network design or IP troubleshooting be the most important thing. And the reality is, if you're doing things right with it, oftentimes you're not gonna be doing the work. Very few IT departments are going to let you mess around with their switches or routers or servers or let you stand up a virtual machine or have database cluster. The reality is they're going to do it and you just simply need to be able to explain what you need done. And thus, if you aren't speaking the same language as it, you're going to be immediately disqualified. Like, if you take one thing
Phil Zito 04:39
out of this episode that will significantly impact your career is to be cognizant of words you're using. So for example, understanding that you're asking for a network trop understanding ports, understanding access links versus trunk links and understanding hosts versus saying, hey, I want to add my device to your network. So Say, Hey, I want to add a host to your network. So I need a port. And I need to know which port that's going to be that the access links going to be available from. And here's my information, and they'll do the rest. But that conversation is very different than just saying, hey, I need an IP address, that can trigger a lot of insecurities, a lot of confusion, and just a lot of distrust in the IT department that doesn't necessarily have to be created. I've noticed that after folks shift their language to adjust based on who they're speaking to, and this applies not just to it, this applies to, you know, selling retrofits to business leaders, going and communicating to energy managers how you message and the words you use. And the terminology used is critically important. This is something I'm constantly improving on I struggle with all the time, because I very much if you followed me for any amount of time, I'm very much a stream of consciousness, teacher and speaker. And sometimes that results in really, really good stuff. And it's raw, and it's relatable. And you feel like you and I are in the same room having a conversation. Other times it's an absolute cluster. And I say stuff that I listened to after the fact and I'm like, oh, man, that is really, really bad. Fortunately, having done this for as long as I have, the amount of times the bad stuff happens is significantly less than the good stuff. But if you take one thing from this, learn to speak eyeties language be cognizant of the words you're saying, saying slow down, and speak in terms that they understand. Number two, who you're speaking with, often dictates your success early on, when I was teaching information technology to folks, I would teach them the concept of the ultimate question or the single question or the one question, I called it something like that. And the concept goes like this, what would have to happen for x to be true? And what I mean by that is, you know, what would have to happen for me to get an IP address? And by asking this question, you're often able to determine what exactly needs to happen in order for you to get an IP address or to get a network drop or to get a route setup or to get a virtual machine stood up. Problem is oftentimes, we as building automation, professionals do not spend a lot of time understanding our customers IT organization. And thus, we'll be speaking with someone who has almost zero influence if if not zero influence on the problem we're facing. And sometimes they won't even tell you that because, you know, they are so happy to be doing something different than the day to day monotony of their job, that they're going to ride that kind of train with you all the way to the station, and you're going to get to the station and realize no one's there at the station to help you accomplish what you need. So it's really critical to figure out, am I trying to solve a network issue, but I'm dealing with a system admin, or am I trying to deal with standing up a database, and I'm dealing with network administrator and network engineer, you know, if you're talking with a network engineer, that's great. You know, if you're trying to solve a network architecture problem, if you're trying to get a virtual machine stood up, that's probably not the right person. So knowing who you're speaking with is going to dictate your success, it's going to be critical to ensuring that you understand what you need, and that you are getting what you need, by connecting with the right person. So you can get I, I'm not going to tell you you can't, you can get a server stood up by working with a network administrator,
Phil Zito 08:58
that network administrator eventually will go and talk with the system administrator and the system administrator will talk with the network administrator and they'll go back and forth back and forth and eventually becomes enough of a headache, you'll probably get your server stood up. However, if you'd went to the system administrator in the first place, and dealt with that person in the beginning, you would significantly reduce your amount of time, folks will often ask me how are you able to go and meet with an IT person and by the end of the meeting, have everything agreed upon that you want? Well because I'll go to the IT person and then I will usually pivot from that it person to the correct it person. And then I will work with them. I'll explain why I'm doing this. I'll explain the reason why they should support it and we'll work through their concerns. I'll address the common concerns that I know most it people have on whichever topic it is. And then we will go from there and usually I can get same day approved. If not usually at least less than a week approval for the it requests I'm making. And understanding that IT personnel are going to break out into a couple groups. And here's the most common groups, right? You'll have frontline support. These are known as helpdesk folks, you'll have system admins, these are folks who are responsible for standing up virtual machines, both on the client as well as the server side, you'll have network side of folks, you'll have administrators who administer the day to day network, and you'll have engineers who architect the network, you'll have cyber security folks. At self explanatory, you have database folks, that's self explanatory. And then you'll have system or enterprise architects. And these are responsible for designing and maintaining system standards across enterprises and business units. The next thing, so number three that I want you to take from this episode is it gear is often installed after the project. This is not been a big deal historically, because most of our it drops have been, you know, to the supervisory device or to the servers. And we've been able to survive by going in basically putting in a wireless router or just doing partial commissioning. But now that we've got IP controls, now that we're using a lot of virtualized systems now that we're using cloud based systems, we're finding that we're running into barriers for proper commissioning, proper execution and proper closeout of a project. So understanding that it gear is often installed after the project is going to affect how you implement your projects, especially if they are it heavy, like if you're doing an IP controls architecture. And it is mainly a star pattern. And for some reason, using a star pattern instead of, you know, a daisy chain or ring pattern. But let's just go with it. Right, let's say you're using a star for 1000 controllers, I don't know why you would do that. But let's say you are, well, you kind of need some switches in order to go and do that. And considering that the average switch stack and we're talking it switch stacks, is going to be limited to somewhere around 700 to 900 ports, you're going to find real quickly that you can be using a lot of IT resources. problem is these IT resources are not going to exist on the job yet. So you're going to have to resolve that issue. And that is either going to be through project communication and letting the project team know that hey, if they really wanted on the it network, not much you could do until the switchgear and the IDs and MDs are all stood up and functional. That being said, there are some solutions you can take outside of an IT gear centric solution, which may be is industrial switches that later get plugged into it switches, maybe it's an OT versus an IT network. There's a variety of approaches you can take. And this is true for IoT network gear. This is true for cloud support. This is true for virtualization. This is true for databases. This is true for cybersecurity setup, all sorts of IT issues both I can be caused by not having the it gear on the project, but can also be resolved by being cognizant that the it gear is not on the project. So having that awareness is going to shape your project planning. And it's going to shape how you communicate to your project team. Now another thing to be cognizant of, is number four that it source can be or it can be outsourced.
Phil Zito 13:42
And it also can be a cost center. Now these are not mutually exclusive, it can be outsourced at a cost center at the same time, but I'm going to talk about them separately. The first thing is it can be outsourced. Oftentimes when you're dealing with large enterprises, you'll have something like Verizon managed services. And so when you're going and asking for an IP, an IP address, or you're going in asking about having a port activated or something, you aren't talking with the customers it group, you're actually talking with a managed service provider. So you need to be cognizant of that because there are different processes in place. In order to actually go and work with a managed service provider. Oftentimes, you have to do a requisition request. So you have to go and basically submit a request to the customer who then will submit a request to the MSP managed service provider, and that person will then go and execute this can add several days worth of delays into common tasks, so it's important to be cognizant of it. Additionally, as we move to IP controls as we move to more virtualization, it can be a cost center. What that means is that we can be charged per port we can be charged per service, we can be charged by bandwidth. There's a variety of charges that can be applied in order for us to access the it now Work, basically the it network, the compute resources, the storage resources, those all can be metered services that we can actually pay for from a consumption perspective, thinking like in an energy management perspective, right, you have consumption and you have demand. So we can be paying for in a consumption perspective, based on what do we consume of bandwidth? Or what do we consume of resources, or we can pay on a capacity. So how many IP addresses how many ports, how many virtual machines, so there can be a capacity aspect to the cost, or there can be a bandwidth aspect to the cost. And sometimes there can be both. So be cognizant of that, because that's something that can blindside you, if you're working on a project, especially a corporate project. And you have to go and use it resources. And all the sudden there's these costs that someone is trying to figure out who's going to bear that usually it's fall on the facility department. But sometimes it can fall on the contractor. Now, speaking of contractors and projects, we've assumed that we've won the project, but I've been involved in quite a few pursuits, where it actually disqualified people. One of the most complex pursuits had been involved in was with a major oil and gas provider doing their headquarters. And what happened was, they actually did a white box and a black box assessment of the building automation system, white boxes, where they openly assess the cybersecurity of the system. And then black boxes where they attempt to analyze the cybersecurity of the system as a quote unquote, hacker to see if they can break in, we had to go and capture network traffic and data traffic, we had to give database analysis, we had to explain our patching policy, we had to explain our software management policy, our software development lifecycle, all of this had to be explained, several of our competitors could not and they lost a $13 million controls project because of that. Now that may seem extreme. This is a corporate headquarter for oil and gas. Of course, their cybersecurity, of course, they're very focused on this. That used to be the case. But nowadays, you were actually seeing it becoming a decision maker at lower and lower volume projects. I've seen a project recently that was between 250,000 and $500,000. I'm not going to get more specific on that for commercial real estate building, where it was one of the deciding factors, because they wanted the system to be able to interface with the tenants so that the tenants could have a greater tenant experience. And because of that
Phil Zito 17:39
they were worried about how will the system securely interface with the tenants network side. And so they analyze the network architecture and made a decision based on how securely the proposed architecture was implemented, on who they were going to allow to bid the project. So I T can determine if you win a project and you need to be cognizant of that. Because if you're not, and I fear that this is going to become more of the norm as we continue to move towards analytic solutions for IQ monitoring, as we start to move more towards outsourced maintenance solutions, as we're trying to figure out, how do we do low or no touch facility service support, which is something I'm going to discuss in a future episode is how to do low or no touch service and support of a building automation system. But as that becomes more of the norm, rather than the exception, we're going to see that it becomes more heavily involved in project. At the least it could be submittal approval and architecture approval. But I think you will see even more so that it will be approval of who can actually bid on the project. Here's a controversial lesson, our thing that I think you should know about it, is that it can no less than you know, oftentimes we can feel intimidated. We walk into a room with it. And we see these people who have been doing networks for 2030 years. And we feel like really what leg Do we have to stand on? Sure. If we're talking about h facture. If we're talking about building automation, sure, if we're talking about controls theory, we would absolutely feel comfortable. But we don't feel comfortable talking to these people around networks and virtualization. And we don't feel confident because they've been doing it 2030 years. So they must be the expert. The reality is that is not the case. You know, I've seen this on our own business where folks will come to us and they'll say, I'm not sure if we should train this 20 year person. I'm not sure if we should even assess them because one of our processes is Do a skills assessment prior to training to ensure that we know what people know and don't know. So we select the proper courses. But they'll say I'm not sure we should put this person in, they've been doing controls for 20 years. And we go to find out that they've been doing controls for 20 years on the same commercial office building working on pneumatics. That does not equate to 20 years of controls experience. I recall, I just finished my CCD and or my CCDA and my CCNA, which are pretty low level Cisco certifications, they're not very high, not terribly difficult to get. And so thus, I became the quote unquote, network expert. And I ended up going for an MLB, a medical office building, 300,000 square foot medical office building, designing the it network for them. It was very concerning. I walked into this meeting, and there are folks who had 20 years of experience as network engineers, and network administrators. But for whatever reason, they did not know how to design a collapsed core network. Maybe they did, and they were just lazy. And they said, Hey, we're gonna let them do it for us. Maybe they didn't, maybe they had been just fooling their way through the network for 2030 years, I don't know, all I know is that I was responsible for designing the switch layout, the router layout, the access layer, at the core layer, the distribution layer, actually, there wasn't a distribution layer, because there was a collapse core, which actually blends the core and distribution layer. But I was responsible for laying these out during port selection, everything. And it became readily apparent to me as I started to have conversations with these it folks, they didn't know as much as I did. They knew about basic networking, obviously. But they hadn't kept up with the times. And so while they were looking at some legacy, I
Phil Zito 21:55
it architectures, I had recently been trained on more recent it architectures, which put me in a place to be able to create a network design that was based on newer technology. So just because someone has more time than you, and this is true about building automation, that's true about anything I never consider. And this is a bold statement, but I never consider how long someone's been in the industry. I never consider that. Because you could have someone like myself, who had been in the industry for three, four years, but had worked on data centers, prisons, airports, hospitals had done all these major retrofit projects, all these major integration projects, worked with all these different systems. And because of that my experience level would easily compete with some 20 year, folks. And I know that's a bold statement to make that early on in my career. But that was the reality. I didn't know it at the time. But that was the reality. And so what you should consider is your own known experience. Do not assume that just because someone has time that they know more than you. And the final thing I want to leave you with, this is something we don't consider too often. It's that it can be another source of funding. I didn't coin this, and I didn't first say this, but I've been hearing it being said for several years. Now, I wish I knew who first said it. So I could give them credit. But it was basically the premise that eventually it is going to run h fac it is going to run the facilities group. Now does that mean we're going to get rid of facilities, folks, and we're not gonna have engineers or anything like that anymore now. But what it does mean is that it at several of your customers is becoming increasingly enmeshed with building automation, whether it be because of the analytics, whether it be because of the IP architectures, whether it be because of all the cloud stuff and the virtualization, for whatever reason, it is becoming more and more engaged in building automation and facility operation. So that leaves us to a potential solution to a common problem, which is who is going to pay for this. Now, oftentimes, your competitors are going to go direct to the facilities budget. And that's all well and good. But if you go back and you do a little bit of historical research, you'll recall that IP controls and if I'm wrong on this, correct me, but I'm pretty sure my facts are correct. IP controls really as as well as I understand it came out of Canada, really with Delta controls and Cisco partnering on a push to get IP controls specified in government working Canada. Basically, the premise as I understood it at the time when I was doing competitive and analysis of this was that Cisco figured out, hey, we can go and take the infrastructure costs, you know all of the electrical sub cost of installing controls. And we can take that out of the controls budget, and we can place it into the IT budget, which will make our costs appear to be lower, because what happens is, it switches all of that gets paid out of the FF and E budget, towards the end of the project, it does not typically get paid out of the construction project budget. So by taking that cost and transferring it to the FF and E budget and working through eyeties budget, they were able to artificially lower the cost of delta controls bid. Now this went on, as I understand it for two to three years with IP controls getting flat specified in the Canada market. And for those of you who are in Canada, if I'm improperly communicating this, by all means, feel free to correct me. But this is based on my own research and experience with the market at that time. So what happened was, you had these Delta control IP controllers, and you had these
Phil Zito 26:15
IP control solutions being flat SPECT and winning bids, because they were lower, at least from a perceived perspective within the market. Now, what this ended up doing was, this is really what drove the push for IP controls. Having worked at a fortune 500 company at the time, I will tell you, there was always conversation in the higher levels of leadership about how are we going to close this IP control solution gap, we're losing to flat SPECT IP controls, how do we close this gap? Now, eventually, people became aware that this was just basically a shell game of moving one part of the budget to a different part of the budget. And that gap got closed, as far as I know. But it brings into an interesting point into this conversation, which is, it has budgets that are different than our budgets, and properly utilize, they can be used to go and supplement our costs on our project, whether that's through compute resources, whether that's through network resources, whether that's through our electrical costs, there's a variety of ways that you can work with it to have another source of funding, will this be 20 30% of the project? Like it was on these initial IP controls projects? No, probably not. But if you can say five, even 234 5% off the cost of your project that puts you in a uniquely competitive scenario, compared to your peers. So it is something to consider as you look at strategies to approach the market. Alright, with that being said, I want to thank you all for listening to this episode. Like I said, in next week's episode, we're going to be looking at low to no touch service solutions for building automation professionals. I think that that is going to be a very, it's going to be a message that I believe aligns quite well with the market, especially since it looks like we're going to be going back into lockdowns. I sure hope not. But it sure seems like that's going to be happening. And we as an industry need to be prepared on how can we continue to deliver value? And how can we continue to gather revenue in that market shift and low to no touch services seems to be a good solution to that problem. So as I mentioned, everything is available at smart building or at podcast that smart buildings academy.com forward slash two to seven. Once again, that's podcast that smart buildings academy.com Ford slash two to seven, and really encourage you to check out our it course if that is a gap that you are looking to close in your skill set, you definitely need to close it. And the last thing I will leave you with, keep this on your radar, our upcoming Black Friday to cyber monday sale 20% off all courses except for our lab course. So lab materials will never be discounted. They're already pretty much at cost. But all courses 20% off on Black Friday to Cyber Monday. That cost discount will automatically be applied when you purchase a course. So nothing for you to do on your end. So pay attention to that. You know, we only do this maybe two to three times a year if that. So thanks a ton. And I look forward to talking to y'all in next week's episode. Take care
