Softwareentwickler Benjamin Willenbring war begeistert, als sein Arbeitgeber Autodesk im Jahr 2015 automatisiertes Software Testing einführte. Diese Begeisterung legte sich allerdings relativ schnell wieder, denn die Kommunikation mit dem kleinen Automation Team gestaltete sich schwierig und die Ergebnisse der Bemühungen entsprachen nicht den Erwartungen.
"Meine Kollegen sprachen darüber, dass Testläufe aus unvorhersehbaren Gründen scheiterten und ließen keinen Zweifel daran, dass sie nicht besonders überzeugt von der ganzen Sache waren", plaudert Willenbring aus dem Nähkästchen. Die Testphase zum Laufen zu bringen, gestaltete sich schwierig: Es gab keine Dokumentation und Files in Hülle und Fülle. Das automatisierte Testing sollte Willenbrings Arbeit eigentlich vereinfachen - stattdessen warf das Automation-Projekt so viele neue Probleme auf, dass der Entwickler den Großteil seiner Energie in den Folgejahren dafür investieren musste, diese zu lösen.
Die Erfahrungen, die Willenbring in Sachen Automatisierung gemacht haben, sind allerdings nicht ungewöhnlich. Je höher der Automatisierungsgrad in den IT-Abteilungen, desto mehr lehrreiche Beispiele gibt es, die zeigen, wie man Automation nicht angehen sollte. Egal, ob automatisierte DevOps Workflows, Robotic Process Automation oder Prozessautomatisierung - eigentlich soll die Technologie dafür sorgen, Fachkräfte von repetitiven Aufgaben zu befreien. Aber unzureichende Rahmenbedingungen und Fail-behaftete Rollouts können aus dem Automation-Traum schnell einen Albtraum machen. Wir zeigen Ihnen sechs Wege, um es gar nicht erst zum Automatisierungs-Desaster kommen zu lassen.
Automatisierung geht alle an
Willenbrings Testing-Automation-Albtraum wurde insbesondere durch einen Umstand ausgelöst: Die einzigen, die in der Lage waren, die automatisierten Tests zu verstehen, waren die, die sie aufgesetzt haben. Leider war das entsprechende Team in einer anderen Stadt angesiedelt.
"Ein Problem am Test-Framework war, dass es bei Fehlern kein wirklich gutes Feedback zur Verfügung gestellt hat", erzählt Willenbring. "Wenn ein Fehler auftrat, war die erste Maßnahme Slack anzuwerfen, um den Test-Lead nach der Ursache zu fragen. Der wiederholte den Test dann manuell und kommunizierte die Ursache für den Fehler."
Das Testing Framework verletzte somit wesentliche Regeln, an denen jede Automatisierungs-Initiative ausgerichtet werden sollte, so Robert Haas, DevOps Product Manager bei DXC: "Automation Code muss dokumentiert sein, egal ob Sie auf moderne Methoden wie Documentation-as-a-Code setzen oder Visio-Diagramme verknüpfen. Probleme zu lösen ist deutlich einfacher, wenn sich nachvollziehen lässt, wie der Ursprungszustand ausgesehen hat."
Weil das in Willenbrings Fall nicht passierte, waren die Testergebnisse für sein Team unbrauchbar. Das führte wiederum zu sinkendem Vertrauen in die Tests und das Team, das diese aufgesetzt hatte. "Manchmal blockierten die Entwickler einfach und ignorierten offensichtliche Fehler", erzählt der Softwareentwickler.
Aufgrund der räumlichen Distanz zwischen Entwickler- und Testing Team entstanden zusätzliche Probleme: "Man braucht Experten, die wissen was sie tun und gezielt auswählen, was getestet wird. Unmengen an Tests ohne echten Plan führen in der Regel nicht zu verwertbaren und sinnvollen Ergebnissen", so Willenbring.
Erst ein neuer Leiter der Entwicklungsabteilung war in der Lage, Willenbring und sein Team aus diesem Teufelskreislauf zu befreien - er stellte klar, dass Qualität oberste Priorität hat, auch wenn es um Testing Automation geht. Zentralisiertes Testing ist seitdem passé - inzwischen setzen individuelle Abteilungen die Tests für "ihren" Code auf. So konnten auch Willenbring und sein Team Tests an den Start bringen, die auf ihre Bedürfnisse angepasst waren und diesen Prozess letztlich in den Arbeitsalltag integrieren. Willenbrings Fazit zu dieser Erfahrung: "Eine Einstellung im Sinne von 'das gehört nicht zu meinem Job' sollten Sie gar nicht erst zulassen."
- Der Über-Versprecher
Speziell in Situationen, in denen immenser Druck herrscht, neigen manche Mitarbeiter dazu, alle möglichen, absurden Versprechungen zu machen. Entweder um Aufmerksamkeit zu erringen oder um dem Vorgesetzten beziehungsweise dem Management zu gefallen. Versprechungen machen ist immer einfach, aber wenn das Mega-Projekt dann eben nicht in den versprochenen zweieinhalb Wochen abgeschlossen ist, ist das ungünstig. <br><br/> Alexander Maasik empfiehlt: "Wenn es ein Teammitglied gibt, das am laufenden Band falsche Versprechungen gibt, von denen bereits vorher klar ist, dass sie unmöglich einzuhalten sind, sollten Sie seine Worte nicht mehr für bare Münze nehmen. Wenn Sie können, verlängern Sie den Zeitrahmen und/oder erhöhen Sie Budget oder Ressourceneinsatz, um Engpässe in anderen Bereichen kompensieren zu können." - Der Verantwortungsschieber
Dann gibt es diese Kollegen, die das Collaboration-Prinzip der geteilten Verantwortung auf ihre ganz eigene Weise interpretieren. Getreu dem Motto: "Die anderen werden es schon richten." Experte Maasik rät in einem solchen Fall dazu, dem betreffenden Mitarbeiter eine definierte Rolle und spezifizierte Verantwortlichkeiten im Team zuzuweisen. Alternativ könnten Sie den Verantwortungsschieber auch fragen, ob es Bereiche gibt, die ihn besonders interessieren. Eventuell könnten Sie so seine Leistungs-Leidenschaft neu entflammen. <br><br/> "Manchmal können Sie solche Leute motivieren, indem Sie ihnen Führungsverantwortung übertragen oder ihnen die Verantwortung für ein bestimmtes Gebiet/Thema übertragen, das ihnen am Herzen liegt. Sollte betreffender Kollege allerdings für ausschweifende Arbeitsunlust bekannt sein, hilft unglücklicherweise nur, ihn (oder sie) im Auge zu behalten und sich wenn nötig an höhere Instanzen zu wenden." - Der Fremdfeder-Connoisseur
Es ist nur menschlich, nach Wertschätzung und Anerkennung zu streben. Aber einige Menschen übertreiben das in einem Ausmaß, dass sie fast schon selbst daran glauben, wenn sie sich fälschlicherweise die Erfolge anderer zuschreiben. <br><br/> Maasik: "Leider nimmt der Enthusiasmus dieser Leute rasant ab, wenn es darum geht, die Verantwortung für Misserfolge zu übernehmen. Um solchen Entwicklungen entgegenzuwirken, empfiehlt es sich, genau festzuhalten, wer für welchen Part der Projektarbeit zuständig ist. So können auch alle Beteiligten sehen, wer welchen Beitrag leistet. Sollte jemand auf das Einheimsen von Lorbeeren bestehen, stellen Sie sicher, dass derjenige auch im Fall des Misserfolgs sein Fett abbekommt." - Der Makel-Magnat
Nicht führt die Team-Moral schneller und geradliniger in den Abgrund, als einer, der ständig nur kritisiert, auf Fehler "hinweist" oder sich über jeden Aspekt eines Projekts nur beschwert. Egal, ob es um Zuständigkeiten, Workloads oder die Strategie geht, der Makel-Magnat hat einfach immer was zu meckern. <br><br/> "Dieses Verhalten ist absolutes Gift für das Teamwork. Diese Leute verbringen mehr Zeit damit, sich zu beschweren, als mit der Erfüllung ihrer Aufgaben. Der beste Weg solche Menschen zu handlen: 1. Ignorieren Sie das Gemecker, 2. Geben Sie ihm so viel Verantwortung, dass er (oder sie) keine Zeit mehr hat rumzujammern." - Der Aussteiger
Manche Leute arbeiten besser alleine. Ist auch gar kein Problem. Außer es handelt sich um Personen, die in Team-Projekte eingebunden sind. Dann könnte jemand, der Anweisungen aus Prinzip ignoriert und affin für Alleingänge ist, das ganze Projekt auf's Spiel setzen. <br><br/> Deswegen empfiehlt auch Alexander Maasik, solche Leute lieber aufs "Abstellgleis" zu befördern: "Finden Sie einen Bereich im Projekt, an dem ein solcher Mitarbeiter alleine arbeiten oder sich selbst verwirklichen kann. So holen Sie das Maximum an Produktivität aus diesem Kollegen heraus und stellen gleichzeitig sicher, dass der Rest des Teams intakt bleibt."
Automation bringt Komplexität
Bei Tripwire, Anbieter für Automatisierungslösungen im Bereich IT Security und Compliance, wunderte man sich über die Vorgänge bei einem Großkunden aus dem Finanzbereich. "Unsere Lösungen werden automatisiert ausgerollt", erzählt Irfahn Khimji, Country Manager für Kanada bei Tripwire. "Deswegen haben wir uns irgendwann gefragt, warum das bei diesem Kunden so lange dauert. Wir konnten keinen Anstieg bei der Nutzung der Lizenzen feststellen, was nicht dem normalen Muster entsprach."
Wie sich herausstellte, wurde das Ideal einer nahezu vollständig automatisierten CI/CD Pipeline von der Realität eingeholt: Jede der vielen unterschiedlichen Abteilungen beim Kunden nutzte ein eigenes, individuell ausgestaltetes Set von Softwarekomponenten.
"Der Kunde wollte mehr als 30 Applikationen einbinden - was zu zahlreichen Problemen führte, etwa, wenn es um die diversen Bibliotheken ging", erzählt Khimi. "Die Pipeline so anzupassen, dass sie alle Anforderungen zuverlässig abdeckt, verlangsamte den Automatisierungsprozess deutlich."
Um ein solches Problem zu lösen, gibt es kein Wundermittel. Sie sollten sich aber darüber im Klaren sein, dass mit einer steigenden Zahl von Komponenten, die in den Automation-Prozess eingebunden werden sollen, auch die Komplexität steigt - schließlich müssen diese Komponenten miteinander verknüpft und entsprechende Anpassungen vorgenommen werden. Das wird wiederum dazu führen, dass die Automatisierungs-Initiative mehr Zeit und Ressourcen benötigt. Dabei spielt es auch eine Rolle, woher diese Komponenten kommen: Das Gros der Pipelines und RPA-Umgebungen beinhaltet einen heterogenen Mix aus Inhouse- und Third-Party-Komponenten. Gerade letztere können beim Auftreten von Fehlern zu echten Problemen führen.
- KI und Automation
Auf Einladung der Computerwoche diskutierten Ende November 2018 in München Experten über Künstliche Intelligenz (KI), Machine Learning und Automation. - Bernhard Mandutz, Business Unit Manager Valuemation bei der USU GmbH: „Bei Serviceprozessen wird KI in Zukunft die zentrale Rolle spielen, egal ob es um Automatisierung, Predictive Maintenance oder Chatbots geht.“ Die USU GmbH ist ein Spezialist für Enterprise Service Management.
- Santiago Cabrera-Naranjo, Consulting Director bei Teradata: „Data Science ist heute allzu oft ein Prozess, bei dem neue Erkenntnisse und Modelle als einmalige Anstrengung entwickelt oder ad hoc in der Produktion eingesetzt werden. Sie erfordern deshalb ein regelmäßiges Babysitting zur Überwachung und Aktualisierung. Wir wollen das ändern.” Das ehemals vor allem als Data Warehouse Anbieter bekannte Unternehmen Teradata widmet sich längst vorrangig Themen wie Business Analytics und Big Data.
- Stefan Gössel, Managing Partner beim IT-Dienstleister Reply: „Wenn Sie Arbeitsplätze mit zwei Bildschirmen haben, haben wir etwas zu tun.“ Reply ist ein Spezialist für Geschäftsmodelle, die auf Paradigmen wie Big Data, Cloud-Computing oder dem Internet der Dinge basieren.
- Tobias Mirwald, Geschäftsführer beim CRM-Hersteller Adito Software: „An die Daten kommt man oft schwer ran, weil sie in Silos liegen. Erst muss man vernetzt denken, bevor man mit KI die Daten nutzen kann.“
- Sven Munk, Partner Technical Sales Lead EMEA LATAM, bei Informatica: „Das Datenvolumen explodiert, mehr und mehr Datentypen werden erzeugt. Unternehmen müssen diese Daten strategisch nutzen, um Innovationen zu erzeugen und ihre digitale Transformation voranzutreiben.“ Informatica ist ein führender Anbieter von Enterprise Cloud Data Management Lösungen.
- Thorsten Urbanski, Head of Communication beim Security-Anbieter ESET, schätzt die Herausforderungen und das Potenzial im Bereich Automation und IoT gleichermaßen hoch ein. Im Zuge der digitalen Automatisierung werde es von essentieller Bedeutung sein, sich vor Manipulation der relevanten Daten zu schützen: „Wenn wir uns die Folgen im Bereich Robotic und Industrie 4.0 oder Autonomes Fahren vorstellen, wären die Auswirkungen mehr als fatal.“
- Kristina Appelt, Manager Systems Engineering bei Cisco: „Es ist wichtig, den Anwenderunternehmen eine performante, validierte Infrastruktur für KI und Automation bereit zu stellen.“
- Alexander Hartmann, Mitglied des Vorstands bei SYSback: „Wir deutschen Unternehmen sind viel zu zurückhaltend in der Vermarktung von KI.“ SYSback ist Service-Provider für Holistische Automation und orchestriert und automatisiert mit diesem Ansatz verschiedenste Prozesse und IT-Ressourcen.
Automation-Prozesse als Black Box
Insbesondere in der Finanzbranche stehen Robotic Process Automation und Chatbots hoch im Kurs. In diesem Zusammenhang warnt Muddu Sudhakar, CEO und Mitbegründer der Softwarefirma Aisera vor einem gängigen Szenario: Prozesse werden als monolithische Funktionseinheit gesehen, deren interne Abläufe nur noch schwer voneinander zu trennen sind und so zur Black Box werden: "In einer monolithischen Struktur will der Kunde seinen Kontostand checken, Geld abheben oder überweisen - das alles passiert in einem Schritt", erklärt Sudhakar. "Wenn dabei etwas schiefgeht und keine Monitoring-Maßnahmen bestehen, bleibt nur noch ein Anruf beim Kundenservice oder der physische Besuch der Filiale."
Dem Experten zufolge ist diese Art der Architektur typisch für die Anfangsbemühungen von Unternehmen mit Automatisierungstechnik. Zwar könnten solche Projekte gute Ergebnisse hervorbringen, so Sudhakar, aber nur solange alles nach Plan läuft. Wenn nicht, bleibe nur, die einzelnen Funktionen aus der Black Box herauszulösen - weswegen man eine solche von vornherein vermeiden sollte.
"Unterteilen Sie jeden Prozess in Bausteine, die auditier- und überprüfbar sind", empfiehlt der Automation-Spezialist von Aisera.
Automatisierungs-Gewaltenteilung
So manch automatisierter Prozess kann vom Poka-Yoke-Prinzip profitieren. Die in Japan erfundene Fehlervermeidungsstrategie kommt beispielsweise im Produktionssystem von Toyota zum Einsatz. Hierbei wird ein einzelner Prozessschritt in zwei verschiedene aufgeteilt - wobei der zweite Schritt vom ersten abhängt. Paradoxerweise führt die Vermehrung der einzelnen Schritte zu Effizienzgewinnen, weil Fehler nicht in die Produktionskette einfließen - wo sich ihre Effekte vervielfachen können.
Einzelne Automatisierungsschritte sollten nicht nur auditierbar sein, sondern konstant von anderen automatisierten Prozessen überprüft werden. Damit nähern Sie sich dem Bereich AIOps: Hierbei entlasten automatisierte Plattformen menschliche Fachkräfte von der Bürde des IT Managements.
Automation braucht Security
Automatisierte CI/CD Pipelines haben oft ein schmutziges Geheimnis: Viele wurden initial von der Schatten-IT ausgerollt, um Security-Richtlinien zu umgehen. "Entwickler wollen eben entwickeln und zügig mit ihrem Code vorankommen", erklärt Irfahn Khimji von Tripwire. "Wenn rigorose IT- und Security-Prozesse dabei im Weg stehen, haben sie sofort Ideen im Kopf, um diese zu umgehen."
Das soll nicht heißen, dass solche CI/CD Pipelines per se unsicher wären - aber Sie sollten unbedingt im Blick haben, welche Sicherheits-Praktiken dem Automatisierungs-Effizienzgewinn geopfert wurden. Darüber hinaus sollten Sie nicht vergessen, dass jeder automatisierte Prozess immer auch einen weiteren Angriffsvektor darstellt. Autonome Prozesse, die mit erweiterten Berechtigungen ausgestattet sind, stellen unter Umständen besonders attraktive Angriffsziele dar. Muddu Sudhakar kann sich nicht nur an einen Fall erinnern, bei dem Innentäter die DevOps Pipeline dazu missbraucht haben, Malware einzuschleusen. Diese konnte sich ihren Weg bis in die Produktionsumgebung bahnen und legte das komplette System lahm.
Billig-Automatisierung lohnt sich nicht
Jeder Hype kommt mit Missverständnissen im Schlepptau. Ajeet Dhaliwal, Lead-Entwickler und Gründer von Tesults, hat schon viele Unternehmen gesehen, deren Vision von automatisiertem Testing in recht deutlichem Kontrast zu den Best Practices steht. Insbesondere kleinere Unternehmen, deren Führungsebene keinen technischen Hintergrund mitbringt, scheinen von diesem Phänomen betroffen zu sein. In der Logik dieser Menschen stellen automatisierte Tests schlicht manuelle Tests ohne menschliche Beteiligung dar.
"Also ermutigen sie traditionelle QA-Tester ohne Kenntnisse in der Softwareentwicklung dazu, das Testing zu automatisieren", fasst Dhaliwal die Folgen zusammen. "Die Robustheit und Flexibilität solcher Ansätze liegt deutlich hinter dem, was ein Softwareentwickler mit Automatisierungs-Knowhow leisten kann." Natürlich sei es kein Problem, auch junge Entwickler mit einzubinden, so der Testing-Experte. Aber diese sollten von erfahrenen Developern angeleitet werden, um gute Ergebnisse sicherzustellen. (fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CIO.com.