Programmed vs. Configured Solutions: Which Approach is Best? (As appeared in InfoComm’s All Voices Blog on May 10, 2017)

AV control system programming is still a highly-valued offering with clear advantages, but its future is becoming more ambiguous as the industry’s understanding, needs, and expectations evolve. While many clients value a high degree of customization, they are burdened with the time constraints and costs of highly customized offerings. As a result, many are gravitating to “off the shelf” or “configured” solutions that do not require the perceived challenges of implementation, time requirements, or expenses.

This is not a sudden shift or hot trend.  There have been many attempts throughout the years to simplify the effort of control system programming by offering fixed system designs, programming templates, or “wizard” style processes. The features and functionality of these “no-programming required” solutions are constantly advancing and creating a presence in the control space.  As such, configuration seems to be here to stay.

While both programmed and configured solutions are both sustainable options, it is important to understand the basis, involvement, and impact of each. As opposed to programmed solutions, the configured approach does not require the involvement of a highly sought-after skilled programmer. Configuration is simple enough for an engineer, technician, project manager, or technology manager to do themselves, given they understand how the system is intended work.

If configuring systems is easier, cheaper, and quicker to implement, why has this approach not become mainstream? And, as result, why do programmers continue to be in such demand?

The configured approach typically works well for systems that have definitive uses, need minimal customization, and are not anticipated to significantly change beyond switching out a device. It is also a great way to get systems up and running without the need of a highly-trained programmer.

And while it may be true that programmed systems require more of an investment in time, money, and skills, this approach should still be strongly considered for specific types of systems and situations. In the right situation, the investment of programming can result in a more efficient, cost effective, and long-lasting solution that is easier to maintain and upgrade.

So, although configuration for smaller, more basic projects is generally faster than programming, certain projects, depending on size or complexity, can be simply programmed for an effective solution, saving time in the end. This is especially true for programmers who have libraries of code that have been built and serve as a resource for new projects. The ability to cut and paste programming code cannot be mimicked very easily in a configured approach. Thus, no matter how simple or quick a configuration can be, a programmed approach can be more efficiently implemented.

Today, a programmed approach is usually selected when there is a need for more system operation flexibility, varied application usage, as well as the ability to anticipate, change, and customize user requirements.

If broken down, the typical configured solution is one that provides either predefined functionality or limited options for providing custom functionality. For simpler systems, differences between standard and custom functionality may not be noticeable, and can be justified. However, when looking at either complex systems that require a degree of customization or are intended to include specific functionality, the configured approach will likely not fit the bill. For example, with enterprise solutions, where consistency, customization, modification, and the ability to upgrade need to be planned from the onset, the flexibility and unlimited potential provided by programming should be strongly considered.

In the end, there are no right or wrong answers. The key is ensuring an informed decision is made, and a clear and detailed project process to support the chosen solution is in place. Below are tips for effective decision making and project planning to help achieve client satisfaction.

  • The first and critical step before deciding whether to configure or program is to identify the needs and expectations of the user.
  • Next, the system functionality should be documented in the form of interface design screen captures, narrative of operation, and/or a button-by-button description of operation. Our preferred method is a Control Functionality Specification (sample can be found at controlconcepts.net/resources.)
  • Once a submission is approved, a conversation should be had with the client to determine whether configuration or programming is the ideal approach citing pros and cons of each along with a recommendation. This is a very critical step as it is important that the client understand and accept the basis for this decision and benefits, and short drawbacks of each method. This is particularly essential when defining a budget, time frame, capabilities, and limitations of the system for current and future upgrades.
  • Even if not needed for the actual creation of the system operation, when configuration is chosen, the involvement of a programmer or field engineer with control system knowledge is still valuable. A programmer can provide insight, experience, and guidance as to the capabilities of devices, system design, and user interface to ensure a successful outcome.
  • Proper planning for allocation of IP addresses, device setup, testing procedures, and troubleshooting techniques is needed to make any system function properly regardless of the configuration or programming approach
  • Device selection with corresponding modules/drivers can be critical in the success of both configuration and programming. The availability of modules or drivers (depending on the control system platform) are key to easily and cost effectively integrating devices to provide the desired solution. When a module/driver is not available, either it should be developed to support the configuration approach or the system will need to be programmed. Regardless, the programmed approach may entail a considerable among of additional effort without the convenience of a specific module/driver to support the device integration.

By following a comprehensive approach, understanding the benefits and shortcomings of each solution, and involving the client in the ultimate decision, the appropriate choice between the configurable and programmed solution will be more clearly and confidently identified.