Software Delivery Management: Den Software-Bereitstellungsprozess überdenken

Anbieter zum Thema

MicroConsult Academy GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Software wird zunehmend in Unternehmen und gesellschaftliche Prozesse integriert. Dementsprechend entwickelt auch sich die Art und Weise weiter, wie diese entworfen, geschrieben und bereitgestellt wird. „Software Delivery Management“ oder kurz SDM gibt diesem neuen Ansatz einen Namen.

Innovationen und neue Denkweisen benötigen Zeit, um auszureifen und sich in der Praxis durchzusetzen. So verhielt es sich auch bei der kabellosen Kommunikation, den sozialen Medien und aktuell der praktischen Umsetzung des Internet of Things (IoT). Ein weiteres Konzept, dessen Umsetzung in der Praxis noch bevorsteht, ist ein neuer Ansatz für die Bereitstellung von Software.

Der Bereitstellungsprozess von Software ist heute wesentlich komplexer als früher, da weitaus mehr Ressourcen und Module beteiligt sind. Wurden die verschiedenen Aspekte der Bereitstellung in der Vergangenheit häufig als separate Teile betrachtet, wird heute mehr darüber nachgedacht, wie diese am besten zusammenarbeiten. Dieser Umstand führt zur Etablierung von Software Delivery Management (SDM).

Diese neue IT-Kategorie fasst all jene Teams, Werkzeuge, Informationsquellen und Prozesse, die an der Bereitstellung von Software beteiligt sind, unter einem Dach zusammen. Ineffizienzen, die sich im Laufe der Jahre angesammelt haben, lassen sich mit SDM identifizieren und beseitigen. Dadurch richtet sich der Bereitstellungsprozess stärker darauf aus, dem Unternehmen einen echten Mehrwert zu liefern und die Organisationsressourcen auf gemeinsame Ziele zu fokussieren.

Der Weg zum SDM

Jahrzehntelang war die IT in zwei Lager gespalten: Hardware und Software. Teilweise ist das noch heute der Fall. Analysiert wurde vor allem der Output der beiden Lager. Experten verfolgten, wie viele Computer ein großer Hersteller wie IBM oder Digital Equipment Corp. gefertigt hatte oder wie viele Software-CDs Microsoft produziert hatte.

Jedes Unternehmen hatte seine eigenen Methoden, Produkte auf den Weg zu bringen. Zur Steuerung dieser Prozesse kamen Managementmethoden wie TQM („Total-Quality-Management“) zum Einsatz. Den konkreten Schritten, die Unternehmen auf diesem Weg unternahmen, wurde von außen jedoch nur wenig Aufmerksamkeit geschenkt.

All dies wandelte sich, als sich auch die Rolle von Software zu verändern begann: Das Internet, Smartphones und vielseitigere Betriebssysteme öffneten den Softwaremarkt für jedermann. Softwarehersteller, Lieferanten wie SAP und Anwenderunternehmen, haben die einzelnen Aspekte des Auslieferprozesses fortlaufend verbessert. Es wurden Teams mit Spezialisten geschaffen, die Software-Anwendungen untersuchen, planen, entwickeln, programmieren, integrieren, testen oder vermarkten konnten. Dabei griffen die Unternehmen auf eine Vielzahl an Werkzeugen für spezifische Aufgaben zurück und implementierten Prozesse wie Continuous Integration und Continuous Delivery (CI/CD).

Diese Weiterentwicklungen brachten die Software dorthin, wo sie heute ist: Unternehmen stellen Anwendungen kurzfristig bereit und aktualisieren diese kontinuierlich. Operative Teams arbeiten mit Entwicklern zusammen und Unternehmen tun ihr Bestes, um Kundenbedürfnisse zu antizipieren sowie Qualitäts-Kontrollmechanismen zu etablieren. Software hat eine Rolle übernommen, die viele nicht für möglich gehalten hätten. Und dennoch weist der Bereitstellungsprozess immer noch erhebliche Schwächen auf.

Isoliert in Silos

Viel zu oft noch werden zusammengehörende Module in Betrieben voneinander getrennt. Tools und Anwendungen funktionieren nicht zusammen. Teams sprechen nicht ausreichend miteinander. Informationen werden in Silos isoliert, die jeweils nur Teilen der Organisation zugänglich sind, und gemeinsam genutzte Daten werden nicht regelmäßig aktualisiert.

Unterbrechungen wie diese verursachen eine Art „Welleneffekt“ in der gesamten Organisation. Projekte verzögern sich dadurch, und schlimmer noch, Anwendungen werden mit Fehlern und/oder Schwachstellen ausgeliefert. Weil Entwickler eingangs nicht über den aktuellen Informationsstand verfügten, müssen sie ganze Initiativen neu starten, um ein richtiges und gutes Ergebnis zu erzielen. So verwundert es nicht, dass Entwickler ebenso frustriert sind wie die Führungskräfte, die oft nur sehen, dass ihre Teams die Ziele nicht erreicht haben.

Die Verantwortung dafür liegt im Gesamtprozess. Sie liegt nicht bei einem Team, nicht bei einem bestimmten Werkzeug und auch nicht bei einen ungeeigneten Plan. Ein Entwicklerteam kann großartige Arbeit mit den besten Tools gemäß eines gut durchdachten Plans leisten. Allerdings wird das Projekt zwangsläufig Probleme bekommen, wenn die Produktentwickler die Software-Entwickler mit veralteten Informationen versorgt haben und sich ein Testwerkzeug nicht mit einer Tracking-Datenbank integrieren lässt.

Ganzheitliche Perspektive auf die Bereitstellung

Um derlei Probleme zu vermeiden, bedarf es einer ganzheitlichen Perspektive auf das Konzept der Softwarebereitstellung, denn alles ist mit allem verbunden. Software Delivery Management bildet diese Verbindungen transparent ab. Eine Reihe von Eckpfeilern zur Vereinheitlichung von Daten, Erkenntnissen, Prozessen und Funktionen richtet ganze Organisationen neu auf gemeinsame Ziele aus – und generiert damit einen veritablen Mehrwert.

* Anders Wallgren ist Vizepräsident Technologie-Strategie bei CloudBees. Er verfügt über mehr als 30 Jahre fundierte Erfahrung im Konzipieren und Entwickeln kommerzieller Software. Bevor er zu CloudBees kam, bekleidete Wallgren Führungspositionen bei Electric Cloud, Aceva, Archistra und Impresse. Als Manager bei Macromedia war er maßgeblich an Lösungen wie dem Director und verschiedenen Shockwave-Produkten beteiligt.

Continuous Delivery für embedded C/C++-Entwickler

5 Best Practices für Continuous Delivery bei der Embedded-Entwicklung

Dieser Beitrag erschien zuerst auf unserem Partnerportal Dev-Insider.de.

(ID:46845598)