Stärken des Gesamtprozesses ausspielen

Markus Maurer ist bei Serena Software für die technischen Dienste in Zentraleuropa zuständig.

Akzeptanz ja - Umsetzung nein. Diesem Grundsatz folgen viele Unternehmen, wenn es um ALM-Lösungen (Application Lifecycle Management) geht. Dabei sind ihre Erwartungen an eine ALM-Lösung eigentlich klar. Sie soll alle Phasen der Softwareentwicklung, von der Anforderungs-Erfassung über Modelldesign, Codierung und Testing bis hin zur Verteilung, Installation und Konfiguration einheitlich betrachten. Wobei die Betreuung und der Betrieb von Softwareentwicklungen als Zyklus verstanden wird. Und zwar so, dass der Prozess nicht einmalig, von einem festen Anfang bis zu einem festen Ende läuft, sondern vielmehr eine Daueraufgabe bildet.

Diese logischen Anforderungen bilden die Basis für die allgemeine Anerkennung von ALM. Ernsthafte Einwände gegen das Konzept als solches werden kaum vorgebracht. Eckpunkte wie Nachvollziehbarkeit, Prozess-automatisierung, Reporting, dazu Skalierbarkeit und Plattformunabhängigkeit der Lösung, bilden heute die Grundlage der Softwareentwicklung. Dennoch hinkt die praktische Umsetzung von ALM der -Theorie meilenweit hinterher.

Analysen von Forrester Research zufolge sind zwar drei Viertel der IT-Entscheider in Europa und Amerika mit dem Begriff ALM vertraut. Dennoch nutzen nur 29 Prozent der Befragten entsprechende Lösungen auch tatsächlich in der Praxis. Und nur acht Prozent der Befragten geben an, ALM in naher Zukunft einsetzen zu wollen.

Zahlen, die belegen, dass die Umsetzung von ALM nur schleppend vorankommt. Hauptursache: Obwohl das Thema schon fast zehn Jahre diskutiert wird, sind wirklich umfassende ALM-Lösungen Mangelware - was die Zurückhaltung der Anwender verständlich macht. Zwar verfügen viele ALM-Anbieter über ein umfangreiches Portfolio, das auch meist im Hinblick auf den Gesamtprozess zusammengestellt ist und mit seinen Tools alle typischen Entwicklungs-phasen abdeckt. Aber bei der Integration der Werkzeuge in den Gesamtprozess eines Unternehmens hapert es noch viel zu oft.

Damit jedoch die breite, theoretische Akzeptanz in vermehrten Praxiseinsatz mündet, muss die Kluft zwischen Anspruch und Realität geschlossen werden. Das heisst: Die nächste Generation von ALM - Forrester spricht von ALM 2.0 - muss flexibler und konsequenter prozessorientiert aufgegleist werden, als bisher.

Um zu erkennen, weshalb ein solches «ALM-Upgrade» unumgänglich ist, lohnt der Blick zurück. Nachdem lange Zeit die Programmiersprachen und IDE (Integrated Development Environment) die Entwicklung beherrscht hatten, begannen die Unternehmen Anfang der Neunziger Jahre, die Entwicklung zu professionalisieren. Damals konnten sich zahlreiche Lösungen für Change, Configuration oder Release Management etablieren Lösungen, die oft heute noch im Einsatz sind. So erfolgreich dieser Ansatz im Kampf um schnellere und bessere Softwareentwicklung auch war - er brachte nur einen Teilerfolg, denn er blieb auf Einzel-aspekte beschränkt und vernachlässigte den Gesamtprozess. In der Folge führte die wachsende Bedeutung von Software für die Geschäftsprozesse und die zunehmende Globalisierung der Unternehmen zu stetig steigenden Anforderungen an neue Software und an deren Entwicklungsprozess. Die von verteilten Entwicklerteams erstellten, immer komplexeren Systeme machten es nötig, den Gesamtprozess besser zu unterstützen. An dieser Stelle positionierte sich ALM als Ausweg, indem es Werkzeuge verfügbar machte, die beanspruchten, den Gesamtzyklus einer Softwareentwicklung ganzheitlich betrachten zu können.

Doch weshalb sind umfassende ALM-Lösungen nach wie vor Mangelware? Der Grund dafür liegt bei den Anbietern. Sie haben sich ihr ALM-Portfolio häufig durch den Zukauf von Spezialfirmen zugelegt - weshalb die einzelnen Teile des ALM-Werkzeugkastens oft nur oberflächlich integriert sind. Gelegentlich ist nicht mehr als eine einheitliche Benutzerschnittstelle vorhanden. In der Regel fehlt zudem eine durchgängige Prozesssteuerung für alle Phasen des Lifecycle.

Wenn aber gerade die Prozesssteuerung stottert, ist der Nutzen von ALM, beispielsweise gegenüber hoch entwickelten Einzel-tools oder Open-Source-Produkten, gefährdet. Denn ALM ohne die Integration der Lifecycle-Tools ist arbeitsintensiv und fehleranfällig. Und das traditionelle ALM hat noch weitere Schwachstellen:

oTools: Die Tools werden vorwiegend durch die Verwendung eines gemeinsamen Repository integriert; die Zusammenlegung von Repository aber ist aufwändig, und viele Unternehmen sind auf mehrere Repository angewiesen.

o Features: Die einzelnen ALM-Tools beinhalten redundante und inkonsistente Features, sind im Zyklus schlecht aufeinander abgestimmt und überschneiden sich in ihrer Infrastruktur, etwa bei der Workflow-Kontrolle, Reporting und Analyse.

o Rollenverteilung: Die in vielen ALM vorgegebenen Rollen sind für den Praxiseinsatz klar zu starr. Die nötigen Anpassungen machen aber die Prozesse noch komplexer als sie ohnehin schon sind.

o Prozesse: Prozesse auf fachlicher Ebene sind in den Tools abgebildet, während übergeordnete Prozesse nur auf der Integrationsebene angesiedelt sind; eine durchgängige Prozesssteuerung fehlt und die Prozess-Assets können nicht versioniert werden.

Nun soll endlich eine neue Generation des ALM-Konzeptes diese Problemstellen beseitigen. Der Prozess der Softwareentwicklung soll wesentlich breiter organisiert und steuerbar werden. Dabei werden an ALM 2.0 folgende Anforderungen gestellt:

o Neutralität des Repository: Anwender müssen sich nicht auf ein bestimmtes Repository festlegen, sondern können unterschiedliche nebeneinander einsetzen. Das schafft Flexibilität und senkt die Kosten für das Einbringen existierender Lösungen, weil Objekte nicht migriert werden müssen.

o Standardisierung: Die Verwendung offener Integrations-Standards (XML, Web Services etc.) vereinfacht die Integration der einzelnen Tools.

o Allgemeine Services: Funktionen wie Reporting, Auswertung und Sicherheit müssen auf der Fachebene präsent sein.

o Steuerung: Prozesse auf fachlicher und Integrationsebene werden durch einen externen Workflow gesteuert, der beispielsweise auch Versionierung, Auditing und Reporting ermöglicht.

o Aufbau: Die Tools müssen einfacher werden und sich leichter integrieren lassen.

Mögen die Forderungen im Einzelnen noch zu diskutieren sein, erfassen sie im Kern doch unstrittige Punkte: Es braucht flexiblere Werkzeuge für Einzelaufgaben und die Prozesssteuerung muss eine grössere Rolle spielen. Bedeutsam werden künftig zudem Themen wie Project Portfolio, Issue und Security Management sowie Aspekte des operativen Betriebs. Daher werden sich alle Anbieter auf ALM 2.0 einstellen müssen. Die Techniken für ALM scheinen langsam die nötige Reife zu erlangen, die den Firmen ermöglicht, an ALM nicht nur in der Theorie Freude zu haben. Die konsequente Prozessorientierung ist ein wichtiger Meilenstein. Erste Anbieter haben ihn bereits realisiert.