Natürlich sind solche Listen, wie hier von Gartner zusammengetragen und im CIO-Magazin veröffentlicht, Humbug, aber irgendwie sind sie doch auch „inspirierend“ und daher lesenswert. Genannt werden:

• Teure Fachkräfte
• Produktfriedhof (aus historisch gewachsenen Systemlandschaften)
• Dürftige Flexibilität (mit der Folge, dass das Kerngeschäft die Fähigkeit verliert sich zu verändern)
• Eskalierende Kosten (im laufenden Betrieb)
• Veraltete Technik
• Schwieriger Datenzugriff (moderne Unternehmen hängen extrem von aktuellen Daten ab)
• Kapazitätsengpässe (aufgrund des stetig steigenden Transaktionsvolumens un der steigenden Zahl an Schnittstellen)
• Compliance-Risiken (Gesetzliche Bestimmungen gewinnen an Bedeutung)
• Steigende Kosten und schwindende Agilität
• Green IT (Wo der Applikationsbetrieb unter grünen Zielen leidet, ist Gefahr im Verzug)

Klar fallen solche Projektberichte wie die Case Study im CIO-Magazin zur IT-Bebauung bei E.ON immer als Success Story aus (siehe auch unsere Diskussion über 10projects), aber der Artikel beschreibt ganz gut allgemein die Vorgehensweise bei der IT-Bebauung, nur den rosa Filter muss man beim Lesen noch entfernen…

Übersetzungsprobleme sind zugegebenermaßen ein Lieblingsthema von mir. Aktuell wieder zu finden in einem Interview im CIO-Magazin mit Klaus Rausch (Ex-HypoVereinsbank-CIO, heute CTO beim Schweizer Dienstleister Avaloq) mit dem passenden Titel:

Wenn Anwender der IT das Programmieren erklären

Siehe auch:
#144 Übersetzungsprobleme: IT und Business
#131 IT versteht Business nicht

Im CIO-Magazin findet sich aktuell das Beispiel eines Change-Projekts bei der IT-Organisation von Emirates mit den Phasen:

0 – Projektdefinition
1 – Designphase
1.1 – Transparenz schaffen
1.2 – Konzeption und Detaillierung
1.3 – Pilotierung
2 – Implementierung
3 – Optimierung

Als Credo des Projekts formuliert Hubert Weber, einer der Berater von CIO Patrick Naef:

„Es geht weniger darum, eine Checkliste abzuarbeiten, sondern darum, mit welcher inneren Haltung man eine Change-Initiative angeht.“

Heute erschienen in der neuen Ausgabe des Projektmagazins ist Teil 2 meines Artikels über Testmanagement in IT-Projekten. Während es in Teil 1 noch um die Grundlagen ging, beinhaltet Teil 2 vor allem eine Excel-Vorlage. Kommerzielle Test-Suiten sind als Test-Werkzeug häufig überdimensioniert, da ihr Leistungsumfang die Anforderungen vieler IT-Projekte übersteigt und ihre Nutzung meist nur rudimentär erfolgt. Die vorgestellte einfache Excel-Lösung kann der Anwender leicht an seine spezifischen Fragestellungen anpassen und weiterentwickeln.

Janusz Gorycki setzt sich bei AgileSoftwareDevelopment.com (Englisch) mit den Tücken und Fallstricken des Unit Tests auseinander:

(1)  Unit Test dienen nicht zur Systemdokumentation!
(2) Ein erfolgreicher Unittest sagt nichts darüber, ob das Gesamtsystem auch „gesund“ ist.
(3) Testmodellen zu vertrauen ist falsch.
(4) Zu langsame Unit-Tests sind wertlos.

Ein Leser-Feedback bestätigt mich in meiner Einschätzung:

Wir setzen seit einiger Zeit zur Verbesserung der Klarheit und Entwicklung der Fachanforderungen ein Tool ein, das sich sehr bewährt. Das ist m.E.

erheblich wichtiger, als ein Testtool, von dem ich – auch nach langen Jahren – je nach SW (die ja heute hochgradig konfigurierbar ist und de facto strukturbildende Wirkungen für Unternehmen und alle damit verbundenen Org-Einheiten hat) nur wenig halte. Es ist nichts schlimmer, als wenn die Fachbereiche nach langwierigen Prozessen der Definition der Fachanforderungen irgendwann selbst nicht mehr wissen, wer was wann und warum angefordert hat und ob und wie diese Anforderung von wem in Absprache mit wem wann geändert worden ist – was ist dann getestet worden – und wie bekomme ich meine Migrationsaufträge? Dann kann ich mir das Testen im Grunde komplett sparen.

In meinem aktuellen Beitrag für das Projektmagazin habe ich u.a. auf die Rolle des Anforderers bei Test und Abnahme hingewiesen. Hierzu passend eine Meldung des CIO-Magazins: Die Deutsche Bank lagert ihr Software-Testing aus und rechtfertigt das mit Prozessorientierung und Industralisierung der IT.

Ein externes Testing ist legitim, darf aber den Anforderer nicht aus seiner Verantwortung für Qualitätssicherung und Abnahme entlassen. Ein IT-Dienstleister mag durchaus die erforderlichen IT-Prozesse für Software-Entwicklung und Test besser beherrschen, aber kann er auch das erforderliche Business-Know How mitbringen? Weiß er, was Banker wünschen?

In der aktuellen Ausgabe des Projektmagazins (Abodienst) findet sich ein Beitrag zum Thema Testmanagement in IT-Projekten. Als Autor des Artikels kann ich die Lektüre natürlich nur empfehlen…

Im ersten Teil  des Beitrags werden die Grundzüge des Testmanagements und der Testorganisation anhand der immer wiederkehrenden gemeinsamen Fragen skizziert, die vor der Durchführung eines Tests zu beantworten sind:

1. Wann wird getestet?
2. Was wird getestet?
3. Wie wird getestet?
4. Wer testet?
5. Womit und wo wird getestet? 

Teil 2 des Beitrags mit einem ausführlichen Excel-Template ist derzeit in der Schlußredaktion.

Danny Quick hat einen lesenswerten Beitrag des Linux-Magazins ausgegraben, in dem versucht wird Methoden und Vorgehen agiler Softwareentwicklung auf Betriebsthemen zu übertragen. Wie bei allen „agilen“ Themen braucht es dafür gleich einen neuen Namen: Agile Software Administration.

Für ITIL/Governance geprägte Welten mag sich das Gedankentum zunächst anarchistisch/revolutionär anhören, letztlich setzt es aber, wie alle agilen Ansätze, auf einer gestärkten Kommunikation und Eigenverantwortung auf – zwei Dinge, die noch keiner Betriebsorganisation geschadet haben.