Diese Beitragsreihe basiert auf dem Artikel «Five Imperatives for Application Lifecycle Management» der IBM Rational-Mitarbeiterin Carolyn Pampino. Im letzten Beitrag haben wir über die integrierte Planung geschrieben.

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.
Den ganzen Beitrag lesen »

Diese Beitragsreihe basiert auf dem Artikel  «Five Imperatives for Application Lifecycle Management» der IBM Rational-Mitarbeiterin Carolyn Pampino.  Im ersten Beitrag haben wir die Reihe vorgestellt, heute gehen wir auf das erste der fünf Muss ein – die integrierte Planung.

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.
Den ganzen Beitrag lesen »

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 »

«Problem erkannt – nun muss das Handeln folgen.» – So der treffende Titel des am 15. Oktober 2010 veröffentlichten, frei verfügbaren Berichts über eine Befragung zu ALM, die SIGS-Datacom in Zusammenarbeit mit Microsoft bei 90 ITlern kürzlich durchgeführt hat.

«Beim Thema ALM ist es ein weiter Weg von der Erkenntnis- zur Handlungsebene.»

Was sind wohl die Gründe für diesen Mangel? Die Studie sagt dazu nichts, aber die Ursachen liegen auf der Hand:

• ALM ist kein Hype-Thema, sondern eine der  scheinbar unspektakulären weil unabdingbaren Daueraufgaben der IT, mit deren erfolgreicher Bewältigung der CIO aber kurzfristig keinen Prestigegewinn einheimsen kann – zumindest derzeit noch.
• Kein Soforterfolg. ALM ist eine Denk- und Handlungsweise, die die IT und die ganze Firma durchdringen muss. (Kleine) Einzelerfolge können sich kurzfristig zeigen, der grosse Erfolg ist aber erst nach Monaten sichtbar.
• Das Tagesgeschäft geht vor. Aber Hand aufs Herz: Würden Sie in eine Luftseilbahn steigen, die nicht regelmässig gewartet wird? Aber gerade weil es an ALM fehlt, bindet das Tagesgeschäft –  die Feuerwehrübungen! – immer mehr Ressourcen. Ein Teufelskreis, aus dem man nur durch ALM ausbrechen kann.
• Keine Zahlen. Wüssten viele Firmen wirklich, wieviele Kosten der IT auf mangelhaftes ALM zurückzuführen sind, würden sie schleunigst die Konsequenzen ziehen.

Den ganzen Beitrag lesen »

Zwei Drittel der von der Firma Expeso für das dritte Java-Trendbarometer Befragten sind mit den Prozessen für Anforderungsanalyse, Entwicklerdokumentation, Test und Qualitätssicherung unzufrieden.

Das Ergebnis überrascht in seiner Aussage und noch mehr in seiner Deutlichkeit. Nur ein Drittel ist zufrieden. Was immer sich hinter «unzufrieden» verbirgt, das Spektrum der Mängel wird breit gefächert sein.  Es ist aus wirtschaftlichen Gründen notwendig, diese Prozesse unter die Lupe zu nehmen, denn: «Das Verbesserungspotenzial ist erheblich, hier lauern enorme Risiken.» So die Autoren der Studie.

Den ganzen Beitrag lesen »

Kürzere Release-Zyklen beeinträchtigen die Software-Qualität.
Die Lösung: Work smarter, not harder.

Unter dem Titel «Schlechte Software-Qualität wegen immer kürzeren Release-Zyklen» zitiert Inside-IT eine Umfrage, nach der sich die IT-Fachleute beklagen, dass die unter unrealistisch kurzen Zeitvorgaben erstellte Software den Qualitätsansprüchen nicht gerecht werde.

Verkürzung der Prozesszeiten, der Änderungsintervalle, der Lieferfristen: Welche Branche kennt das nicht? Das Business gibt den Takt vor, die IT hat danach zu tanzen: Das ist IT-Business-Alignment!

Den Takt kann nur mithalten, wer sich mit angemessenen Verfahren und Mitteln ausstattet. Das heisst unter anderem ein integriertes, hoch automatisiertes Change- und Konfigurationsmanagement. Vom Requirements Engineering über das Testen bis zur Auslieferung müssen die Prozesse durchgängig sein. Wer sich mit Unzulänglichkeiten der Prozesse und der Softwareverwaltung herumschlagen muss, hat schon verloren.

Wie viel Zeit geht bei Ihnen verloren wegen Mängeln in den Abläufen? Mehr als Sie für möglich halten. Wieviel es wirklich ist, erfahren Sie erst nach einer Renovation oder totalen Neugestaltung der Prozesse und Infrastruktur.

Unter diesem Titel fasst pressetext einen Bericht der Standish Group zusammen, der auf die Folgekosten abgebrochener IT-Projekte hinweist. Nicht nur das investierte Geld ist weg, sondern auch Know-how, technische Weiterentwicklungen und effizientere Prozesse gehen verloren.

Jetzt, wo das Sparen erste Priorität hat, werden vermehrt IT-Projekte abgebrochen. Projekte, die dazu bestimmt waren, die Prozesseffizienz zu verbessern, neue Geschäftsarten und -abläufe überhaupt zu ermöglichen; Projekte mit Aussicht auf einen ROI. Werden diese Funktionen, Verbesserungen und Neuerungen nicht mehr benötigt? Mag sein, aber die Quartalszahlen sind den Verantwortlichen offenbar wichtiger als die Sicherung des Unternehmenserfolges.

Den ganzen Beitrag lesen »

Das ist das Fazit einer Studie über IT-Veränderungsprojekte des Infas-Instituts, über die Computerworld Schweiz berichtet. Mit den Ergebnissen der Systemharmonisierungen, -konsolidierungen, -umstellungen und Reorganisation sind die CIOs zwar weitgehend zufrieden, aber der Aufwand an Zeit und Geld  ist ihnen zu hoch, und die Projekte laufen ihnen zu lange.

Aufhorchen lassen die Bemerkungen, dass «es häufig an einer klaren Vorgehensweise fehlt» und dass «drei Viertel der IT-Verantwortlichen der Auffassung sind, dass sich IT-Landschaften durch weitgehend automatisierte Abläufe auf Basis einer Standardlösung deutlich schneller abwickeln liessen.»

Den ganzen Beitrag lesen »

Unter  der Wirtschaftskrise leiden gute Gewohnheiten im Software-Engineering. Qualitätsssicherung, Dokumentation, Anforderungsanalyse, Vorgehensweisen und kontinuierliche Integration werden vernachlässigt.  Die künftigen Wartungsaltlasten sind damit vorprogrammiert.

Unter dem Titel «Krise und Software-Entwicklung: Firmen sparen an der Qualität» fasst inside-it.ch das neueste Java-Trendbarometer der expeso GmbH zusammen.

Es lohnt sich, sich diesen Bericht von der expeso GmbH herunterzuladen, auch wenn man mit Java überhaupt nichts zu tun hat. Was sich auf dem Programmiersprachen-Mainstream tut, ist nicht überraschend, sondern menschlich: nämlich kopflos und kurzsichtig.

Unsere Beobachtungen in der Praxis decken sich mit den Erkenntnissen des expeso-Berichts. In der Schweiz sieht es nicht besser aus!

Den ganzen Beitrag lesen »

Verzicht und Automatisierung sind Prinzipien, die man bei der Formulierung der Ziele und der Konzipierung neuer Lösungen für das ALM eisern befolgen muss.  Nur so kommen wir zu schlanken und wirtschaftlichen ALM-Lösungen. Fett ansetzen tun sie von alleine wieder!

Ausgangspunkt dieser Artikelreihe ist die Beobachtung, dass die IT sich anschickt, ALM-Silo neben ALM-Silo zu stellen, genau so, wie sie das mit den Silos der betrieblichen Anwendungen getan hat.

Die Erfahrungen zeigen, dass ALM-Funktionen, -Daten und -Abläufe viele Redundanzen enthalten, die in den letzten Jahren erst noch stark zugenommen haben. Denn jede Programmiersprache, jede eingekaufte Anwendung,  jede Plattform und manche  Systemsoftware kommt  mit ihrer eigenen Infrastruktur  für die Verwaltung von Metadaten daher. Damit nicht genug: Die Einführung von IT-Ressourcen-, Project-Portfolio-, und Enterprise-Architecture-Management sowie ITIL , — wenn möglich jedes mit seinem eigenen Werkzeug — hat die Metadatenmenge  vergrössert, und natürlich hat jedes Werkzeug und jedes Arbeitsgebiet seinen privaten Silo!

Beim Durchforsten des Dickichts von Funktionen, Daten und Prozessen sollten wir uns von diesen Prinzipien leiten lassen:

Verzichte auf alles, was nicht wirklich nötig ist und nicht mit vernünftigem Aufwand fehlerfrei auf Stand gehalten werden kann. Es gibt Informationen, die man sich gescheiter ad hoc beschafft, als dass man sie dauernd pflegt. Nicht jedes Metadatum muss in Echtzeit erfasst werden.

Wir alle haben schon zur Genüge erfahren, dass eine absolute Mussanforderung wegen «höherer Gewalt» plötzlich zum Nice-to-have-Feature mutiert. Warum nicht selbst einmal die höhere Gewalt spielen?

Vereinfachen: Mit Verzichten vereinfachen wir. Das was uns schliesslich als unverzichtbar erscheint, lässt sich meistens noch einmal vereinfachen. Was bringen komplizierte Lösungen, die keiner versteht und erst noch nicht richtig funktionieren? Jede einfache Lösung ist ihnen überlegen. Und zum Schluss, um allen das Leben zu vereinfachen:

Automatisiere, was sich automatisieren lässt. Wenn Redundanzen unvermeidlich sind, dann wenigstens auf eine kostengünstige und sichere Art. Viele ärgerliche und zeitraubende Fehler lassen sich durch Automatisierung zu 100 Prozent ausschalten.

Schliesslich ist alles eine Frage der Wirtschaftlichkeit, der Effizienz und Effektivität: Mit möglichst wenig Mitteln möglichst viel leisten. Verzicht, Vereinfachung und Automatisierung sind die wirksamsten Helfer!

Weitere Beiträge in dieser Reihe

(1) Fehler darf man machen — aber nicht zwei Mal dieselben
(2) Anwender- und prozessorientiert zum Erfolg
(3) Manuelle Arbeit — und wie man sie besser los wird
(4) Am Anfang steht die Anforderungsanalyse
(5) ITIL und ALM
(6) Ohne Istaufnahme geht es nicht
(8) Ein Projekt
(9) Prozessautomation
(10) Zukunftsaufgabe Metadaten-Integration