20071112za Application Lifecycle Management ALM 2.0 Serena

Obwohl sich ALM allgemeiner Akzeptanz erfreut, bleibt die praktische Umsetzung hinter den Erwartungen zurück. Für viele Unternehmen ist ALM zu starr und kann seine einzelnen Disziplinen nicht ausreichend integrieren. Ein neues ALM muss daher flexibler und vor allem konsequent prozessorientiert werden.

as Konzept des Application Lifecycle Management (ALM) hat die Welt der Softwareentwicklung in den letzten Jahren verändert. Nachdem lange die Programmiersprachen und IDEs das Thema beherrscht hatten, begannen die Unternehmen in den frühen 90er-Jahren ihre Softwareentwicklung neu zu organisierten und zu professionalisieren. Damals konnten sich zahlreiche Lösungen für Change, Configuration oder Release Management etablieren – Lösungen, die vielfach heute noch im Einsatz sind. So erfolgreich dieser Ansatz war, im Kampf um die schnellere und bessere Softwareentwicklung brachte er letztlich nur einen Teilerfolg, weil er auf Einzelaspekte beschränkt blieb und demgegenüber den Gesamtprozess vernachlässigte.

Die enorm gewachsene Bedeutung von Software für die Geschäftsprozesse und die zunehmende Globalisierung der Unternehmen führte zu steigenden Anforderungen an die Software sowie deren Erstellungsprozess. Die von verteilten Entwicklungsteams erstellten, immer komplexeren Systeme erfordern zunehmend den Gesamtprozess der Softwareentwicklung angemessen zu unterstützen. Nur so ist es möglich, Software in der erforderlichen Qualität und zugleich mit vertretbaren Kosten zu erstellen. Eine These , die sich durch die Probleme in vielen früh gestarteten Offshoring Entwicklungsprojekten eindrucksvoll belegen lässt.

Im Application Lifecycle Management werden in modernen Werkzeugen erstmals alle Phasen der Entwicklung, von der Erfassung der Anforderungen, über Modelldesign, Codierung und Test bis zum Deployment in einer ganzheitlichen Sicht betrachtet. Gleichzeitig unterstrich der Begriff des »Zyklus« auch, dass ein derartiger Entwicklungsprozess nicht einmalig von einem festen Anfang bis zu einem festen Ende läuft, sondern eine Daueraufgabe bildet.

ALM erfreut sich heute allgemeiner Anerkennung. Ernsthafte Einwände gegen das Konzept als solches werden in der IT-Welt nicht vorgebracht. Eckpunkte des Konzepts, wie Nachvollziehbarkeit, Prozessautomatisierung, Reporting, dazu Skalierbarkeit und Plattformunabhängigkeit der Lösung, bilden heute die Grundlage der Softwareentwicklung. Zumindest in der Theorie, denn in der Praxis entsteht oft der Eindruck, als sei ALM vor allem ein beliebtes Schlagwort. So gaben einer Forrester-Studie vom Frühjahr 2006 zufolge rund Dreiviertel der IT-Entscheider in Europa und Amerika an, mit dem Begriff ALM vertraut zu sein. Sobald aber nicht nur ein unverbindliches Bekenntnis zu einer anerkannten Technologie abgefragt wird, sondern die Frage nach konkreten Projekten gestellt wird, ergeben sich eher ernüchternde Zahlen: Nur 29 Prozent der Befragten nutzen laut dieser Studie tatsächlich ALM, vom Rest hatten lediglich 10 Prozent vor, im Lauf des nächsten Jahres einzusteigen. Obwohl das Thema ALM mittlerweile seit fast einem Jahrzehnt diskutiert wird und im Grundsätzlichen durchaus Einigkeit besteht, kommt die Umsetzung offenbar nur schleppend voran.

Tatsache ist, dass wirklich umfassende ALM-Lösungen noch immer selten sind. Die Zurückhaltung der Anwender ist sogar nachvollziehbar, denn viele Anbieter im ALM-Markt verfügen zwar über ein umfangreiches Portfolio, sie haben dieses meist im Hinblick auf den Gesamtprozess zusammengestellt und decken mit ihren Werkzeugen die typischen ALM-Phasen ab, an einer wirklichen Integration der Tools hapert es jedoch oft. Bei vielen Anbietern entstand das ALM-Portfolio durch die Übernahmen der jeweiligen Spezialanbieter, mit dem Ergebnis, dass die einzelnen Teile des Werkzeugkastens nur oberflächlich integriert sind. Mancher Hersteller meinte, mit der Schaffung einer einheitlichen Benutzerschnittstelle sei die wichtigste Arbeit schon erledigt. Auch wenn einzelne Tools verbunden sind, eine echte, durchgängige Prozesssteuerung, die alle Phasen des Life-Cycle vollständig abdeckt, ist in der Praxis selten, erst recht wenn die Werkzeuge von verschiedenen Herstellern stammen. Das Versprechen, dass das Ganze mehr sein müsse als die einzelnen Teile, konnte ALM bislang nicht einhalten.

Für die Anwender steht jedoch der Nutzen in Frage, den eine ALM-Lösung gegenüber hoch entwickelten Einzeltools beziehungsweise Open Source-Produkten bringen kann, wenn gerade die Steuerung des Prozesses stottert. Die erwähnte Forrester-Studie weist denn auch darauf hin, dass ALM ohne die Integration der Life-Cycle-Tools, arbeitsintensiv und fehleranfällig sei. Kein Wunder also, dass sich die Unternehmen bei der Realisierung von ALM zurückhalten.

Bei herkömmlichem ALM sind die Werkzeuge meist nur unzureichend integriert.

Die Schwachstellen des traditionellen ALM, Forrester spricht von ALM 1.0, die eine praktische Umsetzung einschränken, lassen sich unschwer aufzeigen:

· Tools werden vorwiegend durch die Verwendung eines gemeinsamen Repository integriert. Die Zusammenlegung von Repository ist aufwendig und viele Unternehmen sind auf mehrere Repository angewiesen.

· Die einzelnen ALM-Tools beinhalten redundante und inkonsistente Features. Viele Werkzeuge im Zyklus sind unzureichend aufeinander abgestimmt und überschneiden sich in ihrer Infrastruktur, also zum Beispiel bei der Workflow-Kontrolle, beim Reporting, bei Analyse, Sicherheit usw.

· Rollenbasierte Tools sind zu wenig flexibel. Die Rollen im Entwicklungsprozess unterscheiden sich stark von Unternehmen zu Unternehmen, so dass von den Anbietern vorgegebene Rollen zu oft starr sind. Die Unternehmens-IT muss dass entweder den Rollen an die Tools anpassen oder für bestimmte Rollen separate Tools einsetzen, mit dem Ergebnis, dass der Prozess noch komplexer wird.

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

Eine neue Stufe für ALM – ALM 2.0 wie Forrester es nennt – mit der Unternehmen in die Lage versetzt werden, den Prozess der Softwareentwicklung in der gesamten Breite zu organisieren und zu steuern, muss diese Problemstellen beseitigen. Dabei werden folgende neue Anforderungen gestellt:

· Neutralität des Repository: Anwender müssen sich nicht auf ein bestimmtes Repository festlegen, sondern können unterschiedliche nebeneinander einsetzen. Dies schafft mehr Flexibilität und senkt die Kosten des Einbringens von vorhandenen Lösungen, wie die Objekte nicht migriert werden müssen.

· Durch die Verwendung offener Integrations-Standards, wie XML, Web-Services oder den Standards im Rahmen des Eclipse-Projekts (ALF), lässt sich die Integration der einzelnen Werkzeuge stark vereinfachen.

· Allgemeine Services wie Reporting, Auswertung, Sicherheit usw. müssen in den Tools auf der Fachebene präsent sein.

· Prozesse auf fachlicher und auf Integrationsebene werden durch einen externen Workflow gesteuert, für die auch Versionierung, Auditing und Reporting möglich ist.

· Generell müssen die Tools einfacher werden und sich leichter zusammenführen lassen. Hier hat Eclipse mit seinen Plug-Ins schon einige Vorgaben gemacht, an denen sich alle Hersteller werden orientieren müssen.

Solche Forderungen mögen im Einzelnen noch zu diskutieren sein, im Kern erfasst ALM 2.0 jedoch wesentliche Punkte, so die Notwendigkeit der Verwendung flexiblerer Werkzeuge für Einzelaufgaben, vor allem aber die stärkere Rolle der Prozesssteuerung. Diese muss künftig nicht nur alle Phasen sondern auch alle Ebenen des Life-Cycle erfassen und dabei den einzelnen Tools nicht nur konsistente Workflows anbieten, sondern dazu ein komplette Infrastruktur von allgemeinen Services. Ein weiterer wichtiger Punkt ist die Einbeziehung von bisher im Rahmen der Softwareentwicklung erst recht wenig beachteten Themen wie Project Portfolio, Issue und Security Management oder des operativen Betriebs.

Zur Steuerung des Gesamtprozesses wird ALM künftig über eine homogene Infrastruktur verfügen

Wie eine derartige Integration funktionieren kann, zeigt das Projekt Application Lifecycle Framework (ALF), das ALM mit dem Eclipse Framework verbindet. Wurden ALM-Werkzeuge früher als Plug-ins in das Eclipse-Framework integriert, so erweitert das ALF-Projekt das Framework zu einer kompletten Infrastruktur für die nahtlose Interoperabilität der Tools von Tool zu Tool.

Nach und nach werden sich alle Anbieter im ALM-Markt auf ALM 2.0 einstellen müssen. Einige Hersteller haben ja bereits ein stärkeres Gewicht auf das Prozessmanagement gelegt, so beispielsweise Serena, das die Funktionen seiner Lösungen konsequent über Web-Services anbietet und mit der Prozesslösung TeamTrack eine flexible und prozessorientierte Integrationsebene als eine Art Prozess-Backbone für den gesamten ALM anbietet. Diese erlaubt ein flexibles Einklinken von beliebigen ALM-Tools, denn spezifische Präferenzen werden in den meisten Unternehmen auch künftig eine große Rolle spielen; die unternehmensweite ALM-Lösung aus der Box ist oft eher Utopie als Wirklichkeit. Moderne ALM-Lösungen machen es jedoch bereits heute wesentlich leichter, die vorhandenen Strukturen im Unternehmen in einen Gesamtprozess zu integrieren und erlauben es Themen wie zum Beispiel Outsourcing oder Offshoring effizient zu managen. Unabhängig von der verwendeten Technologie sollten Unternehmen die fachlichen und organisatorischen Voraussetzungen einer ALM Initiative nicht unterschätzen.

Wie auch im Bereich SOA, wo zwischen dem ersten »Hype« und der tatsächlichen Umsetzung in den Unternehmen auch fast eine Dekade lag, scheinen die Technologien im ALM-Markt nun so langsam auch die notwendige Reife zu erlangen und somit den Unternehmen ermöglichen an ALM nicht nur in der Theorie ihre Freude haben. Mit einer konsequenten Prozessorientierung ist ein wesentlicher Meilenstein auf dem Weg dorthin schon mal erreicht.

Markus Maurer ist Manager Technical Services Central Europe bei Serena Software.

Serena TeamTrack

Serena TeamTrack ist eine rollenbasierte Workflow-Lösung, mit deren Hilfe Prozesse aller Art gesteuert werden können. Die Lösung verwaltet die erfassten Daten und stellt an den Entscheidungspunkten den Menschen, die diese Entscheidungen treffen, visuelle Auswahlknöpfe zur Bedienung zur Verfügung.

Die Architektur von TeamTrack basiert auf einem Prozessmodell, das sich an definierten Vorgangszuständen (States) und den Übergängen (Transitions) zwischen diesen orientiert. In TeamTrack werden alle im Zuge eines Prozesses entstehenden Aufgaben in Form von Anforderungen (Requests) erfasst und durch den vorgegebenen Prozess geschleust. Der Administrator definiert grafisch über ein Drag-and-Drop-Verfahren die Prozessschritte und die Übergänge zwischen ihnen. Die Übergänge können mit verschiedenen Triggern versehen werden. Mit einem Trigger können Plausibilitätsprüfungen der im Prozess erfassten Informationen und andere Aufgaben durchgeführt werden.

TeamTrack erzeugt einen transparenten Prozess über den gesamten Lifecycle einer Applikation – angefangen von den ursprünglichen Projektanforderungen bis hin zu nachgeschalteten Support-Aktivitäten. Da die Lösung auf einer offenen Architektur basiert, kann sie problemlos mit bestehenden Tools zusammenarbeiten, um Abläufe, Kommunikation und Zuständigkeiten innerhalb des Unternehmens zu verbessern.

Change Governance

Unternehmen sehen sich ständigen Veränderungen gegenüber. Diese wirken sich auch auf die Softwareentwicklung und resultieren in Änderungsanträgen, Bugfixes, Upgrades oder neuen Anwendungen. Bei der unternehmensweiten Anwendungsentwicklung können Veränderungen ein enormes Ausmaß und entsprechende Auswirkungen auf das ganze Unternehmen haben.

Change Governance von Serena bietet mit seinen Lösungen für das Application Lifecycle Management eine ganzheitliche Strategie, die breiter angelegt ist als klassisches Change Management. Sie greift unternehmensweit und basiert auf einer durchgängigen Prozessintegration, mit der Unternehmen folgende Möglichkeiten haben:

l Visualisierung der Auswirkungen möglicher Änderungen

l Koordination geeigneter Prozesse und Richtlinien zur erfolgreichen Einbindung und Berücksichtigung aller Änderungen, die Auswirkungen auf ein Projekt haben können

l Durchsetzung dieser Prozesse und Best Practices im Unternehmen zur Erzielung von Resultaten, die die Anforderungen des Unternehmens erfüllen und vollständig prüfbar machen

Dabei hat jedes Unternehmen auf die eine oder andere Weise mit heterogenen Systemen und Plattformen zu tun. Serena bietet bewährte und führende Lösungen für die Entwicklung in verteilten Umgebungen ebenso wie in einer Mainframe-Umgebung So gilt Serena ChangeMan ZMF als De-facto-Standard für die Steuerung der Softwareentwicklung im Mainframe-Bereich, während Serena Dimensions10 im Client-Server-Umfeld größte Plattformneutralität bietet – von Betriebssystemen über Datenbanken, Server, Sprachen, Browser und mehr.

Copyright © 2003-2012 ap Verlag GmbH