Back to School | IT in AV
Last month we talked about mental health and the 24-hour challenge. Before I go into this month’s topic I just wanted to remind you about last month and hope that you took the 24 hours challenge. I picked a Sunday for mine which meant I was stepping away from #AVintheAM that week. I picked this day as it is a day I find myself the most active on social media. I spent most of the day with my family which was a much-needed mental health break. Now if you would like to share your 24hr challenge with me please tag me on Twitter. Now onto this month’s article.
It is August which means we are heading back to school or will be very soon. What does this mean for our schools and IT? As we know our campuses will be busy again with students walking the halls, hanging outside, and learning in our classrooms. We will have faculty members putting those summer upgrades if we were able to do any, to the test. August might be one of the busiest for us higher education technology managers as we switch gears. We are going from upgrade/patching/installing to support/training/research/designing. This time is another good time to take a mental health break before diving into our next cycle.
I know I have discussed this topic before but let me bring it back up. As we know during the semester we do not always get time in rooms to test and address issues. This is why we need a sandbox environment. We should have at least a rack in our shop that mimics one of our classrooms. This sandbox environment is where we need to develop our next version of code. If you are writing code and sending it out into production without testing it first then you are setting yourself up for failure. Not only is a sandbox environment a location we should be testing out our code in but we should also be testing out updates, firmware, and patches. I know there is a saying in AV of ‘if it not broke don’t break it’ when it comes to pushing out firmware. We should not look at firmware like this as many times there are features in the new firmware we need, mainly for security. Does this mean that we push firmware out without vetting it first? No, that is why we need the sandbox environment. We can push the firmware out to the controlled environment to see how it impacts our equipment. A sandbox is not just a place for us to test the software side but it is also a good place to test out hardware. Yes software-defined AV is replacing most of our hardware but we will always have some hardware that we need to manage. A sandbox allows us the freedom to bring in new equipment and test it out. We can push the boundaries to try and advance our classrooms with little to no risk to our current production environment. We can use the sandbox to see what type of impact it will have on our network, what security issues there might be, how we might deploy it to classrooms, etc..
Now that I talked about how we can use sandboxes, let's quickly talk about this in relation to other members of the IT team. If we can set up a sandbox, this will allow us to have a ‘safe’ place where we can test new hardware and software and get feedback from networking, security, and other stakeholders. Many times the pushback we get from other members of the IT team is due to the impact on the production environment. If we have an environment where mistakes can happen without causing issues to the production environment then it will be easier to get the buy-in from others. We need to remember we all are here for the same goal, to educate our students, by providing the proper tools and resources. These tools and resources need to work cohesively with each other and not become a game of passing the buck or kicking the can down the road.
In conclusion, getting a sandbox environment up and running does not take a lot. I am sure we all have a rack sitting around that we can put some spare gear in. The environment does not need to have every gear that is out in production on day one. Try and build it slowly while working with the other stakeholders, like networking and security.
