There’s a phrase that is said commonly in programming disciplines (developing automations not excluded) - “don’t reinvent the wheel”. This phrase is used to suggest that there may not be a great reason to create something net-new, if there are reusable, potentially optimized assets already available that can be leveraged to solve your problem. In this post, we want to examine how building with a “reusability-first” mindset can accelerate your automation development efforts and ultimately make life as an automation developer easier. Building with a Reusability-First mindset means going through the following thought pattern anytime you come across the need to do something repeatable within your build:
- Is there something that exists already that I can leverage to make my life easier here? This may be identifying and using a built-in package instead of trying to script something out or this may mean checking within the shared public repository of your Control Room to see what reusable subtasks may exist. Either way, a reusability-first mindset means thinking first of leveraging something that already exists rather than immediately thinking to create something net-new
- If something doesn't already exist, what aspects of the solution I’m building could I (or others) re-use in the future? This may be identifying certain subtasks of the greater process you’re automating that could lend themselves to reuse across automation opportunities. This could include common operations like logging in to a particular system, creating a new transaction in a system of record with defined input fields for easy re-use, or even utility-style subtasks to do things like clear temp log files or close all applications on a bot runner.
Now, all of that said, if you’re relatively new to building automations, or your organization is just getting started out - you may not have much in the way of “whats already reusable”... and you may also struggle to know what stuff you will reuse in the future since you’re just working on your Quick wins. But know that as you continue to progress from your first QuickWin automations to delivering from a prioritized pipeline of automation opportunities, you’ll want to be sure to pay attention to those “events” or “actions” that you see repeating themselves across the processes that you’re automating - as they may be a perfect fit for a reusable subtask.
Build Once, Reuse Over and Over
The most obvious benefit of building for reusability is accelerating your ability to quickly design and develop automations. While thats definitely a benefit, and will surely make your life easier as an automation developer - it’s actually not the only benefit of building for reusability. Think about what happens when an application has an update - and breaks a component of your automation - let's say a login page for our example. If you’ve built that login logic individually in 10 of your automations, that means that all 10 automations need to be updated when that login page gets updated. Conversely, if your login logic has been built into a reusable subtask that’s referenced by all 10 of your automations, you only have to make that update once...and now all 10 automations can be fixed by pushing only a single update. So not only have you been able to build more quickly leveraging reusable assets, but your maintenance for existing automations has also gotten significantly easier as well.
Conclusion & Actionable Takeaways
It can be tempting to get in the habit of creating everything net-new for every single automation...but try to identify those patterns of where you find yourself doing the same things over and over again across your automation build outs. These patterns will clue you in on where you may benefit from creating a reusable subtask.
Actionable Takeaways:
- Identify applications and actions/events that seem to be coming up frequently in the processes you’re automating. Start creating small, reusable subtasks that you can use in your automation that could ultimately be leveraged in other automations in the future.
- Work to make these subtasks as “generic” as possible - by using input variables that can have values mapped in by the calling parent task. This will ensure that even if a different bot (or developer) is referencing your subtask, they will be able to take advantage of the work that you’ve already done.
- Identify if there may be some reusable utility automations that could benefit your automation program. Work to build these as reusable tasks that can be invoked from other automations (or from your automation framework/template) to take care of cleanup/utility style tasks.
- Examples: Closing all opened apps on a bot runner when the bot execution finishes, deleting all bot logs older than X days to ensure the logging directory isn't growing out of control, cleaning up any stored/capture screenshots from an automation run that may have been captured for debugging/troubleshooting purposes, forwarding logs to a log forwarder or central repository, etc.