<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=2854636358152850&amp;ev=PageView&amp;noscript=1">

Hey folks, Phil Zito here and welcome back. In this post, we're going to be covering how to work with IT groups. So, below you will find all the resources we reference in this post 

Up to this point, we have been talking about managing our building automation projects, we've talked about releasing from sales to operations, doing submittal creation, lining out our subs, installing programming, graphics, etc. Now we're going to touch on a topic that wasn't really that big of a deal when I first started over a decade ago in this trade and has become a bigger deal. We're going to talk about working with information technology groups. 

 

The first thing we need to understand about information technology and information technology groups, and working with them, is that it's going to be different depending on three factors:  

  1. What type of project is this?  
    1. This will determine who you have to get involved with. There's going to be a different level of involvement on a simple, new construction project versus a complex, retrofit at a hospital. 
  2. What type of building? Is this an existing building? Is this a new building?  
    1. Is it a hospital? Is it an office building? Is it a school district? 
  3. What type of technology?  
    1. Are we using IP controllers, remote access, wireless networks, etc, that's obviously going to have much more IT involvement than a standalone wall-mounted thermostat that's electromechanical in nature. 

 

IT Groups

So, how do we work with these IT groups? Well, first, I want to walk through what the IT groups are.  

  1. The traditional Help Desk. These are the folks who are going to help work through any base level IT issues. You're not going to typically get involved with help desk except for in like, service environments where you're trying to troubleshoot potentially some IT issues and their level one support.  
  2. Then we have the System Administrators. You will typically get involved with these folks when you're standing up virtual servers, servers, standing up desktop environments, trying to get added to the Active Directory for like DHCP, stuff like that.  
  3. Then we have the Network Group. This is both the engineers and the network administrators and designers. You're going to get involved with these folks, when you need IP addresses, when you need routing, when you need to set up a wireless network, when you need to set up your IP control network, etc, and somewhat on remote access.  
  4. Then we have our Cyber Security Group. These folks are responsible for security policies, procedures, and controls that are implemented across information technology systems. You would get involved with these folks when you're trying to remotely access the network, or maybe get your building automation system approved to sit on their network.  
  5. Then we have the Database Team. These folks are going to be responsible for managing the database. So, if you're going to manage the database, you're going to stand up databases, you're going to virtualize your database, anything database, that is going to go to the database folks.  
  6. Then there's Enterprise Architecture. You don't really get involved with these folks, unless you're doing like complex, super smart MSI work. If you're doing super complex, tying into business systems, and building systems and all these things, then you'll get involved with those enterprise architects.  

 

Now let's walk through the journey of our project. Let's touch on a couple projects here and what IT involvement may look like. So, you have a commercial office building. You have a baseline IP controller on the roof on a rooftop unit, and you have a bunch of VAV boxes on MSTP wiring.  

 

You need an IP address, and this commercial office building doesn’t have an IT group. So, guess what? You're going to be most likely calling the cable provider and getting an IP drop for you if you want remote access. Otherwise, you're going to be creating your own IP address with your own private subnet. If you want to learn more about IT, you don't understand what subnets are, private subnets, etc, then definitely check out our IT for BAS Professionals course 

 

Alright, that being said, let's now talk about if we had a major building, and there were IP controllers, hundreds of IP controllers, and we wanted remote access, a virtual server, and a database. How would we coordinate this?  

 

Well, oftentimes you have an issue. You have this new building going up, and there's no IT involvement. Typically, until Certificate of Occupancy, they will not start to move in their IT gear until that is approved. At that point, they'll start to move in their IT gear, which means your involvement with IT is largely dependent on the warranty phase.  

 

So, you have this building, you don't have IP addresses, what do you do? You don't have virtual servers, what do you do? Well, you have to stand up all sorts of temp networks. Sometimes you have to physically stand up a temporary network. Other times, you just have to use some unmanaged switches and give some temporary IP addresses to your devices.  

 

At some point though, during this process, and it's normally during 70-80% of completion, you're going to have to get involved via the owner's rep with the IT group. You're going to have to work with them to get your network set up. So, you have to determine your IP addresses, you'll have to subnet out, figure out what your IP net address range needs to be, and then go to them and present your requirements. It's a big thing with working with IT these days.  

 

You used to go to IT and tell them what you needed, and they would do all the work for you. Nowadays, it's largely where if you don't do the pre-work, and tell them, “I need this subnet with this range, and this many hosts, etc,” they're typically going to just bounce you back and you're not going to get what you need. So that's just working with the network folks.  

 

Now we have to get our server. We have to work with our system administrators. I hope at this point, you're seeing why I took the time to tell you about the different roles because if you go the network guy and you try to work on a virtual server, they may entertain you but you're not going to get anywhere. They have zero approval to stand up a virtual server for you, and zero influence over it. Oftentimes, they may not even know who the system admin folks are.  

 

So, you've have this virtual server you need stood up, or maybe you need some sort of software appliance added to something, so you need to work through system admin folks, and the requests go through them. Now sometimes you could just bring on your own server, and then just transfer that over to them. Sometimes you have to use the IT group server and their requirements. So be cognizant of that.  

 

Just because the spec says you should use XYZ from whatever manufacturer's catalog page, does not mean that complies with your customer’s IT policies. I want to repeat this: 

  • Because the spec says you need this type of server, or you need this type of switch, or you need this type of network, that does NOT necessarily mean that the spec is in compliance with the IT requirements of your customer.  

 

So, you really want to narrow those IT requirements down, typically through an RFI/RFC process through the contracting tier to ensure that you understand, “We’re providing a physical server, does this meet the standard that the customer would accept?” Otherwise, you'll most likely not be able to get the server on site, get the server supported, get the server set up. You often will not be able to do that without meeting the standard of customer expectations.  

 

So, from there, we have our database, and we have to stand up the database. Now in order of importance, I'm kind of listing out how this goes. We typically will get approval for network stuff right away. That's usually the first thing that goes in. Servers and databases tend to follow that, which is typically immediately followed by cybersecurity policies and appliances that get put over that.  

 

So, if we think of the network as the bones, we think of the servers and databases as the muscles, and then cybersecurity and administration as the skin. So that's how this creature gets built from an IT perspective.  

 

So, we talked about IT networks, we talked about servers, we talked about databases. It's at this point that any cyber policies, things that need to be applied, are implemented. Specifically, we're going to look at starting to close ports down, logical ports. We're going to start to look at making sure our systems are patched, at least to the level they can be. We're going to start to make sure we have certificates for authenticated communication installed, and we're going to start to implement whatever other cybersecurity policies, procedures, or appliances are required.  

 

So, policies are things that need to be done, procedures are how to do them, and appliances, also known as controls, are the logical administrative or physical implementations that are going to secure the building automation system and secure the IT network and IT assets.  

 

So there you have it, rather short post, but it should give you an approach on how to think through Information Technology, who you work with, and how you're going to approach them. 
 

We definitely have a lot more resources on information technology in our IT for BAS Professionals Course, as well as looking at our it Podcasts and IT for BAS Mini-Course 

 

Thanks a ton for checking us out. Take care! 

 

Resources referenced in this post 

 

Phil Zito

Written by Phil Zito

Want to be a guest on the Podcast?

 

BE A GUEST