From idea to industry – a robot’s life cycle is much more than you think
Robots from a package, or what is easy
Modern robotic platforms include a whole range of functionalities that facilitate the design, coding and testing of robots. They can be created from a template, using a ready-made component from the library, or even by “recording” the process while it is running. Unfortunately, robots built in this way usually work for trivial or artificially created cases. The real challenge is the effective automation of processes that change over time and thus force changes in the robots. To control them, you need to know what the robot’s life cycle looks like – from the idea of what it should do, through its production, maintenance, to the moment when we decide that its mission has been fulfilled and it must be turned off.
How it all begins, or idea management
Contrary to popular beliefs, most often the teams responsible for robotization do not complain about the lack of ideas where the robots could work. Usually there are too many ideas and you need to think carefully about choosing only the valuable ones. It is necessary to build a process that allows you to efficiently judge against objective criteria which robots will give you the biggest benefits. This is an uneasy task and I can only signal it in a short entry and emphasize that the objectivity of the criteria is the absolute key to success. A very good question that is worth asking at the very beginning is whether we really need a robot in a specific case. Just because a robot can do something doesn’t mean it should do it. There are often other, easier solutions to consider. Although robotization is fast and effective, it is a rather complex IT undertaking, so it is worth reaching for it carefully.
What you need to write before you start coding, i.e. project documentation
According to the agile manifesto, working software is more important than detailed documentation. It’s hard to disagree, but even the most die-hard advocates of agile methods know that sooner or later there comes a point when you have to turn to original assumptions to understand whether the robot is actually doing what it should.
There are two basic documents that should be at least drafted in order to avoid frustrating discussions during the acceptance tests. The first one is PDD (Process Design Document). It is created primarily by business analysts and should help programmers understand how the process works today, what rules it is controlled by, and how to handle special cases or errors. A good PDD should contain a process map.
The second document is SDD (Solution Design Document), usually created by process architects for programmers. Thanks to SDD, programmers should be clear about the standards to use in coding a specific process, what templates, and what ready-made components should be used.
An experienced development team can opt out of SDD. Ultimately, the working robot code is an incarnation of the SDD into a real implementation, so it may eventually serve as self-documenting code.
Something, what tigers like best – development
Robots are a very rewarding field for agile software development methods. By their nature, they are in line with the agile spirit, i.e. continuous, incremental building of new value. Because the best robotic platforms offer support for the coding process, usually offering graphical representations of processes, robotic coding often relies on selection of proper ready components.
In my experience, it is worth focusing on two aspects that bring benefits in the long run from the entire agile toolbox when coding.
The first is the peer review technique, which involves the evaluation of the generated code by colleagues from the team. It perfectly supports the exchange of knowledge and increases the quality of not only the selected fragment of the solution. In the long term, regular use of peer review allows you to avoid very costly mistakes and gives you the opportunity to raise the level of competence of the entire team. When collaborating on code review, the most experienced team members can often see areas where they can improve themselves. Contrary to appearances, peer review is one of the most appreciated and liked techniques related to agile.
The second practice that I strongly recommend is building automated robot tests. It would seem that there is no point in building robots to test robots, because it is an excessive effort. It turns out that in an increasingly volatile environment, automated tests save costly downtime. In many cases the changes in software occur suddenly, or seemingly minor modifications in one place have serious consequences elsewhere. Thanks to automated testing, such anomalies are detected before they reach production environments and give the robotic team a chance to update the code and avoid stopping work. The agile nature of the robots allows such a quickly detected bug to be repaired just as quickly.
When we shall board the train, i.e. release management
One of the biggest challenges in software development is the synchronization of change deployments between multiple operating systems. Companies most often optimize such synchronization points by building the so-called “release train”, which in practice means that every defined time interval the software is implemented in production, i.e. the train stops at the station regardless of whether someone is getting on or off it.
Unfortunately even such train has its disadvantages because some changes are urgent and must be implemented between stations, which complicates a lot this uneasy puzzle.
The robots are great for deployment independently of the moving release train, which makes costly synchronization unnecessary. For this to be possible, first of all, you should build an appropriate system for automated code implementation, but also prepare the robots so that they work with both the old and the new version of the application on which they work. Of course, such robots also need to detect when the application is deployed in order to be able to comply with the changes. It takes a bit of discipline, but gives you great flexibility in robot deployments.
All flows, i.e. change management
Unfortunately, nothing is given once and for all and robots also have to change depending on changes in applications and processes they work on. In order for this process to run flawlessly, we need not only a system for registering new notifications and the process of assigning appropriate priorities. First of all, we should have a robot code repository to make sure that every change is made on the current version of the robot. Moreover, we also need to have appropriately separated development and test environments, so that the testing process is independent of a production robot.
I feel like someone is watching me, i.e. monitoring
I used to write about monitoring in this article, so I won’t repeat the recommendations that it contained. I will only emphasize, that even the smallest robotic installation will not be effective, if we do not ensure that it is automatically supervised. The role of a human being in the process should be only to resolve exceptions, and only those that are non-trivial and non-standard. Everything else has to be handed over to the robots.
It’s time to say goodbye, i.e. the robot withdrawal
Even the best performing robot stops working sometime. This usually happens because the process is stopped or has been automated with non-robotic tools. Remember to withdraw such robot from use every time. It will save the licenses and infrastructure as well as the time needed to maintain the robot. It is important to keep all documentation and the robot code so that it can be brought back up and running quickly when the process resumes. It is also good practice to periodically evaluate the sense of further robots’ operation. Sometimes you find out that the process volume drops to such low values that it may not be economically justified to keep maintaining the robot, although the robot can still perform its tasks. Keep in mind that robots only make sense when their work brings tangible benefits.
What is the result, i.e. a summary
As you can see, even a superficial description of the robot’s life cycle can be the subject of a fairly long article. This does not mean that robotization is difficult or very expensive. On the contrary – well-built processes for the production and monitoring of robots mean that they can be built by people without education or experience in IT. If we properly ensure that the robot’s life cycle is as automated as possible, we will achieve a real democratization of robot production, i.e. everyone will be able to automate the tasks that they are least willing to perform.
It is worth undertaking this job.
See how robots may help your company
