Im letzten Interview haben wir darüber gesprochen, weshalb eine durchgängige Prozess-, Methoden- und Tool- (PMT) Landschaft für Unternehmen unverzichtbar ist. Gleichwohl bleibt eine vollkommen homogene PMT-Struktur auch künftig eine Illusion – zu unterschiedlich sind die Anforderungen der verschiedenen Domänen an ihre Implementierungs- und Absicherungsmethodik und damit auch an einzusetzende Methoden und Tools. Welche Rolle spielt an dieser Stelle der konsequente Einsatz von DevOps als Lösungsansatz?
Sebastian Heinemann: „Zunächst kurz etwas zum Hintergrund von DevOps: Unter diesem aus ‚Development‘ und ‚Operations‘ zusammengesetzten Begriff verstehen wir den Ansatz, innerhalb einer Organisation eine Kultur zu schaffen, die sich durch Eigenverantwortlichkeit und Zusammenarbeit auszeichnet. Ursprünglich entstand die Idee hierzu in IT- und softwarebasierten Technologieunternehmen. Heute wird DevOps meist lediglich als Methodik und Tooling zur Hochautomatisierung der Entwicklungsprozesse verstanden, um die Entwicklung und den Betrieb softwarebasierter Produkte zu beschleunigen beziehungsweise performanter zu gestalten. In der Automobilindustrie sind die DevOps-Ansätze mittlerweile etabliert und werden als Enabler wahrgenommen, damit wir künftig ‚software-defined cars‘ entwickeln können. Was jedoch häufig noch fehlt, ist eine Hilfestellung für die Entwickler, also eine Automatisierung die sie wiederum sicher durch die Prozesse führt und sie im Arbeitsalltag entlastet. Hierfür haben wir unser Process Automation Kit (PAK) entwickelt. Damit ermöglichen wir, dass die Entwickler mehr Zeit für wertschöpfendes, eigenverantwortliches Arbeiten haben und einzuhaltende Richtlinien und Prozesse trotzdem verlässlich bedient werden. Gleichzeitig erhöhen wir die Qualität der Eingangsartefakte für die CI Pipeline, damit möglichst wenige Builds fehlschlagen, was andernfalls meist immer manuelle Nacharbeiten zur Folge hätte.“
Wie genau sieht eine solche Hochautomatisierung von Entwicklungsprozessen durch DevOps aus?
Sebastian Heinemann: „Bei DevOps-Ansätzen werden Tools und agile Zusammenarbeitsmodelle geschickt kombiniert. Das sorgt neben einer höheren Geschwindigkeit gleichzeitig auch für eine geringere Fehlerrate in der Entwicklung und im Betrieb neuer Softwareprodukte. Die einzelnen Schritte der Entwicklung (plan, code, build, test, release, deploy, operate, monitor) greifen dabei nahtlos ineinander und bilden die Phasen der DevOps-Pipeline. Durch die Einbettung der DevOps-Pipeline in eine Infrastruktur aus Continuous Integration, Continuous Testing, Continuous Delivery und Monitoring erreichen wir zusätzlich Geschwindigkeit und Skalierbarkeit: Nimmt beispielsweise einer unserer Entwickler Änderungen an einem Code vor, werden diese nicht nur kontinuierlich zu einem aktuellen Stand der Software zusammengeführt, sondern können auch automatisiert ausgeführt und getestet werden. Dadurch erhält der Entwickler schnell Feedback, kann bei Bedarf anschließend wieder Änderungen am Code vornehmen und den durchgängigen Prozess entlang der DevOps-Pipeline erneut starten.“
Der Entwicklungsprozess ist also bereits stark automatisiert. Gibt es hier noch Optimierungspotentiale?
Sebastian Heinemann: „Wie schon kurz angesprochen gibt es hier definitiv noch Optimierungspotentiale: Zwar liefert DevOps mit agilem Mindset als kultureller Komponente sowie passenden Prozessen und Tools den Rahmen für die neue Form des Zusammenarbeitens. Gleichwohl bleibt bei aller Automatisierung der Mensch der entscheidende Faktor: Für die gewünschten Resultate müssen neue Prozesse von allen Beteiligten eingehalten und die DevOps-Kultur gelebt werden. Gleichzeitig geben uns Standards und Normen wie A-SPICE und ISO26262 sowie die domänenspezifischen Besonderheiten einen komplexen Rahmen vor. Die große Herausforderung – und Optimierungspotentiale – liegen deshalb darin, allen operativen Entwicklern, in ihren spezifischen Rollen als beispielsweise Requirements Engineer, Architekt, Funktions-/Softwareentwickler, Integratoren und Tester ihre Aufgaben und die Erwartungen an sie zu vermitteln. Das Resultat sind lange, spezifische Einarbeitungsphasen und operative Aufgaben, die teils rein der Prozessbefriedigung oder zeitaufwendigen Bedienung der eingesetzten Toolkette dienen. Der ursprüngliche DevOps-Gedanke, die Zusammenarbeit der Mitarbeitenden und damit ihre Kreativität und wertschöpfenden Tätigkeiten zu fördern, geraten dabei oftmals in den Hintergrund.“
Wie trägt das Process Automation Kit (PAK) von ASAP dazu bei, diese Optimierungspotentiale zu heben?
Sebastian Heinemann: „Die von uns entwickelte Automatisierungslösung setzt dort an, wo andere Lösungen aufhören: auf Entwicklerebene. Das Process Automation Kit (PAK) bietet damit die Möglichkeit, die komplexe PMT der Organisation und des Projektes auf Entwicklerebene einheitlich abzubilden, maximal zu automatisieren und rückt den Menschen in der DevOps-Pipeline in den Fokus. PAK ist deshalb für jede DevOps-geprägte Organisation oder jene, die es werden will, eine geeignete Lösung zur sinnvollen Ergänzung der eigenen Automatisierungs-Pipeline. Durch die Baukastensystematik von PAK können wir Entwicklungsschritte spezifischer Entwicklerrollen definieren, automatisieren und später für weitere Prozesse wiederverwenden. Mittels PAK kann man bis auf Organisationsebene beziehungsweise in die domänenübergreifende PMT allen Teams einen Marktplatz zur Prozessautomatisierung anbieten, der bereichsübergreifend genutzt und erweitert werden kann. So entsteht ein Methodenbaukasten, in dem alle einmal bereits entwickelten Automatisierungen für Prozessschritte, bei denen keine kreativen Leistungen der Entwickler erforderlich sind, hinterlegt sind. Alle Abteilungen greifen dann gemeinsam auf den Methodenbaukasten zurück, in dem bereits entwickelte Automatisierungen als ‚Commands‘ getestet und freigegeben hinterlegt, immer aktuell und jederzeit für neu zu entwickelnde Prozesse wiederverwendbar sind. Einmal entwickelt, lassen sich die ‚Commands‘ also beliebig oft in jedem künftigen Workflow-Modell nutzen. Demnach lassen sich neue Prozesse mit der Zeit immer schneller automatisieren, was die Lösung individuell skalierbar macht. Das Ergebnis: Die Nutzung einer einzigen Prozess-Sprache sorgt für eine einheitliche und durchgängige Prozess- und Methodendefinition aller Teams und Projekte. Mit PAK müssen Entwickler die ihrer Rolle zugeordneten Prozessschritte nicht mehr auswendig kennen und haben gleichzeitig mehr Freiraum für ihre kreative Entwicklungsarbeit. Ganz im Sinne von agilem Mindset und DevOps-Kultur befreit PAK sie von nicht wertschöpfenden Prozessschritten, führt sie durch den Entwicklungsprozess und informiert sie, sobald sie selbst aktiv werden müssen – und das alles unter Einhaltung definierter Prozesse und Quality Gates. So sorgt PAK schlussendlich neben mehr Zeit für kreative Leistung auch für gesteigerte Mitarbeiterzufriedenheit.“
Mehr zur Automatisierungslösung PAK erfahren Sie hier: Microsite PAK. Neben weiterem Informationsmaterial erwarten Sie dort unter anderem Anwenderberichte zum Process Automation Kit.