Autor der beiden Blogbeiträge ist AccuRef, ein US-Hersteller von Werkzeugen für das Software-Konfigurationsmanagement:

• SCM Best Practices and Continuous Integration Go Hand-in-Hand
• Continuous Integration and Enabling Local Developer Builds

Die Beiträge sprechen Wahrheiten aus, die hüben und drüben leider noch nicht Allgemeingut geworden sind.

Versionskontrolle: Voraussetzung für Agile Entwicklung

Agile Development ohne Software-Versionskontrolle ist etwa so wirkungsvoll wie Nägel einschlagen mit der blossen Faust. Entwicklung in kleinen Inkrementen funktioniert nur, so die Ansicht von AccuRef, wenn die Versionskontrolle Buch führt, Ordnung und Überblick über alle Artefakte der Entwicklung. Dazu gehören neben der entwickelten Software auch alle Werkzeuge, Datenbankbeschreibungen, Test- und Installationsscripts, Fremdsoftware usw.

Agile Entwicklung benötigt Continuous Integration

Agile Entwicklung bedeutet automatisch Continuous Integration, sprich Integration im Minutentakt, (was nicht ganz wörtlich zu nehmen ist). Was sollen die Entwickler mit den fertigen Artefakten tun? Es gibt nur Eines: integrieren in das entstehende Release. Zögerndes Abwarten hat nur zur Folge, dass darin enthaltene Fehler nicht jetzt, sondern eben erst später entdeckt werden, im Stau der andern liegen gebliebenen, zur Integration aufgeschobenen Artefakte.

Continuous Integration setzt Private Workspaces und Automatisierung voraus

Aber dass der Entwickler den Mut haben darf, ja nicht nur den Mut, sondern die Voraussetzungen, um überhaupt rasch integrieren zu können, muss er – lokal für sich – eine Umgebung zur Verfügung haben, in der er ungestört  für sich allein – vollautomatisch!, ohne manuelle Intervention – mit den «echten» Bibliotheken, Software-Builds und -Tests von A bis Z durchführen kann.  Nur so ist mit dem Gebrauch lokaler Workspaces das Phänomen«auf meiner Maschine lief aber alles!» vermeidbar.

Lokale Workspaces schützen den Entwickler vor den Einflüssen der anderen Entwickler, die ebenfalls Software integrieren. Und umgekehrt, aus der Sicht seiner KollegInnen, sind diese gefeit vor seinen Fehlern.

Haben wir das nicht auch schon gesagt?

In der Tat, das alles erinnert an einige unserer früheren Blogbeiträge:

Agile Methoden und SCCM

Gerade agile Methoden brauchen SCCM

Continuous Integration

Best Practice: Merge and Integrate as Often as Possible
Continuous Integration – 50 Mal pro Tag!

Automatisierung

Automatisierung von Build und Deployment reduziert Kosten – ein Praxisbericht
Automation lohnt sich
ALM-Integration: Prozessautomation

Private Arbeitsbereiche

Best Practice: Private Arbeitsbereiche

Fazit aus diesem Blick in die Blog-Vergangenheit und -gegenwart: Was gestern schon aktuell war ist es immer noch – und bleibt es auch, denn die Aufgaben bleiben!

Im abschliessenden Beitrag geht es um kontinuierliche Prozessverbesserung: ein Dauerthema, wie die Bezeichnung selbst es sagt.

Gesagt heisst noch nicht gehört,
gehört noch nicht verstanden,
verstanden noch nicht einverstanden,
einverstanden noch nicht angewandt
und angewandt noch nicht beibehalten.

Die einen schreiben dieses Wort dem Verkaufstrainer Heinz Goldmann zu, andere dem Zoologen, Verhaltensforscher und Nobelpreisträger Konrad Lorenz.

Egal, Prozesse unterliegen diesem Gesetz ganz besonders: Sie werden nicht von alleine beibehalten, sie verlottern, sie erodieren.

Prozesse: unsichtbar und allgegenwärtig

Prozesse sind für mich etwas ganz Seltsames: Alles, wirklich alles, was wir selbst tun, was alle anderen tun, wirklich alles, was um uns herum geschieht, alles ist ein Teil eines Prozesses. Die Regeln, nach denen ein Prozess abläuft, sind aber meistens unsichtbar: Nur selten haben wir eine Prozessanweisung vor uns liegen, z.B. wenn wir ein Kochbuch benutzen, den Bildschirmdialog des Billettautomaten.

Die angenehmsten Prozesse: die automatisierten

Bei Prozessen ist eine unsichtbare Hand vonnöten, die dafür sorgt, dass die Prozesse nicht verludern. Die unsichtbare Hand des Bildschirmdialogs und die unsichtbare Hand des vollautomatisierten Prozesses im Hintergrund sind solche unsichtbaren Hände. Ja, zugegeben, ein schlecht konzipierter Mensch-Maschine-Dialog ist mehr als nervend; da ziehe ich die Automatik im Hintergrund vor. Aber mit der lässt sich nicht alles erledigen.

Prozesse brauchen Pflege

Es ist nun mal so: Weil Prozesse unsichtbar und trotzdem allgegenwärtig sind, müssen wir sie pflegen. Sie festzulegen, ist nicht einfach, weil sie unsichtbar sind, und deshalb ist kaum einmal ein Prozess von Anfang an perfekt. Und zudem ändert sich die Prozessumgebung ja auch. Deshalb müssen wir dauernd ein Auge auf den Prozessen haben, um Mängel zu entdecken und zu beheben, um Verbesserungsmöglichkeiten wahrzunehmen. Das ist eine Daueraufgabe – überall. Die Managementlehre der letzten zwei Jahrzehnte ist voll davon, weil sie erkannt hat, dass die Prozesse das Öl und das Getriebe sind, ohne die der Karren nicht läuft.

Carolyn Pampinos Checkliste

Was Sie sofort tun können

Der Vorteil einer Daueraufgabe: Man kann sogleich damit loslegen! Der Zeitpunkt ist nie falsch. Machen Sie’s doch gleich.

Was ist kürzlich bei Ihnen im ALM (Anforderungsdefinition, Entwicklung, Wartung, Test, Build, Auslieferung usw.) schief  gelaufen?

Warum? – Haben Sie die Antwort? Ja. Und jetzt fragen sie nochmals: warum? und dann nochmals usw. Spätestens beim fünften Warum, meistens schon früher,  sind Sie bei einem Prozessmangel angekommen. Und den sollten Sie jetzt beheben.

Übrigens hat dieses Warum-Fragen einen Namen, die fünf Warum, und stammt aus dem Kaizen, was auf deutsch mit kontinuierlicher Verbesserungsprozess übersetzt wurde. Das Internet liefert Ihnen mit den Stichwörtern «fünf Warum» eine Fülle an Informationen dazu.

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.

Mit Kollaborationswerkzeugen arbeiten

Greifen wir mal aus Pampinos Do’s und Dont’s-Liste (siehe weiter unten) die Do-Empfehlung «Diskussionen über einzelne Artefakte sind in die Pläne integriert» heraus.

Wenn die Diskussionen, die über eine Anforderung oder einen Fehler geführt worden sind, zur Artefaktbeschreibung dazugehören, dann sind sie immer wieder greifbar. Nehmen wir an, es wundere sich später einmal jemand über die gewählte Lösung, so kann er sich selbst anhand der Diskussionen ein Bild über Varianten, Pro und Kontra machen. Was das Zeit erspart!

Oder nehmen wir Pampinos Do-Empfehlung «Zusammenarbeiten bedeutet auch, dass man weiss, was läuft, ohne dass man fragen muss». Wie ich es schätze, dass mir das Tracking-Tool täglich meldet, bei welchen Fehlerfällen und Anforderungen sich der Status oder sonst etwas geändert hat: Sofort habe ich den Überblick, und mit einem Klick kann ich hineintauchen in die Details und mich selbst informieren, ohne nachfragen zu müssen – was ich ja immer noch tun kann. Und darauf bin ich dank der Fakten aus dem Kollaborationswerkzeug bestens vorbereitet.

Kollaborationswerkzeuge tragen zur Versachlichung bei

Man weiss es zwar, aber gewisse Leute tun es immer wieder: E-Mails sind ein Informations-  aber kein Kommunikationsmedium.  So entsteht leicht aus einem Missverständnis eine nicht mehr enden wollende Tirade von Gehässigkeiten, die man mit cc- und bcc-Adressaten weite Kreise ziehen lässt.

Natürlich schützt auch ein Kollaborationswerkzeug nicht vor Missbrauch; siehe Internetforen. Aber die Werkzeuge schränken den Missbrauch durch ihre Ausrichtung stark ein: Hier werden Daten, Informationen zu einem Artefakt, einem Geschäftsfall festgehalten, und es wird nicht eine Mitteilung geschrieben nach dem Motto: So, dem sag’ ich’s mal!

Kollaborationswerkzeuge erleichtern die Zusammenarbeit

Richtig eingesetzt bringen Kollaborationswerkzeuge wirklich das, was sie zu bringen versprechen: Eine Verbesserung der Zusammenarbeit. Der Mechanismus ist subtil: Fakten werden mit der Kollaborationssoftware zusammengetragen, und jeder kann sich diese Fakten ansehen, jeder kann sie ergänzen, jeder kann den Kontakt zum Autor suchen. Man muss es selbst erlebt haben, um den Nutzen und die Leichtigkeit, mit der dieser erzielt wird, richtig schätzen zu lernen.

Carolyn Pampinos Checkliste

Was können Sie tun?

Ich hoffe, Sie können die Vorteile eines Kollaborationswerkzeugs bereits nutzen. Wenn nicht: Sorgen Sie dafür, dass Sie möglichst bald davon profitieren.

Das gilt nicht nur für Werkzeuge des Anforderungsmanagements sondern für jede Werkzeugeinführung in der Software-Entwicklung!

Der Artikel hat Substanz und Humor: ein Lesevergnügen – sofern man keine Angst davor hat, in den Spiegel der eigenen Unzulänglichkeiten zu blicken.

Jens Palluch nennt die klassischen drei Argumente gegen jede Werkzeugeinführung: das Werkzeug ist zu komplex, passt nicht zu unserem Prozess, erhöht die Qualität nicht. Das sind meist Vorurteile. Palluch zeigt, wie sie entstehen und wie man ihnen begegnet: durch angemessene Schulung und den rechtzeitigen Einbezug aller Betroffenen ins Einführungsprojekt.

Als «Klassiker» bezeichnet er die zutreffenden Aussagen «A fool with a tool is still a fool» und «Erst den Prozess definieren, dann das Werkzeug einführen», denen zu wenig oder keine Beachtung geschenkt wird, so dass sie tatsächlich ihre negative Wirkung entfalten können. Auch hier wieder: Ausbildung verhindert falsche Werkzeuganwendung und ein Werkzeug kann keinen fehlenden Prozess ersetzen!

Aber lesen Sie selbst:
«Von den Vorurteilen gegenüber den Werkzeugen im Anforderungsmanagement». Der Artikel wird Ihnen gefallen. Und überdies enthält er Hinweise auf weiterführende Literatur.

Nur was man misst, kann man auch managen.

Sich auf das Gefühl allein zu verlassen, ist im Management gefährlich. Zahlen können ein Gefühl unterstützen oder in Frage stellen und damit zu ganz neuen Einsichten führen.

Zahlen müssen nebenbei anfallen.

Jeder hätte gerne Zahlen, unabhängig von seiner Position und Funktion. Aber wer sammelt gerne Zahlen? Die wenigsten. Deshalb muss das Zahlensammeln und -auswerten so weit wie möglich automatisiert sein. Wenn die Arbeiten strukturiert geplant sind, also aufgeteilt sind in einzelne Anforderungen, Testfälle, Fehler usw. fällt ein grosser Teil der Zahlen bei der Bearbeitung dieser Artefakte nebenbei an.

Weniger ist mehr.

Ein paar wenige verständliche Zahlen, regelmässig, verlässlich und automatisch ermittelt, bringen mehr, als eine Vielzahl ausgeklügelter Grössen, die keiner so richtig versteht.

Der Nutzen

Zahlen geben Orientierung. Sie zeigen, ob Massnahmen greifen, ob sie das bewirken, was beabsichtigt war, oder ganz etwas anderes. Sie ersetzen Annahmen und Ansichten durch Tatsachen; sie bringen Sicherheit.

Carolyn Pampinos Checkliste

Klein anfangen, verbessern, möglichst viel automatisieren, weniger ist mehr, so die Maximen.

Was Ihnen sofort etwas bringt

Keine Zahlen haben Sie ja nicht, oder? Aber nutzen Sie die auch wirklich? Welche Zahlen haben Sie? Wie häufig sehen Sie sich diese an? Vergleichen Sie vergangene mit gegenwärtigen? Sehen Sie einen Trend?  – Ich bin sicher, Sie haben mehr aussagekräftige Zahlen als Sie auf den ersten Blick zu haben glauben.

In diesem Beitrag geht es um die Verbindungen zwischen den Artefakten einerseits und zwischen Artefakten und Teamplayern andrerseits. Das Kennen dieser Verbindungen ist für den Projekterfolg wichtig, denn nur wenn ich weiss, wer woran arbeitet, wer wofür zuständig ist, welche Dinge voneinander abhängig sind, sich gegenseitig beeinflussen usw., wird ein Projekt übersichtlich und steuerbar.

Artefaktverknüpfungen kennen = das Projekt kennen

Ganz konkret geht es darum zu wissen, wer an der Behebung von Fehler “x” arbeitet, welche Module, Tests, Dokumentationen, Bildschirmdarstellungen, Listen, Dateien, Datenbanken, Formulare usw. von der Änderung “y” betroffen sind. Wo überall wird Modul “z” verwendet, das wir ändern wollen? Wo sind welche Schnittstellen davon betroffen? War dieser Fehler im Vorgänger-Release auch schon drin?

Der Beziehungen sind Legion. Wer die Beziehungen kennt, kennt sein Projekt, kennt Abhängigkeiten und Auswirkungen, womit er  die Chance hat, die Kontrolle zu haben.

(Dieses Thema hat bei Pampino den Titel Traceability, was mich ein Stück weit in die Irre geleitet hat. Ich verstand Nachverfolgbarkeit, also die Verfolgung der Artefaktgeschichte. Die Lektüre zeigte mir, dass die Artefaktgeschichte zwar auch dazu gehört, aber eben nur ein Teil des Beziehungsgeflechts ist.)

Grundlagen für die Artefakt-Vernetzung

Wer mit Papier und Bleistift versucht, den Überblick zu wahren– oder, wie immer noch vielerorts üblich, mit Excel- und Access-Dateien! – , der hat schon verloren. Oder kennen Sie einen grösseren Industriebetrieb, der sich bei seiner Produktionsplanung und -steuerung auf derlei Hilfsmittel verlässt? Notwendig sind:

• Repository: Die gestellten und ähnliche Fragen können nur mit einer guten, intakten, und aktuellen Datenbasis beantwortet werden.
• Integration von Projektarbeit und Projektdaten-Erfassung: Diesen Integrationsanspruch kann die Datenbasis nur erfüllen, wenn jeder Arbeitsschritt, jede Verknüpfung zwischen Artefakten ihre Spuren in der Datenbasis automatisch hinterlassen.
• Repository-Integration: Mit Datenbasis ist nicht ein einziges, Monster-Repository gemeint, denn die Realität ist heute viel komplexer. Jede Plattform, jedes Projekt, jede Programmiersprache hat ihr eigenes Repository; Anforderungen, Problembeschreibungen, Projektplanung usw. haben auch ihre eigenen Datenhaltungen.
• Prozess-Integration: Automatisierte Arbeitsprozesse müssen diese Silos (Repositorys) silo-übergreifend und vollautomatisch beschicken und auswerten und ähnlich einer Business-Intelligence-Lösung zentral konsolidieren.

Der Nutzen: verbesserte Zusammenarbeit

Der Nutzen der Artefaktvernetzung schlägt sich vor allem in Form einer vereinfachten und besseren Zusammenarbeit nieder, weil gerade die schwierigen Fragen einfach beantwortet werden können, z.B.:

• Welche Anforderungen werden in dieser Iteration angegangen?
• Sind alle Anforderungen getestet?
• Welche Fehler bezüglich welcher Anforderungen wurden festgestellt?
• Welche Anforderungen und Fehler wurde in diesem Release implementiert bzw. behoben?

Carolyn Pampinos Checkliste

Zentrale Forderung der Do’s ist eine integrierte Werkzeugbasis, Kern der Dont’s ist eine Absage an den Versuch, mit disparaten Werkzeugen den Überblick zu gewinnen. Zugleich sind sie auch eine Absage an geschlossene Werkzeuge, die keine Anpassung an die individuellen Bedürfnisse erlauben.

Kennen Sie Ihr Netz? … Ihre Netze?

Sie kennen nicht nichts. Da ist schon Einiges vorhanden. Wenig?, viel? oder gar zu viel? Fangen Sie klein an, konzentrieren Sie sich auf das Wichtigste.

Das «integriert» hat mich auf den ersten Blick etwas stutzig gemacht, denn wer in der IT eine zeitgemässe Lösung anpreist, bezeichnet diese als integriert. Integriert ist hier jedoch keine leere Modefloskel, sondern eine Absage an eine Planung, die ein Eigenleben führt, losgelöst von der Realität der Umsetzung. Eine solch wirklichkeitsnahe Planung ist nur möglich mit einfach zu handhabenden Werkzeugen, die Soll und Ist miteinander verbinden.

Planung und Realisierung: ein unzertrennliches Paar

Planung und Realisierung müssen Hand-in-Hand gehen. Sie beeinflussen sich wechselseitig. Wenn ich das so hinschreibe, wird mir bewusst, wie schwer ich mich selbst damit oftmals tue, und ich weiss, dass ich damit in guter – nein, in grosser – Gesellschaft bin.

Klar, die Planung darf nicht zum Hemmschuh werden, der jeden ungeplanten Schritt verhindert. Aber ohne Planung geht es nicht, und ohne den laufenden Feedback aus der Realisierung zurück in die Planung geht es auch nicht.
Fazit: Wir müssen uns diese Aufgabe mit entsprechenden Werkzeugen erleichtern, Werkzeuge, die den Kreislauf zwischen Planung und Realisierung automatisch unterstützen.

Geplantes abhaken = den Erfolg bewusst machen

Ich erlebe es immer wieder als angenehm, eine Anforderung zu spezifizieren, zu programmieren, zu testen; einen Fehler zu korrigieren; einen Test durchzuführen: jeder Punkt nach Plan, jeder Punkt einzeln spezifiziert, jeder Punkt ein Eintrag im Plan. Und wenn ein Punkt erledigt ist, kommt der Aufsteller: abgehakt! erledigt! geschafft! Ein angenehmes Erlebnis, der Erfolg wird sichtbar, erlebbar.

Carol Pampino:

«We plan, because we want to know when we are done.»

Allein das gute Gefühl des «done!», des erledigt! zu erleben, macht die Mühsal der Planung mehr als wett! Und noch etwas: Die beim Abhaken erfassten Istdaten fliessen sofort, ohne separate Anstrengung, in die Projektplanung ein. Der Kreislauf zwischen Realisierung und Planung ist hergestellt.

Pläne sind die unverzichtbare Grundlage, um geordnet zu arbeiten und um Abweichungen vom Kurs rechtzeitig festzustellen – oder schöner, um festzustellen: Wir haben’s geschafft! Wir sind auf Kurs!

Carolyn Pampinos Checkliste

Sie fassen das Gesagte plakativ zusammen:

Feiern Sie Erfolge – jetzt!

Was alles können Sie heute abhaken? Fühlt sich gut an, nicht wahr?, wenn Sie wieder ein Häkchen machen können! Gönnen Sie sich dieses Glücksgefühl immer mehr – und vor allem Ihrem Projektteam.

In diesem und weiteren Blogbeiträgen stellen wir Pampinos Kernaussagen vor, wobei wir die produktbezogenen Aspekte weglassen.

Druck auf die Software-Entwicklung

Die  Software-Entwicklung steht unter Druck: Einerseits verlangen Konkurrenz- und Innovationsdruck immer kürzere Abstände zwischen Software-Releases und andererseits fordern die umfangreicher werdenden Softwaresysteme und Infrastrukturen die Entwickler immer mehr. Wie können Entwickler unter solchen Umständen Software termingerecht und im Kostenbudget herstellen, ohne bei der Qualität Abstriche zu machen?

Notwendig: Umfassende Verbesserungen

Diesem Dilemma entrinnt man nur durch eine Verbesserung von Abläufen, Zusammenarbeit und Werkzeugen über den gesamten Lebenslauf der Software: Anforderungsdefinition und -management, Änderungs-, Architektur-, Konfigurations- und Qualitätsmanagement,  Automatisierung von Build und Verteilung. Die unzähligen Beziehungen zwischen den Artefakten müssen offengelegt werden, Veränderungen der Artefakte müssen sich nachvollziehen lassen, Abläufe müssen festgelegt, durchgesetzt und beibehalten werden, und schliesslich müssen Daten zu Statistiken und Führungsinformationen aufbereitet werden.

Eine Universallösung (One-size-fits-all-Solution) gibt es nicht, denn die Bedürfnisse sind zu verschieden. Deshalb muss jede Lösung auf die besonderen Bedürfnisse zugeschnitten sein und jede muss fünf Muss-Anforderungen erfüllen:

• Integrierte Planung
• Vernetzung der Artefakte
• Messen und auswerten
• Automatisierung und Zusammenarbeit
• Kontinuierliche Prozessverbesserung

Diese fünf  oder Muss-Anforderungen (Imperatives) sind Gegenstand der weiteren fünf Beiträge in dieser Serie. Jede Anforderung wird mit Do’s und Dont’s dargestellt – was man tun sollte und was nicht.

Starten Sie – jetzt!

Benutzen Sie diese Muss-Anforderungen als Checklisten zur Überprüfung Ihres ALM. Ihre erste Standortbestimmung können Sie damit selbst machen. Und schon haben sie das Fundament gelegt für eine kontinuierliche Verbesserung: Die Muss-Anforderung «Kontinuierliche Prozessverbesserung» haben sie damit bereits in Angriff genommen. Den ersten Schritt haben Sie schon getan!

Solche «Brownfield-Projekte» laufen Gefahr, dass Software und Software-Architektur zunehmend zerfallen, bis sie nicht mehr erweiterbar sind.

Brownfield-Projekte sind das Gegenstück zu Greenfield-Projekten – solche, die auf der grünen Wiese gestartet wurden. Mit anderen Worten: Jedes IT-Projekt mit Geschichte ist ein Brownfield-Projekt, eines bei dem nicht alles so ist, wie man’s heute machen würde. Also: Fast alle Projekte.

Im  soeben erschienenen Sonderheft «iX Developer Programmieren heute» stellen Stefan Lieser und Ralf Westphal im Artikel «Kontra Verrottung» zunächst die Prinzipien und Praktiken der «Clean Code Developer» und danach einen Sieben-Schritte-Plan, um Brownfield-Projekte zu sanieren. Schritt Nr. 1: Versionskontrolle einführen.

Es geht nicht anders: Ohne geordnete Ablage und ohne Buchführung über die Veränderungen verschwinden die Wirkungen aller anderen Massnahmen. Das Verschwinden ist wortwörtlich zu nehmen; im schlimmsten Fall verschwinden Änderungen oder ganze Artefakte  auf obskure Weise, weil Ablage und Versionskontrolle versagen.

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?