Over the past few years, low-code/no-code platforms have become ubiquitous in many industries. Users can now use drag-and-drop platforms to create websites, build applications, design automations, and so much more. While the use of low-code platforms is still increasing significantly (Gartner predicts a market growth of 23% in 2021), they have become the norm for many enterprise teams.
I remember building my first website in Microsoft FrontPage 98. As awesome as it was to be able to drag-and-drop a couple of buttons, a visitor counter, and some blinking text onto the screen, it was equally as frustrating to do anything outside of the pre-defined functions FrontPage had to offer. (Little did I know that my few drag-and-drop elements would create thousands of lines of undecipherable and unmaintainable code that I had to comb through if I wanted to change anything outside of the nice UI.)
Even today, this same challenge still exists. No matter how a low-code platform is designed and what use case you solve with it, in the end, it produces code and the visual elements you see are a representation of that code. In the case of automation platforms, this correlation of visual elements and code is particularly obvious. One task on an automation canvas roughly matches one line of code.
The Challenge of Most Low-Code Platforms
Roughly 10 years after my failed attempts to build a maintainable website using FrontPage, I attended an eye-opening college course entitled “Good Coding Practices,” but it might as well have been called “List of every dumb mistake Alex ever made while coding.”
- Copy & pasting whole sections of code? Sure.
- Having functions with well over 200 lines of code? Absolutely.
- Overwriting my input parameters multiple times along the way? Why not?
- Documentation? I’m the only one using this anyways…
- Refactoring? When did that ever solve a problem?
Taking this class and following good coding practices took me from “somehow solving a problem” to “designing a solution for a problem.”
For me, this experience describes well the challenge of using low-code platforms, automation platforms in particular. I often see many, if not all, of these 5 bad practices in automations built with different automation tools. Most low-code platforms make it easy to build something, but very few make it easy to maintain and extend what you have built, which is critical for the long-term success of your automation journey. Low-code automation platforms usually fall in one of these three buckets:
- Limited Flexibility – They limit the flexibility and extensibility of the automations you build. This works well for many smaller use cases, but changing business processes usually drive you to the point at which you need more than the pre-defined feature set, at which point you are stuck and have to switch platforms or hope for them to add the feature you need.
- Allow Code Additions – They allow to add “actual code” when advanced features are required. While this doesn’t leave you stranded when your automation has advanced needs, it is often hard to marry machine-produced code with human-produced code, which in turn requires you to hire a developer for your low-code platform (you often even need a particularly skilled one that knows the domain specific language your automation tool uses).
- Flexible Canvas – They allow for flexibility on the automation canvas. This is the closest you can get to a visual programming language and offers the most flexibility, but that flexibility usually comes at the price of maintainability issues, often caused by “bad code” that non-developers produce when using the tool.
Itential’s Automation Studio
Itential’s Automation Studio was purpose-built to fall into the third bucket by providing as much flexibility as possible in our canvas. While our customers enjoy the ability to build their most complex business processes accurately in our low-code automation canvas, we have been working together to find ways to improve our canvas to ensure that automations they build are easier to understand, troubleshoot, and maintain.
To continue to make strides in building the best automation canvas available for network automations, Itential recently launched a new automation experience in our 2020.2 product release full of new features to help build modular and maintainable automations that abide by best coding practices and are easy to understand and re-use.
- Best Practice Analyzer: Itential’s Best Practice Analyzer is your personal “good coding practices” tutor that looks over your shoulder while building automations and gives useful hints if what you’re building doesn’t follow best practices. For example, it may suggest using a JST task for your automation in a case in which it would replace at least 3 data manipulation/merge/query tasks.
- Looping in child workflows: Loops are often modular, reusable functions that other automations could benefit from. By putting loops in child workflows, they automatically become re-usable and make both parent and child automations cleaner and easier to understand.
- Grid-based canvas: Our new automation experience includes a grid-based canvas so that all of your tasks stay organized. New icons for each task replace the colored task delineation and different zoom levels make sure you can navigate your automation without losing the information you need.
Following good coding practices also means re-defining some functionality that existed in our previous automation canvas. Modular retry transitions instead of globally available reverts, strongly typed / immutable input parameters instead of Job Variables, looping only over modular child automations and a limited use of parallel execution to prevent race conditions are only some of the changes we’ve made after careful consideration of the benefits each feature provides toward more maintainable automations and the drawbacks of limiting some of its flexibility.
You can read the full details of our latest product release in my previous blog as well as watch a quick demo video of Itential’s Automation Studio.