Table of Content
Das Application Lifecycle Management (ALM) ist ein Top-Down-Prozess, der von den Entwicklern, Testern und IT-Mitarbeitern, die ihn nutzen mussten, abgelehnt wurde. ALM hat seinen Ursprung in industriellen Fertigungsverfahren, wie z. B. der Product Lifecycle Management Software (PLM), und war niemals richtig für die Softwareindustrie geeignet. In letzter Zeit haben Prozesse wie das Continuous Deployment begonnen, die traditionellen ALM-Verfahren und Tools zu verdrängen. Dieser Artikel befasst sich mit den Gründen für das Wachstum des Continuous Deployments und warum Sie sich dafür entscheiden sollten.
Wasserfälle und Silos: ALM-Prozess & -Verfahren
ALM umfasst die Phasen Planung, Design, Implementierung, Testing, Auslieferung und Wartung im Lebenszyklus einer Anwendung. Werfen wir einen Blick auf den ALM-Prozess und die Tools, die für diesen Prozess verwendet werden.
ALM-Prozess
Jede Phase des ALM-Prozesses wird nacheinander von verschiedenen Teams nach dem Wasserfall-Entwicklungsmodell durchgeführt. In größeren Unternehmen wird dieser Prozess oft von Business-Analysten initiiert, die festlegen, dass ein bestimmtes Produkt oder eine bestimmte Dienstleistung benötigt wird. Die Analysten sammeln Business-Anforderungen, die dann an das Design-Team übergeben und in funktionale Anforderungen umgesetzt werden, welche für das Design einer Systemarchitektur und Spezifikationen verwendet werden. Wenn das Design fertig ist, wird es einem Entwicklungsteam zugewiesen, das den Code schreibt und das Design implementiert. Nachdem der Code geschrieben und die Anwendung erstellt wurde, beginnt die Testphase, nach der die Anwendung zum Release an das Deployment-Team übergeben wird.
An dieser Stelle sehen wir bereits eine Reihe gängiger Probleme, die mit der Implementierung des ALM-Prozesses verbunden sind. Zunächst einmal basiert er auf einem industriellen Supply-Chain-/Produktionslinienmodell, welches davon ausgeht, dass wesentliche Komponenten unter Einhaltung strenger Terminvorgaben geliefert werden. Jeder, der am Softwareentwicklungsprozess beteiligt ist, ist sich bewusst, dass nichts jemals pünktlich geliefert wird und es immer zu Verzögerungen kommt. Zu allem Überfluss ist der ALM-Prozess auf spezialisierte Teams angewiesen, die sich um jede Phase kümmern. Im Idealfall sollte der Prozess horizontal ablaufen, wobei Informationen und Ergebnisse von einer Gruppe zur nächsten fließen. Die einzelnen Teams aus Analysten, Designern, Entwicklern und Testern teilen sich jedoch im Laufe der Zeit auf und bilden vertikale Silos. Die Teams kommunizieren nicht und entwickeln oft Feindseligkeiten gegeneinander.
ALM-Tools
Eine gängige Methode, um die dem ALM innewohnenden Probleme zu überwinden, besteht darin, Tools zu erstellen oder zu kaufen. Dies führt jedoch oft zu einer Reihe neuer und anderer Probleme, auch wenn Unternehmen ihre ALM-Lösung aus Best-of-Breed- oder integrierten Systemen auswählen.
Der Best-of-Breed-Ansatz basiert auf der Annahme, dass Sie das beste Produkt in seiner vorgesehenen Kategorie oder Unterkategorie auswählen können. Theoretisch ist das Endergebnis dieses Ansatzes ein System, bei dem die Summe jeder Komponente ihre Einzelteile übersteigt. In der Praxis kommt dies nur selten vor, da die Integration von Produkten verschiedener Hersteller immer schwierig und frustrierend vonstatten geht. Wie in der Softwareindustrie üblich, gibt es eine Phase der Konsolidierung, in der die kleineren Anbieter vom marktbeherrschenden Anbieter übernommen werden. Theoretisch sollte dies dazu führen, dass man Best-of-Breed-Produkte von einem einzigen Anbieter auswählen kann, der sich um die Integration, Wartung und Unterstützung jedes einzelnen Produkts in seinem umfangreichen und wachsenden Portfolio kümmert. Leider sieht die Realität so aus, dass dieses Ergebnis, wenn auch möglich, äußerst selten ist.
Ein integriertes ALM-System ist bestrebt, alle wichtigen Teile des ALM-Prozesses in einem einzigen Paket zur Verfügung zu stellen. So sollen Anwender Anforderungen, Tests und Fehler über ein einziges Produkt verwalten können. Aber der integrierte Ansatz ist ein Alleskönner, der nirgendwo der Beste ist. Wenn das Produkt beispielsweise von einem Unternehmen entwickelt wurde, das sich auf Software-Testtools, spezialisiert hat, ist es sehr wahrscheinlich, dass das Testmanagement-Modul weitaus besser ist, als die Module für Anforderungen und Fehler. Dies hat zur Folge, dass sich die Anwender für das kleinere von zwei Übeln entscheiden müssen: zu versuchen, mit weniger geeigneten Tools ihres gewählten Herstellers zu arbeiten oder zusätzliche Tools von Drittanbietern einzubinden. Das bedeutet, dass eine Organisation, die sich für einen integrierten Ansatz entscheidet, tatsächlich eine Best-of-Breed-Lösung erhält.
Continuous Alles: Integration, Delivery und Deployment
In den letzten zwanzig Jahren hat sich ein ganz anderer, basisorientierter Ansatz zur Steuerung des Softwareentwicklungsprozesses. Nach der Veröffentlichung des Agile Manifesto kamen eine Reihe von neuen Methoden und Verfahren aus der Entwicklungs-Community. Dazu gehörten Agile, DevOps, Lean Startup, Open-Source und testgetriebene Entwicklung. Parallel dazu veränderten neue web- oder cloudbasierte Technologien, wie Git, GitHub, Paketmanagement, Testautomatisierung, virtuelle Maschinen und Container, die Art und Weise der Softwareentwicklung. Im Laufe der Zeit führten diese Entwicklungen zu neuen Möglichkeiten der kontinuierlichen Integration und Bereitstellung von Software, die in Continuous Delivery und Deployment gipfelten.
Continuous Delivery zielt darauf ab, auf Continuous Integration aufzubauen und die Lücke zwischen dem Schreiben von Anwendungsquellcode und dem Live-Deployment dieses Codes für Anwender von softwarebasierten Produkten und/oder Diensten zu verringern. Um dieses Ziel zu erreichen, muss eine „Delivery Pipeline“ aufgebaut werden, die die erforderliche Infrastruktur für die Erstellung, das Testen, das Release und das Deployment von Produktivsoftware in großer Häufigkeit bereitstellt. Viele Continuous Deployment-Fachleute erstellen den Produktivcode nicht nur, sondern aktualisieren ihn auch mehrmals täglich. Um dies zu bewerkstelligen, setzt der Prozess auf die Einbindung von Software für das Open-Source-Testing, die Quellcodekontrolle, den Build und das Deployment, um einen hoch automatisierten und effektiven Prozess zu schaffen.
Im Allgemeinen haben kontinuierliche Prozesse (Integration, Delivery und Deployment) bessere und konsistentere Ergebnisse erzielt als ALM-basierte Prozesse. Ein wesentlicher Grund für die weite Verbreitung dieser neuen Verfahren ist die allgemeine Akzeptanz der agilen Entwicklung. Agile ist keine umstrittene Randbewegung mehr und hat sich im Mainstream etabliert. Sie finden die Fachleute in den kleinsten Start-ups bis hin zu Großunternehmen und in einigen Fällen sogar im öffentlichen Sektor. Jetzt, da agile Verfahren weitgehend akzeptiert sind, haben Entwickler Tools entwickelt, die auf agilen Idealen basieren. Und viele dieser Tools wurden von den Leuten entwickelt und gewartet, die sie täglich benutzen, so dass sie einfach zu erweitern und mit anderen Open-Source-Tools zu integrieren sind.
Im Laufe der Zeit sind diese Werkzeuge ausgereift und zu den Grundbausteinen der modernen Anwendungsentwicklung geworden. So können sich Entwickler heute darauf konzentrieren, Produkte zu liefern und Ergebnisse zu erzielen, anstatt sich mit komplizierten Prozessen zu beschäftigen. Und Kunden und Anwender erhalten neue Produkte und Funktionen mit der zusätzlichen Möglichkeit, ihr Feedback in nahezu Echtzeit zu geben. Dies bedeutet, dass sobald ein Anwender ein Problem mit einer Anwendung entdeckt und die Entwickler benachrichtigt, die Entwickler das Problem beheben und eine neue, verbesserte Version des Produkts schneller als je zuvor releasen können.
Bereitstellung von kontinuierlichen Verbesserungen
ALM war in vielerlei Hinsicht ein Versuch, den Entwicklungsprozess zu zähmen, indem man versuchte, die totale Kontrolle darüber zu erlangen. Eine Methode zur Realisierung dieser Kontrolle bestand darin, Anforderungen zu sammeln und sicherzustellen, dass die endgültige Umsetzung diese erfüllte. Eine weitere wichtige Methode bestand darin, die Projektmanager immer am Puls des Projekts zu halten, indem sie eine Reihe von Kennzahlen definierten und die Key Performance Indikatoren (KPIs) überwachten.
In der agilen Welt von heute ist das Management von Anforderungen und Metriken weitgehend in den Hintergrund getreten, aber diese beiden Bereiche sind nach wie vor von entscheidender Bedeutung für die Entwicklung und Implementierung von hochwertiger Software. Um erfolgreich zu sein, muss eine Anwendung oder ein Dienst nach wie vor den Anforderungen ihrer Anwender entsprechen. Darüber hinaus ist die Delivery-Toolkette, die zur Erstellung moderner Anwendungen verwendet wird, hoch automatisiert und erfordert Instrumentierung, d. h. Überwachung und Metriken. Hier kann eine Enterprise Agile Delivery (EAD) -Lösung, wie Panayas Release Dynamix (RDx) unterstützen. RDx ermöglicht es Ihnen, Anforderungen zu verwalten und den gesamten Delivery-Prozess mit agilen Methoden sowie DevOps Continuous-Tools zu steuern, um erstklassige Software zu erzeugen.
Zusammenfassung: Die Kombination des Besten aus beiden Welten
ALM mag eine unvollkommene Methode gewesen sein, die bestenfalls zu gemischten Ergebnissen geführt hat, aber es war ein Versuch, Ordnung in das damals herrschende Chaos bei der Bewältigung von Software-Entwicklungsprojekten zu bringen. Dieser Beitrag kommt zu dem Schluss, dass ALM-Prozesse bestehende Probleme wie Kommunikationsausfälle und Abschottung verschärft haben und dass viele Organisationen versucht haben, die Komplexität von ALM mit teuren und komplizierten Tools zu überwinden. In beiden Fällen haben weder die Prozesse noch die Tools die Dinge verbessert und in vielen Fällen sogar verschlechtert.
Heute befinden wir uns in einer neuen Welt der Continuous Integration, Delivery und Deployment. DevOps-Prozesse gelten als die endgültige Umsetzung der agilen Bewegung. Dennoch gibt es Erkenntnisse aus ALM, von denen Teams und Organisationen bei der Implementierung und Erweiterung kontinuierlicher Prozesse profitieren können. Durch den Einsatz neuer Frameworks, wie Enterprise Agile Delivery und neuer Tools, wie Panayas Release Dynamix, können Sie das Beste aus beiden Welten kombinieren, um zukunftsweisende und hochwertige Anwendungen zu erstellen.
Lesen Sie mehr darüber, wie Agile und DevOps den Erfolg fördern sowie einige Best Practices für Enterprise Agile Delivery, im kostenlosen Forrester-Bericht The State of Agile 2017: Agile at Scale.