Robotics, bots and chocolate teapots

Increasingly in operational efficiency and automation circles we're hearing about bots and robotics. As a software engineer in days past and a recovering enterprise architect I have given up biting my tongue and repeatedly note that, "we have seen it all before." I've written screen scrapers that get code out of screens, written code to drive terminal applications and even hunted around user interfaces to find buttons to press. The early price comparison websites over a decade ago used these techniques to do the comparison. These techniques work for a while but are desperately fragile when someone changes the name of a button, or a screen or a screen flow. However, they can help. I recall a while ago a manager lamenting 'the solution' was about as useful as a chocolate teapot. A useful 10 minutes hunting for this video of a chocolate teapot holding boiling water for one whole pot of tea made the point for me. Sometimes all you need is one pot of tea.

Tea poured from a chocolate tea pot

So it's not new, some bots may be fragile and with my "efficiency of IT spend" hat on (the one typically worn by enterprise architects) stitching automation together by having software do what people do is an awful solution - but as a pragmatist sometimes it's good enough. Things have moved on.

Rather than a physical machine running this with a ghost apparently operating mouse and keyboard we have virtual machines and monitoring of this is a lot better than it used to be. Further machine learning and artificial intelligence libraries are now getting robust enough to contribute meaningfully smart or learning bots into the mix that can do a bit more than rote button pressing and reading screens. In fact this is all reminiscent of the AI dream of mutli-agent systems and distributed artificial intelligence where autonomous agents collaborated on learning and problem solving tasks amongst other things. The replacement of teams of humans working on tasks with teams of bots directly aligns with this early vision.

The way these systems are now stitched together owes much to the recent work on service oriented architecture, component orchestration and modern approaches to monitoring distributed Internet scale applications. For outsourcers it makes a great deal of sense. The legacy systems are controlled and unlikely to change, the benefits are quick and if these bots do break they can have a team looking after many bots across their estate and fix them swiftly. It may not be as elegant as SOA purists would like but it helps them automate and achieve their objectives.

The language frustrates me though, albeit bots is better than chocolate teapots. I've heard bot referred to as a chunk of code to run, a machine learning model and a virtual machine running the code. I've even heard discussion comparing the number staff saved to the number of bots in play - I can well imagine operations leads in the future including bot efficiency in their KPIs. Personally, I'd rather we discussed them for what they are - virtual desktops, screen scraper components, regression models, decision trees, code, bits of SQL were appropriate, etc. rather than bucket them together but perhaps I'm too close to the technology.

In short bots may not be a well-defined term but the collection it describes is another useful set of tools, that are becoming increasingly robust, to add to the architects toolkit.