Software-Pannen - und wie sie sich vermeiden lassen

Der Markterfolg Schweizer Unternehmen hängt immer stärker von der Qualität der Software ab – je schneller die Digitalisierung der Welt voranschreitet, umso mehr. Hochperformant, perfekt integriert, innovativ und selbstredend fehlerfrei sollen die Programme sein und möglichst rasch in den produktiven Einsatz gehen können (Time-to-Market). Die Zeit, die das Business zu warten bereit ist, hat sich in den letzten Jahren drastisch auf einen Zehntel bis einen Hundertstel der ursprünglich tolerierten Entwicklungsdauer re­duziert. Was früher noch 100 Tage dauern durfte, soll heute in 5 bis 10 Tagen fixfertig sein. Ganz besonders bei mobilen Applikationen scheint der Gedulds­faden immer dünner zu werden (vgl. Posi­tion Paper von CA und PAC: «Application Development in a Digital World»). Der Erwartungsdruck an die Software und ihre Entwickler ist extrem gestiegen. Kunden stellen, völlig zu Recht, hohe Ansprüche, denn ein kompetitiver Markt stellt auch hohe Anforderungen an sie.

Das nimmt allerdings nicht immer einen guten Ausgang. Nur zwei schlagende Beispiele: Schweizer Bürgerinnen und Bürgern ist der Insieme-Skandal des Schweizer Finanzdepar­tements noch lebhaft in Erinnerung. 2005 lief das IT-Grossprojekt an, das die alten Infor­ma­tiksysteme der Eidgenössischen Steuer­ver­waltung zusammenführen und runderneuern sollte. 2012, nach einer Reihe von Pannen, verlor der Bund die Geduld und zog endgültig die Reissleine. 150 Millionen Franken an Steuer­geldern wurden in den Sand gesetzt. Gering­fügig preiswerter kam die irische Ulster Bank davon, die gegenüber ihren Kunden Kompen­sationszahlungen in Höhe von 18 Millionen britischen Pfund leisten musste. Nach einem «harmlosen» Routine-Upgrade am 19. Juni 2012 brachen die IT-Systeme des Bankhauses zusammen. In Folge konnten Kunden einen Tag lang nicht auf ihre Konten zugreifen, Geld abheben oder Finanztransaktionen tätigen. Jeder der 450000 Kunden erhielt zwischen 20 und 60 Pfund Entschädigung. Was den Ausfall letztlich ver­ursachte, wurde nie endgültig geklärt. Sicher ist: Vorfälle wie dieser sind nur die Spitze des Eisbergs. Die Dunkelziffer der unter den Tisch gekehrten kleinen und grossen Katastrophen dürfte signifikant höher liegen.

Software-Bereitstellung, und zwar über den gesamten Lebenszyklus, muss sich ändern, diese Lehre ziehen die Analysten vom PAC daraus. «In den letzten Jahren lag der Fokus stark auf dem Testing», betont Christian Rudolph, Vice Pre­sident Borland Sales International bei Micro Focus. Software-Entwickler testen zu spät, meint er, und die Beseitigung von Fehlern gehe umso stärker ins Geld, je später sie entdeckt werden. Heute würden bereits einzelne Module (nach jedem Scrum-Sprint) Tests unterworfen. «Damit haben wir dieses Problem mittlerweile in den Griff bekommen», sagt Rudolph. Aber jetzt taucht ein neues auf: das Anforderungsmanagement. Dort müssen sich Anbieter und Kunden gleichermassen an die eigene Nase fassen. «Kunden nehmen sich gar nicht mehr die Zeit für eine Business-Analyse und eine exakte Anforderungsspezifikation, sondern legen grossen Wert auf Flexibilität», erzählt Hansjörg Süess, Geschäftsführer von Adesso Schweiz, aus der Praxis. Den Grund sieht Süess in der Schnelllebigkeit des Markts: In einem halben Jahr könne das Geschäft des Kunden schon wieder ganz anders aussehen. Im Klartext: Viele Kunden, die Software in Auftrag geben, wissen heute noch gar nicht so genau, was sie in einem halben Jahr eigentlich benötigen. Sie wollen sich möglichst viele Optionen offenhalten. Die Folge: Kunden erstellen ihren Anforderungs­katalog während der Entwicklung der Software sozusagen «on the fly». «Die grösste Herausforderung, der sich Software-Entwickler heute stellen müssen, ist die schnelle Reaktion auf geänderte Marktgegebenheiten und geänderte Kundenanforderungen», so sieht es auch Christian Rudolph. Unternehmen müssten bessere Software noch schneller liefern. Erschwerend komme hinzu, dass sich Änderungen häufig schon während des Entwicklungsprozesses ergeben und noch vor der Fertigstellung eingebaut werden müssten. Lesen Sie auf der nächsten Seite: ruinöse Kostenspirale

Nachträgliche Änderungen und Ergänzungen aber führen schnell zu einer Kostenspirale, die Software-Anbieter in den Ruin treibt. «Zwischen 30 und 40 Prozent der Entwicklungsarbeit gehen für die Fehlerbeseitigung und die Korrektur in Folge ungenauer Anforderungen drauf», schätzt Rudolph. Methoden der agilen Software-Entwicklung, die das intensive, regelmäs­sige Feedback von Kunden suchen, können Fehler, Zeitaufwände und Mehrkosten zwar reduzieren, aber nicht völlig beseitigen. In Konsequenz hat Adesso vor eineinhalb Jahren das von ihren Kunden heiss geliebte Festpreis­modell abgesetzt und eine Art Punktesystem ein­­ge­führt. Auch um die Kunden ein wenig zu disziplinieren. Adessos Schweizer Geschäftsführer Süess nennt das neue Konzept «gezähmte Agilität»: Jede Anforderung des Kunden wird nach Aufwand, also nach Personentagen und Prio­rität, geschätzt. Wirft der Kunde eine ursprünglich eingeplante Software-Komponente raus, um stattdessen zwei neue einzuführen, und erhöht sich in Folge die Gesamtpunktzahl des Projekts, dann steigt auch der Preis. «Dadurch bieten wir unseren Kunden finanzielle Sicherheit und grösstmögliche Agilität», betont Süess. Zwar gibt es bei Adesso nach wie vor auch das klassische Festpreisprojekt, aber Festpreise schliessen den nachträglichen Anforderungstausch oder die Neueinführung aus. «Wir entwickeln momentan viele Projekte in den Bereichen Cloud, Mobile und Web», erzählt Süess. Einen enorm hohen Stellenwert haben Software-Design und -Architektur. Daran ändert auch die von Adesso eingeführte gezähmte Agilität nichts. Eine hochperformante Architektur muss in der Lage sein, laufende Anforderungen leicht in das «Project in progress» integrieren zu können. Die alte Wasserfallmethodik mit Pflichtenheft, Tests und finaler Endabnahme durch den Kunden verschwindet laut Süess zunehmend. Sie ergibt aber in einigen wenigen Nischen durchaus noch Sinn. Habe man als Entwickler zum Beispiel eine wasserdichte Spezifikation zur Hand, in der Regel handelt es sich dann um geschlossene Software-Subsysteme mit wenig Anwenderkontakt, dann führe das Wasserfallmodell immer noch zu guten Ergebnissen.

Das Anforderungsmanagement sei wohl eher ein «ewiges Thema» in Sachen Software-Entwicklung, glaubt Daniel Liebhart, Senior Solution Architekt und IT-Dozent bei Trivadis. Liebhart sieht zwei Trends von Bedeutung: Die IT muss lernen, damit zu leben, dass sich Anforderungen berechtigterweise über die Projektlaufzeit ent­wickeln können. Der Kunde gewinnt mit dem Projektfortschritt und dem damit verbundenen Wissensgewinn auch ein klareres Bild von seinen Anforderungen. Aber auch dem Business, also den Auftraggebern, gibt Liebhart Hausaufgaben mit auf den Weg. Der Trend läuft dahin, Anforderungen zunehmend über standardisierte, formalisierte Verfahren abzubilden. Liebhart nennt das Requirement Abstraction Model (RAM) samt seiner agilen Variante. Das Business sollte sich mit diesen Verfahren auseinandersetzen und einsehen, dass eine exakte Anforderungsspezifikation in einer von der IT bevorzugten Form für beide Seiten grosse Vorteile haben kann. Angesichts immer stärker miteinander vernetzter Appli­ka­tionen sei diese Annäherung zwischen Kunde und Lieferant notwendig und in beiderseitigem Interesse, unterstreicht Liebhart. Dieser dringende Appell scheint bitter nötig. Denn eine von VansonBourne im Oktober 2013 durchgeführte Befragung unter 590 Teilnehmern kam zu dem Ergebnis, dass die Mehrheit für ihr Anforderungsmanagement am liebsten Office-Werkzeuge wie Excel und Word einsetzt. Noch nicht einmal die Hälfte greift auf dedizierte Anforderungs-Management-Tools zurück, die ihren Job natürlich viel besser erledigen, aber eben auch etwas mehr Einarbeitung erfordern (VansonBourne/Micro Focus: «The problems of outsourcing applications, development and testing»). Lesen Sie auf der nächsten Seite: die magische Formel

Das Thema Testing hält Liebhart, im Gegensatz zu seinem Kollegen Christoph Rudolph, noch nicht für erledigt und gänzlich abgehakt. «Ich gehe davon aus, dass der Testaufwand zunehmen wird», sagte er zu Computerworld. Es gebe heute kaum eine Anwendung, die nicht ohne Infrastruktur auskomme, kaum eine mobile App, die nicht auf mehreren Geräten und über eine Cloud laufe, kaum ein Unternehmen, dessen Applikationen ohne Backend-Systeme funktioniere und kaum eine Datenbank oder ein Webserver, der nicht mit Hunderten von Konfigurationsmöglichkeiten glänze. In Zukunft würden immer mehr dieser einzelnen Komponenten eine einzelne Anwendung ausmachen. «All diese Ausprägungen gilt es zu testen, und das wird sicherlich nicht unerheblich Zeit kosten», betont Liebhart. Sogar die magische Formel «20-20-40-20» sieht er in Gefahr: Demnach verschlingen Administration und Dokumentation 20 Prozent des Zeit- und Ressourcenaufwands, 20 Prozent die Projekt­leitung, 40 Prozent die Entwicklung und (bislang) 20 Prozent das Testing. Der Trend hin zu immer komplexerer, hochgradig miteinander vernetzter Software wird laut Liebhart dazu führen, dass sich Entwicklungsmethodiken immer mehr am Anwendungsfall orientieren. Es werde also eine Software-Methodik für mobile Anwendungen geben, eine für Sensornetze, eine für Cloud-Systeme, eine für Integrationsplattformen, eine für Backend-Systeme etc. «Software-Ingenieure werden sich auf entsprechende Domänen spezialisieren, und die übergreifende Rolle des Software-Architekten wird stark an Bedeutung gewinnen», prognostiziert er.

Software gehe immer mehr in Richtung Design/Architektur und immer weiter weg vom klassischen «Programmierroboter», sagt Andrej Vckovski, CEO der Zürcher Software-Schmiede Netcetera. Zwei Drittel der Belegschaft von Netcetera arbeitet in Zürich, ein Drittel in der mazedonischen Hauptstadt Skopje. Damit hat Netcetera bereits in seiner Gründungs-DNA fest verankert, was viele an­deren Firmen erst mühsam einzuführen ver­suchen: das Outsourcing/Nearshoring von Software-Dienstleistungen. Viele CIOs, mit denen Computerworld gesprochen hat, betonten vor allem die durch Outsourcing/Nearshoring realisierbaren Kostenvorteile. Laut Vckovski beinhaltet dieses Geschäftsmodell jedoch auch Risiken. Zum einen halte die Lohn-Arbitrage zwischen den Ländern, auf der die Kosten­vorteile beruhen, nicht ewig. Die Löhne tendierten dazu, sich anzugleichen. Zum anderen seien Monsterprojekte in der Grössenordnung von 200 Mitarbeitenden, die man für drei Jahre outsourcen könne, heute rar gesät. Es gebe schon noch diese riesigen Kisten, nur sehr viel seltener, sagt Vckovski, und «für kleinere Projekte, wie wir sie machen, sind physikalische Meetings schon sehr nützlich». Netcetera bestreitet seinen Umsatz zu jeweils einem Drittel mit Banken/Versicherungen, Transport und Gesundheitswesen/öffentliche Hand. Auf die Ausschreibungspraxis der öffentlichen Hand angesprochen, winkt Vckovski leicht entnervt ab. Nahezu alle Bewerber erfüllten alle Anforderungen, das Differenzierungskriterium sei letztlich nur der Preis. Die Pleiten der letzten Jahre könnten ausserdem zu einer von Angst getriebenen Überdifferenzierung führen, also zu extrem detaillierten Anfor­derungsspezifikationen und Beschrieben, die dann womöglich am Ende, allem guten Willen zum Trotz, nicht zu guten Lösungen führen.

IT werde heute nicht mehr nur als Kosten­faktor, sondern immer mehr als Wettbewerbs­faktor gesehen, berichtet der Netcetera-Chef aus seinen Gesprächen mit Kunden. Früher kamen Kunden mit Problemen, heute kommen sie mit Ideen. Vckovski hat jedoch ein Problemfeld entdeckt, das von Schweizer Kunden bislang sträflich vernachlässigt wurde: Software- und Datenabfall. Die wenigsten Schweizer Unternehmen machen sich über Software-Ent­sorgung Gedanken. Sie denken nicht darüber nach, wie sie Software, die sie gerade einführen, am Ende des Lebenszyklus’ in 15 oder 20 Jahren wieder loswerden. Etwa 10 Prozent aller Applikationen, so schätzt Vckovski, fristen dergestalt als Software-Zombies ihr Dasein. Sie generieren keinen Mehrwert, fressen Ressourcen und bedrohen durch Seiteneffekte mit aktuell benötigten Programmen, die bei vielen Millionen Codezeilen kein Software-Architekt in Gänze überblicken kann, sogar den Betrieb der laufenden IT. Ein grosses Schweizer Beförderungsunternehmen arbeite gerade daran, seine Software-Leichen zu entsorgen und seine IT zu konsolidieren, verrät Vckovski, bittet aber darum, weder Namen noch Zahlen zu nennen. Lesen Sie auf der nächsten Seite: teure Mainframe ablösen

Zumindest eine Branche scheint ihre Haus­aufgaben in Sachen Software-Abfallentsorgung schon gemacht zu haben. «Banken und Ver­sicherungen sind unsere Hauptkunden, und in diesen Märkten hat die Software-Konsoli­dierung bereits stattgefunden», sagt Adesso-Schweiz-Chef Süess. Unter dem permanenten, durch die Finanzkrise provozierten Kostendruck habe man mittlerweile aufgeräumt. Unter Software-Gesichtspunkten sind Banken und Ver­sicherungen mittlerweile sauber. Süess berichtet jedoch von einer Entsorgung der ganz anderen Art. Die Swica migriere zurzeit von einem Mainframe auf eine Java-Architektur, erzählt er. Zwar haben treue Mainframe-Kunden an ihren dicken Eisen überhaupt gar nichts auszusetzen. Besonders punkto Sicherheit und Zuverlässigkeit haben Mainframes das Image des Felsens in der Brandung – die absolut sichere Burg. Aber Mainframes seien eben auch sehr teuer. «Viele Kunden sind nicht mehr gewillt, diesen finanziellen Aufwand zu betreiben», fasst Süess zusammen. Ausserdem seien Mainframe-Experten in der Regel um die 50 Jahre alt, den «alten Eisen» geht absehbar der Nachwuchs aus. Demgegenüber ist Java viel jünger, und viel verbreiteter. Eine Mainframe-Ablösung verläuft laut Süess typischerweise in zwei Stufen. Erst wird der Mainframe gekapselt und parallel dazu eine Java- oder .Net-Umgebung aufgebaut. In dieser Phase steigen natur­gemäss die Kosten. In Phase zwei wird der Mainframe abgelöst, also letzten Endes ab­geschaltet. Die Migration dauert etwa drei bis vier Jahre. «Bei der Barmenia haben wir das erfolgreich so gemacht», berichtet Süess stolz.

Vom Riesen-Mainframe zum kleinen Smartphone am anderen Ende des Software-Entwicklungsspektrums. Die Basler Software-Schmiede Terria Mobile entwickelt mobile Applikationen für Vertrieb, Aussendienst und Service. Viele mobile Geschäftseinheiten seien mit den Standardlösungen der Grossanbieter wie SAP oder Oracle nicht zufrieden und wünschten sich eine integrierte mobile Applikation für alle Backend-Systeme, die sie benötigen. Keiner wolle zwischen zehn Einzelapplikationen hin und her wechseln müssen, beschreibt Robin Wirz, CEO von Terria Mobile, die Anforderungen seiner Kunden. Ein typisches Entwicklungsprojekt laufe etwa über drei Monate. Eines der jüngsten Projekte, das die Basler erfolgreich zum Abschluss gebracht haben, ist die iPad-App «Knowledge» für ein grosses Unternehmen der Beratungsbranche. Die App bietet iPad-Nutzern einen mobilen, personalisierten Zugang zu Studien und Blog-Einträgen und ist Baustein einer breiteren Content-Marketing-Strategie des Beratungshauses. Über Push Notifications lassen sich neue Inhalte abonnieren und für den Offline-Gebrauch herunterladen. Klar würden Android-Geräte weltweit mit grossem Abstand den Markt anführen. Aber in den Business-Etagen der Schweiz, den «höheren Käuferschaften», sei Apple extrem dominant, berichtet Wirz. «Im Smartphone-Markt ent­wickeln wir immer parallel für iOS und Android, aber die Knowledge-App gibt es wegen der hohen Business-Affinität bislang nur für das iPad», erklärt er. Auch das Windows Phone habe Potenzial und sei auf dem Vormarsch, bewege sich bisher aber noch auf bescheidenem Niveau. «Microsoft gewinnt Marktanteile und hat in den USA viele Millionen ins Marketing investiert, aber richtig durchgeschlagen hat das noch nicht», meint Wirz. Das kann ja noch kommen. Eine andere mobile Plattform hat das Entwicklerteam von Terria Mobile jedoch schon so gut wie ab­geschrieben: «Für den BlackBerry», so Wirz, «sehe ich momentan nur düstere Zeichen.»