Welcome!

Microservices Expo Authors: Pat Romanski, Elizabeth White, Liz McMillan, Stackify Blog, Andreas Grabner

Related Topics: Microservices Expo, Mobile IoT

Microservices Expo: Article

The Automation Paradox

This script is not intended for use in the operation of nuclear facilities

A recent article appeared in the IEEE spectrum on "the automation paradox" which was reflected with the question by Steven Cherry of "Would we be safer overall if we just accept a few deaths due to software?" The concept is a little funny in my mind, since for many years it seems like a lot of the software that I have worked with always carried a EULA that stated something like "...IS NOT INTENDED FOR USE IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL SYSTEMS, LIFE SUPPORT MACHINES OR OTHER EQUIPMENT IN WHICH THE FAILURE OF THE SOFTWARE COULD LEAD TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE"

This got me to thinking about how far we have come with software and how many devices these days rely on generic software to run a multitude of devices. The question I guess comes down to the level of rigor that has been applied in the testing and quality assurance processes, and the relevance of the technology to the task at hand. It is becoming increasingly difficult to find technology that doesn't rely to some extent on a homogeneous platform and in fact the use of a platform brings many benefits like scale, total cost of ownership, etc. The idea of moving away from discrete things built to perform discrete actions is very appealing.

Consider the smartphone for example. Irrespective of whether you use one, the underlying technology is pretty standard for a given family of products. Of course this ‘standard' has proven to be somewhat of an undoing for some of these platforms in that you might have a tablet device running an Android operating system with the froyo release and yet you cannot make phone calls with it, despite the fact that it has a dial-pad and a ‘make a call' button. So, what it appears a given platform can do is not necessarily reflected in the reality of what you can actually do - this is an obvious one that you quickly realize. Again, as previously mentioned, it is however cost effective for manufacturers to use a generic image of the software to make the hardware usable and then it is up to the consumer to determine what he/she wants to use it for.

Another parallel comes from the world of music. Over the holidays, I met with family and we discussed how being a deejay has transformed over the last couple of years with the almost complete elimination for  the tunes-minder to drive a minivan brimming with boxes of CDs or vinyl records. The MP3 standard and digitizing music into data files has effectively rendered that industry much more efficient. So much so  that you could be carrying thousands of hours of broadcast grade audio media in your pocket in the same device that you make phone calls. All pretty amazing except that now there is so much of it, it is difficult to manage unless you are an incredibly disciplined or organized person. I have terabytes of recorded media at home: songs, videos, movies, and photos that I have tried to store in a sorted fashion, but whose volume has rapidly outstripped my discipline levels. I almost despair when I try to find things sometimes. So do deejays really carry their entire library of music with them? I assume not. They have a standard repertoire probably and a few extra tracks in the wings for the occasionally requested, but not mainstream songs.

Back to the concept of the automation paradox then. The idea here is that automation is the operation of some activity automatically, without continuous input from an operator. The more reliable one considers an automation to be, the more complexity one introduces to the automation and ultimately the less the operator can contribute to the resulting success. This is a paradox because it could be a contradiction. I have my audio tracks so now I don't have to carry hundreds of discs from venue to venue. But because there is so much of it, I only carry some of it now. I have changed my usage model. I've switched from a phone that just makes calls, to a phone that makes calls, surfs the webs, plays music and takes photographs but really, what do I use it mostly for? I have over 60 applications installed, but I only use two or three regularly. I am not representative of anyone except myself, but do you see some parallels here with yourself? In theory at least, I don't need my phone, MP3 player, camera and my laptop, but which ones have I really shed?

I thought this topic relevant in the realm of creating automations around SAP transactions because we assume that we can save time and energy by building scripts around all manner of actions in the world of SAP. However, sometimes we simply need to step back from the problem and evaluate whether we really should be modeling automations around things that we find annoying or that we think we can build automations around.

The message has to be that even though you ‘can' build a script around a given transaction or process in SAP, is it the right thing to do? The transaction recording mode for example that comes to my mind is building scripts using GUI scripting. While this method often works and works well, it is an area that has been frequently called out by SAP admins  and SAP auditors as an area to be cautious with. The challenge with this method is that it leverages classic screen scraping and doesn't rely to the same extent on the field and screen definitions defined programmatically in the SAP transaction. In a phrase, "you can sometimes land up with unexpected outcomes"; you can only assess success if you perform a review of the results. Do you always do that?

Again, you can build a degree of checking and controlling into your recording, but the level of effort may ultimately make it better by not trying to build such an automation. In such circumstances, I always encourage people to look at alternative ways to achieving the same objective, perhaps using multiple scripts or considering a BAPI or an SAP API like a remotely enabled Function Module to achieve the same result. Irrespective of the approach that you choose, of course, testing will be key and playing through a number of use cases and scenarios will be pivotal to determining whether your automation is robust and reliable.

Fortunately, all of this isn't likely to be very life threatening. You're not likely to be using that transaction recording to run a defibrillator, fly an airplane or a heart lung machine. Don't underestimate the script's importance though, especially if you are using it to do interesting things like maintain bills of materials for the manufacture and assembly of items. Do consider though whether ultimately you aren't building something that will make more work for you in the long run, if something goes wrong. Remember that in the world of SAP, without a system restore, there is no undo, only the ability to fix forward.

Suggested further reading:

The Benefits of Risk - IEEE Spectrum

What is Froyo - Gizmodo

Radio Deejays versus Radio Automation - Hubpages

More Stories By Clinton Jones

Clinton Jones is a Product Manager at Winshuttle. He is experienced in international technology and business process with a focus on integrated business technologies. Clinton also services a technical consultant on technology and quality management as it relates to data and process management and governance. Before coming to Winshuttle, Clinton served as a Technical Quality Manager at SAP. Twitter @winshuttle

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Microservices Articles
In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the p...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
Most DevOps journeys involve several phases of maturity. Research shows that the inflection point where organizations begin to see maximum value is when they implement tight integration deploying their code to their infrastructure. Success at this level is the last barrier to at-will deployment. Storage, for instance, is more capable than where we read and write data. In his session at @DevOpsSummit at 20th Cloud Expo, Josh Atwell, a Developer Advocate for NetApp, will discuss the role and value...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and...
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and co...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, will discuss how to use Kubernetes to setup a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace....
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, discussed why containers should be paired with new architectural practices such as microservices rathe...
SYS-CON Events announced today the Kubernetes and Google Container Engine Workshop, being held November 3, 2016, in conjunction with @DevOpsSummit at 19th Cloud Expo at the Santa Clara Convention Center in Santa Clara, CA. This workshop led by Sebastian Scheele introduces participants to Kubernetes and Google Container Engine (GKE). Through a combination of instructor-led presentations, demonstrations, and hands-on labs, students learn the key concepts and practices for deploying and maintainin...