Diese Beitragsreihe basiert auf dem Artikel «Five Imperatives for Application Lifecycle Management» der IBM Rational-Mitarbeiterin Carolyn Pampino.
Ich kenne aus eigener Erfahrung die Vorteile von Kollaborationswerkzeugen in der Software-Entwicklung. Sie sind für mich die humane Version der Workflow-Werkzeuge: Sie gängeln mich nicht mit einer täglichen To-do-Liste, sondern sie bieten mir eine Arbeitsplattform, die mir und den anderen Informationen einfach zugänglich macht. Hake ich in einem Kollaborationswerkzeug einen To-Do-Eintrag ab, oder ergänze ich eine Anforderungsbeschreibung, so steht diese Information sofort allen zur Verfügung.
Übrigens sind hier mit Kollaborationswerkzeugen weniger die unter dieser Bezeichnung daherkommenden Werkzeuge wie Lotus Notes, Sharepoint oder Zimbra u.a. gemeint, sondern von ALM-Lösungen (für das Anforderungsmanagement, die Ticketverwaltung usw.), die nach den Prinzipien der Kollaborationswerkzeuge bzw. auf einem solchen gebaut sind.
Den ganzen Beitrag lesen »
Was überhaupt ist ALM?
Dass auf dem Zürcher S-Bahnnetz überhaupt Rollmaterial fährt, dass die Waggons sauber (na ja …) und funktionstüchtig sind, dass dieses Jahr nach 20 Jahren S-Bahn die dritte Rollmaterialgeneration in Betrieb geht – das ist dem «Rollmaterial-Management» zu verdanken. Es umfasst alle Tätigkeiten, um sicheres, zeitgemässes Rollmaterial in genügender Menge zum richtigen Zeitpunkt bereitzustellen.
Ersetzen Sie «Rollmaterial» durch «Anwendung» – und wir haben die ALM-Definition.
Die Definitionen sind zwar gleich, die Realität verschieden: Wäre das Lifecycle-Management der Bahn auf dem gleichen Qualitätsniveau wie jenes unserer IT-Anwendungen, läge die Zufriedenheit der Bahnkunden wohl um Einiges tiefer!
ALM als Disziplin begreiflich machen
Die IT – und innerhalb der IT die IT-Anwendungen– sind immer noch nicht überall als betriebswirtschaftliche Ressource erkannt. Jedem ist klar, dass Rollmaterial, Gebäude, Maschinen und Finanzen bewirtschaftet werden müssen. Jemand muss die Verantwortung dafür tragen, muss planen, was wann gepflegt, erneuert, ersetzt werden muss.
Welches Glück, dass IT-Anwendungen sich nicht abnutzen! Oder etwa vielmehr: welches Pech?! Das ist einer der Gründe, warum es ALM so schwer hat. Die Abnutzung eines materiellen Gutes kann jeder mit seinen Sinnen wahrnehmen, oder zumindest begreift er sie. Die physisch nicht stattfindende – aber trotzdem existierende – Abnutzung von Software und Abläufen begreiflich zu machen ist viel schwieriger! Software und Prozesse passen nicht mehr in ihre sich wandelnde Umwelt: die Anwenderbedürfnisse und Plattformen ändern, Komfortansprüche und Sicherheitsanforderungen steigen. Die Anwendungen werden erst angepasst, wenn es nicht mehr anders geht – und das ist dann meist der dümmste Augenblick – mit entsprechenden kostensteigernden Auswirkungen.
ALM schafft genau hier Abhilfe. Anstatt von den Änderungen in der Umgebung angetrieben zu werden, nimmt der ALM-Manager das Heft in die Hand, plant die Evolution der Anwendungen und setzt diese Pläne um.
Was meinen Sie: Ist das nicht der Weg, den man von einem geordneten Betrieb erwarten würde?
Der Artikel «Stiefkind der Enterprise IT» in der Computerwoche Online fasst unsere immer wieder vorgebrachten Feststellungen zum und Argumente für das ALM (Application Life Cycle Management) zusammen, bestätigt und verstärkt sie nachdrücklich.
Die Quintessenz
IT-Führungskräfte sehen das ALM als lästige Daueraufgabe und Kostentreiber, verursacht durch ein heterogenes Anwendungsportfolio. Wenn man sich jedoch klar macht, dass diese Heterogenität die Folge von Mängeln im ALM ist, so bekommt das ALM plötzlich ein neues Gesicht:
Fehlendes ALM verursacht Kosten, funktionierendes ALM hingegen ist eine lohnende Investition, um aus dem Teufelskreis unzureichender Anwendungen und horrender Wartungskosten auszubrechen.
Den ganzen Beitrag lesen »
Unter dem Titel «Release-Management – eine lästige, aber notwendige Pflicht» berichtet die Computerwoche von der erfolgreichen Einführung eines IT-gestützten Release-Managements bei der Schufa:
«Projektbezogene Dokumentationen und Konfigurationen, uneinheitliche Versionierung sowie ungestützte Change-Prozesse – so sieht das “Release-Management” in vielen Unternehmen aus. Es führt ein Schattendasein als ungeliebte und aufwändige Pflichtaufgabe im Bereich Softwareentwicklung. – Das war bei der Schufa zunächst nicht anders.»
So schildert der Bericht die Ausgangslage der Schufa, die heute ein IT-gestütztes Release-Management betreibt, «um die Qualität der Softwareentwicklung zu steigern.»
Den ganzen Beitrag lesen »
Die Hälfte der SCCM-Anwender sind mit ihrem Konfigurationsmanagement-Werkzeug nicht zufrieden.
So die Ergebnisse einer Befragung der Firma Gebert Software bei 307 Unternehmen mit über 50 Mio € Umsatz. 20 % der Befragten waren mit ihrem Werkzeug für das Software-Konfigurationsmanagement unzufrieden und 30 % nur bedingt zufrieden. Kurz: Die Hälfte hat etwas auszusetzen.
Wer vermutet, dass von der zweiten Hälfte auch nicht alle rundum zufrieden sind, liegt richtig: Nur gut 20 % der 307 Befragten sagten: ja, wir sind zufrieden, 30 % mühten sich zu einem «weitgehend zufrieden» durch.
Überträgt man diese Zufriedenheitsrate auf das Handy, das Navi oder das Auto, so wird einem bewusst, wie alarmierend diese Zahlen sind. Sie decken sich mit unseren praktischen Erfahrungen, die wir in diesem Blog schon mehrfach angesprochen haben.
Den ganzen Beitrag lesen »
Mängel im Change-Management gefährden Ihre Projekte! So eine der Lehren aus einer Studie von Capgemini.
Sie können sich die 58-seitige Studie hier kostenlos herunterladen.
Unter dem Titel «Horror-Erlebnis: Gescheiterte IT-Projekte» berichtet Computerworld Schweiz am 6. März 2009 über die Ergebnisse einer Studie. welche die Capgemini vergangenen November in den DACH-Ländern durchgeführt hat: Nur 16 Prozent der IT-Projekte lagen im Zeitplan, und 85 Prozent haben ihr Budget massiv überschritten. Mit 43 % der Nennungen steht als Grund, warum IT-Projekte scheitern, «Fehlendes Change-Management» auf dem vierten Platz der Rangliste.
(Auf den Medaillenplätzen als Projektkiller stehen: zu viele Projekte werden gleichzeitig durchgeführt; zu wenig interne Ressourcen; fachliche Ziele des Projekts unklar.)
Auch inside-it.ch hat der Studie einen Blogbeitrag gewidmet, der sie kurz und knackig zusammenfasst.
Den ganzen Beitrag lesen »
Die Wirtschaft liegt darnieder und sie spart. Machen wir’s doch so, dass dabei Produktivität und Qualität zunehmen, damit wir auch später im Aufschwung immer noch etwas davon haben. Ein Widerspruch? Nein, denn Not macht erfinderisch.
Wie Computerworld Schweiz in der Nummer 4 vom 27. Februar 2009 berichtet, hätten auf die Frage «Wie reagiert Ihre IT-Abteilung auf Budgetkürzungen?», 20 % geantwortet mit: «Wir suchen aktiv nach neuen Lösungen, die Kosten sparen.» Da liefern wir gerne Ideen! Vor allem auch an die Mitarbeiter jener 25 % der Befragten, die die Frage beantworteten mit: «Weniger Personal muss mehr arbeiten.»
Den ganzen Beitrag lesen »
Software-Entwicklung und -wartung ist teuer und reich an Risiken. Grund genug, gerade jetzt in der Wirtschaftsflaute die Kosten und Risiken im Griff zu halten und Produktivität und Qualität zu steigern.
Da sind Ideen gefragt, man muss sie nur finden. Die meisten Firmen haben viele Möglichkeiten, die Entwicklungs- und Wartungskosten zu senken. Zum Beispiel sind geographisch verteilte Entwicklungsgruppen, die viele verschiedene Werkzeuge verwenden – was an der Tagesordnung ist – unrentabel. Oder: Automatisierte Prozesse und integrierte Entwicklungs-Umgebungen senken die Entwicklungskosten ganz beträchtlich.
Den ganzen Beitrag lesen »
Auch agile Methoden brauchen SCCM. Oder gerade sie: Denn häufigere Integration bedeutet Mehraufwand und mehr Fehler. Ihnen kommt man nur mit automatisierten Prozessen bei.
Ironie und Paradox der Konstellation: Agile (schlanke) Methoden versprechen Freiheiten, rufen aber unweigerlich nach Formalismen und Kontrollen, weil sonst die befreienden Wirkungen der Agilität in Terror durch Chaos umschlagen. Die mit den agilen Methoden gezwungenermassen einhergehende kontinuierliche Integration illustriert diesen Widerspruch.
Den ganzen Beitrag lesen »
Ein Praxisbericht in der Nummer 2/2009 von ObjektSpektrum zeigt, wie eng Konfigurations-, Change- und Test-Management miteinander verbunden sind.
Der Bericht stützt unsere Auffassung, dass Konfigurationsmanagement keine Insel sein darf, sondern in die Entwicklungs- und Wartungsprozesse integriert sein muss. Die Zeitspanne von zwei Jahren verdeutlicht, mit welchem Aufwand bei solchen Vorhaben in einer Entwicklungsabteilung mit 50 Mitarbeitern zu rechnen ist.
Den ganzen Beitrag lesen »
