Episode 47

In our last blog, we explored the adoption of electronic automation. In this blog we will explore the best management practices around the development and maintenance of electronic automation systems, in the context of software systems.

Technology advances are exponential over time. With low- and no-code application development platforms experiencing significant growth over the last few years, development of software automation systems is changing. Increasingly, non-professional developers, (Citizen Developers and Power Users), work with these application development platforms to develop automation solutions with little to no supervision from IT departments. This empowerment of business users can be beneficial to the organization as the individual’s closest to the problem are responsible for development. However, it is paramount to understand that these applications are software systems that must be managed no differently than an application developed by a traditional IT team. These systems must be maintained, and knowledge of their working structure must be institutionalized.


Like mechanical systems, software systems require maintenance to function optimally. Maintenance can come in different forms: corrective, adaptive, preventative, and perfective. Corrective maintenance focuses on the discovery and removal of errors or faults within the software application. Corrections could be made to the design, logic, or to the code itself. Adaptive maintenance is done when the environment containing the software changes. Changes to the environment could be the operating system, hardware, or other software dependencies. This is very common and adaptive maintenance is particularly important since the frameworks and platforms the software is built on are not static and receive updates that may impact the security and functionality of the software system. Preventative maintenance refers to changes made to the software to extend the useful life of the application. Replacing software applications can be both risky and expensive, depending on how critical the application is to the organization, and preventative maintenance to perform updates ensuring the application remains stable, understandable, and maintainable is a prudent decision. Lastly, perfective maintenance focuses on improving (or perfecting) the user experience, adding features to meet new needs, or removing features that are not effective or functional.

With software automation development split between traditional IT and citizen developers there are elements beyond maintenance to consider. Traditional IT professionals must always be learning: the languages, frameworks, and development methods a professional developer used a decade ago are likely not in use in new development today. No and low-code development platforms are also always in flux, with the rate of change seen in these platforms so quick it is absolutely insane (mostly in a good way). Business users that are splitting their time between their normal role and development are on the same skill treadmill as professional developers, constantly requiring professional developers to learn new skills. To maintain the solutions, they develop; citizen developers must take the time to maintain their development skills.

Lastly, a persistent challenge for both professional and citizen developers is maintaining working knowledge of the systems deployed within the organization. Speaking from personal experience, looking at code that I have not worked with for several months is much like visiting an archeological site. Before I can get back to work on the code, there is an extended period of trying to determine what state of madness I was in while working on that section last. Exploring old code developed by a different person is more like visiting an archeological site on a different planet. It is critical for developers to include an appropriate level of relevant documentation and implement a corporate wide development governance structure to reduce the confusion that can occur when different developers are left to their own devices. There is no shortage of stories of pro and citizen developers leaving an organization and crippling the infrastructure while others try to piece together the system they built.

The next blog in this short series will look at a common automation problem: organizational reporting.