Engineering AV Control Like a Software Developer
With the growing belief in the diminishing value of custom AV systems, control system programming and control system programmers are finding their place in the industry being seriously challenged. Despite the fact that the AV integration industry can tailor and personalize solutions to offer a user experience that addresses specific user needs, many technology managers are opting for the consistency, simplicity, value, and ease of deployment found in configured or even closed systems that involve limited or no customization. What is behind this shift in mindset from custom to standard solutions?
As complex systems have become streamlined due to the advances in technology, the investment in APIs, control modules, and drivers by manufacturers, and the natural simplification of components, the mountains that need to be climbed to make integrated AV systems work are not as steep and demanding as they used to be. On the flip side, new challenges and opportunities are increasing tenfold by the growing number of systems that need to be managed and maintained. In years past, it was a lot for an organization or campus to have more than 200 technology-equipped spaces. Now, such deployments aren’t unusual at all, and the ratio of “hang and bang” systems to custom-integrated systems has also changed dramatically. While custom-programmed systems used to dominate the landscape of an organization’s technology spaces, they are now becoming the minority.
The AV industry started out making complex, intimidating technology simpler and easier for users to operate in order to serve specific needs, provide added capability, or offer convenience. While this still remains the intent, the desired result is not always attained. Too often systems are designed, installed, and programmed without really understanding the true needs, desires, and expectations of the users. This is not intentional, but more so a product of the typical approach to AV projects.
Control system programming and the role of the control system programmer have been, and in many cases, continue to be a small consideration in the overall outcome and success of a project. While the sentiment grows that control system programming is too complex, too costly, too unpredictable, and ineffective, causing clients to lean in favor of configured or static solutions, is it fair to judge the outcome without taking some responsibility for the result?
Upon reflecting on the process of control system programming and likening it traditional software development, significant differences can be identified, and the flaws can be correlated to the growing dissatisfaction of the outcome. Typically, an AV project with an integrated system that involves control system programming offers little to no voice for the control system programmer. Often, the project is planned, designed, bid, sold, and scheduled without involving the entity responsible for defining and implementing the functionality. The control system programmer must then assume the role of a technician, piecing together a solution to make the system work with limited understanding of intention and expectations, under the pressure of a project schedule—rather than being a software developer focusing on how to provide an ideal user experience.
From a software development approach, the process would involve key steps geared toward planning for the desired user experience. These include understanding the client; exposing, clarifying, and prioritizing needs; and defining user profiles or personas. As needs are identified, expectations are defined, and requirements agreed upon; wireframes, mockups, and demos modeling potential solutions would be presented, reviewed, and ultimately approved using an iterative process of making adjustments along the way based on client feedback. As the software development process evolves, confidence grows that all parties implementing the solution will address needs, soothe pain points, and successfully achieve the desired outcome.
All throughout, the software developer is involved in discussions with other key parties who can shape the outcome, to ensure that the roadmap is being followed. A key difference in the software development approach versus the traditional AV control system programming approach is that the hardware, system design, and other elements of the system are defined as a result of the software development process, rather than the other way around, where limitations and constraints in the system design and specification can hamper the ability to carry out the software solution. Additionally, added care and consideration for short-and long-term support, maintenance, and upgrades are staples in the software development model, and rarely exist in typical control system programming projects.
Although the shift to less custom-programmed and more configured standard systems is a reality, and control system programmers must up their game and demonstrate added value, the industry is long overdue to consider a new approach to control system programming. By changing the mindset and approach to projects using a software development spin, control system programmers will have the opportunity they need to step up, show what they can do, and earn the respect and prominence in the industry that they had previously held.
