Wege aus der Softwarekrise: Verbesserungen bei der Softwareentwicklung

Wege aus der Softwarekrise

Patrick Hamilton

Wege aus der Softwarekrise Verbesserungen bei der Softwareentwicklung

123

Dr. Patrick Hamilton Am Grundweg 22 64342 Seeheim-Jugenheim

ISBN 978-3-540-72869-6

e-ISBN 978-3-540-72871-9

DOI 10.1007/978-3-540-72871-9 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. c 2008 Springer-Verlag Berlin Heidelberg  Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Einbandgestaltung: KünkelLopka GmbH, Heidelberg Gedruckt auf säurefreiem Papier 987654321 springer.de

Es wäre gut Bücher kaufen, wenn man die Zeit, sie zu lesen, mitkaufen könnte, aber man verwechselt meistens den Ankauf der Bücher mit dem Aneignen ihres Inhalts. Arthur Schopenhauer (1788–1860)

Inhaltsverzeichnis

1

Prolog................................................................................................... 1

2

Irrwege und Auswege … ................................................................... 9 2.1 Softwarebau in der Dauerkrise.................................................... 9 2.1.1 In den Sümpfen des mystischen Mann-Monats ............. 11 2.1.2 Fehler ohne Verjährungsfristen ..................................... 13 2.1.3 Handeln mit Kurzsichtigkeit.......................................... 15 2.2 Haben und Schein ..................................................................... 18 2.2.1 Der Traum von Fließbandproduktion ............................ 20 2.2.2 Handeln von heute, Trends von morgen ........................ 23 2.2.3 Auf der Suche nach Schwachstellen .............................. 28 2.3 Ausbruch aus dem schwarz-weißen Zeitalter............................ 30 2.3.1 Abschied von einer diskreten Welt ................................ 32 2.3.2 Wissensgetriebener Softwarebau ................................... 36 2.4 Wege zur Professionalisierung.................................................. 37 2.4.1 Organisationsaspekte in der IT-Produktion ................... 41 2.4.2 Rollen mit Zukunft ........................................................ 45

3

Aufbruch in die Zukunft.................................................................. 49 3.1 Modellwelten stellen sich vor ................................................... 49 3.1.1 Messlatten der IT-Organisation ..................................... 50 3.1.2 Schemagetrieben – und doch nicht schematisch............ 53 3.1.3 ITIL – eine Library für Servicemanagement ................. 55 3.1.4 Six Sigma oder „Besser ist billiger“ .............................. 58 3.2 Qualifizierte Hersteller brauchen gute Produkte....................... 61 3.2.1 Was gute Software auszeichnet ..................................... 61 3.2.2 Das Eisberg-Prinzip ....................................................... 66 3.2.3 Erfolgreich und doch kein Zufallsprodukt? ................... 68 3.2.4 Erweitertes Kano-Prinzip............................................... 72 3.2.5 Was macht ein Softwareprodukt gut? ............................ 74 3.3 Alte Ziele, neue Wege............................................................... 81 3.3.1 Wenn Softwarebau vom Gehirn lernt ............................ 81 3.3.2 Konstruierte Wirklichkeiten .......................................... 82 3.3.3 Wahrnehmung und Denken ........................................... 84 3.3.4 Konstrukte reiner Logik................................................. 85

VIII

Inhaltsverzeichnis

3.4

3.5

Systeme im Quadrat? ................................................................ 89 3.4.1 Die Kunst der Steuerleute .............................................. 92 3.4.2 Mehr als nur systemisches Arbeiten .............................. 94 3.4.3 Was heißt systemisches Handeln? ................................. 99 Systemisch arbeiten................................................................. 102 3.5.1 Umzug ins nicht-triviale Kontinuum ........................... 105 3.5.2 Konstruierte Wirklichkeiten ........................................ 111

4

Hilfsmittel aus der Krise................................................................ 115 4.1 Nieder mit den binären Zöpfen ............................................... 115 4.1.1 Weiche Worte schaffen harte Fakten........................... 119 4.1.2 Kommunizieren – eine Kunst!..................................... 122 4.1.3 Mäeutik – oder die Kunst zu fragen............................. 129 4.1.4 Fragen für Fortgeschrittene.......................................... 133 4.2 Kreativität, Wissen und Lernen............................................... 139 4.2.1 Kreative Softwareproduzenten .................................... 139 4.2.2 Kreativität und Softwarebau ........................................ 140 4.3 Denken, wissen und kommunizieren ...................................... 145 4.3.1 Universum des Wissens ............................................... 146 4.3.2 Piaget lässt grüßen ....................................................... 150

5

Wege zum Softwarebau von morgen ............................................ 155 5.1 Systemischer Softwarebau ...................................................... 155 5.1.1 Vom Gedanken zum Produkt....................................... 155 5.1.2 Schwachstellenbeseitigung .......................................... 158 5.2 Architekten in der Softwareproduktion................................... 160 5.2.1 IT-Architekten in Vergangenheit und Gegenwart ....... 162 5.2.2 IT-bewanderte Systemiker und Coaches gesucht ........ 169 5.2.3 Erweitertes Rollenverständnis ..................................... 172 5.3 Systemisches Arbeiten in der IT ............................................. 177 5.3.1 Ein Fallbeispiel ............................................................ 178 5.3.2 Der Weg ist das Ziel .................................................... 181

6

Epilog............................................................................................... 183

7

Anhang ............................................................................................ 185 7.1 Abbildungsverzeichnis............................................................ 185 7.2 Weiterführende Literatur......................................................... 185 7.3 Quellenübersicht ..................................................................... 191

Stichwortverzeichnis ............................................................................. 195

1 Prolog

Und wenn das, was du tust, dich nicht weiterbringt, dann tu etwas völlig anderes – statt mehr vom gleichen Falschen! Paul Watzlawick (1921–2007) Einmal angenommen, Softwarebau wäre – anders als heute zugrunde gelegt – keine Engineering-Disziplin, sondern wäre stattdessen den psychologienahen Fächern zugeschlagen worden. Einmal angenommen, dieses Fach hätte sich als Folge der seit den frühen 70er Jahren schwelenden Softwarekrise zu einer dort angesiedelten Disziplin gemausert, und einmal angenommen, wir redeten über die Art und Weise, wie die Ergebnisse in Bezug zu ihrer Aufgabenstellung stünden, und nicht so sehr darüber, mit welchen technischen Methoden oder Maschinen man Code implementiert. Würden wir dann in einer anderen Welt leben (soweit es die industrielle IT betrifft)? Könnten möglicherweise Dinge innerhalb der Computerwissenschaften als gelöst betrachtet werden, die sich bis heute als ungelöst, mühevoll und ineffizient darstellen? Keine Angst, dieses Buch hat es sich nicht zur Aufgabe gesetzt, bewährtes im Softwarebau neu zu definieren. Ausgangspunkt ist hier allerdings eine Betrachtungsweise, deren primärer Fokus nicht techniklastig ist, sondern die, vergleichbar den Kognitionswissenschaften, anstehende Fragen aus einem erweiterten Blickwinkel ergründet und hieraus ihre Schlüsse zieht. Dabei steht im Fokus der Betrachtungen und Überlegungen immer wieder die im industriellen Softwarebau so entscheidende Fragentrias: Wie wird Softwarebau effizienter? Wie wird Softwarebau kostengünstiger? Wie wird die entwickelte Software qualitativ besser? Viel ist hierzu in den vergangenen Jahrzehnten unternommen und ausprobiert worden. Manches hat sich als gut erwiesen, anderes hat nur für kurze Zeit das Licht der Welt gesehen. Egal welche Methoden und Techniken gerade en vogue sind – diejenige Größe, die sich am wenigsten im Sinne der eigenen Beteiligung verändert hat, ist der Mensch selbst. Auch wenn ihm neuartige Automaten zur Verfügung stehen, wenn Konstruktionshilfen jeglicher Art ihm das Leben beim Bau von Software erleichtern

2

1 Prolog

sollen und eine immer höhere Automatisierung das Ihre dazu beiträgt: Am Ende sind es trotz all der beeindruckenden Technik gerade die SoftwareEntwickler in ihren verschiedenen Rollen, die durch ihr Wissen, ihr Zusammenspiel und ihre individuellen Vorgehensweisen maßgeblich darüber entscheiden, ob ein Produkt die geforderten Ziele erreicht oder nicht. Dabei unterliegt industrielle Softwareproduktion ein paar sehr einfachen Grundparadigmen. Die Betriebswirtschaft lehrt, dass ein Produkt in Richtung auf den Markt ein materielles oder immaterielles Objekt sei, das diesem angeboten werde und in der Lage sei, Kundennutzen zu stiften. Mit anderen Worten: Mit einem solchen Produkt möchte die eigene Organisation die Wettbewerbsposition verbessern, bestimmte Marketingziele erreichen, Marktsegmente ausbauen bzw. diese halten – kurz Geld verdienen und damit erfolgreich sein. Diese Grundsatzziele liegen normalerweise außerhalb des Zeitfensters, in welchem die eigentliche Projektarbeit zur Softwareerstellung stattfindet. Hierdurch werden gerade diese Anliegen oft für die Entwicklungsmannschaften intransparent, weshalb sie leicht in Vergessenheit geraten. Da Softwarebau alles andere als trivial ist, sondern in Hinblick auf die Prozesse, die eingesetzten Werkzeuge und Techniken oder auch die erwarteten Resultate den beteiligten Projektmitarbeitern sehr viel abverlangt, geraten diese Grundparadigmen gerne außer Sichtweite. Dabei ist es längst kaum noch möglich, dass eine geniale Entwicklungsplattform, gepaart mit ein paar guten Ideen sowie dem obligaten Internetanschluss über Nacht zu Wohlstand und Ansehen verhelfen und neue IT-Garagenfirmen erfolgreich das Licht der Welt erblicken. Dieser Wunschtraum mag bei einigen funktioniert haben oder sich in Ausnahmefällen auch noch so erfüllen, für den Rest von uns heißt es jedoch strategisch ganzheitlich zu planen, ungenutzte Kapazitäten in der eigenen Organisation aufzuspüren, diese zu kanalisieren bzw. fehlerträchtige oder ineffiziente Bereiche zu verbessern. Mit anderen Worten: Statt liebevoller Bastelstuben muss die eigentliche Softwareproduktion immer mehr industrialisiert werden, will sie auch weiterhin den Wünschen der Kunden nach einem entsprechenden Preis-Leistungs-Verhältnis gerecht werden. Dieser Einsicht folgend werden hier vor allem jene Bereiche analysiert, die Verbesserungspotential in der Herstellung versprechen, oftmals jedoch übersehen oder unterschätzt werden, zugleich aber einen ungenutzten Pool an Ressourcen bereithalten. – Das Hauptaugenmerk dieser Abhandlung wird daher auf einer genaueren Betrachtung der zentralen Rollen im Softwarebau liegen. Dabei werden Skill- und Rollenentwicklung wesentliche Parts zukommen, wobei Wissenserfassung im Sinne des Anforderungsmanagements sowie Wissenstransformation im Sinne von IT-Architektur und Implementierung ein hohes Maß an Aufmerksamkeit erhalten werden.

1 Prolog

3

Bei all dem versteht sich dieses Buch nicht als eine rein akademische Abhandlung, sondern stammt aus vielen Jahren Praxis im Softwarebau sowie dem IT-Beratungsbereich. Es geht in erster Linie um die beteiligten Mitarbeiter und deren qualifizierte Weiterentwicklung. Dies geschieht vor dem Hintergrund, dass viele Publikationen über Produktionsprozesse oder Einzelverfahren den Eindruck vermitteln, dass die eigentliche Workforce in ihren jeweiligen Rollen bereits Teil einer nahezu heilen Welt sei: Mit ihren ohnehin schon vorhandenen Qualifikationen – so der leicht aufkommende Eindruck – brauche diese nur noch auf das jeweils anzuwendende neuartige Vorgehensmodell oder die zu nutzenden Werkzeuge umgeschult zu werden und schon wurde der qualifizierte Umstieg umgesetzt. – Die Wirklichkeit weicht hier ganz offensichtlich von solchen Wunschvorstellungen deutlich ab – und dies insbesondere deshalb, weil die beteiligten Personen mehr als nur ein neues Handbuch oder eine Tagesschulung über einen neuen Softwareprozess bzw. eine entsprechende Methode brauchen, sondern selbst oftmals durch einen mentalen und intellektuellen Veränderungsprozess hindurchgeführt werden müssen. Wie oft wird Verbesserung der eigenen IT-Organisation in eben der Weise vollzogen, dass die betroffenen Mitarbeiter einen Kurzlehrgang für ein Tool oder ein Verfahren erhalten und man managementseitig im Anschluss daran bessere Ergebnisse erwartet. Dieser Ansatz, der ein wenig an Kochrezepte erinnert, hat mit Sicherheit immer wieder einmal seinen Platz – auch in der Informatik! Aber reicht dies tatsächlich aus, um anspruchsvolle Software zu bauen – und dies mit entsprechend qualifizierten und erfahrenen Mitarbeitern? – Ich fürchte nein! Ein renommierter Architekt wie etwa Norman Forster, der bekannt wurde durch seine genialen Entwürfe, etwa den des Berliner Reichstages oder der Londoner „Gurke“, hat seine Popularität sicherlich nicht deshalb erlangt, weil er mit Hilfe teurer CAD-Systeme, guter Templates oder ausgefallener Werkstoffe geniale Wasserleitungsrohre oder Fassaden perfekt in Bauwerke integrierte. Nein, ganz offensichtlich bedarf es deutlich mehr als nur ingenieurmäßig das Richtige zu tun. Dass dies nicht nur für Bauarchitektur gilt, sondern gleichermaßen auch für den IT-Bereich notwendig ist und z. T. auch schon stattfindet, ist daran zu erkennen, dass große Softwarehäuser, etwa der Gigant Microsoft, dies in ihrer eigenen Binnenorganisation entsprechend berücksichtigen1.

1

Hier findet sich – bezogen auf das Jahr 2007 – eine dreiköpfige Führungsmannschaft, die sich zusammensetzt aus der politischen Führung (= klassisches Management), einer kaufmännischen Führung sowie einer technischen Führung, die zum einen Visionär und Impulsgeber ist, zum anderen aber sicherstellt, dass alle Produktentwicklungen in die technische Gesamtvision passen.

4

1 Prolog

Wenn dem so ist, dann bedarf es zweifellos eines Paradigmenwechsels in der Branche. Dieser kann wohl am besten mit demjenigen Wandel verglichen werden, der sich in der vergangenen Dekade im Bereich des WebDesigns vollzogen hat. Waren dort ursprünglich codenahe Kenntnisse gefragt, um z. B. HTML-Tags richtig zu platzieren, die wiederum die Basis der oft stereotypen Klötzchenwelt früherer Web-Seiten waren, so ist heute deutlich anderes gefragt! Anstatt primär die im Hintergrund laufende Technik zu sehen, ist dieser Bereich inzwischen zu einer Domain von Designern geworden. Dabei sind Design und Nutzerinteraktionsplanung zu tragenden Säulen bei der Erstellung solcher Seiten geworden, während die vorhandenen IT-Techniken den für die Realisierung notwendigen technischen Rahmen liefern. Die Erkenntnis hat sich durchgesetzt, dass der wichtigste Kunde solcher Webseiten das menschliche Auge mit seiner nachgeschalteten Wahrnehmung ist. Genau dieses gilt es mit den entsprechend aufbereiteten Informationen sinnesgerecht zu „beliefern“! Nun kann komplexer Softwarebau nicht ohne weiteres mit Webdesign auf eine Stufe gestellt werden, dennoch gibt es einige Parallelen, die es zu bedenken gilt. Um es auf den Punkt zu bringen: Wann wird der Tag kommen, an dem standardmäßig im industriellen Softwarebau zentrale IT-Mitarbeiter mit einer Zusatzqualifikation in Gesprächsführung, eher Coaches oder Changemanagern gleich, so mit den Kunden zusammenarbeiten, dass nicht länger IT-technische Dornröschenschlösser mit vielen nachträglichen Erkern und Anbauten entstehen, während der Anwender weiter von märchenhafter Software träumt? Professionalisierung des Softwarebaus

Erfolg hat nur, wer etwas tut, während er auf den Erfolg wartet. Thomas Alva Edison (1847–1931), amerikanischer Erfinder Der Softwarebau hat sich in der Tat erheblich weiterentwickelt, wird aber in den kommenden Jahren noch deutlich auf dem Weg hin zu fabrikmäßiger Produktion zulegen müssen, da es mit Sicherheit kein akzeptabler Zustand ist, wenn um die 50% aller Softwareprojekte2 nicht im Erwartungshorizont der Auftraggeber enden. Folgt man dem „Chaos-Report“ der Standish Group für das Jahr 2006, so wurde in 46% aller registrierten Fälle das Kosten- oder Zeitbudget gesprengt. In der Fachpresse wurde dies als Erfolg gefeiert, da die Quote zwei Jahre zuvor noch stolze 53% betragen 2

Mit Blick auf das Jahr 2006 wurde die Erreichung der 50%-Marke als großer Erfolg in der Fachpresse gefeiert.

1 Prolog

5

hatte. Ebenso wurde als neuer Rekord gefeiert, dass für denselben Vergleichszeitraum jetzt 35% aller berücksichtigten Softwareprojekte planmäßig in Betrieb gehen konnten, im Gegensatz zu 29% im Berichtszeitraum zwei Jahre zuvor. Wiederum zehn Jahre zuvor, wir schreiben das Jahr 1994, als die Standish Group zum ersten Mal diese Zahlen erhob, belief sich diese Erfolgsquote auf ganze 16%. Und noch eine Auswertung, die zu denken gibt: Im Jahr 1994 musste jedes dritte Softwareprojekt als Totalverlust abgeschrieben werden, inzwischen wird relativ gleichbleibend „nur“ noch jedes fünfte bis sechste Projekt komplett versenkt. Die hier wiedergegebenen Zahlen drücken eine deutliche Verbesserung aus, gleichwohl kann man sich leicht von diesen Quoten blenden lassen! Aber Hand aufs Herz: Würden Sie es als Produzent – egal ob Sie Autos, Fahrräder oder Nähmaschinen herstellen – sonderlich amüsant finden, wenn Sie nur bei jedem zweiten Produkt auf die geplanten Einnahmen kämen und jedes fünfte als Ausschuss aus der Produktion nehmen müssten? – Ich denke, dass kein Industriemanager oder Geschäftsführer im Non-IT-Bereich eine solche Ausschussquote lange akzeptieren würde, wenn ihm sein Job lieb ist! Auch wenn die Professionalisierung im Softwarebau Fortschritte macht, so kann nicht behauptet werden, dass die von Edgar Dijkstra 1968 erstmals ausgerufene „Softwarekrise“ tatsächlich überstanden sei. Aus diesem Grunde ist es notwendig von anderen Branchen zu lernen, die dort gewonnenen Erkenntnisse zu analysieren, wo immer geeignet, sich diese für den IT-Bereich zu eigen zu machen und die Entwicklung mit aller Kraft voranzutreiben. Dabei entsteht der Eindruck, dass sich der Softwarebau derzeit in einer vergleichbaren Situation befindet wie der Automobilbau der 70er Jahre: Während man in Europa und den USA nach den besten Verfahren und Methoden suchte, zog die japanische Automobilindustrie – allen voran der damals fast vom Untergang bedrohte Automobilproduzent Toyota – zum Schrecken aller an der Konkurrenz vorbei und setzte neue Standards in Sachen Effizienz und Qualität (Womack, Jones et al. 1991). Ganzheitliche Produktionsmethoden sowie die optimierte Einbeziehung der wichtigsten Ressourcen, nämlich der Mitarbeiter, bildeten hier die Ausgangsbasis für den Erfolg. Was aber bedeutet in diesem Kontext Professionalisierung? Folgt man einer kurzen, prägnanten Definition von Scott-Morgan (Scott-Morgan, Hoving et al. 2001), so steht dieser Begriff für Folgendes: Professionalität = stetiger Fortschritt + keine Überraschungen Professionalität = Fachwissen + neue Herausforderungen Dies bezieht sich sowohl auf die Produktseite, wie auch auf die Seite der Akteure. Professionelles Arbeiten des Einzelnen alleine reicht dabei nicht aus. Erst dann, wenn eine Organisation die notwendige Innovationsfähig-

6

1 Prolog

keit aufweist, wird dies dauerhaft zu besseren Produkten und damit verbunden größeren Marktchancen führen. Erlauben Sie mir daher anhand dieser, zugegebenermaßen sehr einfachen Formeln folgende ketzerische Frage: Leben Sie in einer IT-Organisation, bei der die laufende Produktion bzw. die ausgelieferten Produkte keine regelmäßigen Überraschungen mehr zu bieten haben? – Oder ergeht es Ihnen (wenn Sie ganz ehrlich sind) so wie übrigens immer noch recht vielen IT-Häusern – dass IT Management in der eigenen Organisation gleichzusetzen ist mit dem Bewältigen all der ständig neuen Überraschungen und Hiobsbotschaften. Auch der zweite Teil der Scott-Morgan’schen Aussage lässt sich durch eine weitere einfache Formel definieren: Innovationsfähigkeit = Kreativität + Ideenrealisierung Somit werden aus Business-Sicht einerseits Fachwissen in Verbindung mit Kreativität und andererseits Innovation gepaart mit der tatsächlichen Umsetzung dieser Ideen zu den zentralen Business-Drivern. Dem gegenüber steht ein in der IT-Community recht verbreiteter Ansatz: Er besteht darin, dass primär nach immer neuen Strukturierungsmethoden und technischen Werkzeugen gefahndet wird, um hiermit Software hoch systematisch zu entwickeln. Was aktive Ideenfindung anbelangt, so wird diese vielfach nur diffus erwartet, so als würden die richtigen Ideen an der korrekten Stelle eines Prozesses auf Knopfdruck ins Dasein purzeln. Dementsprechend werden die hierfür notwendigen intellektuellen Handwerkszeuge kaum kommuniziert oder geplant zum Einsatz gebracht. Dabei werden gerade mit deren Hilfe die wesentlichen Voraussetzungen dafür geschaffen, dass ein Unternehmen mit innovativen Produkten und Lösungen schnell und flexibel am Markt agieren kann, um so erfolgreich zu sein zu können. Während wir durch ingenieurmäßig strukturiertes Vorgehen Software als Konstrukte binärer Logik mit Hilfe solcher Methoden und Modelle entwickeln, werden mehr und mehr Grenzen sichtbar. Diese haben Ähnlichkeiten mit dem Übergang von der klassischen Mechanik zur Quantenmechanik, wo irgendwann einmal schmerzlich klar wurde, dass die schöne und klar umrissene Welt eines Isaac Newton und seiner Fallgesetze eben doch nur in erster Näherung passt und viele Fragen offen lässt. Sich dieser Erkenntnis zu stellen mag für manchen Betroffenen unbequem sein, ist doch jeder Computerchip und jede darauf ablaufende Software eine definierte Abfolge von logischen Schaltelementen bzw. Befehlsketten. Dies ist zweifellos der Fall, berücksichtigt aber nicht, dass die inzwischen ungeheure Menge dieser Schaltungen bzw. Schaltanweisungen superponierte Effekte hervorbringt, die eben nicht mehr ausschließlich klassisch logisch zu verstehen und zu lösen sind, obschon ihnen genau diese Logik zugrunde liegt.

1 Prolog

7

Und so wundert es nicht, wenn Bill Gates davon spricht, wie viel Neuland noch zu betreten sei. In einem Artikel über das, was Datenverarbeitung in den vergangenen 25 Jahren geleistet und hervorgebracht hat, berichtet er (Gates 2007) von den Grundsatzentwicklungen auf dem langen Weg zur Konsolidierung und flächendeckenden Nutzung von Software und weist Perspektiven auf neue Arbeitsfelder aus, wie z. B. die Robotics. Aber ist das Software-Engineering an sich, also diejenige Kunst, die auch bei noch komplexeren IT-technischen Fragestellungen reproduzierbare und qualitativ vorhersagbare Applikationen hervorbringen soll, auch schon bei solch einer Konsolidierung angelangt? Ich meine nein und betrachte die eingangs zitierten Zahlen als einen Indikator dafür. Zwar versuchen schon längst viele technisch Verantwortliche unter dem Motto „Simplify your IT“ dem Rad in die Speichen zu greifen und eine solche Konsolidierung bzw. Standardisierung in die Wege zu leiten, aber gelingt es ihnen tatsächlich, der rasch wachsenden Komplexität sowie den kontinuierlich neu hinzukommenden Anforderungen entgegenzusteuern? Viel wird investiert, um reproduzierbare Abläufe in möglichst weiten Bereichen der Software-Produktion zu etablieren und somit die Softwareentwickler in einem gewissen Maß zu Fließbandarbeitern zu machen. Ebenso sucht man einem der Hauptfeinde innerhalb der IT-Produktion, nämlich der Komplexität (Hamilton 2006) entgegenzuwirken, indem Standorte geschlossen werden oder einheitliche Plattformprodukte initiiert werden. Was bei all diesen Bemühungen jedoch offen bleibt ist die Frage, ob eine solchermaßen vorgenommene Konsolidierung tatsächlich zum gewünschten Erfolg führt, muss doch die Software von gestern im Sinne von Veränderungsmanagement und die Software von morgen im Sinne von innovativem Planen und Handeln gleichermaßen berücksichtigt werden. In diesem Sinne möchte ich Sie auf den folgenden Seiten dazu einladen, mich auf der Suche nach Verbesserungspotentialen im Softwarebau von heute und morgen zu begleiten, und dies vorrangig mit Blick auf die eigentlichen Akteure und deren hierfür benötigte Handwerkszeuge.

2 Irrwege und Auswege …

2.1 Softwarebau in der Dauerkrise Man kann ein Problem nicht mit den gleichen Denkstrukturen lösen, die zu seiner Entstehung beigetragen haben. Albert Einstein Es gibt wohl kaum ein Thema, das im Bereich der Softwareentwicklung heftiger, häufiger und auch kontroverser diskutiert wird, als die so genannte Softwarekrise. Existiert eine solche tatsächlich, ist sie längst Historie oder stecken wir immer noch mittendrin? Die Diskussion über die Frage, ob es diese Krise, von der Dijkstra erstmalig sprach, immer noch gibt, hat spätestens im Jahr 2001 eine ganz neue Facette bekommen, als es über Nacht zu dramatischen Einbrüchen an den Technologiebörsen speziell im Umfeld von Softwarehäusern kam. War Software über Nacht etwa qualitativ deutlich schlechter geworden? Hatte man Trends verschlafen? Oder brach, einer Vulkaneruption gleich, einfach ein totgeglaubtes, vielleicht auch totgeschwiegenes Problem mit lautem Getöse wieder hervor? Was immer die ganze Breite der damaligen Ursachen gewesen sein mag: Tatsache ist, dass in den vorangehenden Jahren die Werte der meisten IT-Firmen bis zu 1.000% an den Börsen gestiegen waren. Manches Unternehmen hatte sich verleiten lassen, mehr auf die eigenen steigenden Aktienkurse zu achten als auf qualitativ hochwertige Entwicklung der eigenen Produkte. Mitten in einer Zeit des Umbruchs, in der erste CASE3Tools angeboten wurden, die durch ihren integrativen Ansatz Planung, Entwurf und Dokumentation nachhaltig verändern sollten, herrschte Euphorie. Man sah sich endlich befreit von den lästigen Schatten der Vergangenheit, vertraute vielfach recht blauäugig auf die Versprechungen der Produktanbieter und stellte oftmals zu spät fest, dass es deutlich mehr bedurfte, als nur Tool-Schulungen, um diese sinnvoll und effizient anzuwenden. Da es an entsprechend darauf abgestimmten Vorgehensmodellen fehlte, scheiterten viele daran, diese Werkzeuge vernünftig einzusetzen, und so wundert es nicht, dass eine Krise ganz eigener Art – nennen wir sie Toolund Prozesskrise – zustande kam (Versteegen, Kruchten et al. 2000). Zwar 3

CASE = Computer Aided Software Engineering

10

2 Irrwege und Auswege …

war zu dieser Zeit im deutschen Bereich das V-Modell, andernorts das sog. Wasserfallmodell als Prozessmodell bereits im Einsatz, doch beide Vorgehensmodelle wiesen erhebliche Mängel für den Softwarebau auf, da in sehr statischer Weise Planung, Umsetzung und Qualitätssicherung der neuen Software abgearbeitet werden mussten. Zwar existierten auch schon Spiral- oder Iterationsmodelle (Boehm 1988), doch fehlte es weitgehend an der Durchgängigkeit im produktionstechnischen Sinn. Softwareseitig mauserten sich objektorientierte Methoden und versprachen einen eleganten Ausweg aus der Krise, allerdings tobte ein Methodenstreit, der erst schrittweise beigelegt wurde. Sucht man nach den damaligen Ursachen hierfür, so spielte die Anforderungserfassung sowie ihre technische Umsetzung eine wesentliche Rolle, da Anforderungen unklar formuliert bzw. nicht verstanden oder falsch bzw. unvollständig erfasst wurden und in Folge dessen instabil waren. Die Folge war vielfach eine falsche oder unvollständige Umsetzung, die erheblichen Einfluss auf die Realisierung der angestrebten technischen Lösungen hatte. Überdies kämpfte man in der Branche mit den immer wieder auftretenden Technologiesprüngen sowie mit dem Mangel an qualifizierten Mitarbeitern. Dies sind vorrangige Gründe für die Probleme, die man um die Jahrtausendwende im industriellen Softwarebau hatte. – Aber sind es nicht genau dieselben Probleme, mit denen wir noch heute zu kämpfen haben, obwohl viele „Best Practices“ bzw. neue Entwicklungstools eingeführt wurden, man viel in Qualitätssicherung investiert hat und vielfach große Anstrengungen unternommen wurden, um Softwarebau zu prozessualisieren? Obschon moderner Softwarebau auf mehrere Jahrzehnte an Erfahrung blickt, bewegt er sich immer noch nicht auf einem einfachen Weg, sondern gerät immer wieder in neue Krisen. Mit wachsender Komplexität der neuen Produkte sowie neu entstehenden technischen Hilfsmitteln verlagerte sich die eigentliche Problemzone zunächst Richtung Projektmanagement und dann weiter Richtung Anforderungserfassung. Mehr und mehr kamen in den 1990er Jahren Faktoren ins Spiel, die nur im Zusammenwirken der unterschiedlichen Beteiligten als aufeinander eingespieltes Team zu bewältigen waren, wofür geeignete technische Austauschplattformen erforderlich wurden. Was den immer wieder neu auftretenden Krisenzeiten gemeinsam ist, liegt interessanterweise nicht primär im Bereich technischer Ursachen, sondern hat zu tun mit den komplexen sozialen und organisatorischen Rahmenbedingungen. Dies zumindest belegen Studien der ETH in Zürich (Kuhnt and Huber 2001)4. 4

Am Institut für Informatik der Universität Zürich setzt man sich mit Fragen des IT-Projektmanagements auseinander und untersucht dort die Gruppenprozesse in IT-Projekten.

2.1 Softwarebau in der Dauerkrise

2.1.1

11

In den Sümpfen des mystischen Mann-Monats Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest. Frederick Brooks

Bei all dem bewegen wir uns in einem Kontext, der keineswegs neu ist. Seitdem Frederick Brooks im Jahr 1975 seine IT-Essays über den sagenumwobenen „Mann-Monat“ (Brooks 1995) erstmals veröffentlichte, hat sich technologisch betrachtet sehr vieles verändert. Brooks, der viele Jahre als IT-Professor und zugleich bei IBM für die Hardware-Entwicklung des „Systems 360“ verantwortlich war, untersuchte in diesem Werk die Eigendynamik großer Softwareprojekte. Wir begegnen dort den Monstern der IT, nämlich nicht eingehaltenen Terminen, gesprengten Budgets sowie fehlerhaften Produkten. Aspekten also, die sich im ganz normalen Entwicklungsalltag zunächst als harmlose Zeitgenossen ankündigen und dann auf einmal, um in der Sprache von Brooks zu bleiben, sich aus dem Nichts in furchterregende Werwölfe verwandeln, für deren Erlegung man die berühmte silberne Kugel braucht, nämlich diejenige Wunderwaffe, um diesen Ungetümen den Garaus zu machen. Klingt dies nicht mehr als dreißig Jahre später immer noch äußerst aktuell? Haben nicht über all die Jahre hinweg immer wieder wissenschaftliche Institute oder Entwicklungshäuser den Sieg, die allein rettende Wunderwaffe aufgrund technischer Neuerungen ausgerufen, und ist es nicht ein Faktum, dass seit den frühen 70er Jahren des vergangenen Jahrhunderts diese Krise laut Brooks oder Dijkstra existiert und keine Entwicklung sie wirklich aufgelöst hat? Dabei wäre es sicherlich ungerecht all den vielen genialen und weniger genialen Köpfen, die die IT seither massiv weitergebracht haben, die gelbe Karte zu zeigen. Hatte Brooks vielleicht doch Recht, als er in seinem Werk postulierte, dass er keinen überraschenden Erfolg erwarten könne und binnen der folgenden 10 Jahre nicht mit wirklichen Durchbrüchen in Bezug auf die Erledigung dieses Ungetüms zu rechnen sei? – Ja, ist es nicht sogar noch viel schlimmer gekommen? Ist nicht inzwischen über ein Vierteljahrhundert verstrichen, ohne dass es zu wirklichen Erfolgen auf breiter Front kam? Wie löst sich die Problematik der menschlichen Fehler in der Softwareentwicklung – noch dazu, wo Werkzeuge, Verfahren und Applikationen immer komplexer werden? – Reicht es aus, Menschen mit genial durchdachten Checklisten und Prozessvorgaben ans Werk zu schicken, da-

12

2 Irrwege und Auswege …

mit sie auf keinen Fall einen der vielen Teilschritte im Softwarebau übersehen oder gar vergessen? Ist der Mensch in dieser wohl kompliziertesten aller von im gehandhabten Technologien einfach am Rande seiner intellektuellen Kapazitäten? – Oder könnte es sein, dass wir aus lauter Technikund Prozessverliebtheit wesentliche Aspekte im Softwarebau unzureichend betrachtet haben? Lassen Sie uns hierzu den Ausführungen von Brooks folgen und die Schwerpunkte seiner Ursachenforschung von damals zusammenfassen: Änderbarkeit: Im Gegensatz zu anderen Industriegütern, die seiner Meinung nach nur einer geringen Veränderungsrate unterliegen, ist Software einer hohen Änderungsquote unterworfen, insbesondere da keine Materialkosten anfallen. Unsichtbarkeit: Zur der Zeit, als Brooks diese Aussagen machte, wurde Software noch nicht visualisiert. Entsprechend fehlte es an graphischen Werkzeugen und Diagrammformen, also all dem, was heute moderne Tools und Modellwelten zu bieten haben. Die Folge: Abstraktion führt sehr viel leichter zu Fehlern. Komplexität: Da jede Software auf ihre Weise ein Unikat ist, bedeutet Softwareerweiterung nicht notwendigerweise eine Wiederholung bestehender Elemente, sondern die Schaffung neuer. Da Komplexität ein zentrales Problem im Softwarebau ist und diese überproportional mit der Größe eines Programms zunimmt, stellen sich hierdurch Zusatzprobleme ein, etwa Sicherheitslücken aufgrund nicht dargestellter Zustände. Konformität: Programme müssen den Anforderungen der Benutzer entsprechen, diese aber sind oftmals willkürlich! Ebenso muss Software sich an gegebene Situationen anpassen können, bzw. es werden extrem hohe Anforderungen an solche Systeme gestellt. Diese wiederum bewirken eine Erhöhung der Komplexität. Folgt man diesen Problemkreisen im Softwarebau, so lässt sich im Hinblick auf heute sehr wohl erkennen, wo überall bereits Baulücken geschlossen wurden, seitdem Brooks diese Themenfelder postulierte. Inzwischen sind visuelle Tools, das Modellieren von Use Cases oder auch prozessgetriebenes Arbeiten in unterschiedlichen Ausprägungen gangbare Möglichkeiten, um Software zu bauen.

2.1 Softwarebau in der Dauerkrise

2.1.2

13

Fehler ohne Verjährungsfristen Operative Hektik ist ein Zeichen geistiger Windstille. Joseph Schmidt, Management-Trainer

Softwarebau ist weit mehr als nur das geschickte Platzieren von Bits und Bytes, das Definieren von Objekten und Strukturen bzw. das Implementieren von Geschäftsmodellen und Prozessen. Hat man in den Planungsphasen vorwiegend diese Bereiche im Auge, so darf es nicht verwundern, wenn eines der nachfolgenden Ergebnisse zutage tritt. Zufallsdesign: (engl. Design by Default) Während der Entwicklung hat man sich auf die eingesetzte Technik und die geforderten Funktionalitäten konzentriert. Eher zufällig sind dabei die Gesamtstruktur wie auch die Schnittstellen zum Anwender entstanden. Eine gezielte Planung in diesen Bereichen fand nicht oder viel zu spät statt. – Die Folge: am Ende hat man ein Produkt, das sehr stark von den eingesetzten Techniken geprägt ist. Benutzerfreundlichkeit ist nicht unbedingt die Stärke einer solchen Anwendung. Nachahmungsdesign: (engl. Design by Mimicry) Dies ist nicht das erste Softwareprojekt einer Organisation, und so kopiert man Fragmente von eigenen Produkten oder man kupfert von Fremdprodukten so viel wie möglich ab. Dies geschieht in der Hoffnung, so die eigenen Entwicklungsaufwände zu begrenzen. Planungen über gezielte Wiederverwendbarkeit oder von echten Produktfamilien5 fanden nicht oder zu spät statt. Die Folge: Der Pflegeaufwand für diesen „Zoo“ an ähnlichen Programmen ist immens, da jedes Produkt, trotz seiner scheinbaren Ähnlichkeit, individuell angepasst bzw. gepflegt werden muss. Schicksalsdesign: Ohne einen zentralen „Mastermind“, der ein Gesamtkonzept verfolgt und Impulsgeber für das Gesamtergebnis ist, sitzen viele Spezialisten an ihrem spezifischen Bereich und liefern hierfür entsprechende Lösungen. Auch wenn technische Abstimmungen zu anderen Fachbereichen stattfanden und auch am Ende ein funktionierendes Produkt entstand, so ist das Gesamtprodukt eher mit einer bunten Blumenwiese unterschiedlicher konzeptioneller und technischer Ausprägungen mit vielfältigen Redundanzen zu vergleichen, dem zugrundeliegende gemeinsame 5

Produktfamilien bilden sich aus einer Gruppe von Produkten, die in definierten Bereichen auf gleiche Komponenten zurückgreifen (= Commonalities), während sie in anderen definierten Bereichen voneinander abweichen (= Variabilities). Typischerweise werden Produktfamilien dazu verwandt, unterschiedliche Teilbereiche eines größeren Gesamtmarktes individuell zu bedienen.

14

2 Irrwege und Auswege …

Konzepte fehlen. Die Folge: auch wenn man es vor dem Kunden verheimlichen kann – aber ein Blick in das Innere dieser Konstruktion lässt nur noch einen Satz über die Lippen kommen: „Hier wurde liebevoll, aber nicht konsequent strukturiert gearbeitet, schlimmstenfalls gebastelt“. Können wir uns solche Arten ineffizienten Softwarebaus in einer Zeit, wo es um industrielle Qualität und Zertifizierungen, aber auch hohen Wettbewerbsdruck geht, noch leisten? – Mehr noch: Wie immer die in Ihrer Organisation entwickelte Software aussehen mag, Fakt ist, dass es intrinsische Eigenschaften gibt, die im Lebenszyklus des Produktes zu erheblichen Risiken und auch Folgekosten führen können. Hier einige Beispiele: • Software ist nicht nur als Problemlöser zu betrachten, sondern stellt aufgrund seiner inhärenten Eigenschaften ein erhebliches Problem und somit auch Risiko da. – Kennen Sie die individuellen Risiken und deren Ursachen? • Software wird für ein einfach zu modifizierendes Produkt gehalten. Es trifft zwar zu, dass Programmcode, ohne Materialkosten zu verursachen, geändert werden kann, die zielgerechte und korrekte Änderung ist wegen der dabei möglichen Verletzung der gewünschten inneren Wirkzusammenhänge oder wegen der möglichen Hinzufügung neuer, nicht beabsichtigter innerer Wirkzusammenhänge jedoch extrem teuer. – Sind diese Wirkzusammenhänge in Ihrer Organisation bekannt und haben Sie effektive Wege damit umzugehen? • Software wird oftmals für ein preiswert zu erstellendes Produkt gehalten. Preiswert ist lediglich die Vervielfältigung eines einmal entwickelten Systems, die Ersterstellung ist allerdings sehr personal- und somit kostenintensiv. – Was tun Sie dafür, dass Ihre Mitarbeiter maximal effizient arbeiten können? • Software gewinnt im Laufe der Zeit eine weitgehende Eigenständigkeit dadurch, dass die meisten Anwender die Detailkenntnisse der durch sie repräsentierten Problemlösungsverfahren verlieren6. Software wird somit zum eigentlichen Wissensspeicher in der jeweiligen Organisation oder auch fachlichen Domain – wobei dieses Wissen oftmals nur noch stark verschlüsselt und somit nicht mehr direkt verstehbar vorliegt. – Haben Sie die Wissensproblematik in Ihrer Organisation im Griff oder sind Sie zum Friedhofsgärtner Ihrer eigenen Datengräber avanciert? • Auch wenn viele Dokumente über die eigene Software existieren, so driften Wirklichkeit (= was tatsächlich kodiert wurde) und Fiktion (= was tatsächlich dokumentiert wurde) oftmals auseinander. – Wie halten Sie in der eigenen Organisation Sein und Schein beieinander? 6

Ein ganz simples Alltagsbeispiel: Können Sie noch per Hand Wurzeln ziehen – oder macht das Ihr Taschenrechner bzw. Computer?

2.1 Softwarebau in der Dauerkrise

15

• Software wird fälschlicherweise als ein nicht verschleißendes und damit nicht alterndes Produkt angesehen. Die fortlaufende Korrektur und die immer wieder notwendig werdenden Änderungen und Erweiterungen – zur Vervollkommnung des durch sie repräsentierten Problemlösungsverfahrens – führen zum „Einbau“ nichtbeabsichtigter Effekte, zu strukturellen Verwaschungen und damit zum Altern. – Wie sehen die „AntiAging“-Pillen für Ihre Software-Produkte aus – oder leben Sie nach dem St. Florians-Prinzip? Trotz aller eingesetzten Techniken und Methoden: Wenn es auf diese und andere Fragen keine oder nur unzureichende Antworten gibt, so sind genau diese Themen es, die im Laufe der Jahre in erheblichem Maß zum Risiko und zur Kostenfalle werden. – Wenn also diese Aspekte zu demjenigen Stoff gehören, mit dessen Konsequenzen wir uns täglich auseinandersetzen müssen, so ist zu fragen, wie diesen rechtzeitig begegnet werden kann. – Auch wenn es in der Branche immer noch recht beliebt ist, auftretende Probleme erst dann abzuarbeiten, wenn es brennt, so ist anzumerken, dass grundsätzliche und rechtzeitige Antworten sehr viel zielführender sind als nur die Beseitigung aktueller Störfälle. Im Sinne eines TQM7 oder anderer qualitätsgetriebener Vorgehensweisen geht es darum, Probleme an der Wurzel zu lösen. Auch wenn mancher Manager Problemlösung und Ziele in einen Topf wirft und folglich aus der Lösung von Problemen Zielerreichungsaufgaben definiert (Radatz 2004, S. 132ff.), an welchen dann wiederum Zusatzvergütung – vielleicht auch die eigene – hängt, so muss man sich Folgendes klar machen: Indem Sie Probleme abarbeiten, beseitigen Sie sichtbare Defizite und gelangen somit auf den Null-Stand – aber auch keinen Deut weiter! Dies hat zur Folge, dass Sie – gerade im Softwarebau – ein paar Fehler weniger haben werden (hoffentlich!), jedoch keine Innovation. Mit dererlei Ansätzen betreiben Sie Symptom-, aber keine Ursachenbekämpfung! 2.1.3

Handeln mit Kurzsichtigkeit Wir leben in einer Zeit vollkommener Mittel und verworrener Ziele. Albert Einstein (1879–1955, dt.-amerik. Wissenschaftler)

Softwarebau isoliert von der jeweiligen Organisation und ihren Entscheidungsträgern zu sehen ist blauäugig. Aus diesem Grunde erscheint es notwendig einen Teil der Krise außerhalb der eigentlichen IT zu suchen, und zwar in den Köpfen der Verantwortlichen bzw. Beteiligten. Grundsätzli7

Total Quality Management

16

2 Irrwege und Auswege …

ches Umdenken ist hier auf allen Ebenen angesagt, da sich viele ITtechnische Probleme eben nicht damit lösen lassen, dass man einfach mehr desselben im Sinne von mehr Technik, mehr Mitarbeitern oder Prozessen tut. Anhand einiger Beispiele werde ich Ihnen vorstellen, was ich damit meine. Dabei einen Blick in die eigenen Reihen zu werfen und sich zu fragen, welche Fallen menschlicher Logik hier zu suchen sind, kann sehr heilsam sein. Worum es geht, ist gut gemeintes Handeln und Planen – oder um es mit dem 2007 verstorbenen Kommunikationswissenschaftler Watzlawick auszudrücken: „Mehr desselben zu tun kann für sich zum Problem werden.“ – Nebenbei bemerkt: Es ist erstaunlich, wie oft dieser „Mehr-desselbenEffekt“ gerade auch den realen IT-Alltag betrifft. – Wie dies zu verstehen ist, lässt sich sehr einfach an einer Geschichte um die US-amerikanischen Saturn-Mondraketen zeigen: Als diese Raketen zum Einsatz gebracht werden sollten, suchte man nach Möglichkeiten um diese gigantischen und zugleich hochempfindlichen Konstrukte vor Witterungseinflüssen, insbesondere Regen und Blitzschlag zu schützen. Infolgedessen konstruierte man einen Hangar, der so hoch war, dass er solch eine Rakete stehend aufnehmen konnte. Bei der Konstruktion dieses riesigen Gebäudes ging man von den Erfahrungen im Flugzeug-Hangerbau aus und extrapolierte die Dimensionen entsprechend. – Das Gebäude wurde entsprechend realisiert und nach dessen Fertigstellung zeigte sich, dass ein Raum derartig gewaltiger Ausmaße entstanden war, dass er ein eigenes, inneres Klima entwickelte, bestehend aus Regengüssen und Entladungen statischer Elektrizität. Somit war genau das in der Halle vorhanden, wovor man die Raketen hatte schützen wollen. – Mehr derselben Lösung wurde hier zum Problem! Im Bereich der Logik, wie auch der Planung gibt es eine ganze Reihe solcher Fallen. Die Folge ist im realen Alltag hektische Betriebsamkeit und volles Engagement bei Dingen, die nicht wirklich zielführend sind. Abb. 2.1 verdeutlicht solch einen Regelkreis am Beispiel von fehlenden Zieldefinitionen. Wurden zu Anfang eines Projektes nicht eindeutige Ziele definiert und wechselseitige Abhängigkeiten ermittelt, so wird sich durch das gesamte Projekt, wie auch den nachfolgenden Lebenszyklus eine stetig wachsende Schleppe von Unklarheiten und Problemen hindurchziehen, die eben nicht durch weitere Mitarbeiter oder bessere Werkzeuge gelöst werden, sondern Folgen solcher unberücksichtigten Abhängigkeiten sind. Der Zeitpunkt für die grundsätzliche Vermeidung einer solchen Problem Schleppe lag ganz weit am Projektanfang. Dort hätte man durch ganzheitliche Sichtweisen auf die zu realisierende Software im Kontext der eigenen Organisation, deren Zielen und Fähigkeiten Klarheit schaffen können. Ebenso hätten mutige und umsichtige Entscheidungen an genau dieser Stelle hohe Folgekosten verhindern können. Ist dieser Zeitpunkt einmal überschritten,

2.1 Softwarebau in der Dauerkrise

17

Abb. 2.1. Folgen fehlender Ziele

so wachsen die Kosten zur Beseitigung dieser Unachtsamkeiten quasi auf Tagesbasis – die Folgekosten zur Beseitigung der Kollateralschäden übrigens auch! Wie immer Sie letztendlich Ihre Software bauen: die Spätfolgen werden Ihnen über die Software-Entwicklungsphase bis zum Ende des Lifecycle erhebliche Folgeprobleme und somit -kosten bescheren! In seinem Werk „Logik des Misslingens“, (Dörner 2006, S. 94ff.) geht der Psychologe Dietrich Dörner dieser Art problem-erzeugender Logik nach und zeigt auf, wie schwierig es ist, komplexe Systeme zu beherrschen. Bei allen guten Absichten tappen wir als Menschen sehr leicht in die erwähnten logischen Fallen. – Was es braucht, ist ganzheitlich strategisches Denken in komplexen Situationen. Dies beinhaltet deutlich mehr, als nur die klassischen Themen der IT zu beherrschen. Eine weitere Spielart dieser „Mehr-desselben“-Problematik gehört in vielen IT-Häusern zum Standard-Repertoire der Verantwortlichen: Spreadsheets sind hervorragende Werkzeuge und man kann eine Menge vernünftiger Dinge damit anstellen. Fängt man aber an, Projektmathematik damit zu betreiben, so entpuppen sich diese Instrumente leicht als felsgroße Stolpersteine! Warum? Bewerten Sie selbst das nächste Beispiel aus dem realen Leben: Sie haben für ein Softwareprojekt eine gewisse Anzahl von Mitarbeitern abgeschätzt. Nun gefallen diese Zahlen den Projektsponsoren aber nicht, weil diesen alles zu lange dauert oder zu teuer ist. Sie erhalten den Auftrag, das gleiche Projekt mit gleichem oder geringerem Budget in, sagen

18

2 Irrwege und Auswege …

wir, der halben Zeit umzusetzen. Was tun Sie? Nun, der „gesunde“ Menschenverstand sagt: Schieb alles weiter nach vorne und stelle sicher, dass die Gesamtsumme gleich bleibt. Sollten Sie auch zu dieser Lösung gelangt sein, so darf ich Sie herzlich im Club der Projektmystiker begrüßen! Warum? Glauben Sie tatsächlich allen Ernstes, dass Sie mit doppelter Belegschaft (= „Mehr desselben“) in der halben Zeit dieselbe Lösung erreichen können – oder war dies nur eine „politische“ Aussage, damit die Projektsponsoren wieder ruhiggestellt sind? Faktisch gesehen geht diese irrige Annahme in weitem Bogen an der Wirklichkeit vorbei, wie man bereits seit den zwanziger Jahren des letzten Jahrhunderts weiß. Aus dieser Zeit stammen frühe Experimente des Organisationsmanagements, wie etwa der Hawthorne-Effekt. Dieser besagt, dass jede Veränderung der Arbeitsumgebung (etwa am Arbeitsplatz) einen kurzzeitigen Anstieg der Produktivität nach sich zieht. – Aus dieser einfachen Beobachtung leitet sich für die Betriebswirtschaftslehre ab, dass menschliche Arbeitsleistung nicht nur von den objektiven Arbeitsbedingungen, sondern ganz wesentlich auch von sozialen Faktoren geprägt ist. Gerade der zweite Punkt gilt in besonderem Maße für die SoftwareProduktion, da hier eine störungsarme Kommunikation zwischen den Beteiligten von größter Bedeutung ist. Diese muss sich aufgrund der sozialen Rahmenfaktoren entwickeln und entsteht nicht auf Knopfdruck oder per Anordnung. Vielmehr wächst so etwas sehr langsam, ist überdies sehr pflegeintensiv und korreliert in hohem Maße mit Teamgrößen. – Hiermit gekoppelt ist die Erfahrung, dass eine Beliebigkeit bei der Zusammensetzung von Teams ebenso wenig funktioniert. Jedes Team, das neue Mitarbeiter bekommt bzw. von welchem Mitarbeiter abgezogen werden, wird zunächst in der Leistung nachlassen, da sich die jetzt zusammenarbeitende Gruppe von Menschen erst einmal wieder neu finden muss – und auch dies kostet nicht unerheblich Zeit (Belbin 1996).

2.2 Haben und Schein Die Leute glauben oft, dass Unternehmen aus Zahlen (wie der »Bilanz«), aus Kräften (wie den »Marktkräften«) oder Dingen (»dem Produkt«) – auch aus Fleisch und Blut (»unseren Mitarbeitern«) bestehen. Aber das stimmt nicht. Unternehmen bestehen aus Ideen – Ideen, die in Worten ausgedrückt werden. James Champy Noch immer ähnelt Softwarebau in weiten Bereichen der IT-Community eher einem Überlebenstraining unter erschwerten Bedingungen, bei dem

2.2 Haben und Schein

19

die Mitarbeiter bis an die Grenzen ihrer psychischen und physischen Leistungsfähigkeit kämpfen, um die geforderten Produkte zu realisieren. Die unter hohem Einsatz erstellten Applikationen wiederum, welche die eigene Organisation verlassen, erfüllen zwar auf den ersten Blick ihre Zwecke, haben aber bei genauerer Betrachtung oft deutliche Abweichungen von den ursprünglichen Wünschen, Qualitätsansprüchen oder Zielkosten. In Folge dessen wird zwangsläufig Kundenbefriedigungspolitik auf unternehmenspolitischer Ebene betrieben. Zugeständnisse aller Art oder Softwarepatches in rasender Abfolge sind dabei gern eingesetzte Mittel, einfach nur um eben diese Kunden ruhig zu halten bzw. sie nicht zu verlieren. Dabei beschreibt so mancher Verantwortliche dies als das wirkliche Leben im Softwarebau. Andere Branchen sind hier inzwischen ehrlicher geworden und würden so etwas weniger nonchalant als Vertuschung von Pfusch bezeichnen. Einmal Hand aufs Herz: Klingt das nicht wie ein zur Routine gewordener Notbehelf ? Sind nicht viele Unternehmen weit von dem entfernt, was man als eine konsolidierte IT-Produktion bezeichnen könnte? – Wo aber liegt das Problem? Managementseitig fehlt es sicherlich immer wieder am Mut und der Risikobereitschaft, Dinge grundsätzlich und konsequent zu ändern und nicht nur Kosmetik zu betreiben bzw. erhöhte Anforderungen an die nachgeordneten Mitarbeiter zu delegieren. Auf Seite der Technik hingegen ist vielfach die notwendige Weitsicht nicht vorhanden, um jenseits des eigenen IT-technischen Tellerrands auf diejenigen Dinge zu schauen, die im realen Alltagsleben über Wohl und Wehe der eigenen Entwicklung entscheiden. Ebenso wenig leistet man sich vielfach noch den Luxus, interne systematische Schwachstellen ausfindig zu machen, sondern versucht durch Einzelmaßnahmen besser zu werden. – Wie aber kann ein in sich so hoch vernetztes System8, wie es Softwarebau nun einmal darstellt, signifikant verbessert werden, wenn nicht auf dieser Systemebene im Kontext der eigenen Organisation damit begonnen wird, Probleme dieser Art aus dem Wege zu räumen? 8

Softwareproduktion als System verstanden, bedeutet, dass Sie sich die Abhängigkeiten und Störgrößen in der Produktion und der Pflege von Softwareproduktion vor Augen halten. – Einige Beispiele hierzu: Sie müssen schnell Software bauen und ausliefern, diese wird in den meisten Fällen eine höhere Fehlerquote aufweisen, als sorgsam geplanter und entwickelter Code. Die Folge ist, dass Sie z. B. aufgrund von Reklamationen nacharbeiten müssen, was wiederum Mitarbeiter aus der aktuellen Produktion bindet und das nächste in Entwicklung befindliche Produkt negativ belastet. – Oder Sie möchten, dass Sie schnell zu Produkten kommen, ohne eine wirklich klare (technische) Produktstrategie in der eigenen Organisation zu pflegen. Die Folge wird sein, dass Sie z. B. die aktuelle IT-Architektur relativ schnell adaptieren müssen, Code muss infolgedessen umgearbeitet oder ergänzt werden und spätere Änderungswünsche führen zu deutlich höheren Mehraufwänden.

20

2 Irrwege und Auswege …

Dies wird umso kritischer, als immer mehr und immer komplexere Tätigkeiten des täglichen Lebens auf diese Form maschineller Intelligenz übertragen werden. Vieles, was bis vor Kurzem noch direkt von Menschen für Menschen – etwa als Dienstleistung – erbracht wurde, ist schon längst durch rein digitale Dienstleister ersetzt worden.9 Ergo: Die Anforderungen an die IT-Wirtschaft wachsen in jeglicher Weise. Computergestützte Maschinen werden immer mehr zum interaktiven Gegenüber des Menschen. Um dies zu leisten müssen sie mit dem Anwender mittels geeigneter Dialogformen kommunizieren und somit viele derjenigen Fähigkeiten intern abbilden, wie sie der menschlichen Kognition entsprechen. Ein ganzes Heer ausgebildeter IT-Spezialisten und Business-Analysten widmet sich inzwischen der Suche nach prozesstechnischen Abbildungen vormals von Menschen ausgeübter Tätigkeiten auf Daten verarbeitenden Maschinen, um so immer neue Aspekte unseres täglichen Seins informationstechnisch zu automatisieren und auf Computersystemen abzubilden. Je weiter sich diese Grenzen technischer Möglichkeiten verschieben, umso mehr werden Binnenfaktoren innerhalb der IT-Produktion zum eigentlichen Hemmschuh der Entwicklung. Die Rede ist vom Umgang mit der stetig wachsenden Komplexität, gekoppelt mit der Intransparenz solcher Systeme oder dem oft nicht mehr vorhersagbaren Verhalten von Applikationen, etwa im Bereich der Performance. Diese Hemmnisse lassen sich nur dann aus dem Weg räumen, wenn die tatsächlichen Kundenwünsche in hinreichender Weise ermittelt, abgegrenzt bzw. geclustert wurden und anschließend in hocheffiziente und -performante Codestrukturen überführt werden. Mit diesem Ziel vor Augen und dem Wissen, dass Softwareentwicklung sehr häufig mit nebulösen Vorstellungen beim Kunden beginnt und erstellte Lösungen fast immer neue Ideen und Wünsche bei diesem auslösen, braucht es andersartige Ansätze und Strategien, um diesem Dilemma systematisch zu begegnen. 2.2.1

Der Traum von Fließbandproduktion

Somit bilden nicht alleine mehr Teamgrößen oder eingesetzte Hardwareplattformen die wirklich kritischen Begrenzungen, sondern Fragestellungen darüber, wie die entstehenden Lines of Code überhaupt noch überschaubar 9

Ich denke hierbei nicht nur an den heimischen PC mit Dingen wie dem Internet als Chat- und Shoppingplattform, Behördenkommunikation und Buchungsmaschine von Reisen. Ebenso gehören für mich die Automatisierungshilfen wie etwa Pfandflaschenrückgabesysteme, interaktive Eincheckmaschinen oder quasi-intelligente technische Haushaltshilfen dazu – um nur einige wenige Beispiele zu nennen.

2.2 Haben und Schein

21

bleiben können bzw. wie man sie auf eine halbwegs sichere Art und Weise managen kann. Immerhin sind Quellcodes mit mehreren Millionen Zeilen nichts Ungewöhnliches mehr und Programme mit etwa 100 Millionen Lines of Code werden nicht mehr lange auf sich warten lassen. – Es verwundert somit nicht, wenn renommierte Automobilproduzenten, die in ihren hochwertigen Auto-Modellen bis zu mehrere Mio. Lines of Code haben, hinter vorgehaltener Hand über die Verschlankung der IT-Technik im Automobil nachsinnen, da auch dort die Fehlerquote der entwickelten Software nicht oder nur mit größten Anstrengungen im gewünschten bzw. benötigten Bereich zu halten ist. Es ist nachvollziehbar, dass nach immer neuen Wegen gesucht wird, um diese Codemassen im Sinne eines Kontinuums beherrschbar zu machen. Dabei stehen sehr unterschiedliche Konzepte im Raum: etwa die viel diskutierten Ansätze des SOA10 oder MDA11, Überlegungen zum ontologiegetriebenen Softwarebau12 oder Experimente mit sich autonom entwickelndem Code13. Allen Ansätzen gemeinsam ist dabei, dass die so entwickelten Programme natürlich nach wie vor eine gigantische Kette von Logikbefehlen darstellen. Mit Blick hierauf wird der bereits erwähnte Vergleich zur Thermodynamik transparent: Alle Gesetze der Mechanik – etwa die Stoßgesetze – gelten innerhalb der Thermodynamik. Aufgrund der großen Masse beteiligter Einzelelemente überlagern sich jedoch zusätzlich Eigenschaften, die bei der Präsenz von wenigen Objekten so nicht feststellbar sind. – Übertragen auf die Codebasis heißt dies, dass sich letztendlich eine erweiterte Handlungslogik mit eigener Dynamik der klassischen Ablauflogik überlagert und wirksam wird. Als Beispiel sei hier auf die Dominoeffekte verwiesen, bei welchen durch Überlastung oder Ausfall eines Systems bzw. einer Datenstrecke andere Systeme in Mitleidenschaft gezogen werden und sich im Zweifelsfalle selbst abschalten oder möglicherweise sogar in undefinierte Zustände übergehen. In Folge eines solchen Ausfalls können zusätzliche Systemausfälle anderswo eintreten, bis dahin, dass ganze Bereiche kollabieren, wie dies wiederholt im Internet aufgrund von Computerviren geschehen ist. Die Frage lautet somit: Kennen wir die grundlegenden Mechanismen einer solchen superponierten Eigenlogik und -dynamik und beherrschen 10 11 12 13

SOA – Service-orientend Architecture MDA – Modell-driven Architecture Ontologien werden als Möglichkeit genutzt, um Wissensnetzwerke abzubilden. Im Rahmen der NASA-Forschung wird nach Möglichkeiten gesucht, wie Computercode sich selbst weiterentwickeln kann. Auch an der Universität Karlsruhe befasst man sich unter der Themenstellung „Autonomic Computing“ mit dieser Art von Fragestellungen, wobei man hier nach Wegen der Selbstkonfiguration, Selbstoptimierung bzw. der Selbstheilung von Software sucht.

22

2 Irrwege und Auswege …

wir diese „thermodynamischen IT-Effekte“ im Softwarebau oder leben wir immer noch in einer Welt simpler Funktionsabläufe, wie sie einstmals für ein „Hello-World-Programm“ sinnvoll und notwendig waren? – Tun wir dies, so drücken wir dem Prinzip Zufall den Dirigentenstab in die Hand und müssen uns keineswegs wundern, wenn ungewünschte und nicht vorhersagbare Resultate im Softwarebau weiterhin Tagesgeschäft sind. Dabei ist klar: Industrieller Softwarebau ist in der Mehrzahl aller Fälle nichts, was sich aus klinisch reinen Phasen des Planens, Umsetzens, Austestens und der anschließenden gebrauchsfertigen Auslieferung von Applikationen zusammensetzt und prozessual lupenrein – einem Fließband gleich – entsteht. Auch wenn viele Methodenhandbücher auf vollkommene Prozesstreue setzen, so bedarf es dennoch in bestimmten Phasen der Softwareproduktion eines hohen Maßes an Phantasie, Kreativität und Improvisationsvermögens. Darüber hinaus gilt es einen Blick in eine andere Richtung zu werfen: Während immer noch so mancher fehlerhafte Software als Fatum der Informationstechnik betrachtet und diese entnervt oder auch stoisch hinnimmt, ist längst nachgewiesen, dass es sehr wohl möglich ist fehlerfreie Produkte zu bauen, wenn die richtigen Vorgehensweisen zum Einsatz kommen. Dabei ist codeseitig bereits jetzt die Palette an Möglichkeiten breit gestreut: So kommen etwa bei Microsoft Model-Checker14 zum Einsatz oder Theorem-Beweiser15 werden für sicherheitsrelevante Software, etwa im Luftverkehr, eingesetzt. Diese Techniken können Fehler, etwa in der Programmlogik, aufspüren – und das steigert die Qualität erheblich. Wie viel effektiver wäre es jedoch, wenn Fehler direkt am Ort ihrer Ursache gefunden und dann grundsätzlich bekämpft würden? Dieser Ansatz, der mit den Grundforderungen der „Lean Production“ im Automobilbau bzw. dem TQM konform geht, führt folgerichtig in vielen Fällen zu der Entwicklungsmannschaft selbst. 14

15

Hierbei werden für Software-Modelle kritische Zustände definiert, die nicht gleichzeitig mit anderen Programmteilen auftreten dürfen. Model-Checking versucht zu beweisen, dass solche verbotenen Kombinationen, wie sie z. B. durch Drittanbieter-Komponenten im Betriebssystemkern verursacht werden könnten, nie gemeinsam auftreten – und bricht Prozesse rechtzeitig ab, um die Systemstabilität zu gewährleisten. Diese Werkzeuge überprüfen, ob ein Computercode lückenlos die an ihn gestellten Anforderungen erfüllt, dabei nicht in unkontrollierbare Zustände gerät oder mit Werten operiert, die zu Fehlfunktionen im Programmablauf führen könnten. – Dieser Thematik wird große Bedeutung beigemessen, weshalb seit 2004 die Deutsche Forschungsgemeinschaft in ihrem Sonderforschungsbereich „Automatische Verifikation und Analyse komplexer Systeme“ die formale Verifikation für hochgradig vernetzte Systeme fördert.

2.2 Haben und Schein

2.2.2

23

Handeln von heute, Trends von morgen

Die knappste Ressource in Unternehmen sind leistungsfähige Menschen. Drucker (1995) Komplexe Systeme, wie etwa moderne Software, lassen sich nicht mehr durch ein Heer von „Einzelkämpfern“ realisieren, sondern verlangen „echte“ Teamarbeit. Dies bedeutet, dass die Gruppe von beteiligten Personen auch im sozialen Sinne sehr eng interagieren muss und es nicht ausreichend ist Rollen, Prozessabläufe oder Templates in sinnvollen Reihenfolgen vorzugeben und zu erwarten, dass diese in entsprechender Weise strukturiert abgearbeitet werden. Der Trend im Softwarebau, möglichst vieles in klar definierbare Schrittabfolgen zu zerlegen, kann demzufolge zum Fallstrick werden. Um dies an einem simplen Beispiel zu verdeutlichen: Ausschließlich prozessgetriebenes Handeln führt sehr schnell – gerade bei größeren Organisationen – zu Situationen, bei denen jeder Mitarbeiter seiner Rolle gemäß genau nachschlagen kann, was jetzt an diesem Prozessschritt für ihn zu tun ist. Man hat seinen Prozess, weiß, wen man wann mit welcher Sache zu beliefern hat, verfügt über Templates bzw. Checklisten und hat bei alledem letztendlich zwei virtuelle Körbchen auf dem ebenso virtuellen Schreibtisch des eigenen Rechners stehen; das eine trägt den Aufdruck „Eingang“, das andere den Aufdruck „Ausgang“. Wie zu Großvaters Zeiten arbeitet ein jeder sein Eingangskörbchen ab und überführt die eigenen Zwischenergebnisse ins Ausgangskörbchen. Die Methode ist geblieben, der Bote hat sich geändert – er ist jetzt ein hoch automatisiertes ProzessManagement-System, das darüber wacht, welcher Status durch welche beteiligte Person an welchem Artifact gesetzt wurde. So geht nichts verloren, nur die Effekte „echter“ Teamarbeit können im Nu auf der Strecke bleiben! In Folge dessen werden die Potentiale, die in ganzheitlicher Teamarbeit16 liegen, nicht genutzt (Katzenbach and Smith 2003). 16

Bei der Lösung schwieriger Aufgaben – gerade im Softwarebau – sind solche Hochleistungsteams sehr effizient. Der Nachteil besteht darin, dass dies nicht mit austauschbaren Leistungseinheiten im Sinne von „Human Resources“ möglich ist, da ein sehr störungsempfindliches soziales Gefüge entsteht und am Leben gehalten werden muss. Der Grund hierfür: diese Art von Teamzusammenarbeit wird maßgeblich aus der sozialen Interaktion sowie der gemeinsamen Zielsetzung gespeist. Man steht füreinander ein (ähnlich wie beim Teamsport), hat dasselbe Ziel und entwickelt eine transaktive Zusammenarbeit bzw. verfügt über ein transaktives Gedächtnis. Das bedeutet: man verknüpft im wahrsten Sinne des Wortes die individuellen und intellektuellen Leistungen zu einem großen Ganzen. Dies ist für Softwarebau optimal, aus Organisationssicht jedoch schwierig zu handhaben.

24

2 Irrwege und Auswege …

Es ist in diesem Zusammenhang bemerkenswert, dass z. B. die Softwareproduktionsmethode „SCRUM“17 dies berücksichtigt. Allerdings wird dieser Ansatz vor allem in asiatischen und angelsächsischen Ländern eingesetzt, obschon Firmen wie Siemens und IBM ihn auch hierzulande immer wieder zu verwenden suchen. Ganz offensichtlich ist hier aber für viele der notwendige Mentalitätswandel als Voraussetzung zu solch einer offenen und transparenten Arbeitsweise die größte Hürde. Nun möchte ich nicht grundsätzlich gegen prozessgetriebene Vorgehensweisen sprechen, jedoch daran verdeutlichen, dass es erheblich mehr braucht, als nur den Einsatz von Collaboration- oder Prozess Tools, die irgendwo den Begriff „Team“ im Produktnamen führen bzw. rein prozessualen Vorgaben folgen. Ein Blick auf die typischen Projektmitarbeiter macht deutlich, dass sich hier Seiteneffekte einstellen können, die durch ausschließlich technologie- oder prozessgetriebenes Arbeiten das soeben angedeutete Dilemma nicht auflösen. Es lohnt sich einen Blick auf ein paar Persönlichkeitsprofile solcher Mitarbeiter zu werfen und sich einige Beispiele aus der Wirklichkeit vor Augen zu halten: • Mitarbeiter – speziell im IT-Bereich – führen ein weltabgewandtes Dasein, insistieren aber darauf, die Probleme der (Betriebs-)Welt verstanden und unter Ausschluss der Öffentlichkeit bereits Lösungen gefunden zu haben. • Teams – oder korrekt ausgedrückt Pseudoteams – bekämpfen sich und erreichen dadurch, dass andere Mitarbeiter durch inneren oder äußeren Rückzug, durch „Information hiding“, erhöhte Krankheitsrate oder sogar durch Weggang hierauf reagieren. • Leiter liefern sich Grabenkämpfe um Formalien, die ganze Projekte gefährden bzw. enorme Mehrkosten zur Folge haben. Es sind Kämpfe, die sich, bei Lichte betrachtet, oft um die eigene Pfründe, Position oder Stellung ranken, aber mit Hilfe technischer Scheinargumente ausgetragen werden. Dies genau aber sind reale Produktionsbarrieren, bei denen keines der beschriebenen Mittel greift. – Natürlich, Konflikte treten in Organisationen immer auf. Was ich allerdings an dieser Stelle verdeutlichen möchte, ist der sensible Zusammenhang zwischen effizientem Softwarebau und sozialen Nebeneffekten.

17

SCRUM – hierbei handelt es sich um ein agiles Vorgehensmodell für das Projektmanagement im Rahmen von Software-Entwicklung. Das Modell weist sehr wenige festgelegte Regeln auf und zeichnet sich vor allem dadurch aus, dass die beteiligten Mitarbeiter sich selbst organisieren – also aufgrund ihrer sozialen Interaktion individuelle Spielregeln festlegen und danach handeln.

2.2 Haben und Schein

25

Aber zurück zu den Mitarbeitern: Hier gibt es ein weiteres Phänomen zu beleuchten, das oftmals dazu beiträgt, dass Planung und Wirklichkeit auseinanderklaffen. Die Rede ist von dem austauschbaren Mitarbeiter, den man per Excelsheet in Mannwochen oder -jahren definiert und der sich dadurch auszeichnet, dass er an allen Orten dieser Welt, in fast allen möglichen Erfahrungsstufen sowie in allen nur erdenklichen Produktionssituationen als „Professional“ dieselbe Qualität und Quantität an Arbeit leistet. Dabei ist es durchaus nachvollziehbar, wenn immer wieder so gedacht wird, braucht man doch ein Einheitsmaß, an dem qualifizierte Fachkräfte gemessen werden können. Aber gibt es diesen uniformierten Einheitsinformatiker tatsächlich – selbst wenn man ihn in Junior… und Senior… differenziert? Und verfügt dieser über die notwendigen Fähigkeiten der Zukunft? – Die Sicht, die hier oftmals über die fachlichen Mitarbeiter existiert, überspringt vielfach die notwendigen Entwicklungsschritte des Einzelnen und ähnelt dem folgenden Dialog. Dieser macht deutlich, wie eng Aufgabe und breitangelegte, rechtzeitige Kompetenzentwicklung zusammengehören. Folgen Sie mir also in diesen Dialog (aus: Rieckmann 2000, S. 82ff.) und übertragen Sie diese Szene in Ihren eigenen Kontext: Die Akteure: • Dr. Durchblick, der Unternehmensleiter • Willi Bleifuß, der Werkschauffeur Der Dialog: Dr.D.: WB.: Dr.D.: WB.: Dr.D.: WB.: Dr.D.: WB.:

Bleifuß, wie lange sind Sie schon bei uns? 23 Jahre, Herr Doktor. Und wie lange fahren Sie schon unseren Werkswagen? 20 Jahre! Können Sie ihn auch warten und reparieren? Ja, Herr Doktor! Schon oft gemacht. Und wie lange fahren Sie schon unfallfrei? 20 Jahre!

Dr.D.: Wunderbar, Bleifuß! Dann können Sie ja ab morgen auch unseren neuen Werkshubschrauber fliegen! Was uns hier begegnet, ist ein gerade in der IT weit verbreiteter Fehlschluss: Die Tatsache, dass jemand ein hervorragender Entwickler oder Softwaredesigner ist oder aber sehr bewandert darin, Geschäftsprozesse zu modellieren bzw. Use Cases zu definieren, macht ihn nicht automatisch zum Experten in anderen Themenfeldern.

26

2 Irrwege und Auswege …

Werden hier Mitarbeiter ohne die notwendigen praktischen Erfahrungen und Qualifikationen an neue Aufgaben gesetzt, so ist der Effekt vorhersagbar: Die Organisation hat einen guten Fachmann in der Produktion verloren, zugleich aber eine weniger qualifizierte Kraft im neuen Aufgabenbereich gewonnen. Ein Effekt, den Prof. Heijo Rieckmann, Professor für Organisationsberatung an der Universität Klagenfurt, den „Oberschraubendrehereffekt“ nennt, hat zugeschlagen. War der Blick des Spezialisten bisher auf eine Rolle und ein eng umrissenes Tätigkeitsfeld ausgerichtet, so sind nun völlig andere Aufgaben zu bewältigen, die ganz andere Fähigkeiten voraussetzen, welche dieser nicht notwendigerweise beherrscht. Was aber ist die Erwartungshaltung an zukünftige IT-Mitarbeiter? Folgt man Trendaussagen über die Art und Weise, wie in naher Zukunft Software entstehen wird, so zeichnet sich Folgendes ab: Das Vorgehen nach dem Wasserfallmodell, also eine möglichst vollständige ingenieurmäßige Vorwegplanung, wird allgemein als Auslaufmodell betrachtet, andere sehr viel flexiblere Arbeitsmethodiken werden hier verstärkt zum Zug kommen. Auch erwartet man eine deutliche Verschlankung und Restrukturierung der Projektdokumentation. Überdies wird eine Arbeitsteilung prognostiziert, bei der insbesondere die Projektplanung vor Ort beim Kunden, die Umsetzung der eigentlichen Software aber an ganz anderen Orten stattfindet. Dies bedeutet, dass ein Team direkt beim Kunden arbeitet und dort die Anforderungen für die kommende Applikation analysiert und die IT-Architektur plant. Sobald die andernorts gefertigten Softwarekomponenten geliefert worden sind, werden diese vor Ort integriert und getestet. Um dies zu bewerkstelligen ist es notwendig, dass die Mitarbeiter, allen voran der Projektleiter, über die notwendigen technischen, wie auch beratenden Fähigkeiten verfügen. Die Konsequenz hieraus: IT-Spezialisten müssen über den Technikhorizont hinausblicken und Fähigkeiten als kreative Berater mit Weitsicht entwickeln, wollen sie nicht dem Oberschraubendrehereffekt zum Opfer fallen. Wird das aber in Ihrer Organisation ausreichend berücksichtigt? Mitarbeiter zur Meisterschaft bringen

In diesem Zusammenhang ist ein weiterer Punkt zu nennen. Betrachtet man sich in der IT den vielfachen Umgang und die Weiterentwicklung von Mitarbeitern, so gilt für viele immer noch die folgende Philosophie (Citrin, Smith et al. 2003): • Unternehmen streben danach, die talentiertesten Führungskräfte anzuwerben und zu halten, aber sie sind nicht in der Lage, die am meisten gewünschten Ressourcen zu identifizieren oder anzuziehen.

2.2 Haben und Schein

27

• Mitarbeiter sind frustriert, weil das Unternehmen nur wenig Unterstützung beim Managen ihrer Karrieren bietet, jedoch mangelt es den Mitarbeitern auch an Wissen und den Hilfsmitteln, um wirklich Verantwortung übertragen zu bekommen. • Top-Talente möchten für ihre persönliche Leistung ansehnlich belohnt werden, sind aber besorgt, dass Leistung innerhalb des Unternehmens nicht angemessen und sorgfältig bewertet wird. • Unternehmen haben ein klares Verständnis von den unternehmerischen Kompetenzen, die erforderlich sind, um zu konkurrieren und zu gewinnen, sind aber unsicher, ob diese Talente auch unter den Mitarbeitern vertreten sind und, wenn ja, ob sie auch da eingesetzt sind, wo sie den meisten Nutzen bringen. Mag sein, dass Sie sich an dieser Stelle fragen, was dies mit Softwarebau zu tun hat. Ich meine, eine ganze Menge; zeigen doch jüngste Untersuchungen bei IT-Firmen, dass diese gut beraten sind, wenn sie fähige fachliche Mitarbeiter aus gerade diesem Bereich halten und diese konsequent weiterentwickeln. All das, worüber auf den kommenden Seiten noch zu reden sein wird, macht nur dann Sinn, wenn die verantwortlichen Leiter dafür sorgen, dass der Horizont der eigenen Mitarbeiter kontinuierlich erweitert wird und diese im eigenen Haus bleiben. Hierbei rede ich nicht notwendigerweise von gutgemeinten Kursen über Präsentations- oder Moderationstechniken bzw. die Kenntnisse im Umgang mit bestimmten Werkzeugen. Worauf ich referenziere sind die zugrundeliegenden Skills, die letztendlich die wirklichen Wettbewerbsvorteile gerade in den kommenden Jahren in einem erheblichen Maß mitbestimmen werden und die maßgeblich darüber entscheiden, ob aus guten Ideen mittelmäßige Produkte oder hervorragende Gesamtlösungen entstehen. Das wohl prominenteste Beispiel ist der nicht immer unumstrittene Softwareproduzent Microsoft. CEO Steve Ballmer formulierte es kurz nach der Jahrtausendwende einmal so: „Unsere Talente und unsere Organisation zu verbessern ist eine unserer obersten Prioritäten auf unserer Liste.“ Man mag über diese Firma an verschiedenen Stellen seine eigene Sicht haben, was allerdings Untersuchungen – wie auch Börsennotierungen – belegen, ist folgende Tatsache: Im Laufe der Jahre war Microsoft sehr erfolgreich im Rekrutieren, Entwickeln und Halten intelligenter und sozial kompetenter Menschen. Neben interessanten beruflichen Entwicklungsperspektiven und finanziellen Anreizen verstand man es, die eigenen Mitarbeiter zu fördern und zu Verantwortungsträgern zu entwickeln sowie gezielt neue Mitarbeiter von außen hinzuzunehmen (Citrin, Smith et al. 2003, S. 245ff.)

28

2 Irrwege und Auswege …

2.2.3

Auf der Suche nach Schwachstellen

Nur wer Performance und Innovation fördert, wird dauerhaft bestehen! (unbekannt) Bereits in den 40er Jahren des vergangenen Jahrhunderts entwickelte Karou Ishikawa (1915–1989), Professor an der Universität in Tokio, eine Vorgehensweise, mit der Probleme und Schwachstellen im Organisationskontext aufgedeckt werden können, die 6M-Methode. In den nachfolgend beschriebenen sechs Blickrichtungen wird dabei im qualitätstechnischen Sinne nach Schwachstellen gefahndet. Dabei handelt es sich um folgende Bereiche: Mensch: Wie sieht es mit den direkt oder indirekt beteiligten Personen aus, etwa Mitarbeitern, Vorgesetzten, Stakeholdern18 (Interessengruppen)? Alles, was sie als Person ausmacht, wirkt als Ursache: Ausbildung, Erfahrungsgrad, Wohlbefinden, Motivation oder auch Know-how. Management: Inwieweit spielen der/die Vorgesetzte/n, das Führungsverhalten, die Organisationsstruktur, offizielle und inoffizielle Vorgehensweisen, Fehlentscheidungen usw. eine Rolle? Methoden: Hier wird betrachtet, wie Aufgaben erledigt werden, ob Methoden oder Vorgehensweisen geeignet oder ungeeignet, gelebt oder ignoriert werden. Maschinen: (im IT-Kontext eher Tools) Zählen ebenfalls zu möglichen Problemverursachern, da sie möglicherweise nicht leistungsfähig genug oder sind bzw. fehlen. Gerade im IT-Bereich ist dabei zu klären, wie z. B. mit der Anzahl an Medienbrüchen zwischen den eingesetzten Werkzeugen oder auch dem Maß an Automatisierung real umgegangen wird. Material: Dies wurde ursprünglich auf etwas physisch Vorhandenes bezogen, mit dem oder an dem gearbeitet wird. Da es im Softwarebau in dieser Form kein Material gibt, Software selbst ebenfalls eine andere Konsistenz hat, nimmt jegliche Form von relevantem Wissen und der Umgang damit diesen Platz ein. Mitwelt: Ist alles, was von außen auf das betrachtete System einwirkt: Berichte in der Presse, die Gesetzgebung, Konkurrenten, Absprachen, aber auch der soziale Kontext. 18

Stakeholder sind all diejenigen, die berechtigte Interessen an einem (Software-) Produkt wahrnehmen. Dies können z. B. die Kunden sein (sie haben das Produkt und dessen Leistungsumfang beauftragt), die Anwender (sie nutzen das Produkt später), die Projektbeteiligten (sie entwickeln das Produkt) oder auch das eigene Management (es hat das Produkt in Auftrag gegeben und hat z. B. wirtschaftliche Interessen.)

2.2 Haben und Schein

29

Übertragen auf den Softwarebau lassen sich hieraus folgende Zonen mit Verbesserungspotential ableiten. Dabei werden nur solche Bereiche betrachtet, die im Produktionsalltag eher vernachlässigt werden, jedoch schnell zu großen Stolpersteinen von IT-Projekten werden können: • Explizite Erweiterung der Softskills (= Menschen); insbesondere die Tatsache, dass immer mehr IT-Mitarbeiter direkt beim Kunden arbeiten und die IT-Wirtschaft händeringend nach Entwicklern sucht, die aber zugleich die Fähigkeit von Consultants haben, weist in diese Richtung! • Aktiver Umgang mit nicht ausschließlich prozessgetriebenen Arbeitsmethoden (= Methoden). Ob nun im Team oder alleine, vor Ort. Prozesse und Werkzeuge zu beherrschen ist wichtig, ebenso wichtig ist es aber auch, dass Mitarbeiter darin geschult sind, Probleme im Kundendialog herauszuarbeiten und diese dann in sinnvolle Lösungsansätze zu überführen. • Software wird immer umfangreicher, vernetzt sich untereinander immer mehr und kann in vielen Fällen nicht mehr als klassischer Businessprozess abgebildet werden (= Material). – Sind Projektmitarbeiter dafür gerüstet, in dieses so anders geartete Kontinuum einzudringen, kennen sie die „Gesetze“ dieser Bereiche und wissen sie, wann welche methodischen Ansätze sinnvoll greifen und wann nicht? • Aktive Einbeziehung des jeweiligen persönlichen Reifegrades (= Menschen). – Noch immer gibt es Softwarehäuser, die zu sehr in Rollen und zu wenig in Reifegraden denken, wie dies in aktuellen Modellen etwa bei CMMI (vgl. S. 50ff.) in hohem Maße betont und gefordert wird. • Umstellung auf wissensgetriebene Organisationsformen (= Management). Software ist eine Form transformierten Wissens und wird daher fast immer Veränderungen unterliegen. Wenn der Umgang mit Wissen und der Bau von Software in allen Arbeitsschritten nicht sorgsam aufeinander abgestimmt sind, entstehen hohe Reibungsverluste in der eigenen Organisation, wie auch in Interaktion mit den Kunden. • Hohe Manager beschreiben Software an sich, ihre Produktion und ihren Betrieb immer noch als sehr unreif19. Ähnliches beschreiben die eingangs zitierten Statistiken (= Menschen, Methoden, Material). – Wie kann die eigene Organisation darin unterstützt werden, Softwarebau von höherer Qualität zu ermöglichen? • Neudefinition der Kernrollen, ihrer Aufgaben, notwendigen Fähigkeiten und Ziele speziell vor dem Hintergrund ganzheitlicher Nutzung des notwendigen Detailwissens (= Material). – Wie können Sie bereits während der Planung von Software sicherstellen, dass am Ende ein innovatives Produkt entstanden sein wird, das alle Aufgaben in einer definierten Domain mit maximaler Kundenzufriedenheit erfüllen kann? 19

z. B. Andreas Resch, CIO bei Beyer, in einem Interview mit Computerwoche (Computerwoche 29/2007)

30

2 Irrwege und Auswege …

Aus diesem Themenkanon werden im Folgenden drei Bereiche herausgearbeitet und im weiteren Verlauf dieses Werkes schwerpunktmäßig thematisiert: Vom diskreten Denken zum Denken in Kontinuen: Zwar besteht Software aus einer Abfolge logischer Entscheidungen. Je größer und komplexer Anwendungen werden, desto mehr überlagern sich emergente Effekte, Phänomene also, die immer nur dann sichtbar werden, wenn es um große Systeme geht. Ungeahnte, aber notwendige Fähigkeiten entwickeln: Der Anspruch der Industrie ist klar: Wir wollen hervorragende IT-Fachleute direkt beim Kunden oder in Entwicklungsteams, die mehr können, als nur ihr ITHandwerk zu verstehen. Gefragt ist ganzheitliche Beraterkompetenz mit den hierzu notwendigen Arbeits- und Vorgehensweisen. Welche sind dies und was bedeutet dies für den Arbeitsalltag? Ganzheitliche Produktionssicht: Wenn Software, deren Produktion und Betrieb immer noch qualitativ so schlecht ist, so muss gefragt werden, ob es systematische Probleme höherer Ordnung gibt, die – zumindest teilweise – nicht ausreichend betrachtet und berücksichtigt werden. Ist das „System“ Softwarebau und -betrieb hinreichend bekannt und werden die wechselseitigen Abhängigkeiten in ausreichendem Maß im Alltag gewürdigt?

2.3 Ausbruch aus dem schwarz-weißen Zeitalter Innovation ist für das Unternehmen, was Sauerstoff für den Menschen ist. Menschen können nur sehr kurze Zeit ohne Sauerstoff überleben. Entsprechend können Betriebe nur kurze Zeit überleben, ohne neue Produkte oder Leistungen zu entwickeln. Und die Zeit, während der Betriebe ohne Entwicklung neuer Produkte, Verfahren oder Dienstleistungen überleben können, wird immer kürzer. Jan Trejborg, dän. Minister für Entwicklungszusammenarbeit Alles in allem gilt: Software nach geordneten Vorgehensweisen im Sinne von Prozessen zu bauen ist eine feine Sache, egal ob Sie dies mit Hilfe von Swimlane- oder Organisationsdiagrammen bzw. UML-Darstellungen realisieren. Diese und andere strukturierte Abbildungsformen haben ihren Platz, da Visualisierungen wichtige Hilfen bei der Abbildung solch komplex verschachtelter Ablauflogiken sind. Aber einmal ehrlich: Sie betreiben modernen Softwarebau. Das heißt, Sie haben eine wie auch immer geartete Anforderungserfassung und

2.3 Ausbruch aus dem schwarz-weißen Zeitalter

31

modellieren anschließend z. B. mittels UML ihre Use Cases. Haben Sie sich schon einmal darüber Gedanken gemacht, was Sie hier letztendlich methodisch tun, wenn Sie ausschließlich einem solchen Ansatz folgen? Um auf den Kern meiner Frage zu kommen, möchte ich den Bereich des Softwarebaus kurz verlassen und Ihnen ein Beispiel aus einer völlig anderen Disziplin zum Nachdenken anbieten: Gesetzt den Fall Sie wären Flugzeugkonstrukteur und sollten eine Maschine entwickeln, die eine bestimmte Anzahl von Menschen über eine definierte Distanz transportieren soll. – Was für ein Flugzeug würden Sie wohl erhalten, wenn Sie bei der Planung Ihres Apparates zunächst einmal alle Geschäftsvorfälle erfassen und daraus Nutzungsfälle, also Use Cases, ableiten würden? Würde dies nicht in letzter Konsequenz bedeuten, dass Sie z. B. Ihre Innenraum-Designer nach Hause schicken könnten, weil – rein aus Nutzungssicht – ein Use Case „angenehmes Ambiente“ nicht wirklich Sinn macht? Ein solches Rollen- und Aktionskonzept wird somit im technischen Sinne die zu erwartenden Themen abdecken, aber was offen bleibt ist nicht zu unterschätzen! Das Gesamtergebnis entspräche dann wohl eher einer funktionalen Röhre im Sinne eines Industriebaus, da viele andere Aspekte, die das Fliegen in angenehmem Ambiente ausmachen, so nicht abgedeckt werden können. Für den Bau vieler Applikationen ist eine Business- oder Use-Casegetriebene Vorgehensweise völlig ausreichend: Ich erwarte von einem Textverarbeitungs- oder Grafikprogramm, dass es immer nach genau denselben Verfahrensregeln gewisse Dinge tut, und würde es als Programmfehler betrachten, wenn hiervon undefiniert oder unkontrolliert abgewichen würde. – Deckt aber diese Art von Applikationen tatsächlich die gesamte Bandbreite dessen ab, was an Software gebraucht wird? Nein, definitiv nicht! Denn spätestens mit dem schrittweisen Umstieg auf wissensgetriebene Systeme, WEB-2 etc. kommen Faktoren ins Spiel, bei denen der Kontext über den prozessualen Ablauf erheblich mitentscheidet! In solchen Fällen macht es wenig Sinn – weil aufwandstechnisch nicht realistisch – alle möglichen Ablaufvarianten in Modellen zu hinterlegen, wie es rein Use-Case-getriebener Softwarebau impliziert. Reicht es dauerhaft tatsächlich aus, im Sinne der aktuellen Businessmodelle statische Prozessschnitte zu beschreiben und diese auf Maschinen abzubilden – oder bewegen wir uns hier nicht immer mehr in eine Richtung, die in ein Kontinuum weist, in dem Einzelprozesse aufgrund ihrer Variantenvielfalt verschwimmen und letztendlich ganz anders behandelt werden müssen? Ist Software tatsächlich so einfach, wie wir sie uns vielfach vorstellen? Mag sein, dass Sie jetzt sagen: Es lässt sich doch alles auf einzelne logische Schritte herunterbrechen. Diese Aussage ist zwar korrekt, aber nicht das, worum es mir geht. Selbst dann, wenn sich Dinge auf ganz einfache

32

2 Irrwege und Auswege …

Grundelemente herunterbrechen lassen, heißt dies noch lange nicht, dass deshalb auch das ganze Konstrukt einfach ist. 2.3.1

Abschied von einer diskreten Welt

Um noch einmal auf die bereits erwähnte physikalische Analogie zurückzukommen: Über lange Zeit hinweg wurde die Welt diskret – also durch fest definierbare Zustände – gesehen und beschrieben. Der bekannte Kernphysiker Schrödinger brachte dann allerdings mit der nach ihm benannten Gleichung diese heile Newton’sche Welt ins Rutschen und führte die sog. Unschärfebeziehung ein. Mit einem Mal war es vorbei mit der Statik und alles musste – zumindest bei genauerer Betrachtungsweise – neu interpretiert werden (Koch 2000, S. 185). Aber geht es der industriellen IT derzeit nicht ähnlich? Man hat es sich mit prozessual darstellbaren Abläufen häuslich eingerichtet, hat sich in dieser Welt etabliert und stellt nun mit Schrecken fest, dass keineswegs alles, was codiert werden kann, auf Geschäftsprozesse zurückzuführen ist. Auch wenn für einen Großteil aller aktuellen Applikationen, wie z. B. kleineren Programmen oder netten Internetauftritten, diese prozessual-binäre Welt noch in Ordnung sein mag, so hat sie doch spätestens durch wissensgetriebenen Softwarebau oder den Übergang zu Metamodellen in IT-Architektur und konsequenterweise auch im dazugehörigen Bereich der Anforderungserfassung deutliche Risse bekommen. Wie werden sich wohl diejenigen Bereiche der Softwareproduktion weiterentwickeln, die für spezifische fachliche Domains bestimmt sind und deren Wissen in seiner Vielfältigkeit, aber auch mit seinen Randbedingungen und eventuell auch Widersprüchlichkeiten möglichst effizient abbilden müssen. Reichen hierzu die aktuellen Ansätze – oder werden sie in ähnlicher Weise vom Aussterben in wohlgemerkt diesen Bereichen bedroht werden, wie viele andere technische Ansätze, die für Übergangszeiten von großer Wichtigkeit waren? Was wäre – um es an einem Beispiel konkret zu machen – wenn der Trend anhält, dass IT und Wissen immer mehr zusammenfinden und sich z. B. zusätzlich noch die von Bill Gates (vgl. S. 7ff.) im Bereich von Motion und Robotics postulierte neue Innovationswelle nach vorne drängt? Müssen wir nicht spätestens dann ein inzwischen lieb gewonnenes Weltbild der binären Zahlenkolonnen aufgeben, selbst wenn die Prozessoren weiterhin in dieser Wirklichkeit ihre Arbeit leisten? Haben Sie sich einmal die Frage gestellt, womit Sie es hier zu tun haben und woraus der „Stoff“ gemacht ist, den man hier IT-technisch formen möchte? – Die Rede ist von der Information! Keine Angst, die Theorien über Bits und Bytes samt den dazugehörigen Formeln können Sie in anderen Werken nachlesen. Ebenso will ich Sie hier nicht mit alten Geschichten

2.3 Ausbruch aus dem schwarz-weißen Zeitalter

33

langweilen. Was ich allerdings tun möchte, ist, hier mit Ihnen einen Augenblick zu verweilen und über die Informationen und deren Verarbeitung nachzudenken! Zunächst einmal gilt es an dieser Stelle aus der Vergangenheit zu lernen und ein paar Abgrenzungen zu treffen. Wenn von Wissensmanagement die Rede ist, so wird eine deutliche Mehrheit der in der IT beschäftigten Personen nahezu umgehend z. B. von „Wiki Webs“, Intranet oder Werkzeugen für die Anforderungserfassung reden. Genau hier aber liegt einer der großen Fehler, die immer wieder begangen werden (Willke 2004). Statt zunächst die Frage nach der Wissensstruktur, etwa im Sinne von Wissenslandkarten, zu stellen bzw. sich über Wissenskultur Gedanken zu machen, wird umgehend und unter oft riesigem Kräfteeinsatz ein Berg an Informationen in wie auch immer geartete technische Systeme geschaufelt. Man gewinnt den Eindruck: „Hauptsache der angehäufte Informationsberg ist möglichst hoch!“ Sollte man dann wirklich in die Verlegenheit kommen, gezielt auf solchermaßen gesammelte Informationen zurückzugreifen, so steht man der schier unlösbaren Aufgabe gegenüber, die berühmte Nadel im Heuhaufen der Informationen möglichst rasch wiederfinden zu müssen. Somit ist klar: Diese Vorgehensweise alleine ist recht wenig zielführend, da Wissen nicht gleichgesetzt werden darf mit der Anhäufung von Informationen auf einem großen Stapel, sei es in Dateisystemen, Internetseiten oder Datenbanken. Zwar ist es im Sinne unserer „Google-Society“ natürlich mit entsprechenden Suchtools möglich auf gewünschte Stichworte in diesem Riesenhaufen an Informationen zu stoßen, was ja letztendlich auch nicht schlecht ist, aber scharf an der Frage nach dem Umgang mit Wissen vorbeiführt. Im beschriebenen Fall haben wir es aus Sicht des Wissensmanagements mit einer kleinen Untermenge zu tun. Dies geht übrigens fließend in einen zweiten Problemkreis über, der in den Bereich der „Quick and Dirty“Lösungen gehört. Statt etwas systematisch und gründlich aufzubauen wird Kosmetik betrieben, ein neues Werkzeug zugekauft oder eine Übergangslösung zur Dauereinrichtung erklärt. Beides bindet Kapital und Zeit, aber bringt nicht wirklich nachhaltige Verbesserungen hervor. Gerade deshalb ist es auch hier notwendig, mit einer abgestimmten schrittweisen Strategie diese Themen anzugehen und umzusetzen. In diesem Sinne reicht es für die zunehmend komplexeren Softwarelösungen nicht mehr aus, deren Entwicklung und Aufbau als Konstrukte reiner Logik zu betrachten und ihre Herstellung ausschließlich als einen rein ingenieurmäßigen Prozess zu betrachten. Vielmehr ist es notwendig, den schrittweisen Paradigmenwechsel der Informatik hin zu einer Systemischen Wissenschaft zu vollziehen – ähnlich wie dies bei den Kognitionswissenschaften stattgefunden hat! Geht man diesen Schritt, so erhält die Informatik einen interdisziplinären Ansatz – wie er übrigens von den Vordenkern der IT, etwa einem John

34

2 Irrwege und Auswege …

von Neumann, diskutiert wurde. Der Verdacht liegt nahe, dass wir aufgrund unserer Betriebsamkeit und der Notwendigkeit, reale EDV-technische Probleme lösen zu müssen, Dingen nicht mehr die nötige Beachtung geschenkt haben, die zu einer Zeit, als die Grundlagen der modernen Informatik entstanden, sehr wohl von Bedeutung waren. So gesehen ist es notwendig, dass Bereiche wie Kybernetik, Informationstheorie sowie allgemeine Systemtheorie, insbesondere mit ihren Implikationen für die Praxis, in geeigneter Form Zugang finden zum realen Softwarebau. Dabei geht es nicht um die Übernahme von Theorien, die nicht alltagstauglich sind. Vielmehr ist zu fragen, welche Aspekte diese Bereiche dazu beitragen können, um Softwarebau effizienter zu machen. Zunächst ist es jedoch notwendig diese Gebiete genauer zu umschreiben: Kybernetik: Also die „Steuermannskunst“. Hier geht es generell darum, das Verhältnis von zirkulären Kausalitäten und Rückkopplungsmechanismen aufzudecken, diese Regelkreise zu studieren und sie entsprechend nutzbar zu machen. Dies spielt z. B. in der Betrachtung von Wechselwirkungen innerhalb von komplexen IT-Systemen eine zunehmende Rolle, da Komponenten zwar auf ihre Weise autark sein mögen, dennoch aber mit anderen Komponenten in Wechselwirkung stehen. Dabei ist wichtig den Begriff der Kybernetik nicht ausschließlich auf technische Systeme oder Regelkreise zu reduzieren, sondern auch andere, nicht-technische Wechselwirkungen näher zu betrachten. Informationstheorie: Hierbei geht es um die Übermittlung von Nachrichten über entsprechende Kanäle. Dies spielt z. B. bei den service-orientierten Softwarearchitekturen (SOA) und ähnlichen Konstrukten eine große Rolle. Auch hier gilt es technische wie auch nicht-technische Nachrichtenübermittlung im weiteren Sinne zu betrachten und dies nicht nur auf die Übertragung von Bits und Bytes zu reduzieren. Allgemeine Systemtheorie: Es handelt sich hierbei in erster Näherung um die Betrachtung der Organisation eines Systems im Hinblick auf Hierarchie und emergentes Verhalten, also das Auftreten von Effekten, die erst dann sichtbar werden, wenn eine große Menge von Einzelkomponenten interagieren. Ähnlich wie in den beiden Bereichen zuvor ist auch hier sowohl die technische als auch die nicht-technische Welt näher zu betrachten. Dies alles sind Bereiche, die im klassischen Softwarebau der ersten Dekade des 21. Jahrhunderts wenig oder keinen Raum finden, aber in den kommenden Jahren erheblich mehr Einfluss auf die entstehenden Produktlandschaften nehmen dürften. Aus diesem Grunde ist es notwendig, dass

2.3 Ausbruch aus dem schwarz-weißen Zeitalter

35

genau hier eine entsprechende Horizonterweiterung der beteiligten Akteure rechtzeitig stattfindet, um für diesen leise stattfindenden Wechsel auch methodisch instrumentalisiert zu sein. Diese Aspekte gelten in gleicher Weise für die Erfassung wie auch die Beschreibung von Software-Anforderungen, etwa mit Hilfe von Wissensnetzwerken im Sinne von Ontologien bzw. durch Exploration des zu erschließenden Themenfeldes mit Hilfe von Simulationen, die Aufschluss darüber geben wie der Umfang notwendiger Anforderungen, an den realen Bedarf angepasst werden kann. War es bisher so, dass Kundenwünsche zusammengetragen und gebündelt wurden, um auf diese Art und Weise eine dem klassischen Pflichtenheft vergleichbare Umschreibung der umzusetzenden Aufgaben zu erhalten, reicht dies in Zukunft nicht mehr aus. Ein solches pflichtenheft-getriebener Ansatz ist zu statisch und letztendlich auch für den Software-Produzenten zu teuer, da sehr viel mehr Softwarekomponenten und somit Funktionalität erstellt werden müssen, als tatsächlich notwendig. Es scheint, dass im Fall der Anforderungs-Erfassung ein ähnlicher Punkt erreicht ist wie damals, als die Rechenschieber durch Taschenrechner unwiederbringlich abgelöst wurden (Stoll 2007). Beeindruckende technische Leistungen wie Keplers Berechnung der Umlaufbahnen oder die Konstruktion der ersten Mondraketen waren mit diesen pfiffigen Rechenhilfen möglich. Ein solchermaßen konstruiertes modernes Verkehrsflugzeug, etwa der A380, wäre jedoch am Boden geblieben wie eine Bleiente, da viel zu viele Sicherheitsreserven an unnötigen Stellen eingerechnet worden wären. – Auch der aktuelle Softwarebau marschiert derzeit mit großen Schritten in solch ein Dilemma, da moderne Programme rasend schnell an Volumen gewinnen und hierdurch rasch an Performanz und Übersichtlichkeit verlieren. So manches inhaltlich gute Programm hat aus diesem Grunde, der eben zitierten Bleiente gleich, nicht vom Boden der Entwicklungsabteilungen abheben können, da die geforderte Performance trotz richtiger Konstruktion nicht erbracht werden konnte. Um noch einen Moment an dem Vergleich mit dem Rechenschieber zu verweilen. Dieses Gerät war ideal dafür, auch komplizierte mathematische Verknüpfungen vorzunehmen. Es war allerdings nicht mehr ohne weiteres in der Lage, hinreichend genau Nachkommastellen zu berechnen. Der erfahrene Ingenieur von damals behalf sich daher mit entsprechenden Sicherheitsaufschlägen auf Wandstärken oder Materialbelastung. Das half, machte jedoch das gesamte Konstrukt schwerer und wohl auch teurer als notwendig. – Ähnlich gestaltet sich die Welt derzeit im Softwaredesign. Zwar sind Nachkommastellen im digitalen Zeitalter kein Thema mehr, allerdings bestehen die mangelnden Nachkommastellen des digitalen Zeitalters in nicht dynamisierten Konstruktionen von Objekten, die nicht ausreichend mit fachlichen Wissenswelten und den dahinterliegenden dynamischen Prozessen verknüpft sind.

36

2 Irrwege und Auswege …

2.3.2

Wissensgetriebener Softwarebau

Ob wir es wahrhaben wollen oder nicht – Softwarebau an sich ist, wenn man ihn strukturiert vollzieht, gekoppelt mit einem gigantischen Datenund Kommunikationsvolumen: Entscheidungen werden festgehalten, Tabellen gefüllt, Anforderungen ausgetauscht, Verfahrensrichtlinien festgelegt oder technische Dokumente verfasst. Mit anderen Worten, wir haben schon längst die Dose der Pandora geöffnet, was den Umgang mit projektbezogener Information anbelangt. Und so wundert es nicht, wenn Statistiker folgende Zahlen ausweisen: Jeder Mitarbeiter verbringt durchschnittlich 2,44 Std./Woche mit der Suche nach Dokumenten. Das kostet ein Unternehmen mit 1.000 Mitarbeitern 3,74 Mio. Euro/Jahr. Jeder Mitarbeiter verbringt durchschnittlich 3,45 Std./Woche mit der Sichtung und Verteilung von E-Mails. Das kostet ein Unternehmen mit 1.000 Mitarbeitern 5,29 Mio. Euro/Jahr. Jeder Mitarbeiter verschwendet ca. einen halben Tag/Woche damit, sich in unterbrochene Arbeitsgänge wieder einzuarbeiten. Das kostet ein Unternehmen mit 1.000 Mitarbeitern 7,1 Mio. Euro/Jahr.20 Die Suche nach E-Mails verschlingt in deutschen Unternehmen täglich fast 2 Millionen Arbeitsstunden. Jeder Mitarbeiter startet im Schnitt zweimal täglich eine Suche in den gespeicherten E-Mails und benötigt dafür jeweils länger als 3 Minuten. Die insgesamt 37 Millionen Suchvorgänge täglich verursachen in den Unternehmen jährliche Kosten von 10,6 Milliarden Euro21. Wenn also das Informationszeitalter in einem derartigen Maß Einfluss nimmt, so ist zu fragen, weshalb nicht der folgerichtig nächste Schritt ins Wissenszeitalter vollzogen wird. Dies betrifft in diesem Kontext zwei zentrale Bereiche, die durchaus eng miteinander verwoben sein können: Applikationen: (nicht alle!) Entwickeln sich immer mehr zu wissensgetriebener Software. Dies bedeutet, Code und Wissen finden immer mehr zusammen – wie dies in erster Näherung bei datenbank-unterstützten22 Systemen gesehen werden kann. Softwarebau: an sich kann immer mehr als Transformator von Wissen in binäre Strukturen verstanden werden (Hamilton 2006) und braucht dazu Organisationsformen, die sich wissensgetrieben weiterentwickeln (Senge 1994) und hierzu die notwendige Infrastruktur bzw. Schnittstellen anbieten.

20 21 22

Quelle: Institut der deutschen Wirtschaft, 2003 Quelle: Erhebung der SER Solutions Deutschland GmbH In diesem Sinne verstanden sind datenbank-unterstützte Systeme KEINE Wissens-Applikationen, obschon auch hier Datenbanken im Einsatz sind!

2.4 Wege zur Professionalisierung

37

In einer Zeit von E-learning, Web 2.0, Blogs etc. wird die Nutzung des Computers als Austauschmedium für Wissen immer zentraler. Dies hat zur Folge, dass Software der Zukunft immer mehr darauf eingerichtet sein muss, Wissen für die jeweilige Ziel- und Nutzergruppe aktiv aufzubereiten, bzw. dem Anwender aktiv selektiv anzubieten. Um dies zu ermöglichen entstehen immer komplexere Formen des Datenaustausches. Dies aber stellt zugleich immer höhere Ansprüche an das, was die dahinter liegende Software in der Lage sein muss zu können. Diese Problematik löst sich nicht alleine durch immer komplexere Hardwarearchitekturen, Datenbanken und Softwarestrukturen, sondern verlangt ganz neue, weil tiefer gehende Wege, um Software, die zunehmend in einer eigenen Wissenslandschaft eingebettet ist, zu kontextualisieren und in Deckung mit dieser Wissenslandschaft zu bringen. Nur indem diese Modelle generisch und vollständig erfasst und definiert werden, ist es möglich zu tragfähigen Lösungen zu gelangen. In Anlehnung an North (North 2002) und seine Grundsatzarbeiten über Wissensmanagement im Unternehmen ist es sinnvoll, diese Ansätze als eine von mehreren Säulen auf die Softwareproduktion zu beziehen. Übertragen auf die hier im Zentrum stehenden Betrachtungen ergeben sich hieraus zwei unterschiedliche Zugänge. Zum einen geht es darum, dass valide Informationen in ganzheitlicher Weise generiert werden. Zum anderen ist es aber auch notwendig, dass die einmal gewonnenen Informationen abrufbar und integrativ nutzbar bleiben.

2.4 Wege zur Professionalisierung Erfolg besteht darin, dass man genau die Fähigkeiten hat, die im Moment gefragt sind. Henry Ford Was muss passieren damit Software, die im Kundenauftrag entsteht, am Ende des Prozesses als leistungsfähig und gut wahrgenommen wird? – Eine ganz entscheidende Rolle spielt dabei die angemessene Erfassung der Eigenarten des Zielumfeldes, der Eigenschaften der geplanten Lösung und der notwendigen Nebenbedingungen. Ist es tatsächlich ausreichend, hier nur die bereits angeführten Nutzungsfälle (= Use Cases) als Handlungsbasis zu beschreiben oder bilden diese nicht letztendlich eine Untermenge dessen, was tatsächlich notwendig ist? Software ist anders als im sonst üblichen Maschinenbau eben doch nicht nur eine Maschine, deren Zusammenspiel man auf dem Reißbrett planen, deren strukturelle Stabilität man ermitteln und deren Funktionsumfang man eindeutig festgelegen kann.

38

2 Irrwege und Auswege …

Im Augenblick wirkt – trotz vorhandener Prozessmodelle, dem Einsatz teurer oder billiger Tools – Softwareproduktion in vielen Organisationen immer noch eher wie liebevoll gebastelt, jedoch nicht wie industriell betriebene Produktion in definier- und wiederholbarer Qualität. Idealerweise fängt Softwarebau genau da an, wo es um Vertrieb, im Idealfall um Firmenund Produktstrategie geht. Gerade hier sind seniore fachliche Rollenbesetzungen aus produktionsnahen Bereichen notwendig, um in jeder Hinsicht profitable Softwaretechnik vorzubereiten. – In einer Zeit, in welcher die Plattformierung von Softwareprodukten und deren Interoperabilität zum Kunden hin sowie technische Produktfamilien oder -linien unter dem Gesichtspunkt der Ressourcenoptimierung eine zentrale Rolle spielen, entscheidet hier hohe fachliche Kompetenz in kürzester Zeit über oft mehrstellige Millionen Beträge im Sinne vergeudeter Mittel oder zusätzlicher Marktchancen. – Wie Sie im weiteren Verlauf feststellen werden, kommt auf eben solch eine ganzheitliche und zukunftsorientierte Rollenqualifizierung große Bedeutung zu, da hier direkte Kausalzusammenhänge existieren. Bei all dem ist ein Trend zur Individualisierung von Produkten in fast allen Branchen einschließlich der IT zu beobachten. Was dabei einen immer höheren Stellenwert erhält ist kundenorientierte Entwicklung. Dabei spielt es keine Rolle, ob es sich um völlig neue oder anzupassende bzw. zu konfigurierende „Off-the-shelf“-Produkte oder Frameworks handelt. Dies können individuelle Datenbank-Applikationen, anwenderspezifische Business Solutions oder Werkzeuge sein, in denen hauseigene Prozessflüsse

Abb. 2.2. Organisatorische Voraussetzungen für gute Software

2.4 Wege zur Professionalisierung

39

abgebildet werden. In Folge dessen rücken viele IT-Spezialisten sehr viel näher an den Kunden heran, müssen im direkten Dialog mit diesem interagieren, ihn fachlich beraten und vor allem dessen tatsächliche Wünsche herausarbeiten. Kurz: Beratung und Anforderungsermittlung, sowie anschließende Transformation in technische Lösungen werden zu Kernkompetenzen in einem solch komplexen Umfeld. Möchte man die frühen Fehler wie etwa bei den CASE-Tools (vgl. S. 9ff.) vermeiden, so muss Softwareproduktion in eine betrieblich strategische Gesamtstruktur eingebettet sein, bei der vier Bereiche (vgl. Abb. 2.2) eng miteinander verwoben sind bzw. fließend ineinander übergehen: Strategie: Hierbei geht es neben den klassischen Themen des Produktmanagements wie etwa Marketing etc. vor allem um sehr konkrete Fragen, die in direkten Bezug zum Funktionsumfang, zur eingesetzten Softwaretechnik, wie auch zu den Produktionsverfahren gesetzt werden können. Diese und andere Fragen gilt es sehr konkret zu beantworten: • Welche IT-fachliche(n) Kompetenz(en) erwarten die Kunden von der eigenen Organisation in den nächsten 3 Jahren? • Was muss getan werden, um diese Kompetenzen oder auch Kompetenzplattformen auf- und auszubauen? • Was macht die eigene Organisation IT-technisch besser als der Wettbewerb und wie können diese Stärken ausgebaut werden? • Was macht der Wettbewerb besser als die eigene Organisation und was lässt sich hieraus konkret für die eigenen Produkte sowie für Produktion, Vertrieb und Servicemanagement lernen? Vertrieb: Vertrieb leistet in diesem Zusammenhang deutlich mehr als nur die ersehnte Unterschrift rechts unten zu ergattern und so den eigenen Umsatzzielen einen Schritt näher zu kommen. Beratung im Sinne von Account-Management ist hier gefragt. Gerade in dieser Branche kommt diesem Bereich die wichtige Rolle zu, Ohr für einzelne Kunden zu sein, deren Bedürfnisse im Sinne von „Opportunities“, also Verkaufschancen, wahrzunehmen und so deren tatsächliche Bedürfnisse in Bezug auf das eigene Produkt-Portfolio zu erfassen. Sind es die Auguren der Strategie, die in weiteren zeitlichen Horizonten denken, so sind es die Verkäufer und/oder Accounts, die die Gegenwartsprobleme der Anwender kennen müssen. Um Software, die als gut wahrgenommen wird, zu bauen müssen die geheimen Wünsche und Beschwerden der Kunden hinreichend bekannt sein (mehr dazu in Abschn. 3.2.3, S. 68ff.). Werden die beiden bisher aufgeführten Bereiche isoliert von der Technik und ihrer Entwicklung gesehen, so mögen zwar aus Sicht der IT-Fachleute

40

2 Irrwege und Auswege …

tolle Produkte entstehen, die Anbindung an die Wirklichkeit (= Vertrieb) und die Ausrichtung auf die Produktzukunft (= Strategie) bleiben aber offen. Für die beiden verbleibenden Bereiche gilt: Produktion: Produktion kann fast durchweg als Projektarbeit gesehen werden. Dies bedeutet: Für die Herstellung einer speziellen Software gibt es einen definierten Anfang und hoffentlich ein ebensolches Ende. Wenn Mitarbeiter allerdings zu projektlastig denken, so wird rasch vergessen, dass die entwickelten Produkte – wenn alles gut geht – über Jahre bei Kunden laufen werden. Ist produktionsseitig der Fokus auf „nur rechtzeitig fertig werden“ gerichtet, so werden immer wieder faule Kompromisse im Code hinterlassen, die nach Abschluss der Erstentwicklung, also in den Folgejahren, viele Extrakosten nach sich ziehen. – Ebenso ist eine Entwicklung, die isoliert von Projekt zu Projekt denkt, nicht aber im Schulterschluss mit Strategie (= Zukunft) und allgemeiner Kundensicht (= Gegenwart), in der Gefahr Insellösungen oder Märchenschlösser zu bauen. Betrieb: Ist Software erst einmal ausgeliefert und im Alltagseinsatz, so entscheidet sich hier, wie professionell eine Software erzeugende Organisation die Kunden während des Lifecycles der Software im Bereich des Servicemanagement betreut. Wie professionell in Probleme geratenen Kunden geholfen werden kann, ist sicherlich zum einen eine Frage der Organisation von Helpdesk, internen Wissensdatenbanken, Incident-, Problem- oder Changemanagement. Aber auch hier gibt es Abhängigkeiten zwischen der Softwareproduktion und dem Betrieb: Wie gut haben die Entwickler Planung und Wirklichkeit dokumentiert, in welchem Maß bleibt dieses Wissen aktuell und wie kann erreicht werden, dass neue Entwicklungen aus alten Fehlern lernen? Eine derartige Orchestrierung innerhalb der eigenen Organisation ist in besonderem Maße dann notwendig, wenn man in dem zuvor definierten Rahmen dem Kunden neue und smarte Softwareprodukte andienen, ihn durch gute Qualität und entsprechenden Service an sich binden und bei all dem eine vernünftige Rendite erzielen möchte. Diese Eigenschaften sind realisierbar – allerdings ist hierfür in die Entwicklung der Mitarbeiter zu investieren. Wenn das vorgestellte Modell in ähnlicher Form in der Organisation abgebildet und stufenweise nach unten umgesetzt wird, so bildet dies den Garanten für zukunftsweisende Produkte in einem bekannten Markt mit gezielter Ansprache der Zielkunden, und das zu guten Lifecycle-Konditionen. Dies verlangt, dass jede dieser vier Säulen mit den bestmöglichen Kompetenzträgern im Sinne von Wissen, Erfahrung und Methoden ausgestattet wird und diese wiederum auf das engste miteinander verzahnt sind.

2.4 Wege zur Professionalisierung

41

Dieser Mix, der die beiden Linien einer kaufmännischen und technischen Sicht integrativ zusammenbringt, stellt die notwendige und zugleich äußerst tragfähige Plattform bereit, um Plattformprodukte im Sinne von Produktlinien zu definieren, effektiv und vollständig umzusetzen und am Markt aktuell zu halten. 2.4.1

Organisationsaspekte in der IT-Produktion Die häufigsten Fehler im Management entstehen dadurch, dass man sich zu sehr damit beschäftigt, die richtigen Antworten zu finden, statt nach den richtigen Fragen zu suchen. Peter Ducker

Ein weiteres ist dabei wichtig – und daran wird sich maßgeblich entscheiden, wie viel in der eigenen Organisation möglich ist. Entsprechend Abb. 2.3 ist zu fragen, in welchem Maß die Organisation selbst die für den Softwarebau notwendigen Kerntätigkeiten und -prozesse durchschaut hat bzw. sie nur vermeintlich zu kennen glaubt. Wie kann also diese Passung zwischen den realen Kerntätigkeiten in der IT und den hierfür benötigten Kernkompetenzen dauerhaft aufeinander abgestimmt und stetig weiterentwickelt werden, sodass die Funktion, die ein entsprechender Mitarbeiter

Abb. 2.3. Passung oder Anpassung

42

2 Irrwege und Auswege …

ausüben kann, und dessen persönliche Weitsicht – zumindest in den Schlüsselrollen – sich konstant erweitert und weiterentwickelt im Sinne einer „lernenden Organisation“ (Senge 1994)? Welch zentrale Rolle diese Aspekte spielen, wird spätestens dann deutlich, wenn man die Messlatte amerikanischer IT-Unternehmen, das bekannte CMMI-Modell (vgl. S. 50ff.) oder vergleichbare europäische Ansätze heranzieht. Das alleine reicht allerdings für den Softwarebau noch keineswegs aus! Trotz aller modernen Technik, trotz ausgeklügelter Verfahren und Methoden ist und bleibt Softwarebau das Produkt menschlichen Handelns. Nicht nur, dass die daran beteiligten Persönlichkeiten im Sinne eines großen Ganzen sehr eng miteinander kooperieren müssen. Nicht nur, dass sie dabei – je nach Aufgabe – auf einen enormen Fähigkeits- und Erfahrungsschatz zurückgreifen müssen. Nein, sie werden auch immer wieder an den Grenzen der eigenen Fähigkeiten operieren und müssen diese daher stetig weiter nach außen verlagern. Was hier auf den ersten Blick wie ein Plädoyer für allgemeine Weiterbildung klingt, beinhaltet bei genauerem Hinschauen eine sehr viel konkretere Seite, die es weiter zu beleuchten gilt: Wie entwickeln Sie in Ihrer Organisation die Fähigkeiten der betroffenen Mitarbeiter – möglicherweise auch die eigenen – um ganzheitlich Probleme im Bereich der IT zu durchschauen und diesen so besser und effektiver begegnen zu können? Oder andersherum gefragt: Kennen Sie hier überhaupt den Bedarf und haben Sie Wege, um diesen Bedarf zu befriedigen? – Tun Sie es nicht, so können aufgrund der hohen Dynamik in der IT die Lösungen von heute zu den Problemen von morgen mutieren. Im Sinne von Abb. 2.3 wird Ihnen sonst schleichend die Passung verloren gehen zwischen dem, was Ihre Mitarbeiter können, und den eigentlichen Problemfeldern der IT. Spätestens dann, wenn nachlassende Produktqualität dazu führt, dass merklich überforderte Mitarbeiter mit aller Kraft versuchen, Dauerkrisen zu bekämpfen und Feuerwehrmännern gleich von einem IT-technischen Brandherd zum nächsten geschickt werden, sollten Sie zur Kenntnis nehmen, dass Sie hier nicht rechtzeitig bzw. nicht ausreichend diese Faktoren berücksichtigt haben. Die Chance, sich dabei in den Tiefen des Watzlawick’schen „mehr desselben Problems“ (vgl. S. 16ff.) verheddert zu haben, ist dabei sehr wahrscheinlich und bedeutet für den realen Alltag, dass Sie nicht ökonomisch arbeiten und somit Geld verschleudern, ohne dabei zu tragfähigen Lösungen zu gelangen. Ebenso ist im Hinblick auf Abb. 2.3 zu fragen, ob die einzelnen Mitarbeiter mit ihren Fähigkeiten richtig eingeschätzt, entwickelt und bewertet werden. Dabei sind folgende Bereiche in Betracht zu ziehen: • professionelle Skills (z. B. die konkreten Fähigkeiten im Softwarebau) • methodische Fähigkeiten (z. B. ihre generell methodischen Ansätze, etwa Zielorientiertheit)

2.4 Wege zur Professionalisierung

43

• interpersonelle Skills (z. B. die Fähigkeit mit Kunden zu arbeiten) • soziale Skills (z. B. ihre Team- oder Kommunikationsfähigkeiten) • systemische Fähigkeiten (z. B. das Erkennen von Zusammenhängen, Wechselwirkungen oder Abhängigkeiten) • persönliches Fachwissen (z. B. die Beherrschung bestimmter Programmiersprachen oder Werkzeugkenntnisse) • persönliche Erfahrungen (z. B. in Projekten gesammelte Erfahrungen). Hier ist übrigens der in England entwickelte Ansatz des „Skills Framework for the Information Age“, kurz SFIA23, ein interessanter Ansatz, der der Fragestellung gerecht werden möchte, welche Qualifikationen in welchem Maß in einer Organisation vorhanden sind bzw. vorhanden sein sollten. Verteilt auf sechs Hauptkategorien mit insgesamt 78 spezifischen Skills ergibt sich hierbei eine individuelle Fähigkeitsmatrix, bei der jeder einzelne Skill mit einer siebenstufigen Verantwortlichkeitsstufe24 bewertet wird. Dabei geht es in den Hauptkategorien um die folgenden Fähigkeitsbereiche innerhalb einer IT-Organisation: • Strategie und Planung (= Strategy and Planning), in den Bereichen Informationsmanagement, Beratung, Geschäftsstrategie sowie technische Strategie • Entwicklung (= Development) in den Bereichen Systementwicklung, menschliche Faktoren (z. B. Nutzbarkeit, Interfacegestaltung) sowie Installation und Integration • Management veränderlicher Faktoren (= „Business Change Management“) in den Bereichen Programmmanagement, Projektmanagement, Änderungsmanagement, Beziehungsmanagement • Bereitstellung von Dienstleistungen (= Service Provision) in den Bereichen Infrastruktur, Operation und Nutzer-Unterstützung • Beschaffung und Management-Unterstützung (= Procurement and Management Support) in den Bereichen Lieferanten-Management, Qualität und Ressourcen-Management • Sonstige Fähigkeiten (= Ancillary Skills) in den Bereichen Weiterbildung und Training sowie Marketing und Vertrieb Diese und ähnliche Modelle weisen in eine Richtung, die deutlich macht, dass Softwarebau sehr viel breiter verstanden werden muss. Allerdings haben sie auch ihre Grenzen. Im Sinne von Best Practices mögen solche Ansätze dazu beitragen aktuelle Organisationsstrukturen zu optimieren. Sie decken jedoch nicht solche Bereiche ab, in denen es um die Entwicklung 23 24

Weitere Details finden sich unter: www.sfia.org.uk (1) Follow, (2) Assist, (3) Apply, (4) Enable, (5) Enable, Advise, (6) Initiate, Influence, (7) Set Strategy, Inspire, Mobilise

44

2 Irrwege und Auswege …

neuer oder andersartiger Fähigkeiten oder Sichtweisen geht, die derzeit im Softwarebau wenig Berücksichtigung finden auf dem Weg in die Zukunft aber unabdingbar sind. Zwar lässt sich jegliche Art von persönlicher Weiterentwicklung grundsätzlich in der Kategorie „Weiterbildung und Training“ unterbringen. Dies liefert jedoch keinen Zugang zu einer mentalen Neuausrichtung größerer Teile der Organisation, wie sie aus den Erwartungen an zukünftige Softwareentwicklung notwendig werden. Eine Studie aus dem Jahr 2006, die vom Oldenburger OFFIS-Institut25 durchgeführt wurde, unterstreicht diese Aussage. Hier ging es um die Fragestellung, welche Erfolgsfaktoren innerhalb von IT-Projekten entscheidend sind. Das Ergebnis dieser unter dem Namen SUCCESS veröffentlichten Befragung von wenigstens 200 deutschen IT-Unternehmen liefert u. a. zwei Ergebnisse, die aufhorchen lassen: 1. Der Projekterfolg der untersuchten Projekte hing nicht an dem verwendeten Prozessmodell. 2. Der Projekterfolg korrelierte sehr wohl mit dem Aufwand für Kundenkommunikation! Insbesondere zum zweiten Ergebnis wurde unter anderem vermutet, dass eine (enge) Zusammenarbeit mit den Kunden bzw. Nutzern des zu entwickelnden Systems die exakte Erfassung der Anforderungen sichert und damit eine Grundlage für die Akzeptanz der realisierten Systemfunktionen darstellt. Somit braucht man mehr als nur die Fähigkeit abstrakt zu denken! Vernetztes Denken verbunden mit methodischen Werkzeugen, um solche Vernetzungen aufzudecken und zu erfragen, avancieren somit zu Kernkompetenzen in diesem Bereich. Mehr noch: Mit dem stetig wachsenden Anspruch an das, was das zukünftige Programm alles leisten soll im Sinne von Interaktivität, quasiintelligentem Verhalten oder dezentralen Strukturen ist die Zahl der Menschen, die zur Verwirklichung eines solchen Produktes benötigt werden, eher noch gestiegen, als dass sie abgenommen hätte. Insbesondere die Produktionsverlagerung auf mehrere Standorte oder gar Kulturkreise hat hier einen zusätzlichen Schwierigkeitsgrad hinzugefügt. Software lässt sich leider nicht wie Autoersatzteile einfach so nach Plan irgendwo auf der Welt erzeugen und dann problemlos in eigenen Applikationen verbauen. Viel zu sehr ist hier soziokulturelles Erbe, gepaart mit den Paradigmen der Mit25

OFFIS steht für „Oldenburger Forschungs- und Entwicklungsinstitut für Informatik-Werkzeuge und -Systeme“. OFFIS wurde am 6. Juli 1991 vom Land Niedersachsen, der Universität Oldenburg und Professoren des Departments für Informatik gegründet. Als ein Institut der Universität erforscht OFFIS neue Formen computergestützter Informationsverarbeitung in Hard- und Softwaresystemen und setzt die Ergebnisse in anwendungsnahe Entwicklungen um.

2.4 Wege zur Professionalisierung

45

wirkenden an der gesamten Prozesskette beteiligt, da jeder Einzelne es mit einem mentalen Produkt zu tun hat, für das es keinen genau festgelegten Bauplan im Sinne von Konstruktionszeichnungen gibt, sondern nur einen mehr oder minder vollständigen Planungsrahmen sowie Ideen, die gepaart sind mit Anweisungen vom Typ: „nutze diese Art von Technik“ oder „arbeite nach jener Vorgehensweise“. So wundert es nicht, dass Studien einen interessanten Zusammenhang aufzeigen: Zwischen der Egomanie der am Projekt beteiligten Mitarbeiter und der Fehlerquote im entstehenden System besteht eine signifikante Abhängigkeit (Weinberg 2004). Ein weiteres: Folgt man der Spencer-Stuart-Studie über außergewöhnliche Karrieren bzw. deren Folgen in der Wirtschaft, so stößt man immer wieder auf den Menschen als Wettbewerbsfaktor. (vgl. Citrin, Smith et al. 2003) Wenn der Mensch also eine so entscheidende Rolle spielt, dann gilt es zu fragen, wie dieser so instrumentiert werden kann, dass hier entsprechende positive Ergebnisse für die Organisation und deren Produkte hervorgebracht werden können. Lässt man diesen Bereich außer acht, stellen sich gemäß einer Untersuchung des Stuttgarter Fraunhofer Instituts für Arbeitswirtschaft und Organisation (IAO) negative Folgen für die eigene Organisation ein, indem wichtige Ressourcen vergeudet und Leistungsträger im eigenen Unternehmen nicht gehalten werden können. Die Folge: Der Wert der eigenen Organisation, aber auch die produzierten Ergebnisse leiden. So kommt eine aktuelle Untersuchung von Hewitt Associates zu der Erkenntnis, dass eine Firma einen Cash-Flow-Zuwachs von 70 bis 160 Millionen US-Dollar erwarten kann, wenn über einen bestimmten Zeitraum hinweg 10% weniger Leistungsträger das Unternehmen verlassen. Das Managementberatungsunternehmen hatte für diese Untersuchung die Human-Ressource-Daten von mehr als 1.000 US-amerikanischen Unternehmen ausgewertet. Wie aber kann dieser „Human-Factor“ im Sinne der Produktivitätssteigerung im Softwarebau beeinflusst werden? 2.4.2

Rollen mit Zukunft

Als letztes möchte ich in diesem Abschnitt den Blick auf die Softwareproduktion an sich und hier wiederum auf zwei Schlüsselbereiche lenken, die in besonders signifikanter Weise über die Qualität und Leistungsfähigkeit des finalen Softwareproduktes entscheiden. Die Rede ist einerseits vom Bereich der Anforderungs-Erfassung und andererseits von der IT-Architektur. Ersteres zählt derzeit zu den definitiven Wachstumsbereichen im SoftwareEngineering. Dieses Wachstum dürfte damit zu tun haben, dass sich Anforderungsmanagement, einst ein exotisches Verfahren im Luft- und Raumfahrtbereich, zunehmend mehr durchsetzt und zum Garanten dafür wird,

46

2 Irrwege und Auswege …

dass fachlich möglichst alles Notwendige aufgenommen und anschließend auf der Grundlage einer IT-Architektur auch tatsächlich softwaretechnisch gebaut wird. Kundenwünsche und -bedürfnisse sollen mit dieser Disziplin möglichst exakt und vollständig erfasst werden, weshalb in der Branche immer wieder ein gewisser Run auf ultimative Werkzeuge zur Anforderungserfassung zu beobachten ist. Werkzeuge, so warnen allerdings Insider26, sind hier keine Allheilmittel, stattdessen sind ausgeprägte Beratungsfähigkeiten notwendig, da Basisanforderungen oftmals dem Kunden selbst nicht bekannt sind. Ganz offenbar bedarf es hier speziell geschulter IT-Mitarbeiter, die – eher technischen Coaches gleich (Herzlieb 2005) – sich darauf verstehen, das mit dem Kunden anforderungstechnisch zu erarbeiten, was dieser primär möchte, aber auch solche Themen herausschälen, die gute Software erst möglich machen, vom Kunden aber nicht bedacht wurden. In Bezug auf die IT-Architektur begegnet uns hier eine etwas andere Facette. Kernthemen der 2007 abgehaltenen Veranstaltung des Fachbereichs Softwaretechnik der Gesellschaft für Informatik („Software Engineering 2007“) waren Fragestellungen zu architekturzentrierter Softwaretechnik. Es ging darum, ob einer „klassischen“ IT-Architektur oder aber dem aktuell vorherrschenden Trend der modellgetriebenen Softwareentwicklung der Vorrang zu geben sei. Dabei wurde eines deutlich: der für die Branche so wichtige Begriff der Architektur sowie die damit verbundene Rollendefinition des IT-Architekten können nicht als abschließend verstanden betrachtet werden. Obschon Rolle und Aufgaben seit langem ihren Platz in der Software-Entwicklung haben, ist im wirklichen Alltag das Tätigkeits- und Skillprofil alles andere als eindeutig. Dem vorgelagert ist eine weitere Fragestellung, die es noch zu klären gilt: Ist IT-Architektur im Sinne eines ingenieurmäßigen Vorgehens zu verstehen oder brauchen wir hier tatsächlich ganz andere Tätigkeitsprofile im Sinne eines Norman Forster (vgl. S. 6)? Wie immer die Ergebnisse ausfallen mögen: Solange keine klaren Tätigkeitsbeschreibungen und damit verbundene Arbeitsmethoden existieren, ist – allein schon wegen des Fehlerfortpflanzungsgesetzes – mit IT-technischen Resultaten zu rechnen, die besser hätten ausfallen können. In diesem Zusammenhang ist interessant, dass von anerkannten Beratungshäusern27 bzw. Fachverbänden28 auf ähnliche Zusatzqualifikationen verwiesen wird, wie im zuvor beschriebenen Aufgabenfeld des Anforderungs-Managements. Mit Blick auf die prognostizierten Entwicklungen in der Softwareproduktion ist ein letztes Teil hier zu ergänzen – und dies ist die jeweilige ITTechnik selbst (vgl. Abb. 2.4). 26

27 28

Chris Rupp und Anette Haupt, Sophist Group, Requirements-ManagementTage 2006 z. B. Bredemeyer Consulting (www.bredemeyer.com) z. B. Worldwide Institute of Software Architects (www.wwisa.org)

2.4 Wege zur Professionalisierung

47

Abb. 2.4. Softwaretechnik gestern, heute und morgen

Gerade hier hat sich über die Jahre hinweg sehr vieles getan und auch in Zukunft ist mit weiteren Innovationsschüben zu rechnen. Dies aber wirft die Frage auf, ob diejenigen Mitarbeiter in Bezug auf die anzuwendenden Handlungsparadigmen ebenfalls ausreichend qualifiziert sein werden, um mit der Fülle an neuen IT-technischen Möglichkeiten Schritt zu halten. Hofft man – wie so oft in der Branche – durch Kurzlehrgänge im Umgang mit bestimmten Werkzeugen diese Lücke zu schließen? Oder werden Mitarbeiter auf die Handlungsparadigmen, die notwendig sind, um effizient gute Software zu bauen, hin ausgebildet? Im historischen Rückblick betrachtet stand zunächst die Funktionsorientiertheit im Mittelpunkt (vgl. Abb. 2.4, links). Waren es anfangs klassische Codestrukturen mit entsprechenden Aufrufen von Sub-Routinen, so wurden diese mehr und mehr abgelöst durch objekt-orientierte Strukturen. Was allerdings sowohl die lineare Programmierung wie deren Nachfolger auszeichnete, war eine hierarchisch starre Strukturiertheit. Gegenwärtig findet immer mehr ein Wechsel zu prozessorientierter Modellierung statt (Scheer 2001): So können sich Anwender mehr und mehr auf die Beschreibung von Prozessen konzentrieren, während Automaten hieraus eigenständig Code erzeugen. Absehbar ist, dass hier eine Entwicklung eingeläutet wurde, die in diesem Sinne verstanden als „lösungsorientiert“ zu bezeichnen ist. Autonome,

48

2 Irrwege und Auswege …

selbstorganisierende Agenten (= Tools) werden schrittweise immer höherwertige Aufgaben im Softwarebau übernehmen oder auch Widersprüchlichkeiten in der Planung aufdecken können. Beides ist bereits heute, wenn auch noch in einer teilweise propriätären Form bei ontologischen Modellen und den zugehörigen Reasoning-Engines29 zu beobachten. Mehr und mehr werden hier autonom interagierende Systeme eine Rolle spielen. Auch wenn der Blick in die mittelfristige Zukunft sicherlich gewagt und spekulativ ist, so lässt sich absehen, dass in dem Maß, wie sich die eben beschriebenen Techniken in Anwendungen und Werkzeugen wiederfinden, mit einer Weiterentwicklung von solchen Systemen zu rechnen ist, die immer stärker Autonomie aufweisen werden, dabei in zunehmendem Maße selbstadaptiv sind und zunehmend mehr vorgefundenes Wissen auswerten und in eigene Handlungsrichtlinien integrieren werden.

29

Reasoning-Engines: Hierbei handelt es sich um Automaten, die z. B. logische Widersprüche oder Brüche aufdecken können.

3 Aufbruch in die Zukunft

Das Geheimnis des Geschäftserfolgs ist etwas zu wissen, was kein anderer weiß. Aristoteles Onassis

3.1 Modellwelten stellen sich vor Gerade weil viele Organisationen ihr Heil, sprich bessere Produktivität, in Prozessen und Standardisierung suchen, möchte ich diese beiden Themen exemplarisch an derzeit aktuellen Vorgehensmodellen ein wenig näher betrachten und erläutern. Derzeit ist in vielen Organisationen die Standardisierung sowohl von Produktions-, wie auch Lifecycle-Prozessen voll im Gange. Hierbei erfreuen sich folgende Ansätze wachsender Beliebtheit, weshalb sie exemplarisch herangezogen wurden: • CMM (= Capability Maturity Model) und CMMI (= Capability Maturity Model Integration) für Projekt-Organisation • RUP (= Rational Unified Process) als Produktionsprozess • ITIL (= IT Infrastructure Library) für das Lifecycle Management • Six Sigma – generisches Modell zur frühen Fehlerursachenbekämpfung Um es vorweg klarzustellen: Sowohl Prozesse wie auch Standards sind äußerst sinnvoll und notwendig, wenn von industrieller Produktion, somit reproduzierbarer Qualität, die Rede ist. Allerdings ist zu fragen, ob sie tatsächlich die generellen Probleme im Softwarebau grundlegend und überall in ähnlich guter Weise lösen. Immerhin scheint es Bereiche im Softwarebau zu geben, die eher Ähnlichkeiten mit einer Künstlerkolonie als einer Fabrik haben. Da es in diesem Zusammenhang um industrielle Softwareproduktion geht, möchte ich zunächst einen Blick auf die ausgewählten Vorgehensweisen werfen, um danach auszuwerten, ob tatsächlich alle für den Softwarebau notwendigen Bereiche abgedeckt wurden. Dabei ist zwischen CMM(I) und den anderen Modellen zu unterscheiden, da CMM(I) nur vorhandene Modelle qualifiziert.

50

3.1.1

3 Aufbruch in die Zukunft

Messlatten der IT-Organisation

Was verbirgt sich hinter CMM(I)?

Das Capability Maturity Model Integration (CMMI) ist ein Prozessmodell, also keine konkrete Prozessbeschreibung. Es definiert die Anforderungen an gute Produktentwicklung (das „Was“), legt aber nicht fest, wie die konkreten Schritte dazu aussehen (das „Wie“). In erster Linie geht es darum, aus der unstrukturierten Welt des reaktiven Handelns auszusteigen und zu kontinuierlichen Prozessverbesserungen zu gelangen. Da CMMI keinen konkreten Entwicklungsprozess definiert, kann es auf sehr unterschiedliche Organisationen und Organisationsgrößen angewendet werden. In diesem Ansatz wird die Verbesserung innerhalb eines Prozessgebiets durch so genannte „Fähigkeitsgrade“ (capability levels) festgelegt, die den Grad der Institutionalisierung des jeweiligen Prozessgebiets definieren. In einer zweiten Bewertungsskala werden die „Reifegrade“ (maturity levels) erfasst (vgl. Tabelle 3.1). Diese umfassen viele Prozessgebiete, die zu einem bestimmten Fähigkeitsgrad umgesetzt sein müssen. Jeder Reifegrad ist ein Entwicklungsplateau in der Prozessverbesserung der betreffenden Organisation. Tabelle 3.1. Fähigkeitsgrade und Reifegrade bei CMMI Fähigkeitsgrade 0 Incomplete

Ausgangszustand. Keine Anforderungen. Die spezifischen Ziele des Prozessgebiets werden erreicht. Der Prozess wird verwaltet.

Reifegrade

Keine Anforderungen. Diesen Reifegrad hat jede Organisation automatisch. Die Projekte werden unter der 2 Managed Leitung durchgeführt. Ein ähnliches Projekt kann erfolgreich wiederholt werden. Der Prozess wird auf Basis Die Projekte werden nach 3 Defined eines angepassten Standardeinem angepassten Standardprozesses verwaltet und ver- prozess mit einer kontinuierbessert. lichen Prozessverbesserung durchgeführt. 4 Quantitatively Der Prozess steht unter statistischer Prozesskontrolle. Managed Der Prozess wird mit den Daten aus der statistischen Prozess5 Optimizing kontrolle verbessert. 1 Performed/ Initial

3.1 Modellwelten stellen sich vor

51

Für CMMI werden dabei Themengebiete (z. B. Anforderungsmanagement oder Projektmanagement vgl. Tabelle 3.2) als sog. Prozessgebiete mit folgenden Zielen zusammengefasst: Generische Ziele: Es wird eine Institutionalisierung innerhalb der einzelnen Prozessgebiete angestrebt, denen überlagert Ziele zu definieren sind, die für alle Prozessgebiete gleichermaßen gelten. Spezifische Ziele: Diese beziehen sich explizit auf ein Prozessgebiet, für welches spezifische Inhalte und daraus resultierende Praktiken beschrieben werden. Tabelle 3.2. CMM- Fähigkeitsgrade für Projektmanagement 1-Performed 2-Managed

3-Defined

4-Qualitively Managed

5-Optimizing

Grundlegendes Projektmanagement findet statt Anforderungsmanagement vorhanden Projektplanung findet statt Prozess und Produktqualität wird überprüft Bewertung und Analyse findet statt Verwaltung der Zuliefererverträge Projektüberwachung und Kontrolle findet statt Konfigurationsmanagement ist im Einsatz Einsatz standardisierter Prozesse Entwicklung von Anforderungen Technische Lösungskonzepte Produkt-Integration Produkt-Verifikation und Validierung Blick auf Prozess-Organisation und Training Integriertes Lieferanten-Management Risikomanagement Analyse von Entscheidungen und deren Folgen Organisation bietet Integrale Plattform Integriertes Training Qualitatives Management Kontrolle der Leistungsfähigkeit organisatorischer Prozesse existiert Qualitative Kontrolle des Projektmanagements Kontinuierliche Prozessverbesserung Organisatorische Verbesserungen werden aufgenommen und planmäßig umgesetzt Kausal-Analysen finden statt – als Folge werden dessen entsprechende Lösungen angestoßen

52

3 Aufbruch in die Zukunft

Während sich der Reifegrad auf die Gesamtheit aller Prozessgebiete bezieht, ist der Fähigkeitsgrad auf der zwischen 0 und 5 definierten Skala für jedes Prozessgebiet spezifisch; dies kann, bezogen auf Projektmanagement, wie in Tabelle 3.2 wiedergegeben aussehen. Formell begannen die Arbeiten am „Capability Maturity Model for Software”, kurz SW-CMM, im Jahr 1986 in Form einer Zusammenarbeit zwischen dem Software-Institut (SEI) der Carnegie-Mellon-Universität und der Firma MITRE. Man nutzte als Ausgangsbasis bereits existierende Arbeiten, die IBM im Auftrag der US-Regierung erstellt hatte und die die Bewertung von Software ermöglichen sollten. Es dauerte dann letztendlich bis in das Jahr 1991, bis man das neue CMM-Konzept als erste Version der Öffentlichkeit vorstellte. Bei dieser Version lag der Schwerpunkt vor allem auf den Assessments, also der Art und Weise, wie die Bewertungen erfasst werden sollten. Im Jahr 1993 folgte aufgrund von Rückmeldungen aus der Industrie eine gründlich überarbeitete Version 1.1. Der Entwurf wurde 1997/98 von CMM2 vorgestellt. Hier allerdings forderte das US-amerikanische Verteidigungsministerium die Überarbeitung und Umstrukturierung des Entwurfs. Aus diesen Änderungswünschen ging das eigentliche CMMI-Projekt hervor. Da es inzwischen nicht nur für den Softwarebereich ein solches Modell gab, sondern u. a. auch für Bereiche wie Systembau, SoftwareBeschaffung oder Ausbildungsstand von IT-Mitarbeitern, forderte man eine integrative Lösung. Diese wurde als CMMI-Modell Version 1.0 im Jahr 2000 vorgestellt und zwei Jahre später durch Version 1.1 abgelöst. Insbesondere hatte man in der neuen Version eine stufenförmige, zugleich aber kontinuierliche Darstellung, die in einem gemeinsamen Dokument für Software und System Engineering ihren Ausdruck findet. Mitarbeiterbewertung nach CMMI

War bisher von Prozessen und deren Zustand in einer Organisation die Rede, so weist gerade CMMI eine Besonderheit gegenüber vielen anderen Ansätzen auf – und das ist die Berücksichtigung der Mitarbeiter sowie deren „Entwicklungsstand“. Die Rede ist dabei nicht nur von der Qualität der Primärausbildung, sondern umfasst eine ganze Reihe anderer Aspekte: Entwicklungskompetenz: Erhalten Mitarbeiter Training und Weiterbildung, so wird dies mit einer 2 (= Managed) prämiert, wird ihre Kompetenz analysiert und weiterentwickelt, so entspricht dies einer 3 (= Defined), wird die Kompetenz gar mit gezieltem Mentoring weiterentwickelt, entspricht dies einer 4 (= Predictable) und werden die Fähigkeiten der entsprechenden Mitarbeiter kontinuierlich und gezielt ausgebaut, so vergibt CMMI hierfür eine 5 (= Optimizing).

3.1 Modellwelten stellen sich vor

53

Aufbau von Arbeitsgruppen und Kultur: Werden gezielte Kommunikation und Koordination vorgefunden, so vergibt CMMI hierfür eine 2, werden Arbeitsgruppen entsprechend entwickelt und eine eigene Arbeitsgruppenkultur etabliert, so entspricht dies einer 3. Eine 4 gibt es, wenn Arbeitsgruppen aktiv gestärkt und die vorhandenen Kompetenzen gezielt zusammengeführt werden. Und die maximale Punktzahl erhält, wer dies kontinuierlich verbessert! Weitere Bereiche sind primär an die Personalentwicklung gekoppelt und haben dort das Ziel die individuelle Leistungs- und Karriereentwicklung zu quantifizieren, bzw. zu bewerten, in welchem Maß die Gesamtmitarbeiterschaft einer Organisation aktiv weiterentwickelt wird. Im Sinne dieses Buches spielen die beiden letztgenannten Bereiche keine Rolle, während insbesondere die zuerst aufgeführten Themengruppen im Sinne von rollenbezogener bzw. teambezogener Weiterentwicklung für den Gesamtkontext dieses Werkes von Bedeutung sind. 3.1.2

Schemagetrieben – und doch nicht schematisch

Schnellkurs in RUP

RUP steht in engem Zusammenhang mit der Entstehung von UML und setzt sich aus klar voneinander abgrenzbaren Tätigkeitsbereichen (Kruchten 1998; Pollice, Augustine et al. 2003; Bergström/Raberg 2004; Grundmann 2005), den sogenannten „Disziplinen“, zusammen: • • • • • •

Geschäftsprozessmodellierung („Business Modeling“) Anforderungsanalyse („Requirements“) Analyse und Entwurf („Analysis and Design“) Implementierung („Implementation“) Test („Test“) Installation („Deployment“) Es gibt drei Unterstützungsprozesse:

• Konfigurations- und Änderungsmanagement („Configuration and Change Management“) • Projektmanagement („Project Management“) • Umgebungsmanagement („Environment Management“) Diese sind so arrangiert, dass geeignete Tätigkeiten parallelisiert wurden, man also nicht wie im klassischen Wasserfallmodell warten muss, bis jeweils die vorangehende Thematik vollkommen abgeschlossen ist.

54

3 Aufbruch in die Zukunft

Der Entwicklungsprozess selbst gestaltet sich in vier Arbeitsphasen, die allerdings komplett abgeschlossen sein müssen, ehe die nächste Phase begonnen werden kann. Diese sind im Einzelnen: Konzeptionsphase: (= „Inception“) Die Infrastruktur der oben erwähnten Disziplinen muss (schriftlich) festgelegt sein, ebenso muss eine Vision zum geplanten Realisierungsprojekt vorliegen. Entwurfsphase: (= „Elaboration“) Die Hauptanforderungen sowie die Basisarchitektur müssen definiert worden sein. Konstruktionsphase: (= „Construction“) Dies ist die eigentliche Umsetzungs- und Kodierphase. Schrittweise gilt es hier zu realisieren, was zuvor definiert worden ist. Diese Phase ist beendet, wenn die Kodierung abgeschlossen ist. Übergabephase: (= „Transition“) In dieser letzten Phase geht es um Dokumentation, Implementierung und Schulung beim Kunden sowie all die anderen administrativen Tätigkeiten, die notwendig sind, um eine ausgereifte Software beim Kunden zum Laufen zu bringen. Die konkrete Arbeitsweise des RUP lässt sich im Sinne einer Geschäftsprozessmodellierung sehr einfach zusammenfassen. Jede Tätigkeit, die im Verlauf des Softwareproduktionsprozesses stattfindet, wird von einer festgelegten Rolle durchgeführt (= „Actor“). Dieser Actor arbeitet in einem bestimmten Tätigkeitsfeld (= „Disziplin“) an einer bestimmten Aufgabe (= „Activity“) und hinterlegt seine Ergebnisse in einem festgelegten Detaillierungsgrad in einem festgelegten Dokument/Datei (= „Artifact“). Das Prozessmodell RUP liefert hierzu ganz genaue Vorgaben, zu welchem Zeitpunkt welcher Actor an welchem Artifact welche Activity durchzuführen hat. Überdies gibt es einen Begriff, der an dieser Stelle kurz zu erwähnen ist: Wir begegnen in diesem Prozessmodell immer wieder dem Begriff Stakeholder. Gemeint sind all diejenigen, die an bestimmten Artifacts in irgendeiner Form Interessen haben. Dies können die Kunden zu Projektende sein, die den ausführbaren Code bzw. beschreibende Dokumente sehen wollen, es können aber auch während des Projektes die Projektleitung, die Geschäftsführung, andere Projektrollen oder andere Abteilungen sein, die an bestimmten Artifacts berechtigte Interessen haben. Ist jetzt also die Welt doch wieder heil und es geht darum alles zu prozessualisieren? Ich meine nein! RUP greift – wie andere Prozessmodelle auch, auf die berühmten „Best Practices“ in der IT zurück. Was aber wäre wohl, wenn einige dieser bewährten Vorgehensweisen selbst das Problem darstellten?

3.1 Modellwelten stellen sich vor

55

Im Hinblick auf einige Stärken und Schwächen des Rational Unified Process lässt sich Folgendes sagen: Durch die klare Aufteilung in Phasen sowie klar definierte Phasenübergänge lassen sich besonders größere SoftwareProjekte aus Sicht des Projektmanagers sehr viel besser handhaben. – Allerdings: die eigene Mannschaft sowie die angrenzenden Bereiche der eigenen Organisation müssen diesen Prozess verstanden und verinnerlich haben – was seine Zeit dauert und recht viel Aufwand mit sich bringt. Achtet man nicht darauf, so wird der RUP zum hyperformalen Albtraum. Ein weiterer Wermutstropfen ist an dieser Stelle seine sehr starke Werkzeuglastigkeit: am effizientesten arbeitet es sich mit den Produkten aus gleichem Hause, die bittere Pille hierbei ist allerdings der sehr hohe Anschaffungs- und Maintenancepreis insbesondere dann, wenn eine ganze Organisation hiermit beglückt werden soll. – Die wohl größte Schwäche des RUP scheint kultureller Natur zu sein: Seine Erfinder suchten im buchstäblichen Sinne hemdsärmlig nach praxisnahen Lösungen und dokumentierten diese gründlich. Im mitteleuropäischen Kulturraum neigt man allerdings dazu diese Dokumente bis auf den letzten Buchstaben genauso umsetzen zu wollen. Und das erzeugt entweder einen gewaltigen Zusatzberg an nutzloser Bürokratie oder den vielfachen Frust der Beteiligten. Hier einen „agilen RUP“ in einer Organisation zu implementieren, der auf die entsprechende Projektgröße angepasst ist, stellt die wirkliche Herausforderung dar! (vgl. Hamilton 2006) 3.1.3

ITIL – eine Library für Servicemanagement

Bereits im Jahr 1989 begann man am britischen Office of Government Commerce (OCG) den zukünftigen Einfluss der Informationstechnologien auf das Geschäftsleben zu erkennen und stellte dabei fest, dass es bis dato keine Konzepte gab, nach denen solche Services sinnvoll bereitgestellt und überwacht werden konnten. Aus dieser Erkenntnis heraus entwickelte die OGC ein erstes ITIL-Werk30, bestehend aus stattlichen 44 Bänden, in welchen man geeignete „Best Practices“ zusammentrug. In einer zweiten Version, die im Jahr 2001 herausgebracht wurde, reduzierte man den Inhalt drastisch auf nur mehr neun Bände, während 2007 eine noch schlankere ITIL3-Version erschien. Ein Überblick

ITIL, ursprünglich eine Bibliothek (Library) aus Erfahrungsberichten (Best Practices) zur Einführung von Service-Management-Prozessen, ist inzwi30

Eine sehr gute deutsche Zusammenfassung von ITIL2 bietet das folgende Buch: Köhler, P. T. (2005). ITIL. Heidelberg, Springer.

56

3 Aufbruch in die Zukunft

schen längst zu einem De-facto-Standard für das IT-Service-Management geworden. Bei ITIL handelt es sich um eine Methodik, die als Leitfaden für die Planung und Implementierung der folgenden Service-ManagementProzesse dient: Zum Leitgedanken von ITIL gehört, dass die IT-Dienstleistungen die Geschäftsprozesse der Servicenehmer maßgeblich unterstützen und damit den Kunden dabei helfen, ihre eigentlichen Aufgaben effizient und zielgerichtet zu erledigen. Es wird konsequent auf die Bedeutung der ServiceQualität dieser Dienstleistungen hingewiesen und es werden Vorgehensmodelle zur kontinuierlichen Verbesserung beschrieben. Dazu ist es zunächst notwendig die Prozesse der einzelnen Funktionen zu optimieren; einen weiteren wesentlichen Qualitätsgewinn erreicht man durch das optimale Zusammenspiel der einzelnen Funktionen. ITIL beschreibt, WAS zu tun ist – WIE diese Aufgaben in den einzelnen Unternehmen umzusetzen sind, ist von der jeweiligen Situation abhängig. Dieser Ansatz gewährleistet, dass die ITIL-Methodik in allen Branchen und Unternehmensgrößen umsetzbar ist und dass ihr Einsatz eine Effizienzsteigerung sicherstellen kann. ITIL2 stammt aus der 2. Hälfte der 1990er Jahre. Ihm folgte nach ca. 2,5 jährigen Vorarbeiten im Jahr 2007 die nächste Version. In ITIL3 hat man nach Wegen gesucht, wie ein noch stärkerer Business-Nutzen in den vorgeschlagenen Ansätzen gefunden werden kann. Dabei gliedert sich die Library nun in fünf Hauptbereiche, die im Original in ebenso vielen Büchern vorliegen. Es handelt sich dabei um die folgenden Themen: Service Strategy (SS): Hier finden sich die Bereiche Service Definition, Service-Management-Strategie, Planung und Realisierung von Mehrwert, IT Service Governance, Verknüpfung von IT-Service-Strategie mit Businessplänen, Service-Architekturen, Business- und Service-Strategien, Definition, Planung, Realisierung und Überwachung von Service-Strategien, Erfolgsfaktoren und Risiken. Service Design (SD): Wie werden Services geplant und geschaffen? Mit dieser Fragestellung deckt dieses Schwerpunktthema u. a. folgende Bereiche ab: Service-Design-Ziele und -Elemente, Service Lifecycle, In-, Outund Co-Sourcing, Service Lifecycle und Shared Services, Grundlagen, Rollen/Personen, Risiken, Planungsmittel. Service Transition (ST): Hier ist an erster Stelle Testen angesagt, sowie der Umgang mit längerfristigen bzw. umfänglichen Änderungen. In Folge dessen spielen diese Themen hier eine zentrale Rolle: Managen von kulturellem und organisatorischem Wandel, Wissensmanagement, LifecycleAspekte und Prinzipien der Service Transition.

3.1 Modellwelten stellen sich vor

57

Service Operation (SO): Es geht um die klassische Operations! Wie wird mit Incidents umgegangen, Problem Management betrieben, andere für den Betrieb notwendige Aufgaben geleistet. Letztendlich finden sich hier all diejenigen Themen wieder, die mit Service Support, Infrastruktur und Application Management zu tun haben. Continual Service Improvement (CSI): In diesem letzten Buch sind all diejenigen Hilfsmittel zusammengefasst, die für kontinuierliche Verbesserung notwendig sind, etwa die Business- oder Technologietreiber, aber auch die aus ITIL2 bekannten Themen um den Bereich des Continual Service Improvement. Im Sinne zyklischen Arbeitens und mit sehr viel Ähnlichkeit zu den CMMI-Ansätzen geht es um kontinuierliche Verbesserungsprozesse im Servicebereich, sodass sich letztendlich um die eigentliche Servicestrategie herum Service Design, Service Transistion und Service Operation drehen und dadurch eine kontinuierliche Weiterentwicklung und Adaption ermöglichen. Welche Vorteile bietet ITIL?

Der wohl größte Vorteil von ITIL besteht darin, dass eine Plan- und Bewertbarkeit klar umrissener Arbeitsbereiche möglich wird und auf diese Weise Transparenz entsteht. In Anlehnung an (Köhler 2005, S. 26ff.) lassen sich die Stärken von ITIL wie folgt zusammenfassen: • ITIL beschreibt, welche Prozesse notwendig sind, um ein erfolgreiches IT-Service-Management durchzuführen; • es bietet eine Grundlage für die wirtschaftliche und zweckmäßige Erbringung von IT-Servicedienstleistungen; • es ist eine Beschreibung von Prozessen oder Verfahren, die Raum lässt für individuelle Implementierung innerhalb einer Firma; • mit ihm profitiert man von den langjährigen Erfahrungen von Nutzern mit großem IT-Anteil; • es ermöglicht eine hohe Transparenz, Bewertbarkeit und somit Planbarkeit eines IT-Service-Managements; • es stellt einen Standard im IT-Service-Management dar, an dem sich alle je nach Bedarf orientieren können; • es gibt die Möglichkeit seine IT-Dienstleistungen zu bündeln und zu konzentrieren; • es ermöglicht durch Einführen von Kennzahlen eine Beurteilung, wie effizient die eingesetzten IT-Verfahren sind und ob diese über einen gewissen Zeitraum betrachtet effektiver gestaltet werden konnten.

58

3 Aufbruch in die Zukunft

Insgesamt ist ITIL eine Beschreibung der wesentlichen IT-ServiceFunktionalitäten. Was allerdings nicht beschrieben wird, ist die praktische Implementierung in Organisationen. Diese ist abhängig von den jeweils vorliegenden Gegebenheiten und bedarf eines guten Überblicks über viele Einzelheiten des täglichen IT-Servicegeschäftes. 3.1.4

Six Sigma oder „Besser ist billiger“

Six Sigma ist der „disziplinierte, daten- und methodenunterstützte Ansatz, um Defekte zu eliminieren“. Hinter dieser zugegebenermaßen etwas steifen Definition verbirgt sich das Ziel, die Fehlerquote in Produkten und damit auch die Qualitätskosten in einer Organisation zu senken. Die Idee wurde 1979 bei Motorola geboren, als ein leitender Mitarbeiter, Art Sundry, bei einem Managementmeeting aufstand und erklärte: „Das eigentliche Problem bei Motorola ist, dass unsere Qualität zum Himmel stinkt!“ (Eckes 2001). Ausgelöst durch diese Erklärung wurde bei Motorola eine neue Ära eingeläutet, die zur Entdeckung des Zusammenhangs zwischen höherer Qualität und niedrigeren Entwicklungskosten bei der Fertigung von Produkten aller Art führte. Six-Sigma-Messungen dienen dabei der konsequenten und systematischen Verbesserung von Geschäftsprozessen, wobei ein konzeptioneller Rahmen im Unternehmen geschaffen werden soll, um konstant Leistungen zu messen, zu verbessern und zu kontrollieren (vgl. Tabelle 3.3). Somit ist Tabelle 3.3. Unterschiede zwischen Six-Sigma-Perspektive und klassischer Sichtweise Gegenstand

Klassische Perspektive

Six-Sigma-Perspektive

Management Herstellbarkeit Prozessoptimierung

Zeit & Kosten Trial & Error „Basteln“

Probleme Analyse Schwerpunkt Verhalten Zielsetzung Mitarbeiter Kontrolle

Reparieren Erfahrung Produkt Reaktiv Realistische Wahrnehmung Kostenfaktor Zentral

Zeit & Qualität „Robuster“ Entwurf Statistische Prozesskontrollkarten Vermeiden Fakten Prozess Pro-aktiv Ausdehnen & „streichen“ Aktiva Lokal

3.1 Modellwelten stellen sich vor

59

es notwendig, dass ein entsprechender Wertewandel im Unternehmen stattfindet, der sich etwa so zusammenfassen lässt: Während die klassische Perspektive auf das Produkt und die Beseitigung auftretender Fehler ausgerichtet ist, richtet sich die Six-Sigma-Methode auf den Prozess sowie die Vermeidung von Fehlern am Entstehungsort. Die Devise lautet, proaktiv zu handeln, statt nur zu reagieren. So betrachtet weist es Parallelen zu Kaizen, KVP31-getriebene Ansätze oder anderen Verbesserungsverfahren auf. Kurz zusammengefasst erhebt Six Sigma den Anspruch, einerseits Kundenzufriedenheit durch Qualität und Geschwindigkeit auf der Basis von Daten und Fakten zu stiften. Andererseits sollen ebenfalls auf der Basis von Zahlen und Fakten eigene Prozesse optimiert werden, indem Defekte im Sinne eines TQM reduziert und Arbeitsabläufe verbessert werden (George, Bowlands et al. 2004; George, Rowlands et al. 2005). Nach der Devise „Gemeinsam sind wir stark“ soll dies als Teamwork stattfinden! Ganz offensichtlich ist Kundenzufriedenheit bei Six Sigma eine wichtige Größe. Aus diesem Grund ist es notwendig zu definieren, was in diesem Zusammenhang unter dem „Kunden“ verstanden wird: Dieser Begriff wird hier sehr breit gefasst, da er zum einen diejenigen Personen einschließt, die von außerhalb kommend ein Produkt oder eine Dienstleistung erwerben möchten, zum anderen aber auch diejenigen bezeichnet, die in der eigenen Organisation sitzen und erstellte Resultate (weiter-)nutzen. Der Blick geht dabei final auf den externen Endkunden und dessen Wahrnehmung (im Sinne von Kundenzufriedenheit) der eigenen Organisation, dies lässt sich zusammenfassen in dem Begriff „Voice to the Customer“ und drückt aus, dass alle Aktivitäten letztendlich aus eine kundenorientierten Haltung heraus stattfinden müssen. Qualität gilt als eine zentrale Säule bei Six Sigma – und dies wird noch sehr viel konkreter durch die dort festgelegte Forderung nach gleichbleibender Qualität. Oder um es direkt auf den IT-Alltag zu übertragen: Wie können Sie erreichen, dass z. B. Ihre Projektdokumente, Use- oder Test Cases durchgängig dieselbe Qualität aufweisen und ein Stelldichein guter und weniger guter Dokumente verhindert wird? Wie definieren Sie die individuellen Maßstäbe hierfür und kontrollieren deren Einhaltung? Stunde der Wahrheit

Untersuchungen der Carnegie-Mellon-Universität zufolge hatten im Jahr 2006 nur 251 von 1377 untersuchten Organisationen, also weniger als 20%, alle CMMI-Prozesse umgesetzt, was CMMI Level 5 entspricht. Die Mehrzahl der untersuchten Firmen war im Bereich CMM 2 oder 3 zu finden. Vergleichbar sah es in dieser Studie für den Umsetzungsgrad von ITIL aus. Fast alle der untersuchten Firmen erhoben für sich den Anspruch, 31

KVP = Kontinuierliche Verbesserungsprozesse

60

3 Aufbruch in die Zukunft

nach ITIL zu arbeiten, jedoch arbeitete bestenfalls ein Drittel der 130 befragten Organisationen32 umfänglich danach. Auch für den RUP dürfte die Situation nicht viel besser aussehen. Die Tatsache, dass sich immer wieder IT-Management mit diesen drei Buchstaben schmückt, möglicherweise auch viele neue Templates im Einsatz hat und Mitarbeiter RUP-Terminologie verwenden, täuscht sehr leicht darüber hinweg, dass dies noch keine Indikatoren dafür sind, dass dieses Prozessmodell gelebt und effizient betrieben wird. Im Sinne der für Softwarebau geforderten Kriterien „In time“, „In quality“, „In budget“ ist der Ansatz von Six Sigma sehr interessant. Allerdings stehen hier mehr die Messmethoden und Resultate im Mittelpunkt und weniger – zumindest was Softwarebau anbelangt – die Vorgehensweisen um dies zu erreichen. In Summe gilt für alle angesprochenen Ansätze: ein „Just do it“ ist nicht mehr haltbar! Worum es vielmehr geht, ist erst zu überlegen, was man zu tun gedenkt und abzuwägen, warum man es gerade so praktizieren möchte. Ebenso ist es notwendig diese erwarteten Ziele bzw. Ergebnisse vorher zu definieren und zu fixieren, denn nur so sind messbare und überprüfbare Ergebnisse zu erreichen! Das gut Gemeinte kann allerdings auch leicht zum Risiko werden, wenn die Konsequenz dieses Ansatzes darin besteht, nur noch linear in Prozessen zu denken. Erst dann, wenn von einer höheren Warte aus darauf geblickt wird, also eine „Meta-Ebene“ betreten wurde, ist verbessertes Handeln möglich. Dabei ist auch hier Handeln im Sinne eines Deming-Cycles machbar und sinnvoll. Dieser besteht aus den Arbeitsschritten PLAN (= Ursachenforschung betreiben, eine Arbeitshypothese aufstellen), DO (= den Ansatz bzw. die Theorie überprüfen), CHECK (= Überprüfung realer gegen erwartete Ergebnisse), sowie ACT (= Umsetzung der definierten Verbesserungen). Im Hinblick auf die für die Softwareproduktion wichtigen Aspekte der vorgestellten Modelle und Ansätze schält sich in Summe betrachtet ein sehr anspruchsvolles Anforderungsprofil an die Mitarbeiter heraus, das sich wie folgt zusammenfassen lässt: Um qualitativ wirklich besser zu werden, braucht es fachlich erfahrene, umsichtig arbeitende Mitarbeiter, die als effektives Team zusammenarbeiten und die – jeder für sich – in hohem Maße mit einer kundenorientierten Beratermentalität ausgestattet sind. Es klingt ein wenig wie Utopia, diese Ansprüche an alle Personen in Entwicklungsteams zu stellen, bestätigt letztendlich aber das, was eher sta32

Die Zahlen wurden einer Studie der Beratungsfirma Materna entnommen, die in 130 deutschen und österreichischen Organisationen hierzu Umfragen durchgeführt hatte.

3.2 Qualifizierte Hersteller brauchen gute Produkte

61

tistisch orientierte Ansätze (siehe vorne) ebenfalls zum Ausdruck gebracht haben. Auch wenn man darüber trefflich streiten kann, ob es wirklich notwendig ist, die Meßlatte dermaßen hoch zu hängen, haben die Kernelemente Signifikanz.

3.2 Qualifizierte Hersteller brauchen gute Produkte Der Schlüssel zum Erfolg sind nicht Informationen. Das sind Menschen. Lee Iacocca 3.2.1

Was gute Software auszeichnet

Gute Software ist nicht gleich gute Software! Das klingt zunächst paradox, wird aber nachvollziehbar, wenn die Zielgruppe des kommenden Produktes und deren individueller Maßstab an das, was für diese gut ist, berücksichtigt wird. Ehe irgendein Planungsdetail erfasst wird, ist daher zu fragen, was gute Software grundsätzlich ausmacht und was dies im konkreten Fall für einen gegebenen Kreis an Zielkunden bedeutet. Diese Klärung des Erwartungshorizontes, die letztendlich mehr ist, als nur inhaltliche Ziele im Sinne einer Vision zu definieren, ist von wesentlicher Bedeutung, wenn das in Planung befindliche Produkt auch „ankommen“ soll. Nur so kann berücksichtigt werden, was für den späteren Nutzer tatsächlich den gewünschten „WoW“-Effekt auslöst, bzw. was für eben diese Zielgruppe Software zu Spitzensoftware macht. – Diese Richtschnur sollte daher notwendigerweise ganz zu Anfang des Projektes festgelegt worden sein, da nur so all das, was während des Entwicklungsprozesses diesbezüglich zu geschehen hat, überhaupt gemessen und bewertet werden kann. Die Abklärung dieser generellen Anwendererwartungen ist in hohem Maße gekoppelt mit der späteren Nutzbarkeit des entstehenden Produktes. Was letztendlich zählt, ist die Nutzbarkeit (= Usability) der Applikation. Es geht also nicht nur darum, vollständig alle Wünsche der Kunden aufzunehmen, sondern die gewonnenen Informationen in mehrfacher Weise zu „veredeln“ und dann daraus eine Software zu bauen, die auf der Basis aktueller Standards und unter Berücksichtigung kundenspezifischer Richtlinien den tatsächlichen Bedürfnissen entspricht. – Dabei ist es eher der Normalfall, dass die Zielkunden selbst die tatsächlichen Bedürfnisse an ein neues Produkt nicht klar formulieren können, weil auch sie vielfach in Lösung auf der Basis ihres eigenen Wissenshorizontes denken. Somit besteht eine wesentliche Aufgabe des Anforderungsmanagements darin, den Kunden gesprächstechnisch so zu begleiten, dass die tatsächlichen Anforderungen erarbeitet und vermeintliche Wünsche so lange weiterverfolgt werden,

62

3 Aufbruch in die Zukunft

bis entweder der Kunde das größere Ganze oder der Anforderungserfasser den allgemeinen Sinn und die Notwendigkeit hierzu verstanden hat. Warum eine solche Vorgehensweise unabdingbar ist, lässt sich anhand von Abb. 3.1 zeigen. Das Dreieck im unteren Teil des Bildes präsentiert zunächst drei oftmals stark divergente „Welten“: Systemwelt: Techniken und Methoden, die derzeit zur Verfügung stehen und eingesetzt werden könnten. Entwicklerwelt: Techniken und Methoden, die der IT-Planer/-Umsetzer kennt und beherrscht. Nutzerwelt: Techniken und Methoden, die der Anwender z. B. aus alten oder anderen Applikationen kennt bzw. in die er sich eingearbeitet hat. Die entscheidende Frage lautet: Wie können diese verschiedenen Welten und Erwartungshorizonte möglichst optimal zusammengeführt werden? Das obere Dreieck in Abb. 3.1 beschreibt, wie fertige Software auf den Kunden wirkt. Diese Grafik, die sich aus Untersuchungen des Fraunhofer Instituts für Softwareforschung ableitet, findet ihr Pendant in der Definition über die Nutzbarkeit von Software. Gemäß ISO 9241-11 wird Usability wie folgt definiert: „... es ist das Maß, in welchem ein Produkt von spezifischen Anwendern genutzt werden kann, damit diese spezifische Ziele effektiv, effizient und zufriedenstellend in einem festgelegten Kontext erreichen können …“ Diese Definition entspricht übrigens dem EU-Standard 90/270/EWG zur Mensch-Maschine-Schnittstelle. Übertragen auf den Softwarebau definieren dabei die folgenden Begriffe, welche Bereiche hier im Einzelnen gemeint sind. Wie die nachfolgende Zusammenstellung verdeutlicht, sind hier auf einmal Aspekte gefragt oder müssen Kenntnisse über die zukünftigen Anwender vorhanden sein, die wenig mit dem zu tun haben, was meist mit Softwarebau in Verbindung gebracht wird. Auf einmal steht nicht mehr die IT-Technik als entscheidende Akzeptanzgröße im Mittelpunkt, sondern ganz andere Faktoren! Angemessenheit der beherrschten Funktionen: Ist die erforderliche Funktionalität vorhanden, um effizientes Arbeiten mit dieser Software zu ermöglichen? Es geht darum, dass der Anwender möglichst einfach, direkt und fließend seine jeweiligen Aufgaben erledigen kann. Somit steht im Mittelpunkt die Frage nach dem, was effizientes Arbeiten im Einzelnen bedeutet. Dies wiederum kann aber nur aus der Kenntnis des eigentlichen Arbeitskontextes abgeleitet werden!

3.2 Qualifizierte Hersteller brauchen gute Produkte

Faszination

Anwender-Engagement Ästhetik, Automatisierungsgrad

Akzeptanz

Angemessene Nutzbarkeit

Effektivität

Güte der Arbeitserleichterung

Effizienz Beherrschbarkeit & Sicherheit

63

Schnelligkeit der Aufgabenerledigung Sicherheit und Einarbeitungszeit

Nutzerwelt seine Erwartungen & Handlungsparadigmen

Systemwelt verfügbare Technik verfügbare Methoden verfügbare Konzepte ….

Welten

Entwicklerwelt Technische Lösungsideen Verstandene Anforderungen Eigene Vorstellungen

Abb. 3.1. Was Kunden wünschen und Entwickler oft nicht liefern

Lernförderlichkeit: Ist der Umgang mit der Software beherrschbar bzw. kann man dies schrittweise erlernen? Niemand, der eine neue Software in Betrieb nimmt, ist sofort ein Meister in deren Anwendung. Wie einfach oder auch wie mühsam sich die Nutzung einer solchen Software für den Neuanwender gestaltet, verbirgt sich hinter dieser Begrifflichkeit. Gelingt es intuitiv, schnell und nachvollziehbar die hierfür notwendigen Kenntnisse zu erwerben – oder muss man sich erst mühevoll durch langatmige Handbücher hindurcharbeiten? Somit hat dieser Bereich sehr viel mit Didaktik an sich zu tun. Erwartungskonformität: In welchem Maß wird das, was ein Anwender von einem Produkt erwartet, von diesem erfüllt? Wenn also ein Computeranwender eine Email an eine andere Person versenden möchte, so erwartet er, dass die verwendete Software einen entsprechenden Menüpunkt mit dem Titel „Senden“ aufweist. – Auch hier wird schnell deutlich: Software kann nur dann erwartungskonform sein, wenn der Hersteller den Erwartungshorizont des Anwenders kennt bzw. diesen möglichst genau prognostizieren kann. Somit wird klar: nur wenn die tatsächlichen Aufgabenfelder sowie die notwendige anwenderspezifische Detaillierungstiefe des zukünftigen Benutzers bekannt sind, kann unter Anwendung aktueller und anerkannter Gestaltungsregeln diese Erwartungskonformität erfüllt werden.

64

3 Aufbruch in die Zukunft

Selbstbeschreibungsfähigkeit: Hierunter werden intuitive Verständlichkeit sowie übersichtliche und kontextabhängige Hilfefunktionen verstanden. Ein Beispiel: Sind die Anwenderschnittstellen so aufgebaut, dass auch ein ungeübter Nutzer sofort erkennt, wie er z. B. seinen Geburtstag in ein entsprechendes Feld eintragen soll, ohne anschließend mit einer Fehlermeldung konfrontiert zu werden, die ihn anmahnt eine andere Schreibweise zu verwenden? Gerade auch was die Hilfe- und Unterstützungsmöglichkeiten anbelangt, verbirgt sich hinter dieser Definition ein weites Handlungsfeld. Ein geübter Anwender wird hier ein anderes Niveau an Selbstbeschreibungsfähigkeit brauchen als ein weniger geübter. Jemand, der eine Funktion immer wieder benutzt, möchte keine langen Romane zu einer bestimmten Funktionalität lesen oder sich lange durch viele Links hindurchklicken, sondern schnell an die gewünschte Information gelangen, wobei er diese in kompakter und dennoch verstehbarer Form erwartet. Somit stehen auf einmal Fragen im Mittelpunkt, die damit zu tun haben, welche Informationen in welcher Weise bzw. welchem Umfang angeboten werden müssen und wie diese möglichst eindeutig an die entsprechenden Zielgruppen kommuniziert werden können. Steuerbarkeit: Wie lassen sich Abläufe flexibel gestalten oder an sich verändernde Aufgabenstellungen anpassen? Oder wie kann der Anwender Einfluss auf „Richtung und Geschwindigkeit“ der Interaktion mit der Maschine nehmen? Es geht an dieser Stelle darum, dass der Benutzer jederzeit die Möglichkeit haben muss die Aktivitäten des Systems zu beeinflussen, aber auch vorangegangene Schritte rückgängig zu machen oder einfach zu einem späteren Zeitpunkt mit einer begonnenen Tätigkeit fortzufahren. Was aber sind die zielgruppenspezifischen Kriterien hierfür und wie ermittelt man diese? Individualisierbarkeit: Hierunter versteht ISO die Anpassung an den Arbeitsstil, unterschiedliche Arbeitskontexte und Nutzerpräferenzen. Nicht alle können gleich gut mit exakt derselben statischen Arbeitsumgebung zurechtkommen. Hier für die entsprechende Flexibilität zu sorgen, ohne dass der Anwender Programmänderungen in Auftrag geben muss, ist ein wichtiges Ziel, da die Zufriedenheit des Anwenders in direktem Bezug zu seiner Produktivität steht und da er mit einer auf seine Bedürfnisse angepassten Software lieber, schneller und auch fehlerfreier arbeitet. Dabei ist das Spektrum an Möglichkeiten sehr weit gefasst, egal ob es sich um „Experten“- oder „Hausfrauen“-Modi handelt, bei denen der eine sehr viel beeinflussen kann, während der andere schnell und sicher zu einem Standardziel geführt wird. Ebenso geht es hier um die Anpassung der Optik, etwa für Sehbehinderte oder bestimmte Umgebungsbedingungen. Somit steht die Frage im Raum, auf welche Weise ermittelt werden kann, welche Individualisierungen notwendig sind und welche für die jeweilige Zielgruppe keine Bedeutung haben – also nur herstellerseitige Aufwände erzeugen würden.

3.2 Qualifizierte Hersteller brauchen gute Produkte

65

Fehlertoleranz: Fehler machen ist menschlich – und so ist es notwendig, dass gerade an den System-Schnittstellen die eigene Software versteht, was Sie als menschlicher Anwender oder ein anderes Schnittstellengerät meinen, obschon nicht alles ganz genau in einer definierten Weise eingegeben wurde. Egal ob nun bei der Eingabe, etwa bei nicht erlaubten Werten oder Prozessschritten – das System muss sich „gutmütig“ verhalten. Überdies beinhaltet dieser Bereich aber auch, dass ein solches Programm schrittweise seine Anwender „erzieht“, diesen also erklärt, was hätte besser sein können und wie dies aussehen sollte. Gleiches gilt übrigens in besonderem Maße für die manuelle Eingabe von Daten: ein fehlertolerantes System muss wissen, welche Wertegrenzen in welcher Situation Verwendung finden dürfen und wann bestimmte Angaben zu reklamieren sind. Soweit die Überlegungen, wie sie sich aus der ISO 9241 ableiten. Da sich diese Norm vor allem auf die Schnittstelle Applikation und Menschen bezieht, sind der Vollständigkeit halber noch zwei weitere Bereiche zu ergänzen. Die Notwendigkeit dieser Bereiche ist anhand von Abb. 3.1 leicht nachvollziehbar. Wissensvernetztheit: Immer wichtiger wird es im Softwarebau, dass nicht nur die richtigen Geschäftsprozesse EDV-technisch abgebildet werden, sondern die Software an sich mit entsprechenden Wissensquellen vernetzt ist. Das kann einerseits die Applikation selbst betreffen, etwa durch entsprechende Hilfesysteme oder Tutorien, es kann aber auch spezifisches Wissen zur jeweiligen Fachdomaine betreffen (z. B. die neuesten Steuergesetze bei einer Buchhaltungssoftware). Da dieser Bereich erheblich an Signifikanz gewinnt, ist es umso wichtiger, im Sinne der Nutzbarkeit von Software diese Anbindung von Wissen als zusätzliches Kriterium zu berücksichtigen. Somit geht es hier um das Maß, in welchem die Software mit entsprechendem (aktuellen) Domainwissen verknüpft ist, und die Fähigkeit, mit welcher eine Software in Abhängigkeit vom aktuellen Kontext dem Anwender relevantes Wissen in verdichteter Form anbieten kann. Automatisierbarkeit: Hierbei handelt es sich um die Aufgabenteilung zwischen Mensch und Maschine. In welchem Maß ist eine Applikation in der Lage, Werte aus bekannten Vorergebnissen eindeutig zu identifizieren und nur noch solches Wissen oder solche Entscheidungen vom Anwender anzufordern, die sich aus Mehrdeutigkeiten, Optionen oder fehlenden Information ergeben? Dies lässt sich in folgendem Anspruch zusammenfassen: Ein gutes Programm sollte so viel wie möglich selbst ausführen (etwa Informationen ermitteln, Defaultwerte eintragen oder Arbeitsschritte

66

3 Aufbruch in die Zukunft

durchführen), während der Mensch so viel wie absolut nötig an dieser Interaktion beteiligt wird. Wie kann man sich in der Software-Produktion reproduzierbar der Pyramidenspitze in Abb. 3.1 möglichst weit annähern? Um dies beantworten zu können muss ein Blick hinter die technischen Kulissen geworfen und die Frage gestellt werden, was psychologisch zu einem solchen Ergebnis beiträgt. Die entscheidende Frage lautet hierbei, ob alle Beteiligten tatsächlich von denselben Dingen reden, bzw. denselben Erwartungshorizont haben. Es bedarf erheblich mehr, als nur den Business Case zu analysieren und daraus Use Cases abzuleiten! Was am Ende zum Zünglein an der Waage wird, sind nicht notwendigerweise die genialen technischen Lösungen bzw. die neuesten Produktionsstandards, auch wenn diese selbstverständlich ihren Part in der ganzen Entwicklung haben. Auch wenn es im Sinne rein ingenieurmäßigen Denkens eher unerwartet ist, so liegt die Antwort im wahrsten Sinne des Wortes unter der Wasseroberfläche logischen Denkens. Ein Blick auf das sog. Eisbergprinzip verdeutlicht rasch, dass der weitaus größte Anteil an dem, was letztendlich über ein fertiges Softwareprodukt wahrgenommen wird, durch sehr viel subtilere Einflussgrößen beherrscht wird und somit eine Art „Akzeptanzmanagement“ vom ersten Tag an notwendig macht. Ein solches Akzeptanzmanagement – und davon wird im weiteren noch ausführlich die Rede sein – gestattet es über alle Prozessschritte hinweg mit Mitteln und Methoden, wie sie z. B. dem Coaching entliehen sind, nach den tatsächlichen Bedürfnissen des Auftraggebers zu fahnden und diese mit ihm zu erarbeiten. 3.2.2

Das Eisberg-Prinzip

An dieser Stelle möchte ich einen weiteren Aspekt ergänzen, der sich in dieser Form nicht notwendigerweise in der Kriteriensammlung des letzten Abschnittes wiederfindet. Gerade in der IT neigen wir in besonderer Weise dazu, in einer paradoxen Welt zu leben: Wir definieren harte Fakten, Businessprozesse und feste Strukturen, wenden diese aber auf ein nahezu unfassbares Produkt an, nämlich die Software an sich. Es ist notwendig, diesem Faktum Rechnung zu tragen. Geschehen soll dies mit Hilfe des sog. „Eisberg-Prinzips“. Hierbei handelt es sich um einen Ansatz, der neben der sichtbaren, sachlogischen Ebene auch die unsichtbare, emotionale Ebene berücksichtigt (vgl. Abb. 3.2). Gemäß dem Eisberg-Prinzip hat die sachlogische Ebene (Strategie, Strukturen, Prozesse und Funktionen) einen Einfluss von nur ca. 10% während

3.2 Qualifizierte Hersteller brauchen gute Produkte

67

Abb. 3.2. Das Eisbergprinzip

die „Kultur-Ebene“ den weitaus größeren Einfluss hat. Wieviele Angebote Dinge zu verbessern, verhallen wohl ungehört, weil sie nicht im kulturellen Erwartungshorizont der Verantwortlichen liegen. Aus diesem Grunde ist es notwendig beide Ebenen bewusst zu berücksichtigen, um so auf innovative Lösungswege zu stoßen. Das Passagierschiff „Titanic“ sank, weil sich die Verantwortlichen nur auf den sichtbaren Teil des Eisbergs konzentrierten. Der größte Teil eines Eisbergs befindet sich bekanntermaßen unter der Wasseroberfläche – genau dort aber kam es zur Kollision und die Titanic sank. Wenn tatsächlich (je nach Quelle) 80% bis 90% derjenigen Dinge, die unsere Kommunikationsprozesse oder Erwartungen steuern, außerhalb der Logikebene ablaufen, so ist zu fragen, wie genau diese Aspekte in einem stärkeren Maß proaktiv eingebunden werden können. Das betrifft mit Sicherheit zum einen den Teamzusammenhalt, hat aber in vergleichbarer Weise auch eine sehr starke Wirkung auf die Außenaspekte. Dies umso mehr, als Software in hohem Maß durch Kommunikation zu den Stakeholdern beeinflusst wird. Unter Berücksichtigung des Eisberg-Prinzips fällt dabei auf: Die Beteiligten konzentrieren sich auf die vermeintliche Sachebene, laufen aber in der Beziehungsebene auf Grund. Projekte scheitern oder technische Resultate fallen schlecht aus, weil Beteiligte mit vorgelagerten Sachargumenten ganz andere Ziele erreichen wollten. – Genau dies verdeutlicht, wie sehr Sach- und Beziehungsebene in einer wechselseitigen Beziehung zueinan-

68

3 Aufbruch in die Zukunft

der stehen: Können wir uns in der Regel auf der sachlogischen Ebene allgemeinverständlich ausdrücken und miteinander kommunizieren, wird dies auf der psychosozialen (Beziehungs-)Ebene für viele deutlich schwieriger. Wie aber kann dem im Projektalltag Rechnung getragen werden? 3.2.3

Erfolgreich und doch kein Zufallsprodukt? „Sich dem Kundenwillen gedankenlos zu unterwerfen, führt einfach zu austauschbaren Produkten, nachgeahmten Werbekampagnen und stagnierenden Märkten.“ Prof. Stephen Brown (University of Ulster/Nordirland und Kellog School of Management/Northwestern University, Evanston, Illinois)

Auch auf der rein sachlichen Ebene lassen sich im Softwarebau einige der soeben angesprochenen Aspekte wiederfinden und verdeutlichen. Hierzu ist es sinnvoller z. B. die Erfassung von Anforderungen zu Beginn einer Produktrealisierung näher zu betrachten. Anforderungserfassung ist dabei mehr als nur das akribische Aufzeichnen derjenigen Aspekte, die der Kunde aktiv vor Augen hat. Die sogenannte Kano-Analyse deckt hier Bereiche auf, die im Eifer des Gefechtes gerne übersehen werden. Diese hochaktuelle Analysemethode (vgl. Abb. 3.3) wurde Ende der 1970er Jahre von Noriaki Kano, Professor an der Tokioter Universität, entwickelt. Sie beruhte auf der Fragestellung, welche Faktoren dazu beitragen, Kundenzufriedenheit entstehen zu lassen. Die KanoAnalyse selbst stellt eine Methode dar, um Kundenanforderungen zu strukturieren und ihren Einfluss auf die Zufriedenheit der Kunden zu bestimmen. Wer einfach nur Kundenwünsche aufnimmt, diese strukturiert und dann in Software überführt, muss mit dem Risiko leben, zwar alle Wünsche in der Lösung berücksichtigt, aber dennoch keinen wirklich zufriedenen Kunden gewonnen zu haben. Ursache hierfür ist, dass der Kunde/Anwender nicht nur die formulierten Anforderungen hat, sondern eine ganze Reihe zusätzlicher, jedoch unausgesprochener Erwartungshaltungen mitbringt. Diese unausgesprochenen Wünsche, vielleicht auch Träume werden die wahrgenommene Qualität des finalen Produktes maßgeblich beeinflussen. Die Wahrnehmungspsychologie lässt grüßen. Statt also nur auf der Faktenebene zu arbeiten, nimmt sich hier der Kunde (unbewusst) das Recht heraus, neben den von ihm definierten Forderungen an eine IT-technische Lösung noch ganz andere, zunächst unbewusste Forderungen zu stellen. Aus diesem Grunde unterschied Kano drei Arten von (Kunden-)Anforderungen, die nachfolgend vorgestellt werden.

3.2 Qualifizierte Hersteller brauchen gute Produkte

69

Basisanforderungen („expected requirements“): Basisanforderungen sind so selbstverständlich, dass sie vom Kunden nicht extra benannt werden. Würde ein Unternehmen diese bewerben, würde es albern wirken. Große Anstrengungen, um diese Basisanforderungen zu verbessern sind daher nicht sonderlich lohnend. Allerdings: Werden diese Anforderungen nicht erfüllt, so fällt gerade dies dem Kunden auf und er ist unzufrieden. Beispiele hierzu: 1. Die Software soll nicht abstürzen. Dies wird als selbstverständlich angesehen und nur dann thematisiert, wenn es tatsächlich zu Programmabstürzen kommt. 2. Mit der Software soll man auch Ausdrucke machen können. Auch dies ist eine Selbstverständlichkeit, die einfach von einer Applikation erwartet wird, ohne viel hierüber zu diskutieren. Diese beiden Beispiele weisen implizit noch auf einen weiteren Sachzusammenhang hin: Der Kunde wird im Kontext des jeweiligen Arbeitsumfeldes bestimmte Dinge als Selbstverständlichkeit betrachten; einfach nur deshalb, weil sie ihm bisher – wie selbstverständlich – zur Verfügung standen. Er kommt daher in vielen Fällen überhaupt nicht auf die Idee, diese als Anforderung zu formulieren – eben weil sie für ihn so selbstverständlich sind! – Aber hat der Produzent, der für einen solchen Kunden Software baut, dieselbe Weltsicht? Weiß er um die Selbstverständlichkeiten seines Kunden oder käme er wiederum niemals auf die Idee, dass genau diese Eigenschaften natürlich technisch abgebildet sein müssen? – Auch wenn es sich hier – anders als im folgenden Punkt – meist um eher allgemeine Fragen handelt, so werden sie höchstwahrscheinlich folgende Reaktion beim Kunden auslösen: Das Produkt ist ja noch gar nicht ausgereift, der Hersteller hat ja so wichtige Punkte wie … vergessen! Leistungsanforderungen („normal requirements“): Hierbei handelt es sich um grundlegende Anforderungen. Sind diese nicht oder nur teilweise erfüllt, so wird der Kunde in hohem Maß unzufrieden sein, da für ihn wesentliche Funktionalitäten nicht im erwarteten Maß existieren. Die Erfüllung dieser Anforderungen führt zu Kundenzufriedenheit. Achtet ein Unternehmen hier besonders auf die möglichst vollständige Herausarbeitung und Erfüllung dieser Leistungsanforderungen, so lassen sich hiermit zufriedene Kunden gut an ein „durchdachtes“ Produkt binden. Bezogen sich die Basisanforderungen auf elementare Eigenschaften, so sind Leistungsanforderungen sehr viel spezifischer auf die fachliche Domaine des künftigen Produktes und deren Anwender ausgerichtet. Wenn

70

3 Aufbruch in die Zukunft

der Hersteller einer Software nicht das fachliche Knowhow mitbringt, um zu wissen, was alles notwendig ist, um z. B. eine Steuererklärung korrekt auszufüllen, einen Flugplan korrekt zu berechnen oder einen verkauften Gegenstand korrekt zu verbuchen, so wird das beim Kunden schlecht ankommen. Dieser wird vermutlich den Hersteller der Software als fachlich inkompetent wahrnehmen.

& begeistert

sehr zufrieden

unvollständig erfüllt

Keine Meinung! en ng eru d r fo an gs un t ngss i Erwartu gen Le run anforde

vollständig erfüllt

& sauer

gsBegeisterun gen anforderun

unzufrieden

Kundenzufriedenheit

Begeisterungsanforderungen („delightful requirements“): Dies sind latent vorhandene Anforderungen, die vielfach von Kunden nicht einmal in Worte gefasst wurden. Ist ein Softwareproduzent in der Lage, solche Merkmale im Rahmen der fachlichen Domain des entstehenden Produktes herauszufinden und zu implementieren, so wird dieser unerwartete Zusatznutzen viele Kunden begeistern.

Erfüllungsgrad Bastelei

Durchschnittsprodukt

Innovatives Produkt!

Ist unvollständig, unzuverlässig und unreif – also noch kein marktfähiges Produkt

Erfüllt seinen Zweck!

Übertrifft Nutzbarkeit und Erwartung des Kunden!

Abb. 3.3. Anforderungen und Kundenzufriedenheit nach Kano

Zusammenfassend lässt sich feststellen: Wenn die Analyse der Anforderungen in der Lage ist die zunächst verborgenen Themen, insbesondere im Bereich der Basis- und Leistungsanforderungen, zu ermitteln und zusätzlich herausfindet, was einen nutzbaren „Wow“-Effekt beim Kunden auslöst, so sind die Chancen auf ein zukünftiges Produkt, dass als gut wahrgenommen wird, gar nicht schlecht! – Auch hier wird wiederum deutlich: Dem Kunden diese Fakten zu entlocken braucht deutlich mehr Kompeten-

3.2 Qualifizierte Hersteller brauchen gute Produkte

71

zen als nur die Fähigkeit, Fakten einzusammeln, Fachinformationen im notwendigen Maß zu strukturieren und diese aufzubereiten. Dabei gelten an alle Anforderungen folgende Bedingungen: • • • • • •

Anforderungen müssen einen Bedarf darstellen. Sie sollen präzise und eindeutig sein. Sie müssen gerechtfertigt sein. Sie müssen sich auf eindeutig definierbare Komponenten beziehen. Sie müssen realisierbar sein. Sie müssen nachvollziehbar sein.

Somit lautet in Anlehnung an Abb. 3.3 die Frage: Wo möchten Sie Ihr Produkt sehen, damit Sie auch in Zukunft damit Geld verdienen können? In den meisten Fällen wird man hier nicht lange überlegen müssen! Was sind aber die notwendigen Parameter, um sich mit den eigenen Softwareprodukten in den rechten Bereich der Grafik bewegen zu können? Für die Leistungsanforderungen ist die Antwort klar: systematisches und vollständiges Erfassen und Umsetzen der Kundenanforderungen. Interessant sind die Aspekte in Bezug auf die Begeisterungsanforderungen. Um es klarzustellen, dieser Begriff steht nicht dafür: „Ich liefere dem Kunden mehr als er bestellt hat, deshalb ist er begeistert!“ Stattdessen geht es um Innovation und Kreativität. Diese definieren sich in diesem Kontext wie folgt: Innovation: „Eine Innovation ist ein am Markt erfolgreiches und damit profitables verbessertes oder neuartiges Produkt.“ Kreativität: „Kreativität ist eine schöpferische Leistung, mit der ein qualitativ neuartiges Produkt verbessert oder entwickelt wird.“ (vgl. Kap. 3.3, S. 81ff.) Um also diesem Anforderungstyp näherzukommen und innovative Softwareprodukte hervorzubringen, sind Arbeitsmethodiken notwendig, die etwas mit gesteuert kreativem Handeln zu tun haben. Wie kann im Rahmen der Beauftragung und im Arbeitskontext etwas geschaffen werden, was bisher so nicht vorhanden war? Es geht also um Merkmale der kommenden IT-technischen Lösung, von denen der Kunde hinterher sagen kann: „Hey, der hat mein eigentliches Problem verstanden, hat sich hier etwas Neues überlegt und damit die Nutzbarkeit für mich noch deutlich verbessert!“ Ist dieser Bereich aber hinreichend gut in den aktuellen Modellen beim Softwarebau abgebildet? – Oder gibt es hier noch Nachbesserungsbedarf ?

72

3.2.4

3 Aufbruch in die Zukunft

Erweitertes Kano-Prinzip

Neben den drei von Kano definierten Anforderungsklassen gibt es im Softwarebau eine weitere Gruppe, die ich an dieser Stelle als „Überlebensanforderungen“ (survival requirements) bezeichnen möchte. Dieses Mal handelt es sich nicht direkt um Anforderungen, die der Kunde stellt, sondern solche, die die eigene Organisation stellen sollte, um mit dem zu entwickelnden Produkt auch längerfristig Geld verdienen zu können. Die Rede ist von solchen Anforderungen, die im späteren Lifecycle des Produktes die Voraussetzungen bilden, um Software mit vertretbaren Aufwänden und schnell genug betriebsfähig zu erhalten oder gar weiterzuentwickeln. Berücksichtigt eine Software produzierende Organisation diese Anforderungen an ein zukünftiges System nicht, so wird sie durch massive Zusatzkosten oder zu schnelle Überalterung des Produkts von der Wirklichkeit abgestraft. Um dies zu konkretisieren hier einige Beispiele: • Wenn im Anforderungskatalog für ein neues Produkt nichts über Plattformierung oder Wiederverwendbarkeit zu finden ist, so werden die Schnittstellen zu anderen Produkten aus der eigenen Organisation schnell sehr viel teurer als notwendig. • Wenn nicht rechtzeitig über Aspekte von Produktlinien-Architektur nachgedacht wurde, so wird eine kostengünstige Variantenbildung für unterschiedliche Zielkunden zum Traum, die Realisierungswirklichkeit aber schnell zum Albtraum. • Wenn nicht bereits bei der Planung neuer Software über deren Wartung, die hierfür notwendigen Methoden und Intervalle nachgedacht wurde, so „altert“ das noch im Bau befindliche Produkt sehr viel schneller und wird auch sehr viel mehr Kapital als eigentlich notwendig durch Instandhaltungsmaßnahmen (z. B. Updates auf neuere Drittanbieter Komponenten oder Integration aktueller Standards und Vorschriften) binden. Insbesondere sollten die folgenden Wartungsbereiche planerisch bedacht sein: (a) Korrekturen (z. B. bug fixing), (b) Adaptionen (z. B. Anpassung der Systemumgebung, etwa bei Betriebssystemen), (c) Verbesserungen (z. B. durch neue Anforderungen durch Kunden oder gesetzliche Vorgaben), (d) Prävention & Refactoring (Vorausschauende Wartung und konstante Codebereinigung, um die Entropie der Software gering zu halten.) – Verzichtet man auf dererlei Ansätze, so straft das Leben mit teuren Reengineerings, die hätten vermieden werden können. Forderungen und geheime Wünsche

Wenn damit begonnen wird, Anforderungen für ein kommendes System zu sammeln, entspricht dies fast immer erst einmal einer Sammlung von

3.2 Qualifizierte Hersteller brauchen gute Produkte

73

Wünschen, die oft recht wahllos, selten strukturiert und fast nie widerspruchsfrei die leicht gestressten Spezialisten oder deren Teams erreichen. Ehe sich ein Kunde für den Bau eines neuen Produktes entscheidet, hat er in aller Regel schon eine ganze Menge Überlegungen in einen solchen Software-Neubau investiert und es gibt in seiner Wahrnehmung ein recht festes Bild darüber, warum die alten Lösungen nicht mehr tragfähig ist. Auf gut Deutsch: er hat schon mit allen möglichen Bordmitteln versucht auftretende Probleme zu lösen und musste vielfach erkennen, dass die eigenen Bemühungen nicht den gewünschten Erfolg brachten. Dies gilt für Software, die Sie im Regal kaufen können, wie auch für solche Produkte, die in ihrem Code oder ihren Scripten an Kundenbedürfnisse angepasst werden müssen. Mit diesem Hintergrundwissen darüber, was zur Beauftragung einer neuen Software geführt hat, eröffnen sich für den IT-Produzenten ungeahnte – oder besser: oft nicht ausgeschöpfte – Informationsquellen darüber, wie er zu einer erfolgreichen Lösung gelangen kann. Warum? Die bisherigen Lösungsversuche und Vorgehensweisen enthalten für den aufmerksamen Zuhörer eine ganze Menge wertvoller Informationen über das, was der Kunde glaubt zu brauchen. Was von all dem, was an Informationen, Fakten, Zusammenhängen und Wünschen zusammengetragen wurde, sind wirklich wichtige Sachverhalte, was davon private Meinungen und was wiederum Dinge, die sich in die Kategorie Weihnachtswünsche packen lassen? – Die alles entscheidende Aufgabe in Bezug auf diesen ganzen Berg an Informationen lautet daher: Wie können diese zusammengefasst, wichtige von unwichtigen unterschieden und das Ganze strukturiert werden? Mehr noch: Wie kann später die Vollständigkeit dieser Anforderungen kontrolliert und überwacht, Widersprüche aufgedeckt werden und was sind mögliche Maßstäbe, um zu ermitteln, wie gut hier zusammengefasst und strukturiert wurde? All das macht das Leben derjenigen, die solches Wissen zusammentragen, keineswegs leicht, zumal die Primärinformationen, wie auch die Sortierung desselben, in wenigstens zwei Stoßrichtungen vollzogen werden muss. Zum einen kommen die Anforderungen von unterschiedlichen Stakeholdern. Das heißt, hier ist eine meist sehr hohe Interaktion mit diesen Personen notwendig. Zum anderen müssen die angesammelten Erkenntnisse aber auch fachlich korrekt sein, weshalb gerade dem Anforderungs-Spezialisten eine entscheidende Beraterrolle zufällt. – Somit wird deutlich, dass die hier zu erfüllenden Aufgaben sich zwischen mehreren Bereichen bewegen, wobei alle Bereiche in wenigstens einem Mindestmaß aktiv beherrscht werden müssen, soll diese Tätigkeit professionell durchgeführt werden (vgl. Lippmann 2006, S. 28ff.).

74

3.2.5

3 Aufbruch in die Zukunft

Was macht ein Softwareprodukt gut?

Um die Aussagen von Abb. 3.1 (S. 63) zu konkretisieren, ist nun zu fragen, welches die wesentlichen Eigenschaften guter Software sind. Mit Blick auf Abb. 3.4 wird deutlich, dass sich hinter den funktionalen Kundenwünschen rasch eine ganze Reihe impliziter Forderungen verbergen, die nicht notwendigerweise bei der Anforderungserfassung beim Namen genannt werden, wohl aber vom Produzenten planerisch zu berücksichtigen sind. Mit Blick auf Abb. 3.4 erwartet der Kunde grundsätzlich ein Mehrfaches: Die zukünftige Software soll nutzbar und sie soll tauglich im Hinblick auf festgelegte Aufgaben sein. Dabei gilt: Nutzbarkeit: Wie hoch ist der tatsächliche Nutzwert des Programms für den Anwender? Kann dieser mit der Software einfach, intuitiv und effizient umgehen oder ist das Produkt kompliziert in der Benutzung und in seiner Anwendungslogik inkonsistent? Tauglichkeit: Deckt die Funktionalität der Software in geeigneter Weise all diejenigen Funktionen und Aufgaben ab, die von dem Produkt in diesem Kontext erwartet werden? Dies schließt übrigens mit ein, ob die von der Software gelieferten Ergebnisse ausreichend genau sind und die entsprechenden Anforderungen des Anwenders erfüllen.

Abb. 3.4. Was gute Software berücksichtigen muss

3.2 Qualifizierte Hersteller brauchen gute Produkte

75

Festgelegte Aufgaben: Hier gilt es letztendlich zu beschreiben, in welchem Bereich die Software später einmal funktional ihre Aufgaben verrichten soll. Dabei ist die Vollständigkeit des Funktionsumfangs besonders wichtig. Des Weiteren verbergen sich hinter diesen scheinbar harmlosen Wünschen sehr viel weitreichendere Erwartungen. Auch wenn der Anwender nur einfach nutzbare und taugliche Software haben wollte, so ist die unausgesprochene Forderung deutlich umfangreicher, betrifft sie doch sehr konkret die nachfolgenden Bereiche (vgl. Abb. 3.4 links)33. Anwendbarkeit: Wie gut lässt sich die neue Applikation nutzen? Effektivität: Wie effektiv ist die neue Applikation? Funktionalität: Sind alle geforderten Funktionen des entsprechenden Aufgabenfeldes mit dieser Software lösbar? Portierbarkeit: Wie leicht ist die Applikation auf eine andere Plattform zu übertragen? Wartbarkeit: Wie leicht ist die Applikation zu erweitern? Zuverlässigkeit: Wie zuverlässig ist die neue Applikation? Dies wirft weitere, weniger triviale Fragen auf, da nun zu klären ist, was dies für die sechs betrachteten Sichten konkret in einem Entwicklungsprojekt heißt. Mehr noch: Es ist jeweils zu klären, was es für eine Applikation in einem definierten Nutzungsbereich z. B. bedeutet, effektiv zu sein. Nur so ist eine Messbarkeit der Qualität und eine genaue Festlegung dessen, was funktional in der Applikation zu realisieren ist, möglich. Bezog sich das bisher Gesagte auf die Kundensicht, so ist dies für die Planung und Umsetzung von Software noch keineswegs ausreichend, da auf einmal Forderungen und Bedingungen aus technischer, wie auch Organisationssicht hinzukommen (vgl. Abb. 3.4 rechts). Im Hinblick auf die nachfolgenden Punkte wird es immer mehr Aufgabe der IT-Architekturplanung, dass diese Punkte in geeigneter Weise in die Gesamtkonzeption einfließen. Viel Kommunikationsgeschick und Überblick ist dabei insbesondere für die Rolle des IT-Architekten gefragt. Er muss klären, wie diese Themen im Einzelnen technisch zu realisieren sind und welche Neben- und Wechselwirkungen dies nach sich zieht. Ebenso ist er es, der die Realisierung zu überwachen hat und der die Maßstäbe für die qualitative Bewertung der jeweiligen Ergebnisse definiert. Seine Aufgabe ist es, sehr früh 33

Dies sind übrigens auch die von ISO-IEC geforderten Basiseigenschaften neuer Applikationen.

76

3 Aufbruch in die Zukunft

KPIs34 zu definieren, mir deren Hilfe die laufende Planung, wie auch der fertiggestellte Code qualitativ bewertet werden können. Um es vorwegzunehmen: Am Ende muss es eine einzige Gesamtarchitektur für die zu entwickelnde Applikation geben – das ist klar! Allerdings ist es sinnvoll die hieraus resultierenden Bereiche aus unterschiedlichen Blickrichtungen zu beleuchten. Zunächst spielen unterschiedliche Zeithorizonte eine Rolle. Es ist der Blick in das Jetzt (= Produkt-Architektur), der Blick in die Zukunft (= Produktstrategische Architektur) und der Blick in Aspekte des Lebenszyklus der Applikation (= Lifecycle-Architektur). Dabei gilt: Produkt-Architektur bezieht sich auf konkrete Individualaspekte des jetzt anstehenden Produktes, während produktstrategische Architektur solche Themen im Auge hat, welche die technischen Implikationen der organisationseigenen Produktstrategie der kommenden 3–5 Jahren möglichst konkret abbilden. Daneben ist ein weiterer Blick im Sinne der Produktlinien-Architektur notwendig. Bei letzterem geht es um das Produktportfolio oder Ausschnitte davon und die nachgelagerte Fragestellung, wo, in welcher Weise und in welchem Maß die verschiedenen Produkte der eigenen Organisation über Commonalities bzw. Variabilities verfügen sollen. Hierbei stehen diese beiden Begriffe für folgendes: Commonalities: Was sind die Gemeinsamkeiten einer Produktfamilie? Wo sind Komponenten, Dienste, Styles, technische Lösungen, Ablaufschemata etc. für alle Mitglieder einer definierten Produktgruppe gleich? Variabilities: Was sind die Unterschiede innerhalb einer Familie von Produkten? In welchen Bereichen und Funktionalitäten grenzen sich die Einzelprodukte voneinander inhaltlich und technisch ab? Wie verlaufen dabei diese Grenzziehungen und warum? Nebenbei bemerkt: Diese Aussagen müssen in enger Abstimmung mit der Produktstrategie der eigenen Organisation zustande kommen, auch ist die Überwachung der Einhaltung solcher Abgrenzungen oder gemeinsamen Plattformierungen ein zentrales und keineswegs triviales Thema. – Auch wenn die nachfolgende Liste nicht vollständig ist, so wird klar, was dies für die vier Architektursichten im Einzelnen bedeutet: Produkt-Architektur

Ressourcenverhalten: Solche Eigenschaften einer Anwendung, die den Ressourcenbedarf und das Zeitverhalten der Software beschreiben. 34

KPI = Key Performance Indicator

3.2 Qualifizierte Hersteller brauchen gute Produkte

77

Zwei Beispiele: • Was sind die maximal erlaubten Rechenzeiten für definierte Funktionen und wie wird deren zeitliche Einhaltung überprüft bzw. sichergestellt? • Wie wird architektonisch berücksichtigt, dass die künftige Software vom Volumen her „schlank“ bleibt und damit z. B. Ladezeiten in definierten Maßen bleiben? Analysierbarkeit: Solche Eigenschaften der Anwendung, die in definierter Weise Systemdiagnosen ermöglichen, klar definierte Abbruchwege in Fehlerfällen oder einfach nur diagnosegeeignete Informationen bei Fehlern zur Verfügung stellen, um so deren Ursachen später möglichst rasch und eindeutig aufzuspüren. Installierbarkeit: Diese Eigenschaften der Anwendung sind notwendig, um in geeigneter Weise die Erstinstallation, Produktupdates oder auch Upgrades sicher auf definierten Betriebssystemen möglich zu machen. Produktstrategie-Architektur

Interoperabilität: Anwendungs-Eigenschaften dieser Art werden benötigt, um in ausreichendem und notwendigem Maß Konnektoren zu anderen externen Systemen anzubieten oder durch entsprechende Automatisierungsskripte eine Steuerung von außen zu ermöglichen. Auch hier zwei Beispiele: • Um Medienbrüche gerade bei solcher Software zu vermeiden, die eng mit anderen Produkten zusammenarbeitet, müssen entsprechende Datenstandards bzw. Schnittstellentypen integriert sein. • Ein Blick z. B. auf die Officeprodukte aus dem Haus Microsoft und die durchgängige Integration von VB-Schnittstellen macht es möglich, dass ein skriptgesteuerter funktionaler Zugriff auf andere Produkte möglich wird. Erweiterbarkeit: Die Basisarchitektur einer Anwendung muss so gestaltet sein, dass es möglich ist mit geringem Aufwand neue Funktionalitäten zu integrieren, ohne dabei nachhaltig das technische Gesamtkonzept zu durchlöchern. Ein Beispiel: • Neue Funktionen zu integrieren geht irgendwie fast immer. Aber: Das Ziel der Erweiterbarkeit besteht darin, allgemeine Basisstandards für alle Funktionalitäten architektonisch zu definieren und diese auch für Erweiterungen verbindlich festzulegen.

78

3 Aufbruch in die Zukunft

Migrierbarkeit: Wie aufwändig ist es, ein System auf eine andere technische Plattform zu migrieren oder andere Drittanbieter-Komponenten zu verwenden? Auch hierzu ein Beispiel: • Was wurde planungstechnisch getan, um den Wechsel in einer datenbank-getriebenen Applikation, sagen wir „MySQL“, auf ein anderes Produkt, vielleicht eine „Oracle“-Datenbank, umzustellen? Ersetzbarkeit: Wie aufwändig ist es, solche Anwendungen, die mit der eigenen Applikation zusammenarbeiten, gegen andere Produkte auszutauschen? Sind in der Architektur an sich hierfür notwendigen Stellen Treiberschnittstellen vorgesehen und entsprechend allgemeingültig definiert? Ein Alltagsbeispiel: • Nehmen Sie die Drucker- oder Bildschirmtreiber, die Ihr Betriebssystem fast automatisch der eigenen Applikation zur Verfügung stellt. Was aber, wenn es gerade den benötigten Treiber nicht gibt und Sie womöglich einen solchen selbst implementieren müssten? Lifecycle-Architektur

Wartbarkeit: Wie stringent ist die Architektur einer Applikation aufgebaut, um Korrekturen oder Ergänzungen am Code effizient und sicher durchzuführen? Konkret: • Wie viel Zeit und Aufwand braucht es durchschnittlich, wenn die Applikation in Betrieb gegangen ist, um einen aufgetretenen Fehler zu isolieren und zu korrigieren? Veränderbarkeit: Was trägt die Applikations-Architektur dazu bei, um auf Änderungen oder Ergänzungen der Betriebsumgebung effizient und sicher zu reagieren? Ein Beispiel: • Wie aufwändig ist es, die Applikation auf eine neue Version des verwendeten Betriebssystems zu migrieren?

3.2 Qualifizierte Hersteller brauchen gute Produkte

79

Stabilität: Was trägt die Architektur einer Applikation dazu bei, das Risiko von Instabilitäten gering zu halten? Wie wird dem insbesondere bei Modifikationen Rechnung getragen? Ein Beispiel: • Wie groß ist der Prestigeverlust für einen Softwarehersteller, wenn die alte Version stabil lief, die neue mit viel Aufwand angekündigte Version zwar deutlich mehr kann, aber bei vielen Nutzern nicht mehr stabil läuft? Testbarkeit: Was trägt die Architektur einer Applikation dazu bei, den entstehenden Code mit solchen Eigenschaften verbindlich auszustatten, dass möglichst viele Teile der Applikation möglichst vollständig (und automatisch) getestet werden können? Ein Beispiel: • Für Software in bestimmten sicherheitsrelevanten Bereichen wird verbindlich vorgeschrieben, dass keine undefinierten Zustände der Software eintreten dürfen. Das bedeutet: Alle verwendeten Variablen müssen im definierten Wertebereich überprüft und alle logischen Verzweigungen auf funktionale Sinnhaftigkeit vollständig getestet werden. Anpassbarkeit: Was trägt die Architektur dazu bei, die Applikationen an unterschiedliche Betriebsumgebungen anzupassen, ohne dabei andere Aktivitäten notwendig zu machen. Beispiele: • Nehmen Sie den Plattformgedanken von JAVA oder „Eclipse“, dann wird deutlich, was hiermit gemeint ist. Anwendungen für derartige Plattformen sollten so geplant und realisiert werden, dass die neue Software tatsächlich auf unterschiedlichen Betriebssystemen spontan laufen kann! Modularität: Was trägt die Architektur zur Modularität der Applikation bei, um so softwaretechnische Anpassungen mit möglichst geringem Aufwand und möglichst behinderungsfrei für den Nutzer vornehmen zu können? Ein Beispiel: • Einzelkomponenten, etwa DLLs unter Windows, können in vielen Fällen per „hot fix“, also im laufenden Betrieb, eingespielt werden, ohne dass für den Anwender lange Wartezeiten oder Arbeitsunterbrechungen entstehen.

80

3 Aufbruch in die Zukunft

Flexibilität: Was trägt die Architektur dazu bei, die Anwendung möglichst flexibel und adaptiv zu gestalten? Ein Beispiel: • Die Konfigurierbarkeit der Software in Verbindung mit geeigneten Werkzeugen und Verifizierungsmechanismen ist hierfür ein gutes Beispiel. Produktlinien-Architektur

Wiederverwendbarkeit: Was trägt die Architektur dazu bei, dass definierte Komponenten in allen betroffenen Applikationen in gleicher Weise zum Einsatz kommen und hier keine Sonderwege beschritten werden? Es geht darum, geeignete Funktionengruppen zu identifizieren und Vorgaben zu entwickeln, wie diese auf hochstrukturierte und systematische Weise für alle betroffenen Anwendungen verbindlich sind. Ebenso geht es darum, Schnittstellen zu Komponenten so allgemeingültig zu definieren, dass spätere funktionale Ergänzungswünsche aus einer beteiligten Applikation allen anderen Anwendungen zugute kommen, diese aber nicht modifiziert werden müssen. Plattformierbarkeit: Was trägt die Architektur dazu bei, die Plattformierung einer definierten Produktlinie zu ermöglichen? Auch hierzu ein paar konkrete Beispiele: • Welche Daten- und Serviceschnittstellen schreibt die Produktlinienarchitektur vor? • Welche Hilfsmittel (etwa Diagnoseschnittstellen) sind für alle Produkte definiert? • Welche Komponenten und Dienste sind für alle Applikationen der Produktlinie gedacht? Wie sind Unterschiedlichkeiten zu implementieren? Es wird dabei deutlich: Solche Messbarkeiten zu definieren ist keineswegs einfach und verlangt einiges an Sekundärwissen, da letztendlich der Architekt zusammen mit den Stakeholdern diese Faktoren festlegen muss, bzw. auf dem Weg dorthin diese entsprechend zu beraten hat. Entscheidend ist an dieser Stelle, dass die Kundenwünsche zu Fragen an eine Architektur führen, die weniger im Sinne von direkten, also linear ermittelten Lösungen führt, sondern verlangt, dass möglichst früh und voll-

3.3 Alte Ziele, neue Wege

81

ständig der gesamte betroffene Lösungsraum definiert wird. Was dies konkret heißt, setzt allerdings die Auseinandersetzung mit einigen Grundsatzthemen voraus, wie sie im Folgenden behandelt werden.

3.3 Alte Ziele, neue Wege Im diesem Abschnitt möchte ich mit Ihnen zunächst den Blick in eine völlig andere Richtung werfen. Es geht um Gehirnforschung und Kognitionswissenschaften, verbunden mit der Fragestellung, ob neuere Erkenntnisse aus diesen Bereichen methodische Ansätze oder Anregungen liefern können, die dazu geeignet sind, den bei Softwarebau stattfindenden Klärungsund Transformationsprozess zu unterstützen. 3.3.1

Wenn Softwarebau vom Gehirn lernt Logik dient dem Beweis, Intuition der Entdeckung. Henri Poincaré

Lassen Sie uns für einige Augenblicke von dem Teil unseres Körpers sprechen, der unser intelligentes und intellektuelles Handeln erst möglich macht. Dieses Stück Gewebe, dass die Größe eines gut gewachsenen Blumenkohls hat, bei Männern mit durchschnittlich 1350 g und Frauen etwas weniger Gewicht zu Buche schlägt, ist mit seinen ca. 100 Milliarden Neuronen das Universum menschlicher Informationsverarbeitung. Neuere Erkenntnisse der Gehirnforschung über eben diese graue Masse bescheren den Computerwissenschaften eine veränderte Weltsicht, die zunächst einmal so gar nicht mehr zu dem passen mag, was mit den Konstrukten reiner Logik – etwa in der IT – verknüpft wird. Der Gehirnforscher Gerhard Roth wie auch andere renommierte Experten auf diesem Gebiet weisen in Bezug auf dieses Organ und unser eigenes Handeln auf einen interessanten Punkt hin: Auch wenn wir dank unseres Großhirns die Fähigkeit zum Abstrahieren und logischen Schließen haben, so führt diese Logik nicht den Dirigentenstab bei den eigentlichen Entscheidungsprozessen. Vielmehr sind nachgelagerte Ebenen – insbesondere das limbische System – in maximaler Weise an der eigentlichen Entscheidung beteiligt. Auch wenn das Großhirn eloquent das logische „Wieso und weshalb“ kommuniziert, so ist der hierfür gesetzte Bezugsrahmen völlig anderer Natur. Während die Logik von der modernen Gehirnforschung als Berater betrachtet wird, kann das limbische System als der eigentliche Vorsitzende im Gehirn angesehen werden. Dabei gilt dort ein anderes Or-

82

3 Aufbruch in die Zukunft

ganisationsprinzip: Das Gehirn reagiert nicht in Sätzen und Logiken, sondern in Bildern – und dies ohne Bezug zu zeitlichen Abhängigkeiten. Gleiches bestätigt übrigens der italienische Gehirnforscher Antonio Damasio und verweist darauf, dass eine der Grundannahmen des westlichen Denkens in der Trennung zwischen Verstand und Gefühl bestehe. Nun geht es in diesem Kontext nicht darum, gefühlvoll Software zu produzieren. Was aber diese Forschungsergebnisse belegen ist die Tatsache, dass ohne Gefühl kein vernünftiges Handeln möglich ist (Damasio 2004), somit gehören Rationalität und Emotionalität eng zusammen. Um diesen Punkt nicht zu überzeichnen, möchte ich diese Aussage aus der Gehirnforschung nur insofern verwerten, als sie deutlich macht, dass rein logikbetontes Handeln offenbar unzureichendes intellektuelles Handwerkszeug darstellt. Dies wird im realen Alltag übrigens an einer ganz überraschenden Stelle sichtbar: Outsourcing! Versuchen Sie einmal, multinationale Teams rein nach logischen Gesetzen oder fest vorgegebenen Workflows zu führen – die Grenzen dieser Vorgehensweise werden zumindest im IT-Alltag sehr rasch sichtbar! 3.3.2

Konstruierte Wirklichkeiten Jedes System ist die Konstruktion eines Beobachters, der nach seinen eigenen Beobachtungsregeln Elemente zu einer Ordnung zusammenfasst. (unbekannt)

Dies hat zur Folge, dass sich wahrgenommene Logik relativiert und sich jeweils auf einen eigenen, von Begleitumständen definierten Wirklichkeitsrahmen bezieht. Ein Beispiel: Forscher am legendenumwobenen Loch Ness haben folgendes Experiment unternommen und wissenschaftlich ausgewertet: Sie haben einen Holzpfahl eines Gartenzaunes mit einer Zugmechanik versehen und diese einige dutzend Meter vor einem beliebten touristischen Beobachtungspunkt platziert. Diesen Holzpfahl konnten sie mit einer entsprechenden Mechanik etwa armlang aus dem Wasser ziehen. Eine nicht darauf vorbereitete Touristengruppe wurde an diesen Ort gebracht und der Stab heimlich aus dem Wasser gezogen, als alle Touristen am Schauen waren. Anschließend bat man die immer noch unaufgeklärten Touristen darum, das zu malen, was sie gesehen hatten. Nahezu alle hatten tierähnliche Formen wahrgenommen und aufgezeichnet. Dieses kleine Experiment verdeutlicht auf sehr anschauliche Art und Weise, dass selbst unsere Logik eingebettet ist in einen Erwartungskontext.

3.3 Alte Ziele, neue Wege

83

Dies hat in verschiedener Weise Konsequenzen auch für den Alltag im Softwarebau! Mit diesem Hintergrundwissen wird klar, dass Lösungsräume, wie sie z. B. bei der Erhebung von Anforderungen durch die jeweiligen Stakeholder gesehen werden, stark von den aktuellen Kontexten geprägt sind. Für jeden, der eigene Erfahrung in IT-Projekten hat, wird schnell transparent, wohin die Reise geht, wenn man sich nur einmal fragt, wie die vielfältigen Sichten der beteiligten Stakeholder zu einer gemeinsamen Sicht konsolidiert werden sollen. Was sind die tatsächlich treibenden Faktoren bei solchen Abstimmungen? Ist es tatsächlich objektivierbares Wissen oder verbergen sich sehr viel subtilere Dinge im Hintergrund? Hinzu kommen die begrenzenden Faktoren, die sich aus den meist unbewusst stattfindenden Handlungsparadigmen der beteiligten Personen ergeben: Da gerade der Bereich des Softwarebaus sehr schnelllebig ist, sind Veränderungen allgegenwärtig. Dabei sind es die einzelnen Menschen, die oft nicht gelernt haben mit diesen Veränderung umzugehen, was zur Folge hat, dass die Beharrungstendenzen stark sind. Wie häufig finden sich im realen Alltag z. B. Software-Entwickler, die ein bestimmtes Produkt inund auswendig kennen, sich aber beharrlich weigern, liebgewordene Arbeitsmethoden oder Programmiertechniken zu verlassen und auf andere Vorgehensweisen umzusteigen. Dass es sich hierbei keineswegs nur um notorische Dickköpfe handelt wird nachvollziehbar, wenn auf das geschaut wird, was hier beim Einzelnen abläuft: Intuitiv tendiert unser Gehirn dazu die erprobten Verhaltensmuster immer wieder zu nutzen. Beim Einzelnen nennen wir dies möglicherweise Sturheit, tun dies größere Teile einer Organisation, so wird diese sich etablierende Vorgehensweise leicht zur „Best Practice“ umgemünzt – und somit leicht zum Verhinderer eines Besseren. So lange die Rahmenbedingungen stabil sind, mag das in Ordnung sein. Was aber, wenn sich diese graduell ändern und die eigene Wahrnehmung es zunächst einfach nicht wahrhaben will? Aus diesem Grunde muss folgender Satz des Change-Beraters Prof. Peter Kruse sehr ernst genommen werden (Kruse 2004): „Die innerbetriebliche Fähigkeit zur Gestaltung von Prozessmusterwechseln ist entscheidend für die Überlebensfähigkeit in global vernetzten Märkten.“ Genau diese Randbedingungen ändern sich aber schrittweise: Immer weniger haben wir es mit Programmen zu tun, die ad hoc zu verstehen sind. Vielschichtige Architekturen, vernetzte Applikationen oder verteilte funktionale Dienste, verknüpft mit komplexen Datenbanken gehören immer mehr zur Tagesordnung. Schrittweise betreten wir dabei ein Kontinuum, in welchem zwar die logischen Grundregeln immer noch gelten – diese aber mit ganz eigenen Dynamiken und Gesetzmäßigkeiten überlagert sind.

84

3 Aufbruch in die Zukunft

Um es konkret zu machen: Stellen Sie sich vor, Sie sind für eine gewachsene Software mit einigen Millionen „Lines of Code“ mit ebenso gewachsener Dokumentation verantwortlich, die aufgrund der Infrastruktur, in die sie eingebettet ist, von vielen anderen IT-Systemen, Interfaces oder Datenbanken abhängt. Werden Sie diesen Quellcode – ausreichende Zeit sei vorausgesetzt – in einen Zustand der Fehlerfreiheit überführen können? Höchstwahrscheinlich nein! Warum? Es wird zum einen Störgrößen und Zustandskombinationen mit den anderen beteiligten Systemen geben, die Sie vermutlich nicht alle auf Anhieb berücksichtigt und durchschaut haben. Ebenso ist davon auszugehen, dass Sie nicht in der Lage waren, die Kombinatorik aller Einstellungs- und Eingabemöglichkeiten auszutesten, da der Variantenraum einfach zu groß ist. Selbst Entwicklung und hoch automatisierte Abarbeitung von möglichst vielen Test Cases wird hier vielleicht Besserung, jedoch keine Lösung des Problems bringen. 3.3.3

Wahrnehmung und Denken Was uns Probleme macht ist nicht das was wir nicht wissen, sondern das was wir mit Sicherheit wissen; was aber in Wahrheit falsch ist. Mark Twain

Spätestens seit den Experimenten von Leon Festinger (1919–1989) über die Theorie der kognitiven Dissonanz (Lange 2007) in den Jahren 1959 und folgende ist bekannt, wie sehr subjektive Wahrnehmung von äußeren Faktoren beeinflusst wird, wie das vorgestellte Experiment am Loch Ness (S. 82) belegt. Eine objektive Wahrnehmung und Beurteilung, wie sie immer wieder mit den Ingenieurwissenschaften in Verbindung gebracht wird, mag es zwar dort geben, wo reine Zahlen im Spiel sind. Die Experimente Festingers (Festinger 1962) belegen jedoch klar: Denkinhalte und Motive stehen in enger Verbindung zueinander! Auf einmal gelten nicht mehr die Gesetze der reinen Logik, sondern Überzeugungen, Motivation und Wissen beeinflussen einander in nicht unerheblichem Maße. Was bedeuten diese Erkenntnisse für den Bau von Software, etwa da, wo es um die Zusammenarbeit mit solchen Stakeholdern geht, die mit ihren Wünschen aktiv zur Gestaltung der zukünftigen Software beitragen? Ein Blick in die Wirklichkeit verdeutlicht, worum es geht: Immer wieder vergeht viel wertvolle Zeit in technischen Abstimmungsmeetings, weil sogenannte „Sachdiskussionen“ über nachrangige Themen geführt werden, die wirklich zentralen Fragen aber unbeantwortet bleiben. Verborgen hinter diesen Sachargumenten werden Überzeugungs- oder Positionskämpfe ausgefochten, die nicht notwendigerweise eine optimale techni-

3.3 Alte Ziele, neue Wege

85

sche Lösung zum Ziel haben, sondern vielmehr darauf ausgerichtet sind eigene Standpunkte durchzusetzen. – Sind Sie bzw. die entsprechenden Mitarbeiter hierfür instrumentiert oder leben wir noch in der paradiesischen Vorstellungswelt, dass wir es hier mit Formen der reinen Logik und Vernunft zu tun hätten, bei der professionelle Souveränität zu optimalen Ergebnissen führt. Psychologie und Gehirnforschung lehren aber noch mehr – und diese Erkenntnis hat bereits in einigen Bereichen der IT-Produktion zu praktischen Konsequenzen, sprich Werkzeugen und Methoden geführt: Wir denken in Bildern! Folglich ist jede Art Dinge in Bildern auszudrücken für uns vorteilhaft. Aus diesem Grunde ist es ein wichtiger Punkt, gerade diese Fähigkeit des Gehirns zu nutzen und die eigene Kommunikation auf Metaphern und Bilder umzustellen. Dabei ist wichtig, dass diese Bilder Vertrautes ausdrücken und somit bei den beteiligten Personen etwas assoziiert werden kann. Um dies aber leisten zu können ist es notwendig, in die Paradigmenwelt des anderen einzusteigen, um durch dessen Brille die Welt zu sehen. Geschieht dies, so wird das Gegenüber letztendlich dazu bewegt, selbst die notwendigen Antworten zu liefern. Damit dies gelingt, muss jedoch die Gesprächsführung nachvollziehbar und nacherlebbar gestaltet werden. So kann erreicht werden, dass sie annehmbar wird! Durch diese Vorgehensweise ist es möglich, Wahrnehmungen – gerade auch beim Kunden – in Worte zu fassen, ihn von den vermeintlichen Problemfeldern zu den tatsächlichen Bereichen zu führen und mit Hilfe dieser Hinterfragungs- und Deutungsprozesse letztendlich die eigentlichen Themen und Probleme auf einem sinnvollen Abstraktionsniveau zu klären. Wenn Logik, wie sie im täglichen Einsatz ist, also doch nicht so lupenrein anzuwenden ist, wie wir dies von brillanten Denkern her kennen, so ist es sinnvoll ein wenig Transparenz in diese Art logischer Fallgruben zu bringen und diesen Bereich ein wenig genauer zu betrachten. 3.3.4

Konstrukte reiner Logik Ein Verstand, der nur Logik ist, gleicht einem Messer, das nichts ist als Klinge. Die Hand wird blutig beim Gebrauch. Rabindranath Tagore

Softwarebau ist das Konstrukt reiner Logik, darin sind wir uns sicherlich einig. Prozessoren sind Maschinen, die durch binäre Sequenzen angesteuert und mit Daten versorgt werden, ebenso sind Programmiersprachen hoch logische Konstrukte, die sich eindeutig auf diese Maschinensprachen transformieren lassen. Und trotzdem ist von Menschen geschriebener Code

86

3 Aufbruch in die Zukunft

voller Fehler, werden logische Widersprüche zum programmtechnischen Desaster und machen enorme Aufwände beim Testen und bei der Fehlervorbeugung notwendig. Ist der Mensch etwa das schwächste Glied in dieser Logikkette und sind wir selbst doch gar nicht so logisch, wie wir immer dachten? Logik gilt als Teil der Philosophie und Mathematik, in der formal festgelegt wird, wann eine Schlussfolgerung richtig ist. Es geht also zunächst um deutlich mehr, als nur im Sinne binärer Logik zwischen Ja und Nein, falsch und richtig zu unterscheiden. Auf dem Weg zur Lösung ziehen wir Schlussfolgerungen, die zwar im Sinne von Businessprozessen zu JA/NEIN-Entscheidungen idealisiert werden, aber nicht notwendigerweise berücksichtigen, wie fehleranfällig oder sicher der Weg zu dieser Entscheidung, also das eigentliche Schlussfolgern, ist. Dies hat zur Konsequenz, dass sich unbemerkt systematische Fehler in unser Schlussfolgern, Erinnern bzw. Erschließen einschleichen. Die Gemeinheit dabei ist: Unsere Entscheidungsfindung ist vielfach eingefärbt von eigenen Überzeugungen und Sichtweise, was zur Folge hat, dass die reine Vernunft auf einmal eine sehr subjektive, ja tunnelförmige Ausprägung erhält und wir anfangen, bestimmte Ereignisse zu Ursachen für nachgelagerte Probleme zu erklären, nur weil diese raum-zeitlich eng zusammen auftreten. Logisches Selfassessment

Um Ihnen dies ein wenig transparenter zu machen, schlage ich Ihnen den folgenden Selbsttest zum Ausprobieren vor.

U

V

8

3

Vor Ihnen liegen vier Karten, die jeweils auf Vorder- und Rückseite bedruckt sind. Die Aufgabe besteht darin zu überprüfen, ob folgende Regel stimmt: „Wenn auf einer Seite ein Vokal steht, so befindet sich auf der Rückseite eine gerade Zahl.“ Welche Karten würden Sie umdrehen, um zu überprüfen, ob diese Aussage tatsächlich zutrifft? Höchstwahrscheinlich haben Sie sich für die Karte mit dem „U“ entschieden. Befindet sich auf deren Rückseite keine gerade Zahl, so ist die

3.3 Alte Ziele, neue Wege

87

Regel falsch. – Haben Sie darüber hinaus die Karte mit der „3“ umgedreht, so gehören Sie zur kleinen Gruppe der logisch Hochbegabten, da auf der Rückseite von Karte „3“ kein Vokal zu finden sein darf. Falls Sie eine der beiden verbleibenden Karten in Betracht gezogen haben, so gehören Sie zur großen Mehrheit von Menschen, die sich logisch haben hinters Licht führen lassen. Für beide Fälle gilt: die Regel ist gültig, egal was auf der Rückseite steht. Die Vermutung der Wissenschaftler lautet: Menschen neigen dazu, die von der Regel explizit genannten Karten umzudrehen – wahrscheinlich, weil sie die Aussage in beide Richtungen interpretieren. Das entspricht dem Umkehrungs-Fehlschluss, also der Neigung, einen logischen Ausdruck auch in umgekehrter Richtung für gültig zu halten. – Dieses kleine Experiment mag zu denken geben, zeigt es doch, dass unser oftmals als streng logisch bezeichnetes Handeln Grenzen hat. Fehlerhafte Logik

Lassen Sie uns hier einige Aspekte zusammenfassen, die zu denken geben sollten. Deanna Kuhn, Professorin für Psychologie an der Columbia University New York, liefert einige Beispiele (Kuhn 2007), die zeigen, wie leicht die eigene Logik hinters Licht zu führen ist. Falsches induktives Schließen: Dies bedeutet, ein logisches Urteil zu fällen, das sich nicht notwendigerweise aus den vorliegenden Informationen ergibt. Solche Fehler entstehen gerne, wenn wir die bedingte Wahrscheinlichkeit eines Ereignisses, also seines Auftretens unter ganz bestimmten Umständen, einschätzen sollen. Ein Beispiel: Ein Test Case wird nicht erfolgreich durchlaufen. Er hat eine Fehlerrate von 10% Prozent. Wie wahrscheinlich ist es, dass die Software hinterher Probleme machen wird? 90% wäre hier die falsche Antwort, da Sie garantiert nicht ständig nur diese eine Funktionalität nutzen werden. Um die Wahrscheinlichkeit zu ermitteln wie häufig mit diesem Fehler zu rechnen ist, muss man auch wissen, wie oft die Funktion im Durchschnitt gebraucht wird! Falsches deduktives Schließen: Logische Schlüsse werden aufgrund von Vorannahmen gezogen. Allerdings hängt die Frage, ob diese tatsächlich logisch richtig sind, nicht von deren Wahrheitsgehalt ab, sondern davon, ob sie korrekt aus den Prämissen abgeleitet ist. Dabei neigen wir Menschen zu systematischen Fehlern, indem wir davon ausgehen, dass logisch korrekte Aussagen auch in umgekehrter Richtung gelten (vgl. das Beispiel auf der letzten Seite).

88

3 Aufbruch in die Zukunft

Kongruenz-Effekt: Er beschreibt die Tendenz, eine unlogische, aber inhaltlich glaubwürdige Schlussfolgerung für wahr zu halten oder aber eine inhaltlich unglaubwürdige, dafür aber logisch korrekte Aussage nicht zu glauben. Atmosphären-Effekt: Dieser Effekt beschreibt die menschliche Neigung, eine Schlussfolgerung für gültig zu halten, welche dieselben (bejahenden oder verneinenden) Ausdrücke enthält wie die vorangehenden Aussagen. Primacy-Recency-Effekt: Wenn Sie eine Liste mit Anforderungen gesammelt haben, so ist die Wahrscheinlichkeit, dass entweder die Reihenfolge oder aber der erste bzw. letzte Eintrag eine besondere Bedeutung bekommt, recht groß – egal was da steht! Diese Informationen hat unser Gedächtnis einfach besser gespeichert. Ganz offensichtlich ist unsere Alltagslogik höchst fehleranfällig, ziehen wir doch allzu oft mit hoher subjektiver Gewissheit die falschen logischen Schlüsse. Wenn die eigene Logik so leicht zum Stolperstein werden kann, so ist zu fragen, ob es Lösungswege gibt, um dieser Fehlerquelle entgegenzuwirken. Zwei Wege, die hier zu deutlichen Verbesserungen führen, sind dabei die Folgenden: Wir können lernen, sorgfältiger und kritischer zu denken. Dafür ist es notwendig zu lernen, die eigenen Handlungsmuster zu hinterfragen. Konkret bedeutet dies z. B. sich zu fragen, woher wir etwas wissen und ob wir uns dieses Wissens wirklich sicher sein können. Damit wird deutlich, dass es einer Art Metawissen bedarf, um die Sinnhaftigkeit und Effizienz der eigenen Methodiken – etwa bei der Erfassung von Anforderungen – zu durchleuchten und so etwa die Qualität der gewonnenen Erkenntnisse zu validieren. Ein weiteres Mittel zur Vermeidung dieser Art von Fehlschlüssen besteht darin, mehr über den Kontext und dessen Abhängigkeiten zu wissen. Es geht darum, etwas von den zugrundeliegenden Handlungsprinzipien höherer Ordnung sowie von den wechselseitigen Abhängigkeiten zu verstehen bzw. diese zu ergründen. Dies bedeutet für den Kontext des Softwarebaus: Wenn es möglich ist zunächst diejenigen Größen zu ermitteln, die Einfluss auf das entstehende Produkt haben bzw. haben werden, so lassen sich bereits in der Planungsphase die wechselseitigen Abhängigkeiten entsprechend berücksichtigen. Dies bezieht sich übrigens keineswegs nur auf technische Abhängigkeiten. Was hier stattfindet ist die Klärung, in welchem System von Abhängigkeiten die gerade in Planung befindliche Applikation operieren wird.

3.4 Systeme im Quadrat?

89

3.4 Systeme im Quadrat? Das Ganze ist mehr als die Summe seiner Teile. Aristoteles Im Bereich des Softwarebaus ist viel von Systemen die Rede. Man spricht von „technischen Systemen“, plant System-Architekturen oder vergibt Namen im Sinne von Systemtechnik. In diesem Sinne versteht man unter einem System eine organisierte Reihe von Komponenten, die auf eine bestimmte Weise zusammenwirken. Diese Definition gilt grundsätzlich für jede Art von System. Dabei ist eine Eingrenzung zwischen dieser ganz allgemeinen Definition und derjenigen für technische Systeme vorzunehmen. Für von Menschen gemachte Systeme gilt: • Das System existiert, damit Menschen davon profitieren können. • Es besteht aus Komponenten, deren Beziehungen untereinander das Ziel verfolgen, für das das System erdacht wurde. • Durch den Austausch von Informationen bzw. Materialien oder Energie wirkt es mit der Umwelt zusammen, in der es existiert und operiert. • Es muss sich in eine definierte Betriebsumgebung einfügen, wodurch sein Verhalten eingeschränkt wird. Zu den Komponenten eines Systems gehören u. a. die Gesetze der Physik, die Soft- und Hardware, mathematische Algorithmen sowie andere konzeptionelle oder physikalische Einheiten. All diese Komponenten müssen sorgfältig integriert werden, wenn ein System seinen beabsichtigten Zweck erfüllen soll. Dieser Blick ist notwendig, um das technische Zusammenspiel aller beteiligten Einzelkomponenten möglich zu machen. Wie aber gelangt man zu einer optimierten Spezifikation solcher technischen Systeme? Wie oben beschrieben, existieren diese, damit Menschen davon profitieren können. Oder, übertragen auf Softwarebau, damit bestimmte Aufgaben in möglichst optimaler Weise von datenverarbeitenden Maschinen übernommen werden können. Auf der Basis des bereits Gesagten wird eines deutlich: Der ausschließliche Blick nach innen auf solch ein technisches System ohne ausreichende Berücksichtigung all derjenigen Faktoren, in die diese Technik eingebettet ist, führt zu unzureichenden Ergebnissen. Abb. 3.5 liefert hierzu einige weitere Differenzierungen. Im unteren Teil der Abbildung wird zunächst eine oft vertretene Sichtweise wiedergegeben. Man blickt auf die Stakeholder, also all diejenigen, die irgendein signifikantes Interesse an dem zukünftigen Produkt haben. Man hat ein Repertoire an Techniken, wie sich eine solche Software realisieren lassen könnte, ist bestrebt, vorhandene Geschäftsprozesse zu modellieren und

90

3 Aufbruch in die Zukunft

Abb. 3.5. Softwarebau als System verstanden

bemüht sich darum, immer effektivere Arbeitsprozesse zu etablieren. Jeder dieser Punkte hat seine Berechtigung – aber reicht diese Sichtweise tatsächlich aus? Um diese Frage zu beantworten, möchte ich Sie zunächst in den Bereich des „Systemdenkens“ (Gharajedaghi 1999; Richmond 2000) mitnehmen. Mit Blick auf Abb. 3.6, S. 91 (oben) geht es um ein auf den ersten Blick einfaches System aus der Tagespraxis im Softwarebau, dass sich im Nachgang als heimtückisch erweist: Ihre Kunden beschweren sich, dass die Qualität Ihrer Software zu wünschen übrig läßt. Um dies auszugleichen wird angeordnet, dass die betreffende Software verstärkt zu testen ist und dass dies hohe Priorität habe. Mit Blick auf das betroffene Produkt ist diese Entscheidung vermutlich gut, mit Blick auf das gesamte System bedeutet es aber, dass Mitarbeiter abgestellt werden müssen, die dies tun. Die Folge: Andere Projekte, vielleicht sogar die dringend benötigte Nachfolgeentwicklung, werden sich verzögern, da die Resourcen anderwärtig gebunden wurden. Als zweites gilt es nun, den Kontext ein wenig zu erweitern und einige der zunächst unberücksichtigten Abhängigkeiten zu betrachten. Abb. 3.6 (unten) enthält zunächst dieselbe Ausgangssituation: Aufgrund schlechter Software soll mehr getestet werden, dazu werden Mitarbeiter aus anderen Projekten vorübergehend abgezogen. – Was ist aber die Folge davon, wenn

3.4 Systeme im Quadrat?

91

Abb. 3.6. Scheinbar einfache Systeme

Mitarbeiter aus anderen Entwicklungsprojekten abgezogen werden? Auch dort gibt es Milestonepläne, auch dort muss man pünktlich fertig werden, auch dort herrscht Termindruck. Die Folge (zumindest sehr häufig!) ist, dass wiederum an gründlichen Planungsaktivitäten gespart wird, was vorhersagbar wiederum weniger gute Software zur Folge haben wird. – Was aber sind die mittelfristigen Konsequenzen? Einerseits werden Sie erheblich mehr Investitionen in Nachbesserungen stecken müssen, andererseits sind weniger zufriedene Kunden auch schlechtere Käufer – auch beim Nachfolgeprodukt. Dies hat zur Folge, dass Ihnen weniger Ressourcen zur Verfügung stehen, mit denen Sie wiederum qualitativ hochwertige Neuund Weiterentwicklungen betreiben können. Kurz: Weil Sie an einer Stelle, nämlich „unvollständiger Planung“, unsauber gearbeitet haben, stellen sich unbemerkt eine ganze Reihe negativer Kausalabhängigkeiten ein, die Ihnen in Zukunft das Leben deutlich erschweren dürften. Anhand von Abb. 3.5 (S. 90) oben wird deutlich: Eine Sicht, die das ganze System betrachtet, ist notwendig. Es reicht nicht aus, nur eine Untermenge aus einigen Prozessen, Dokumenten und Projektplänen zu betrachten. Vielmehr müssen die wichtigen inhärenten Abhängigkeiten der künftigen Applikation ermittelt werden. Dies bezieht sich sowohl auf die Anforderungen des entstehenden Produkts als auch auf die Produktion an sich. Übrigens ist die sehr frühe Ermittlung des betreffenden Gesamtsystems und seiner innewohnenden Abhängigkeiten auch aus Sicht des Risikomanagements eine sehr lohnende Vorgehensweise, da so schon während der

92

3 Aufbruch in die Zukunft

Produktplanung solche Faktoren sichtbar werden, die für eine spätere Einführung der kommenden Software zum Problem werden können. Konkret: Wenn bekannt ist, welche Wechselwirkungen zwischen dem entstehenden Produkt und den avisierten Nutzern bestehen, lassen sich hieraus sehr früh in geeigneter Form Projektmarketing oder die Vorbereitung von entsprechenden Change-Prozessen bei den betroffenen Nutzern anstoßen. Ebenso ist es sehr viel besser möglich, anwenderspezifische Anforderungen zu präzisieren bzw. geeignete Schulungsunterlagen zu entwickeln. Beides hat einen erheblichen Einfluss darauf, wie eine solche Applikation vom späteren Nutzer angenommen wird. Zusammenfassend wird deutlich: Um ein optimales technisches System zu bauen bedarf es einer gründlichen und ganzheitlichen Systemanalyse, noch ehe über die Beschreibung von Geschäftsprozessen oder gar deren Modellierung nachgedacht wird. Um allerdings das „Wie“ solcher gesamtheitlichen Systeme und deren Wechselwirkungen besser verstehen zu können, ist ein Blick auf einen weiteren Bereich notwendig, nämlich die Kybernetik. 3.4.1

Die Kunst der Steuerleute

Zunächst gilt es die Kybernetik praktisch zu verstehen. Heinz von Förster, langjähriger Direktor des legendären Biological Computer Laboratory in Illinois und Mitbegründer der kybernetischen Wissenschaft, formulierte dies am Beispiel eines Steuermanns, der sein Boot sicher in den Hafen bringen möchte: Was macht ein solcher Steuermann? Er absolviert kein ein für allemal festgelegtes Programm, sondern er variiert es permanent. Wenn das Boot vom Kurs und seinem Ziel abweicht, so schätzt er diese Kursabweichung ein und korrigiert den Kurs entsprechend. Er versucht somit, den Fehler zu korrigieren. In jedem Moment wird die Abweichung in Relation zu dem ins Auge gefassten Ziel korrigiert. Das Betätigen des Steuers erzeugt eine Kurskorrektur, Ursache erzeugt somit Wirkung. Diese Wirkung wird wiederum zur Ursache, da dies eine neue Änderung des Kurses zur Folge hat. Diese erzeugt ihrerseits eine Wirkung, nämlich wiederum eine Kurskorrektur. Was hier stattfindet ist eine Form zirkulärer Kausalität. Letztendlich ist dies ein Prozess der Informationsauswertung, der jeweils zur Folge hat, dass sich das eigene Verhalten adaptiv verändert: Man bemerkt eine Kursabweichung und handelt entsprechend, indem man gegensteuert. Gerade für die frühen Kybernetiker standen solche zirkulär kausalen Prozesse hoch im Kurs. Man stellte sich die Frage: Was macht man, um an ein Ziel zu kommen? Wie geschieht das und wie lassen sich Maschinen bauen, die auf ein solches Ziel zusteuern? Norbert Wiener und andere setzten sich 1943 hiermit auseinander und führten das aus dem Mittelalter stammende Konzept der Teleologie wieder in die Wissenschaft ein. Dabei

3.4 Systeme im Quadrat?

93

beschreibt Teleologie die Lehre der ziel- und zweckbestimmten Ordnung von Abläufen, wie auch Lebewesen und deren Verhalten. In dem von der Gruppe verfassten Artikel mit dem Titel „Behavior, Purpose, and Teleology“ (Rosenblueth, Wiener et al. 1943) ging es um die kritische Analyse des damaligen Begriffs von Verhalten, der sich ausschließlich mit der Beziehung eines „Outputs“ zu einem „Input“ beschäftigte. Sie bemerkten, dass diese enge Definition den handelnden Organismus, seine spezifische Struktur sowie dessen innere Organisation, die eben diese Beziehung ermöglicht, völlig ignoriert. Diese Thematik scheint heute wieder ein hohes Maß an Aktualität zu haben! Sind wir nicht an einem ähnlichen Punkt angelangt, wenn wir nur den Input und Output von rollenbasierten Akteuren im Auge haben und uns dabei zunehmend auf die Modellierung von Geschäftsprozessen oder auf rollenbasierte Prozessbeschreibungen fokussieren? Haben hier die Kybernetiker der ersten Stunde möglicherweise Dinge gesehen, die wir beim Versuch, Softwarebau in reproduzierbare Bahnen zu lenken, schlichtweg vergessen haben? Übertragen auf heute müssen die Aussagen Wieners und seiner Kollegen gerade in dem hier behandelten Thema um die folgende Fragestellung ergänzt werden: Was macht man, um das Ziel zu erreichen, gute Software zu bekommen. Was bedeutet es also, zirkuläre Kausalität in den realen Alltag einzubringen – und wie kann das Ganze in sinnvoller Weise genutzt werden? Um diese Frage klären zu können, ist es notwendig zu verstehen, was Kybernetik erster Ordnung (vgl. von Försters Beispiel des Steuermanns, S. 92), von Kybernetik höherer Ordnungen unterscheidet: Beschäftigt sich die „Kybernetik erster Ordnung“ mit Fragen, wie Systeme ihre Organisation aufrechterhalten und hierbei ein objektiver Beobachter das System von außen observiert und beschreibt, so wirft die Kybernetik zweiter Ordnung einen Blick auf den Beobachter selbst und dessen Art und Weise zu agieren. Auf der Ebene erster Ordnung handelt man einfach, verwendet bestimmte Konzepte, Vorannahmen und Theorien, die nicht weiter reflektiert werden. Dies klingt ein wenig nach dem „Just do it“-Ansatz, von dem Qualitätsoffensiven wie etwa Six Sigma deutlich abraten (vgl. S. 58ff.). Erst auf der Ebene der zweiten Ordnung entsteht die Möglichkeit der Selbstreflexion. Nichts ist mehr einfach da, nichts ist mehr selbstverständlich. Entscheidend ist, dass der Beobachter für seine Beobachtungen, sein Sprechen und sein Handeln verantwortlich wird. Er ist untrennbar mit dem Gegenstand und Objekt seiner Beschreibung verbunden. Somit geht die Kybernetik zweiter Ordnung vom Einbezug der Beobachter in die Beschreibung dessen, was beobachtet wird, aus, da jeder die Welt durch die Linse der eigenen Ausbildung, Kultur oder Sprache sieht.

94

3 Aufbruch in die Zukunft

Tabelle 3.4. Kybernetiken verschiedener Ordnung Kybernetik erster Ordnung

Kybernetik zweiter Ordnung

Die Angelegenheit (z. B. ein techn. Problem) wird als unabhängig betrachtet – man sucht eine Insellösung (= Abarbeiten des nächsten Auftrags)

Die Angelegenheit (z. B. das techn. Problem oder eine Anforderung) wird von vornherein als eine Teilsicht auf ein größeres und zugleich dynamisches Ganzes verstanden. Ein Experte arbeitet mit dem Konzept der Angelegenheit und setzt dieses mit dem Problem in Bezug. Eine Person formuliert z. B. eine Annahme darüber, wofür diese Sache generell geeignet ist. Persönliche Veränderungen kommen aus innerer Einsicht und haben eher agilen Charakter.

Ein Experte arbeitet an dem Problem, so wie es sich ihm darstellt. Eine Person betrachtet die Angelegenheit nur aus der einen Perspektive – so wie sie es wahrnimmt. Persönliche Veränderungen (z. B. an Rollen) erfolgen von außen und sind daher vorhersagbar.

Tabelle 3.4 liefert exemplarisch einige Gegenüberstellungen aus der Praxis, wenn Dinge durch die Brille der Kybernetik erster bzw. zweiter Ordnung betrachtet werden. In Hinblick auf die rechte Spalte von Tabelle 3.4 wird deutlich, dass die dort wiedergegebene Betrachtungsweise gerade bei der Erfassung und Planung zu deutlich besseren Ergebnissen kommen kann als Vorgehensformen, wie sie eher der linken Spalte entsprechen. Eine weitere Anmerkung erscheint bedenkenswert: Bekanntlich ist Softwarebau, wenn er z. B. über mehrere Kulturkreise hinweg betrieben wird, wie etwa beim Outsourcing, keine einfach zu lösende Aufgabe und erzeugt vielfach kostentreibende Reibungsverluste. Mit Blick auf die Definition der Kybernetik zweiter Ordnung und deren Bezug auf individuelle Sichtweisen, die geprägt sein können von unterschiedlichen Herkunftsfaktoren der Betroffenen, ist zu fragen, ob und wie dies planungstechnisch berücksichtigt wurde. Verlangt man hier möglicherweise die Prozesstreue vorgegebener Abläufe – was einer Kybernetik erster Ordnung entspräche. – Oder hat man sich die Mühe gemacht, kulturelle Andersartigkeiten zu berücksichtigen und hierfür geeignete Andockpunkte zu definieren? 3.4.2

Mehr als nur systemisches Arbeiten

Ich möchte diesen Abschnitt mit den provokanten Aussagen von Antonio Damasio (Damasio 2004) beginnen. Er ist in der Gehirnforschung durch Arbeiten zum limbischen System bekannt geworden. Dort hat er sich wie-

3.4 Systeme im Quadrat?

95

derum mit der Fragestellung befasst, wie etwa tragfähige Entscheidungen zustande kommen. Damasio brachte in diesem Zusammenhang Folgendes zu Papier: Wenn sich jemand rein an den Ausrichtungen der Aufklärung ausrichtet und sein Leben bzw. seine Entscheidungen primär nach rein rational analytischen Gesichtspunkten angeht, dann ähnelt er in seinem Verhalten solchen Patienten, die schwere Schäden am Frontalhirn aufweisen – durch Unfall oder OP bedingte Zerstörungen dieses Gehirnbereichs gehen einher mit diesen Verhaltensformen. Wozu diese Menschen keinen Zugriff mehr haben, sind diejenigen Bereiche ihres Bewusstseins, in denen eine zweite, nämlich eine weichere Logik sich zu der ersten hinzufügt. Verhält sich nicht so mancher Entscheider oder Mitarbeiter in der IT auffallend ähnlich, wie die beschriebenen Patienten? Und dies nicht etwa, weil das eigene Gehirn Schäden aufweist, sondern weil man in der Branche darum bemüht ist, alles nach schematisierten und wiederholbaren Abläufen zu gestalten. Indem ich dieses Beispiel aufzeige, möchte ich auf einen Missstand aufmerksam machen. Es ist richtig, dass sich gerade die primäre Ausbildung von Informatikern sehr nahe an der Mathematik ansiedelt, ist sie doch aus ihr hervorgegangen. Hier ist reine Logik unverzichtbar und notwendig! Wie aber sieht es z. B. mit der Gestaltung von Mensch-MaschineSchnittstellen aus? Reicht es hier etwa aus, nach den Gesetzen der reinen Logik Software-Bedienungselemente zu platzieren, oder ist es notwendig vertiefte Kenntnisse über Wahrnehmungspsychologie und/oder GrafikDesign mitzubringen? – Oder wie sieht es im Industriealltag aus? Reicht ein solch rein logisches Vorwissen tatsächlich alleine aus, um Kundenwünsche zu erfüllen und Qualität zu liefern? Letztendlich nicht! Das lässt zumindest der hohe Anteil fehlinvestierter Gelder am Gesamtvolumen von Softwareprojekten vermuten. Hiervon ausgehend möchte ich Sie zu einer erweiterten Sichtweise einladen und dazu weitere Grundlagen vermitteln. Die vorgeschlagene Perspektive ist besonders in der Planungsphase von Software von hoher Signifikanz, hilft sie doch, direkte Bezüge zur späteren Wirklichkeit der zu bauenden Applikation bzw. Systemlandschaft herzustellen. Worum es geht, ist der sogenannte systemische Ansatz. Grundsätzlich berücksichtigt systemische Projektarbeit die zuvor eingebrachten Ansätze zur Kybernetik zweiter Ordnung und geht davon aus, dass sich jeder Betroffene in unterschiedlichen Systemen bewegt (Familie, Arbeitsteam, Kunden, Rollen, etc. …). Der Begriff an sich stammt aus der Psychologie und hat sich aus Aspekten der Gestalttheorie, der soziologischen Systemtheorie sowie der systemischen Familientherapie gebildet. Er beschreibt das Zusammenspiel und die Wirkungen einer Person im Kontext ihres eigenen sozialen Netzwerkes. Grundlegend für die Entwicklung systemischer Theorie war die Kybernetik, als Wissenschaft von Kommu-

96

3 Aufbruch in die Zukunft

nikation und Kontrolle in Mensch und Maschine mit ihrem wechselseitigen Ursache-Wirkungs-Prinzip. Das Verhalten eines Menschen (Sender), löst dabei eine Bedeutung (Botschaft) beim anderen (Empfänger) aus, was zu Reaktionen führt, die auf den Sender zurückwirken. Durch neue Reaktionen entstehen kreisförmige Interaktionen, die gesetzmäßig ablaufen. – Zunächst aber möchte ich Ihnen die drei erwähnten Begriffe in Ihrer ursprünglichen Bedeutung näher vorstellen: Gestalttheorie: Es geht hierbei um die konstruktivistische Sicht des menschlichen Erkennens. Im Mittelpunkt steht der Ansatz, dass das mentale System des Menschen aus bestimmten Elementen eine prägnante Gestalt „konstruiert“, obwohl nur die Elemente selbst gegeben sind. – Wenn Sie so wollen, arbeitet die menschliche Logik im Sinne der Gestalttheorie nach dem Legokastenprinzip und formt Gestalten, etwa in Form von Einheiten, Kontexten, Figuren bzw. Ordnungen. Dieses Clustern hilft offenbar unserem Gehirn dabei, empirische Phänomene unter bestimmten Gesichtspunkten zusammenzufassen, diese zu ordnen und sie so überschaubarer bzw. erkennbarer zu machen. Aus dem „Rauschen“ vieler zunächst scheinbar nicht zusammenhängender Beobachtungen gilt es erkennbare „Gestalten“ und definierte Ordnungen zu extrahieren. Dies ist übrigens auch die Art und Weise, wie unser Gehirn aus den komplexen Lichtsignalen der Augen Muster und Objekte schrittweise herausarbeitet und erkennt. Systemische Familientherapie: Der Begriff an sich ist für den Normalbetrachter irreführend, weil nur die Ursprünge in der Familientherapie zu suchen sind. Inzwischen haben die hier gewonnenen Erkenntnisse längst Einzug in die Organisationsberatung gehalten. Die ersten Ansätze stammen aus den 1940er Jahren aus dem Umkreis der sog. Palo-Alto-Gruppe um Gregory Bateson, Paul Watzlawick und anderen. Diese Gruppe untersuchte die Kommunikation innerhalb sozialer Systeme. Ihre Arbeiten weisen nach, dass ein solches soziales Gebilde – etwa eine Familie oder ein Software-Team – nicht nur aus den einzelnen Personen oder Rollen besteht, sondern diesen sich ein Netzwerk an Interaktion überlagert. Schaut man nur auf die einzelnen Personen (oder Rollen) und deren Tätigkeiten, so wird man ein solches soziales System nicht hinreichend verstehen. Durch die Betrachtung der Gruppe entsteht etwas ganz Eigenständiges, das die Summe der beteiligten Personen zu einem eigenen, unverwechselbaren Gebilde werden lässt. Dieses Eigene, so die Erkenntnis der Palo-AltoGruppe, erwächst aus den sprachlich geformten Interaktionen zwischen den Gruppenmitgliedern. Diese verdichten sich zu gruppenspezifischen Strukturen, Prozessen und Regeln der Kommunikation, welche die Identität einer bestimmten Gruppe als System bildet.

3.4 Systeme im Quadrat?

97

Soziologische Systemtheorie: Auch bei der soziologischen Systemtheorie, die auf ihren Begründer Niklas Luhmann zurückgeht, stehen – sehr stark vereinfacht – soziale Systeme und deren Kommunikation im Mittelpunkt. In Abgrenzung zur allgemeinen Systemtheorie geht es hier um eine konkrete Bezugsgröße, um die herum zu definieren ist, was diejenigen Elemente sind, die dieses System kennzeichnen. In diesem Sinne kann die soziologische Systemtheorie als eine Anwendung der Systemtheorie im Kontext eines ganz bestimmten Gegenstandes verstanden werden, während die Systemtheorie an sich eine solche Bezugsgröße nicht kennt. Auch aus dieser Definition leiten sich bereits beim ersten Hinschauen konkrete Implikationen für den Softwarebau ab: Kontexte jeweils ermitteln: Statt umgehend damit zu beginnen, mit Hilfe der ermittelten Stakeholder Business Cases bzw. Use Cases zu definieren, ist eine gründliche Analyse desjenigen Kontextes notwendig, in welchem die zukünftige Applikation laufen soll. Diese umfasst nicht nur technische Größen und Abhängigkeiten, sondern auch soziale Aspekte, wie dies bereits beschrieben wurde. Informationsverdichtung: Im Kontext der Softwareplanung, bei der es darum geht komplexe und diffuse Informationen, etwa von Stakeholdern, zu sammeln, liefert die Gestalttheorie Ansätze, die deutlich weiter gehen, als nur lange Listen mit Anforderungen zu füllen und diese thematisch zu verknüpfen. Es impliziert vielmehr schrittweises Zusammenfassen und Verifizieren der aufgenommenen Informationen. Hieraus leitet sich die Frage nach methodischen Vorgehensweisen zum effektiven Clustern ab. Es ist interessant, dass die Nutzung von Grafiken/Zeichnungen als Hilfsmittel zur Konkretisierung entsprechender Anforderungen (etwa in Ergänzung zu UML) auf dem Vormarsch sind und damit die Erkenntnisse der Gehirnforschung über bildhaftes Denken belegen (vgl. S. 82ff.). Mehr als nur Rollen und Aktivitäten: Solange nur Rollen, Aktivitäten und Resultate, nicht aber die Gruppe der Beteiligten und deren interne Kommunikation beachtet werden – also eine ausschließlich klassische Prozesssicht vorherrscht –, werden zentrale Steuerungsgrößen dem Zufall überlassen. Die vehemente Diskussion zwischen Vertretern prozessgetriebenen Softwarebaus (V-Modell, RUP, etc.) und denen, die agile Vorgehensweisen propagieren (z. B. XP, Extreme Programming o. ä.) weisen implizit auf diese Problematik hin. Wenn gerade die Erfassung von Anforderungen und die initiale Planung von Software festlegen, wie eine gegebene Wirklichkeit auf ein technisches System transformiert werden soll, so sind es genau diese Zusammenhänge und Interferenzen zwischen Denken,

98

3 Aufbruch in die Zukunft

Sprache und Kommunikation der Beteiligten, die wesentlich über das Wohl oder Weh der kommenden Applikation entscheiden. Somit stehen gerade in den frühen Phasen des Softwarebaus kognitive Psychologie, linguistische Aspekte35 und Kommunikationstheorie im Fokus, insbesondere deshalb, weil Denken und Sprechen auf das Engste miteinander verbunden sind. Brachten die bisherigen Überlegungen schon einige interessante Aspekte zu Tage, so gibt es hier Raum für weitere Bereiche, die der Systemtheorie zweiter Ordnung entnommen sind. In einem Ansatz von Radatz (Radatz 2006) wird aus einer gemeinsamen Nutzung des systemischen Denkens, in Verbindung mit radikalem Konstruktivismus sowie Autopoesis das Konstrukt evolutionären Denkens und Handeln. In jeder dieser Theorierichtungen wird die Welt aus sehr unterschiedlicher Perspektive betrachtet und liefert so Zugang zu verschiedenen Arbeitsweisen und methodischen Werkzeugen. Im Weiteren wird der Begriff „Softwarebau“ als Synonym für die Erfassung von Anforderungen sowie die IT-technische Planung der Lösung verwendet. Diese drei Bereiche bedeuten dabei Folgendes: Systemisches Denken: (Foerster, Glasersfeld et al. 2006) Oft gleichgesetzt mit Kybernetik der Zweiten Ordnung, richtet die Aufmerksamkeit auf die Dynamik und Kausalzusammenhänge sozialer Systeme, wie etwa Teams, Kunden und Produzenten, Unternehmen oder auch Kulturen. Traditionelles Denken geht davon aus, dass auf „A“ „B“ folgt und dann „C“. Im systemischen Denken wird aus „A“ nicht unbedingt „B“, sondern es könnte ebenso gut „C“ oder wieder „A“ folgen. Etwas weniger abstrakt: Alles was wir tun, wird Auswirkungen auf das System haben. Führen Sie z. B. mit einem Stakeholder ein Planungsgespräch, um bestimmte Informationen über dessen Anforderungen bzw. deren Umsetzung zu erhalten, so werden Sie durch Ihre Art, dies zu tun, die Ergebnisse beeinflussen. Oder erwarten Sie noch eine konstruktive Zusammenarbeit, nachdem Sie den Kunden z. B. zuvor auf der Basis Ihres Fachwissens niedergemacht haben? – Wohl kaum! Radikaler Konstruktivismus: (Glasersfeld 1997) Dieser erklärt, wie Wissen entstehen kann, ohne auf eine beobachterunabhängige Welt zurückgreifen zu müssen. Konkret heißt dies, dass jede Wahrnehmung kein Abbild der Realität liefert, sondern immer eine Konstruktion aus Sinnes35

Spätestens dann, wenn Sie stundenlang an Begriffen – etwa für ein Vision Dokument – gefeilt haben, um einerseits inhaltlich den gewünschten Scope abzudecken, zum anderen aber nicht zu schwammig zu sein, wissen Sie, worauf ich referenziere!

3.4 Systeme im Quadrat?

99

reizen und Gedächtnisleistung eines Individuums ist. Aus diesem Grunde ist Objektivität im Sinne einer Übereinstimmung von wahrgenommenem Bild und Realität nicht möglich. Ohne Ausnahme ist jede Wahrnehmung subjektiv. Somit gibt es nichts Objektives, auf das wir zurückgreifen und von dem wir behaupten könnten, dass es auch außerhalb unseres eigenen Denkrahmens Gültigkeit habe. In Konsequenz heißt dies wiederum für den Alltag im Softwarebau: Die vielfach beschworenen Sachdebatten sind nur sehr begrenzt tragfähig. Um hier dennoch zu sachlich guten Resultaten zu gelangen ist es für die Mitarbeiter in planenden Rollen notwendig, über geeignete Fähigkeiten der Gesprächsführung, Mediation oder gar des Coachings zu verfügen, um die vom Einzelnen wahrgenommene Objektivität seiner Aussagen zu relativieren und in Verbindung mit anderen Meinungsäußerungen auf eine objektivierbarere Grundlage zu überführen. Autopoiesis: (Maturana 1997) Beschäftigt sich mit der Selbstreferenz lebender Systeme. Sie richtet ihren Fokus auf das Verhalten und Funktionieren des lebenden Systems in Wechselwirkung mit seiner Umwelt. Maturana geht davon aus, dass Menschen immer selbst gestaltet handeln und sich selbst reproduzieren. Das bedeutet, dass Menschen stets aufgrund ihrer eigenen Erfahrungen entscheiden. wie sie sich verhalten und dabei immer wieder Lösungswegen beschreiten, die ihnen vertraut sind, also ihre persönlichen Erfahrungen als Entscheidungsgrundlage verwenden. Auch Autopoisis hat somit einen direkten Bezug zum Softwarebau. Wie sonst können Sie das Verhalten von Nutzern erklären, die seit langem mit einer Altapplikation arbeiten und diese – bei allen monierten Schwächen – dermaßen verinnerlicht haben, dass diese Anwendung immer wieder zum Referenzpunkt für mögliche Nachfolgeentwicklungen wird: Man denkt in Funktionen und Abläufen der Altapplikation, definiert selbst allgemeinere Vorgehensweisen hierüber und ist sich dessen oftmals kaum bewusst. Dies wirft die Frage auf, welches wohl geeignete Vorgehensweisen sind, diese Nutzer an ihrer eigenen lösungsbezogenen Erfahrung vorbeizuführen, um so zu den themenbezogenen Aspekten zu gelangen, die für Planer einer Nachfolgeapplikation von Wichtigkeit sind. Ähnlich wie bereits zuvor erwähnt, ist hier neben der Fähigkeit solche Mechanismen zu durchschauen konkretes Handwerkszeug notwendig, um in die benötigten Lösungsräume vorzustoßen. 3.4.3

Was heißt systemisches Handeln?

Entscheidend für einen systemisch konstruktivistischen Ansatz ist die grundsätzliche Relativität einer Aussage (Tomaschek 2006, S. 26). Es ist äußerst wahrscheinlich, dass ein anderer Beobachter nicht dasselbe wahrnimmt, wie der erste, obschon beide genau das gleiche Objekt vor Augen

100

3 Aufbruch in die Zukunft

haben. Übertragen wiederum auf den Softwarebau könnte das z. B. bedeuten, der erste Beobachter (Anwender) sieht die Bildschirmmaske unter dem Gesichtspunkt: „Hier wird das Arbeiten erheblich vereinfacht, früher mussten Informationen manuell zusammengetragen werden, an die Abläufe habe ich mich gewöhnt.“ Ein Zweitbeobachter, z. B. ein GUI-Experte, sieht eben diese Maske aus einer ganz anderen Perspektive: „Das Layout ist nicht mehr zeitgemäß. Es müssen viel zu viele Klicks und Mausbewegungen ausgeführt werden, um zu den gewünschten Ergebnissen zu gelangen. Hat das System nicht die Möglichkeit einen Teil der manuell eingegebenen Informationen direkt zu ermitteln, um die ganze Prozedur für den Anwender noch schlanker zu gestalten?“ Ein dritter Experte, z. B. für Datenbanken, hat hier wiederum eine andere Sichtweise und Wahrnehmung. Sein Fokus liegt auf dem, was hier an Transaktionen stattfindet, in welcher Form die erscheinenden Daten wohl abgelegt sind und wie diese miteinander verknüpft wurden bzw. wie das entsprechende Domainmodell hierzu aussehen mag. Dieses Beispiel verdeutlich: Ganz offensichtlich bewegen wir uns hier in einem System, dass von sehr unterschiedlichen Faktoren abhängig ist. Genau dieses System gilt es aber als solches zu erkennen bzw. in Vorbereitung für neue Softwareprodukte bewusst zu nutzen. Es wird deutlich, wie wichtig es zum einen ist, die individuelle perspektivische Wahrnehmung der jeweiligen Beobachter zu registrieren, zugleich aber auch herauszuarbeiten, aus welchem Kontext heraus der Einzelne auf eine solche Applikation bzw. den nachgelagerten Lösungsraum schaut. Wie man sieht, reichen Betrachtungen, die primär auf die Technik im Sinne eines geschlossenen Systems ausgerichtet sind, nicht aus. Stattdessen muss das Ganze kontextuell ausgewertet werden. Demzufolge werden Zusammenhänge, die auf rein kausale Denkansätze reduziert wurden – etwa auf der Basis klassischer Prozesse – immer einer Kybernetik erster Ordnung entsprechen und somit nicht notwendigerweise die gewünschten Ergebnisse erbringen. Oder anders herum formuliert: Technische Lösungen, die solche systemischen Überlegungen in der Planungsphase nicht berücksichtigen, werden mit einer sehr viel größeren Wahrscheinlichkeit unvollständig spezifiziert bzw. geplant werden, was wiederum Nachbesserungen, Folgekosten sowie andere Risiken nach sich zieht. Was aber ist notwendig, um den Umstieg aus kausal getriebenen Problemlösungsstrategien, die sich durch fortlaufende Sequenzen im Sinne von … Problem – Lösung – Problem – Lösung … auszeichnen, auf systemische Ansätze umzustellen? – Wenn damit begonnen wird Wechselwirkungen zu betrachten, also Auswirkungen und nicht Ursachen, so werden viele Phänomene, also Dinge, die bisher bizarr wirkten oder übersehen wurden, auf einmal eine ganz andere Ausprägung bekommen. Im Sinne kausalen

3.4 Systeme im Quadrat?

101

Denkens begründen wir z. B. Erfolge bzw. Resultate mit „Weil ...“Aussagen. Wie anders wären wohl die Ergebnisse, wenn stattdessen Fragen im Sinne von „Obwohl das und das dabei herausgekommen ist …“ zur Lösungsgenerierung genutzt würden? Dies zeigt, dass es primär um die Betrachtung von Wechselwirkungen geht. Die Blickrichtung wird dann nicht mehr in erster Linie lauten: Wer muss was machen, damit der andere arbeiten kann, sondern: Wer muss wie mit wem in Wechselwirkung stehen; was sind dabei die individuellen Risiken, bzw. was sind die beschleunigenden oder bremsenden Kräfte? Durch diese Betrachtungsweise ist es möglich produzierende Systeme – also auch das Environment im Softwarebau – in ganz anderer Weise zu optimieren. Letztendlich handelt es sich hierbei um Meta-Ebenen hinter den eigentlichen Prozessen. Direkt sichtbare Abläufe sind im Sinne von Geschäftsprozessen beschreibbar, können optimiert werden und unterliegen direkt nachvollziehbaren Dynamiken. Die hier beschriebenen Ebenen hingegen bleiben zumeist intransparent und neigen damit zur Unkontrollierbarkeit, was zur Folge hat, dass sie ein reges Eigenleben führen, da Fragen wie etwa die folgenden nicht systematisch gestellt oder angegangen werden: • Wer steht mit wem tatsächlich in Wechselwirkung und wie kann man dies optimieren? • Welches sind die Regeln, die auf dieser Ebene schon längst ausgehandelt worden sind und die im Sinne einer prozessualen Änderung neu auszuhandeln wären? • Was sind absolute Tabuthemen und wie können diese – falls notwendig – aufgelöst werden? Um es noch einmal mit von Foerster zu formulieren: Im Abendland ist die sogenannte „Gucklochhaltung“ sehr verbreitet. Man meint, man könne Dinge – wie eben durch ein solches Guckloch – von außen, objektiv betrachten und als neutraler Beobachter ein solches System beschreiben. Dabei entgeht, dass es einen solchen objektiven „Überblick“ nicht gibt, da wir selbst Teil eines solchen Systems sind. Auch wird sich dasselbe nicht notwendigerweise so ändern wie wir es gerne hätten. Was somit bleibt ist gezieltes Fragen, um das eigene, sowie das Fremdsystem in geeigneter Weise anzunähern. (zit. nach Radatz 2006, S. 18ff.) Dies funktioniert allerdings nur dann, wenn nicht persönliche Annahmen bzw. Glaubenssätze oder mangelnde Kernkompetenzen – etwa beim Fragenstellen – zum begrenzenden Faktor werden. Als Randbemerkung sei hier auf von Foersters „Lethologie“ verwiesen. Hierbei handelt es sich um die Theorie des Erlernens und Erwissens von Unwissbarem, Unbestimmbarem und Unentscheidbarem. Planung von neuer Software, die ja immer wieder mit der Kunst der Hellseherei vergli-

102

3 Aufbruch in die Zukunft

chen wird (= „Was wird der Kunde noch alles haben wollen, sobald er sieht, was er jetzt bekommt“) wäre wohl qualitativ deutlich besser, würde diese Kunst im Softwarebau aktiv beherrscht werden. – Auch wenn auf diesen Begriff hier explizit nicht weiter eingegangen werden soll, sind Aspekte hieraus auf den kommenden Seiten berücksichtigt.

3.5 Systemisch arbeiten Zusammenfassend lassen sich aus den vorgestellten Aspekten des letzten Abschnitts einige sehr praktische und praxisnahe Themenblöcke und Sichtweisen formulieren, die in Verbindung mit vorhandenen Arbeitsweisen und Tools zu einer deutlichen Verbesserung im Softwarebau beitragen. In Anlehnung an Abb. 3.7 ergeben sich aus einem systemisch orientierten Ansatz für den planerischen Teil der Softwareproduktion die nachfolgenden Vorgehensweisen. Diese gilt es zu verinnerlichen und aktiv in die eigentliche Projektarbeit zu integrieren. Dabei ist noch einmal klarzustellen, dass keineswegs alle am Softwarebau beteiligten Bereiche oder gar das Servicemanagement einen solchen mentalen Umstieg vollziehen müssen, wohl aber diejenigen Rollen, die an der Analyse von Anforderungen sowie der Definition der zukünftigen IT-technischen Lösung zentral beteiligt sind.

Abb. 3.7. Fähigkeitsbereiche für den Bereich der Softwareplanung

3.5 Systemisch arbeiten

103

Durch die in derselben Abbildung bezeichneten Blickrichtungen, die im nächsten Hauptabschnitt detailliert beschrieben werden (vgl. S. 115ff.), ist es möglich, die sonst ignorierten Informationen zu ermitteln und aufgrund der so gewonnenen Rahmenbedingungen Aussagen über Vollständigkeit, technische und organisatorische Randbedingungen, ja selbst Risiken bei Produktentwicklungen, deren spätere Einführung oder Infrastruktur frühzeitig zu erkennen. Statt also herstellerseitig still vor sich hin protokollierende Spezialisten zu engagieren, die – Sachbearbeitern gleich – alle Kundenwünsche auf virtuelle Bestelllisten übertragen, bedarf es von Anfang an systemisch geschulter Fachberater, die nicht nur den eigenen fachlichen Bereich sehr gut beherrschen, sondern auch in den Nachbardisziplinen bewandert sind. So ist es möglich, sehr früh auf die tatsächlichen Wünsche und Bedürfnisse des Kunden zu stoßen, saubere Systemgrenzen zu ziehen und ein hinreichend vollständig definiertes Gesamtbild zu erstellen. Von nicht-trivialen Systemen

Es wurde bereits geklärt, was im technischen wie auch nicht-technischen Sinne Systeme sind (vgl. S. 89ff.). Ebenso war bereits die Rede von der Wiederauferstehung der Teleologie (vgl. S. 93), also der Zielgerichtetheit im kybernetischen Sinne. Geklärt ist ebenfalls, dass ein System klar definierte Innen- und Außengrenzen, also Systemgrenzen braucht. Beschäftigt man sich mit Systemen, so sind Regeln notwendig, die sich mit den Zielen des Systems beschäftigen, da es Systeme ohne Ziele nicht gibt. Im Hinblick auf die Vorgehensweisen in der modernen IT-Produktion ist allerdings noch eine Thematik unbehandelt geblieben und wird sehr schnell zur bisher nicht beantworteten Frage: Ist ein Computerprogramm ein triviales System oder nicht? Um dies klären zu können möchte ich zunächst triviale und nicht-triviale Systeme definieren: Triviale Systeme: Diese basieren auf voneinander unabhängigen sequentiellen Ursachen. Somit stehen Input und Output eines solchen Systems immer in der gleichen eindeutigen Relation zueinander. Bei gleichem Input (gleichen Ausgangsbedingungen) wird ein immer gleicher Output (das gleiche Ergebnis) erzeugt, womit der Output vorhersagbar wird. Dabei ist ein solches System exakt modellierbar und sein Verhalten im Detail planbar. Nicht-triviale Systeme: Nicht-triviale Systeme verfügen über Rückkopplungsschleifen (d. h. zyklische bzw. selbstreferentielle Strukturen) und sind somit grundsätzlich vielfältig vernetzte, also nichtlineare Systeme. Der Output solcher Systeme wird teilweise wieder in den Input zurückgekoppelt, weshalb ein solches System auf seine eigene Reaktion reagiert. Insgesamt gibt es in solch einem System inhibierende (= abdämpfende), wie

104

3 Aufbruch in die Zukunft

auch desinhibierende (= verstärkende) Rückkopplungen, die es stabilisieren können. Ebenso können nicht-triviale Systeme über eine komplexe, nicht vorhersagbare Zeitdynamik ihres Verhaltens verfügen. Somit ist klar: einfache Businessprozesse, Kühlschränke oder logische Abläufe können in diesem Sinne als triviale Systeme verstanden werden. Eine Kausalbetrachtung ist hier sinnvoll, wenn es darum geht herauszufinden, warum ein triviales Gerät nicht mehr funktioniert. Indem Schritt für Schritt die Sequenzen an Aktionen oder auch Interaktionen durchlaufen wird, gelangt man früher oder später zu demjenigen Teil des Systems, das den Fehler verursacht. Anders sieht dies bei lebenden oder auch komplexen Systemen aus. Dort macht eine kausale Betrachtungsweise recht wenig Sinn. Wozu aber gehört Software? Klar ist: Für Programme der Kategorie „Hello world“ sind all diese Gedanken nicht notwendig. Anders sieht es aber bei solchen Applikationen aus – und diese werden stetig mehr –, bei denen das Maß an Komplexität deutlich höher liegt und Programme Rückkopplungsschleifen mit selbst generierten Daten haben. In solchen Fällen muss – entsprechend der oben gegebenen Definition – das System als nicht-trivial angesehen werden, was mit wachsender Systemgröße eine weitere Einschränkung nach sich zieht: Input und Output können nicht mehr in eindeutige Relation zueinander gesetzt werden. Damit ist ein solches System auch nicht mehr exakt modellierbar! Bezogen auf den realen Softwarebau hat dies eine ganz direkte Implikation. Nicht-triviale Bereiche eines Systems sind nicht mehr vollständig über Geschäftsmodell-Modellierung abbildbar. Die Übergänge mögen hier fließend sein, Tatsache bleibt allerdings, dass eine Vollabdeckung mit einer rein prozessorientierten Denkwelt nicht möglich ist. Ein Beispiel hierzu: Wenn Sie eine Flugplanungssoftware entwickeln wollen, so ist es notwendig alle gesetzlichen Regeln, Abhängigkeiten, die Ordnungen des Luftraums, diejenigen von Flughäfen mit ihren Regelwerken sowie Regeln und Daten