How to find your automation stack
Finding the right tool stack in any software discipline is exhausting. You must figure out your needs and determine a strategy to meet your requirements. Full stack solutions provide an easy exit from this quest. But as every so often in life: the easy way is not the sustainable one. That counts especially in process automation — often mystified for “RPA”.
A custom tool stack has several advantages when chosen wisely. While the freedom of choice my be frighting at first, the learning curve is worth it. Every tool in your stack is ought to be a specialist it its field — not just an average. The must-have requirement for any tool is integration. If it does not provide integration to any standard environment or interface, it is not suitable for you tool suite.
If you intend not to get stuck with a RPA solution you must define a strategy for your automation stack.
If you are working with Robot Framework already, you know the deal. The framework provides a vast amount of APIs (so called keyword libraries) for accessing any 3rd party system python can get its almighty fingers on. Meaning anything that can be accessed through a python module can be hooked in to automation suites by wrapping the module’s functionality in a keyword library.
While Robot Framework is great in providing APIs and a compromise for low code solutions, it answers none or only basic requirements for orchestration, execution and monitoring. Those requirements are up to other specialists. If chosen wisely and with some foresight you are rewarded with a league of specialists fitting perfectly your available resources. Since your tools do not depend on a particular companion, you can trade any tool for any better solution you come aware of.
Rule Number 1: No tool is set forever
For example: if you are tired of administrating a zoo of deprecated plugins for Jenkins — use Gitlab instead! Or Rundeck. Or whatever job scheduler you prefer. Even crontab, if you prefer it basic! As long it can execute a python environment, you may use anything for orchestration.
Rule number 1 of your tool stack is: no tool is set forever. Otherwise you are stuck with another SAP: an idea that must have been visionary decades ago and but nowadays outweighs the burden for its users only by its devastating costs for migrating to an alternative from this century. Ironically that’s the old fashioned business model big RPA vendors have adopted and it is working fabulously — for them. The license based vendor lock threatens customers of being shut down. If you refuse to pay the bill anymore, your processes (and thus your business) stop completely. Do you really want to give any vendor complete control over your most essential process?
If you intend not to get stuck with RPA you have to find a strategy for your automation stack. For a start, consider the following exercise:
Imagine you have decided to set on Robot Framework (for now,; because of rule number 1). What categories of your automation stack do the following components belong to where some:
- Orchestrate Robot Framework executions
- Provide certain runtime environments
- Can be automated through certain Robot Framework open source APIs
The list of components is far from being exclusive. Take your time and argue conclusively.
