Now a university course and (in some places) a school subject, robotics has progressed to include our understanding of the lasers, sensors and other equipment that goes to make up the so-called Internet of Things (IoT). But looking one tier deeper, robotics also now exists as a key part of the way software is built to operate.
Robotics in software
Software robots are sometimes referred to as ‘software agents’ or simply ‘bots’. Essentially, intelligently structured pieces of operational software code. Software robots play a variety of roles that emulate some or all of the interactions that a human being might have with an application, computer service or wider network.
Software robots now form part of a layer that we like to call Robotic Process Automation (RPA). In a world where cloud-based IT services and data-driven workflows are running so many parts of digital business, the action to automate defined processes through robotic intelligence makes a lot of sense.
By using software application architecture controls based upon an agreed ‘data model’, we can specify what actions our RPA robots do within our software universe. Or to put it in less technical terms, we can now build software applications around a template with defined repeatable computer-based actions. We recently announced some very exciting news on this and invite you to ‘meet HR Bob’
Where 1 + 1 will always equal 2 inside a specific part of a total software system, then why not automate it? From this foundational notion, we can build up our RPA robotics layers in a Zen-like fashion, one brick at a time, until we start to look at what has become a complete, end-to-end computer system.
Modern processes for RPA and service management are new, but this concept has been around for a while as a proven component of IT. Older methods of what we called Business Process Orchestration (BPO) used to come somewhere near these ideas.
BPO engaged in so-called ‘screen scraping’, where we saw computer systems try to become aware of what the data values they were processing contained by ‘allowing’ the machine to look at its own screen outputs, based upon defined screen locations.
We used some of these BPO techniques in conjunction with what software application developers still call ‘scripting’ methods. A script is in some way similar to an application ‘macro’, where again we see a documented sequence of events being executed based upon an agreed word or action.
But scripts go deeper than macros and can also function both at the application level as well as the operating system level to create a more powerful level of automation. Scripts can also signal for user interaction when defined ‘exceptions’ are recorded or experienced, so this is automation that can interact with human users in a sophisticated manner.
A higher level of automation
Today we have, thankfully, gone further back into the DNA of the software systems we are building. Using RPA techniques, we can take what we learnt from BPO and extend the way we think about automating business logic into our software services layers.
Where scripts and other smaller elements of automation exist within isolated processes inside an IT system, RPA allows us to automate at a higher level to control services that exist with a far wider footprint across the organisation.
So, what happens next with RPA and software automation? The answer is simple enough - it depends upon us, the users. We now sit at the point where we can engineer intelligent automation into our software layer to drive business outcomes and empower business analytics across the total software stack.