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 über Fluggesellschaften und deren Fluggeräte in geeigneter Weise in einer IT-technischen Lösung abzubilden. Alle diese Bereiche interagieren in nicht-trivialer Weise miteinander. Dies hat zur Folge, dass diese Bereiche, die gemeinsam die Wissensdomaine einer solchen Applikation bilden, im Sinne der Definition nicht modellierbar sind! Dabei ist die Rede noch nicht einmal von der Lösungskomplexität an sich, sondern betrifft bereits die fachliche Seite. Da auch klassische Use Cases sich ihrer Definition nach von der Geschäftsprozessmodellierung ableiten lassen, unterliegen auch sie den gleichen Einschränkungen. Ein Flugplanungssystem ist eben keine Waschmaschine mit vielleicht einem dutzend Nutzungsfällen! Es wird deutlich, dass hier ein Raum betreten wird, der aus dem Bereich des Trivialen herausführt und zunehmend in komplexe nicht-triviale Bereiche mündet.

3.5 Systemisch arbeiten

105

Wir sahen: „Warum“-getriebenes Fragen und Handeln machen nur bei trivialen Systemen Sinn, jedoch sind weder IT-Organisationen noch Softwareproduktion (etwa bei Produktplattformierungen) dieser Gruppe von Systemen zuzuordnen! Folgerichtig wird diese Art des Fragens nicht zielführend sein. Die Ergebnisse dieser Überlegungen führen zurück zu den bereits eingeführten kybernetischen Modellen höherer Ordnung sowie den systemischen Überlegungen (vgl. S. 94ff.). 3.5.1

Umzug ins nicht-triviale Kontinuum

Wenn Sie eine Flugreise unternehmen, so werden Sie in genau festgelegter Reihenfolge mit reproduzierbarer Qualität bestimmte Dienstleistungen erhalten. Egal ob dies der Getränkeservice, der Snack oder die warme Mahlzeit ist: alles findet in genau festgelegter Reihenfolge zu bestimmten Zeitpunkten sowie definiertem Umfang statt und kann per Checkliste jederzeit nachgeprüft werden. – Gleiches gilt auch für Serviceleistungen im Bereich Software, z. B. bei deren Auslieferung, bei Helpdesk-Anrufen, neuen Softwareupdates oder Ähnlichem. Hier macht eine hohe Prozesstreue zur Erreichung gleichbleibender Qualität außerordentlich viel Sinn! Wie aber sieht es mit dem Bau von Software aus? Ist dort eine solche Vorgehensweise in eben dieser Form für alle Bereiche möglich oder könnte es sein, dass hier Grundannahmen getroffen wurden, die sich so nicht ohne weiteres für alle Aufgaben sinnvoll realisieren lassen? Klar ist, es gibt – wenn auch auf einer anderen Abstraktionsebene – bestimmte Tätigkeiten, die in einer festgelegten Reihenfolge sinnvoll sind: etwa Anforderungen erfassen, IT-Architektur planen, Implementieren und Testen, um nur eine Minimalvariante bei der Software-Produktion aufzuführen. Klar ist ebenfalls: es gibt eine Vielzahl von Tätigkeiten in der Produktion von Software, die sehr prozesstreu durchgeführt werden können und auch sollten. Aus wirtschaftlichen und produktionstechnischen Erwägungen liegt es dabei nahe, dass Softwareentwicklung so weit wie möglich zu prozessualisieren ist. Gesucht werden dabei Wege – so wie es in anderen EngineeringDisziplinen geschieht –, mit denen man Software quasi vom Fließband produzieren kann: Man sucht nach Softwareproduktionsstraßen, bei denen bei vorgegebener Taktung Softwarekomponenten gleichbleibender Qualität erzeugen werden. Um dies zu erreichen kombiniert man Modellierung, Werkzeuge und Prozesse, nutzt Best Practices und integriert schematisierte Vorlagen im Sinne von z. B. Patterns. Insgesamt wird dabei zugrunde gelegt, dass Softwareentwicklung ein rein ingenieursmäßiger Vorgang sei, der mit entsprechender Planung und Organisation wie im Maschinenbau üblich industrialisiert werden könne. Dementsprechend werden virtuelle Fertigungsstraßen, bestehend aus Businessanalyse etwa zur Prozessbe-

106

3 Aufbruch in die Zukunft

schreibung, Anforderungsmanagement, IT-Architektur, Design-Programmierung und Testen, aufgebaut und es wird erwartet, dass in kürzester Zeit ein Produkt mit minimaler Fehlerrate, minimalen Kosten, minimalem Zeitaufwand, aber maximaler Qualität vom Band läuft. – So weit die Theorie! Die Resultate der Praxis sehen oft anders aus – trotz virtuellem Fließband! Können auf Softwareentwicklung tatsächlich die Paradigmen aus dem industriellen Maschinenbau übertragen werden oder ist es nicht in vielen Fällen so, dass Softwarebau eher der Erstellung eines maschinenbaulichen Prototypen in der Musterwerkstatt entspricht: Da die Erkenntnisse vielfach erst bei der Erstellung eines solchen Prototypen kommen, ist ein gewisses Maß an „Forschungsarbeit“ notwendig; auch ist eine Planung aller notwendigen Details so gar nicht möglich. Immerhin sind die eigentlichen Problemkinder im modernen Softwarebau ganz anderer Natur. Hier kämpft man mit der hohen Komplexität entstehender Systeme, muss sich mit der hohen Dynamik sowohl auf produktionstechnischer Seite, wie auch in Bezug auf die Weiterentwicklung innerhalb der IT auseinandersetzen und muss Wege finden, wie diese stetige Dynamisierung in eine Flexibilisierung von Produkten und Vorgehensweisen überführt werden kann. Dabei versucht man durch Abstraktion der Komplexität Herr zu werden, definiert Standards, um so Systemintegrationen zu ermöglichen, und entkoppelt Systeme, um zur gewünschten Flexibilität zu gelangen. Hier aber gelangen wir in die IT-technische Musterwerkstatt: Wie muss ein Fließbandprozess aussehen, mit dessen Hilfe Sie aus einem komplexen Zusammenhang das entsprechende abstrakte Modell ableiten können? Mit Blick auf das Beispiel des Steuermanns, der sein Boot in den Hafen lenkt (vgl. S. 92ff.) wird deutlich, dass bestimmte Tätigkeiten nicht mehr uneingeschränkt in solche Ablaufmuster passen. Offenbar gilt auch hier: triviale Abläufe im Sinne der Definition von S. 103 sind so darstellbar, während man bei nicht-trivialen Abläufen, also solchen Vorgängen, bei denen das Ergebnis wieder auf den Eingang zurückgeführt wird, an Grenzen stößt. Dies gilt insbesondere für die beiden hier schwerpunktmäßig betrachteten Bereiche der Anforderungserfassung bzw. IT-Architektur. Was Softwarebau und Hausmannskost gemeinsam haben

Sind die hier betrachteten Softwerker eher als planende Ingenieure oder mehr als Künstler bzw. Forscher zu sehen? Klassische Ingenieurskunst verläuft nach festen Regeln und Erfahrungswerten: Die Belastungsgrenzen bestimmter Bauteile können entsprechenden Nachschlagewerken entnommen werden; die Regeln, wie Komponenten verbaut werden, liegen vor und ebenso sind Konstruktionsregeln zu berücksichtigen. Findet all dies statt, so ist mit einer reproduzierbaren Qualität des Ergebnisses zu rechnen.

3.5 Systemisch arbeiten

107

So baut man Häuser, Autos oder Elektrogeräte – aber gilt dies auch für den Softwarebau? Auch wenn die Rolle des (IT-)Architekten fest im Softwarebau verankert ist, so möchte ich hier diesen Begriff als Synonym für künstlerisches Vorgehen nutzen. Somit ist zu klären, was den Unterschied zwischen klassisch ingenieurmäßigem und künstlerischem Handeln ausmacht. So betrachtet ist Ersteres eher eine Wissenschaft und lebt davon, Prozesse, Werkzeuge und Verfahren in sinnvoller Reihenfolge hinreichend präzise zu nutzen. Das Zweite hingegen entspricht eher einer Kunst, bei der all die vorgenannten Kenntnisse Voraussetzung sind, aber Erfahrung sowie ganzheitliches Vorgehen zusätzlich benötigt werden. Grund dafür ist, dass sich die Architektur mit unstrukturierten Situationen befasst, in denen zunächst weder die Ziele noch die für die Umsetzung sinnvollsten Mittel wirklich bekannt sind. In Anlehnung an „The Art of Systems Architecting“ (Maier/Eberhardt 2002) lässt sich diese Differenzierung wie folgt zusammenfassen: Im ersten Fall geht es vor allem um deduktive, im zweiten Fall um induktive Vorgehensweisen. Ingenieurwissenschaften setzen dabei Werkzeuge ein, die sich von der Mathematik her ableiten, und arbeiten so letztendlich deduktiv. Deduktion bedeutet: Ich bewege mich vom Allgemeinen zum Speziellen. – (Klassische) Architekten hingegen arbeiten vorwiegend mit nicht messbaren Dingen, die ebenso nicht-quantifizierbare Werkzeuge brauchen. Ihre Handlungsanweisungen ergeben sich aus dem eigenen Erfahrungsschatz und den gelernten Lektionen. Im Sinne der Definition systemischen Denkens (vgl. S. 98ff.) muss hier ganz offensichtlich in Lösungsräumen der zweiten Ordnung gedacht werden. Somit ist Architektur ein induktiver Prozess, sucht also vom Speziellen ausgehend auf das Allgemeine zu schließen. In Anlehnung an (Simon 2004, S. 49) lässt sich diese Unterscheidung noch weiter ausformulieren. Was ingenieurmäßiges Arbeiten ausmacht, bezeichnet Simon als „Housewifery“ und stellt dem das grundsätzliche Wirken eines – er nennt es – „Künstlers“ gegenüber (vgl. Tabelle 3.5). Im ersten Fall ließe sich als grundlegendes Motto formulieren: „Die Bewahrung des Guten fördert die Verbesserung“ (= Best Practices), während das Motto im zweiten Fall lautet: „Fange an diejenigen Dinge zu verändern, die Du festhältst“. Im Fall von „Housewifery“ geht es darum, dass vorhandene „Best Practices“ zum Einsatz kommen, also bewährte Prozesse und Konzepte eingesetzt bzw. eingehalten werden, was sich im Fall des künstlerischen Arbeitens anders gestaltet! In der von Simon als „Housewifery“ bezeichneten Vorgehensweise findet sich der Ansatz kausalen Denkens wieder, also eine Betrachtungsweise, die auf Ursache und Wirkung beruht.

108

3 Aufbruch in die Zukunft

Tabelle 3.5. Unterscheidung Engineering und Architektur (nach Simon) „Housewifery“

Künstlerisches Arbeiten

Aufrechterhaltung der vorhandenen Ordnung Aufbau und Aufrechterhaltung von Strukturen Zuverlässig, normativ, konservativ

Neuen Wind in vorhandene Ordnungen blasen Beseitigung von Strukturen

Normalität, Starre Bestätigung von Erwartungen, Vorhersagbarkeit Frieden und Ordnung

Überraschend, nicht normativ, innovativ Dynamik, Flexibilität Nichterfüllung von Erwartungen, Nichtvorhersagbarkeit Unruhe und Chaos

Wie ist es dazu gekommen, dass wir Probleme, ja sogar Geschäftsprozesse fast ausschließlich in der Weise definieren, wie sie eher der linken Seite in Tabelle 3.5 entsprechen? Ein Blick in die Geschichte liefert hier einige interessante Hintergründe und Fakten. (vgl. Nadler/Chandon 2004, S. 2ff.). Die Rede ist von einem reduktionistischen Weltbild, das für die Mehrheit von uns als Basis zur Lösungsfindung genutzt wird. Diese Sichtweise, besser bekannt unter dem Namen „Rationalismus“, geht auf das kartesische Denkmodell des 16. Jahrhunderts eines René Descartes sowie seiner Zeitgenossen Francis Bacon und Isaac Newton zurück. Der von Descartes begründete Ansatz basiert auf empirischen Überlegungen, Logik und Gründen. Er bildet somit eine der wesentlichen Ansätze für die aktuelle Wissenschaft wie auch für Geschäftsprozesse. Lösungen werden hier „wissenschaftlich“ erarbeitet, was bedeutet, dass man Annahmen trifft, hierzu Daten sammelt, diese dann analysiert und zuletzt eine Aussage daraus ableitet, die belegt, dass diese Abstrahierung die ursprüngliche Hypothese belegt. Zudem basiert der kartesische Ansatz auf folgenden Überlegungen: Alles kann in Einzelteile zerlegt werden. In der IT ist dies die Voraussetzung für objektorientiertes Modellieren. Des Weiteren, so der kartesische Ansatz, ist jedes Teil austauschbar. Und hieraus resultierend: „Die Lösung eines Teilproblems kann das Gesamtproblem lösen“ sowie „Das Ganze ist nicht mehr als die Summe seiner Teile“. Hieraus ergibt sich der Ansatz des kausalen Denkens, der letztendlich Ursache und Wirkung beschreibt. Spätestens dann, wenn es keine eindeutige Monokausalität36 mehr gibt, also die vielfach fließende Grenze zur Multikausalität37

36

Monokausalität bezeichnet genau ein Ereignis (Kausalität), bei dem sich das Endergebnis B auf genau einen verursachenden Auslöser A zurückführen lässt.

3.5 Systemisch arbeiten

109

oder zu Kausalketten38 überschritten wird, wurde ein Raum betreten, der als „komplex“ zu bezeichnen ist! Die entscheidende Frage lautet nun, ob kartesisches Denken allein ausreichend ist, um damit Komplexität, Kreativität, wie auch gemeinschaftliches Denken und Handeln abzudecken. Wie sehr die meisten Zeitgenossen in dieser Denkweise festgelegt sind, können Sie an dem nachfolgenden Selbsttest nach Nadler (Nadler and Chandon 2004) überprüfen: 1 Etwas funktioniert nicht richtig. Das erste, was wir tun, besteht darin genau herauszubekommen, was hier eigentlich kaputt ist. 2 Wir sammeln Daten über die vorhandene Situation, insbesondere darüber, was defekt ist oder fehlt (die klassische Servicedesk-Situation). 3 Wir analysieren die Daten. 4 Wir abstrahieren, was hier stattgefunden hat, sodass andere es nachvollziehen können. 5 Wir versuchen durch logische Überlegungen herauszufinden, was genau defekt ist und was möglicherweise die Ursache hierfür ist. 6 Wir suchen nach einem Lösungsweg, um die eigentliche Ursache zu beseitigen. 7 Wir implementieren die Lösung, die uns am geeignetsten erscheint. 8 Wir wenden diese Lösung schnell und effizient an. 9 Wir wenden uns dem nächsten Problem zu. Ob Sie wohl zu den ca. 92% unserer Zeitgenossen zählen, die so denken und handeln? – Was Nadler hier zusammengetragen hat, klingt nach Tagesgeschäft im Projektalltag. Für die meisten ist dies eine idealtypische Vorgehensweise. Die Frage, ob es auch andere Wege zum Ziel gibt, wurde niemals gestellt. Anders sieht die Welt aus, wenn nicht nur nach dem „Warum“, sondern auch dem „Wozu“ gefragt wird. – Lassen Sie mich dies ein wenig beleuchten: Solange rein lösungsorientiert gearbeitet wird, werden all diejenigen Tätigkeiten, die in irgendwelchen Projektplänen aufgeführt werden, „gelöst“, sprich abgearbeitet. Die Frage nach der Finalität (Adler 1984), also danach, warum etwas gemacht wird und ob es tatsächlich zur notwendigen Lösung beiträgt, findet oftmals nicht statt. Hier aber liegt genau eines der Probleme im Softwarebau! Dinge werden gemacht, weil sie geplant wurden, es wird 37

38

Bei der Multikausalität wirken mehrere Auslöser (Ursachen) zusammen oder nebeneinander zur gleichen Zeit. Eine Kausalkette ergibt sich, wenn jede Wirkung selbst wieder zur Ursache für eine neue Kausalität wird und somit zu einem neuen Kausal-Ereignis wird. Daher ist die Kausalkette eine streng zeitliche Aneinanderreihung von hintereinander ablaufenden Kausalitäten, während die Multikausalität gleichzeitige Ursachen benötigt.

110

3 Aufbruch in die Zukunft

aber nicht notwendigerweise hinterfragt, ob sie – z. B. aufgrund veränderter Rahmenbedingungen – so noch notwendig sind oder ob ganz andere Lösungswege sehr viel besser zum Ziel führen. Auch klassische Geschäftsmodellmodellierung trägt hier nur bedingt zur Effizienzsteigerung bei, da letztendlich im Sinne von „Best Practices“ das modelliert wird, was ohnehin schon gegeben ist. Eine Optimierung vorhandener Vorgehensweisen wird vielfach ausgelassen. – Hieran wird deutlich: Wenn kartesisches Denken von Mitarbeitern nicht ergänzt wird durch finales Denken, dann entstehen sehr wohl Lösungen – aber vorwiegend solche, die im Sinne von „Housewifery“ zu klassifizieren sind. In diesem Sinne verstanden, gilt es Steve de Shazers „Lösungsorientierten Ansatz“ (de Shazer 2006, S. 66ff.) auf die Projektarbeit im Softwarebau zu übertragen: Wie können IT-Mitarbeiter so instrumentiert werden, dass sie nicht nur geplante Dinge abarbeiten – sicherlich umsichtig und mit der Absicht, es möglichst gut zu machen –, aber nicht die Frage nach dem „Warum“ stellen. Hier begegnen uns auf einmal wieder denjenigen Aspekten, die bereits auf den vergangenen Seiten über systemisches Denken und Handeln vorgestellt wurden (vgl. S. 99ff.). Dass es sich bei diesen Überlegungen keineswegs um eine rein akademische Übung handelt, wird deutlich, wenn man sich die verschieden positionierten Lager anschaut, die für bestimmte Vorgehensweisen bei der Erstellung von Software stehen. Spätestens dann, wenn die Frage nach dem „besten“ Software-Produktionsprozess aufkommt und streng agiler Softwarebau dem ingenieurmäßigen gegenübersteht, wird das Dilemma deutlich: Produziert man Software besser strukturiert (z. B. V-Modell, Dröschel and Wiemers 1999, RUP, Kruchten 1998, etc.) oder ist eine agile Vorgehensweise vorzuziehen (z. B. eXtreme Programming, Larman 2004, o. ä.)? Ja könnte es sogar sein, dass das von Brooks (Brooks 1995) im „Mystical Manyear“ vorgeschlagene „Ärztemodell“, das nur wenig mit den beiden vorgestellten Hauptrichtungen zu tun hat, sehr viel Realitätsnähe enthält, das jedoch aufgrund einer starken Rollenorientiertheit in Vergessenheit geraten ist? Brooks ging in seinem „Ärztemodell“ davon aus, dass es im Zentrum einer Softwareproduktion wenige erfahrene Programmierer gibt, die, medizinischen Operateuren gleich, aufgrund ihrer Erfahrung die kritischen Teile selbst erstellen. Andere, Assistenten gleich, arbeiten diesen zu. Dadurch können sich die Operateure auf die wirklich wichtigen Dinge konzentrieren, während einfache Teilaufgaben oder Nacharbeiten durch unerfahrenere Kollegen erbracht werden können. Diese Gruppe von Mitarbeitern kümmert sich um die eigentliche Codierung und wird von zusätzlichen Kräften unterstützt, die sich mit Dokumentation, Infrastruktur oder Testen befasst und auf diese Weise den Entwicklern zuarbeitet und diese von solchen Aufgaben entlastet, die diese nicht unbedingt selbst durchführen müssen.

3.5 Systemisch arbeiten

111

Mit Blick auf die Medizin, die bis heute so arbeitet, liegt der Charme dieses Ansatzes darin, dass weniger erfahrene Mitarbeiter erfahrenen Kollegen assistieren und dadurch ein Wissenstransfer auf der Praxisebene stattfindet. 3.5.2

Konstruierte Wirklichkeiten

In Summe betrachtet bedeutet Software zu bauen nichts anderes, als eine komplexe, zunächst unklar abgegrenzte Wirklichkeit im Rahmen des gestellten Auftrags zunächst zu erfassen und abzugrenzen, um diese danach in ein vollständiges, sauber abgegrenztes, jedoch möglichst übersichtliches abstraktes Modell zu überführen. Auf dem Weg dorthin sind unterschiedliche Personen (in zugewiesenen Rollen) mit sehr unterschiedlichen Sichtweisen und Fertigkeiten beteiligt, deren jeweilige Aufgabe nicht nur darin besteht, die zunächst oft unklaren Vorstellungen in eine streng formale Struktur zu überführen, sondern das umrissene Gesamtziel nicht aus den Augen zu verlieren. Dabei sind selbst dort, wo keine expliziten Prozessmodelle zum Einsatz kommen, Vorgehensweisen im Einsatz, die mit (Quasi-)Prozessen39 auf eine Stufe gestellt werden können. Um das eigentliche Ziel, nämlich aus anfänglichen Ideen eine vollständige und funktionale Software zu erstellen, kommen diverse technische Hilfsmittel, also Produkte, zum Einsatz, um hiermit zu planen, strukturieren, implementieren, dokumentieren und zu testen. Wie dies jeweils geschieht, ist organisations- und projektspezifisch, muss aber stets zum selben Schlussresultat führen. Dieses besteht darin, dass Ausschnitte einer komplexen, nicht-kartesischen Welt lückenlos in einer kartesischen Modellwelt abgebildet werden müssen (vgl. Abb. 3.8). Hierbei steht der Begriff „lückenlos“ einerseits für die Forderung Softwarecode so zu entwickeln, dass der Anwender alle definierten Aufgaben im festgelegten Rahmen tatsächlich mit dieser Software bearbeiten kann. Andererseits ist es eine Forderung des Qualitätsmanagements an den Code, speziell von sicherheitsrelevanter Software, dass die Software niemals in unkontrollierte Zustände geraten darf, wodurch sie z. B. abstürzen könnte. Dies wiederum bedeutet: • Die Wertgrenzen für jede verwendete Variable müssen bekannt sein und es ist sicherzustellen, dass sie niemals unter- oder überschritten werden können. 39

Auch wenn Sie keinen eingeführten Prozess in Ihrer Organisation anwenden, so arbeiten Sie dennoch nach einem bestimmten Prozessmodell, etwa demjenigen, Software auf Zuruf zu bauen oder sie so zu erstellen, wie Sie es immer taten (= Ihre persönlichen Best Practices). Vgl. hierzu auch CMM/CMMI (S. 50ff.)

112

3 Aufbruch in die Zukunft

Abb. 3.8. Ingenieure und „Künstler“ im Duett

• Logische Verzweigungen müssen alle möglichen Fälle abdecken; jeder einzelne Fall muss zu definierten Zuständen bzw. Ergebnissen führen. • Nur solcher Softwarecode, der auch tatsächlich verwendet wird, darf im Code verbleiben, ebenso ist redundanter Code nicht zulässig. Um dieses Ziel40 möglichst effektiv erreichen zu können, ist es notwendig dem eher als fabrikmäßig zu bezeichnenden Softwarebau eine explizite Phase künstlerischen Arbeitens vorzuschalten, in welcher die eigentliche Modellwelt definiert wird41. Nur so kann die nicht-kartesische Realität hinreichend verstanden, ausreichend genau abgegrenzt und in eine kartesische Modellwelt überführt werden. Um diesen Teil der Arbeit erfolgreich leisten zu können, müssen die folgenden Fragen beantwortet sein: • Wie vollständig wurde die Wirklichkeit verstanden und abgebildet? • Wie gut konnte sie durch die gewählte Modellwelt angenähert werden? • Wie geeignet ist das verwendete Modell an sich für eine spätere Lösungsumsetzung? 40

41

Mit dieser Aussage wird in erster Linie Bezug genommen auf den (Neu-)bau von komplexer Software. Die Definition einer solchen Modellwelt ist nicht mit der „Modellierung“ gleichzusetzen, sondern ist dieser vorgelagert.

3.5 Systemisch arbeiten

113

Somit stehen an dieser Stelle nicht mehr Tools und Techniken im Mittelpunkt, sondern solche Eigenschaften, wie sie in Abb. 3.7 (S. 102ff.) zusammengefasst wurden. Nebenbei bemerkt: Die qualitätstechnischen Nachweise dessen zu erbringen, was beschrieben wurde, gehört zu den wirklich anspruchsvollen Aufgaben bei der Erstellung von Software. Erst dann, wenn eine kartesische Darstellung möglich ist, also tatsächlich alle Vorgänge strukturiert42 beschreibbar sind, findet der Wechsel zu dem statt, was heute mit Softwarebau assoziiert wird. Jetzt nämlich stehen in der Tat reproduzierbare Prozesse und entsprechende Werkzeuge im Mittelpunkt, mit denen die tatsächliche Umsetzung aus der Modellwelt in Code erfolgen kann. Diese wiederum ist abhängig von • Vorhandenen/eingesetzten Tools • Praktizierten Methoden • Angewandten Prozessen Lässt man also den Gedanken zu, dass wenigstens an einigen (zentralen) Stellen im Softwarebau mehr erforderlich ist als nur kartesisches Denken, so werden hier eigene Arbeitsweisen gebraucht. Folgerichtig ist es nicht ausreichend, direkt mit der klassischer Modellierung von Prozessen einsteigen zu wollen, da dies bereits eine Abstraktion der Wirklichkeit impliziert und man als Paradigma die jeweils applizierte Modellwelt zugrundelegt. Verloren geht so, was für jedes Modell gilt: • Es ist ein vereinfachtes Abbild der Wirklichkeit. • Wichtiges wird hervorgehoben. • Unwichtiges wird unterdrückt. Die Frage, ob die zugrundeliegenden Vereinfachungen geeignet sind, die Wirklichkeit entsprechend abzubilden, wird nicht mehr gestellt, sobald ein solches Modell ausgewählt worden ist. Stattdessen wird man sich im Zweifelsfall mit „Notbehelfen“ um auftretende Problemzonen herumarbeiten. Für triviale Ansätze ist diese Vorgehensweise meist undramatisch, wenn auch nicht immer einfach. Wenn aber nicht-triviale Systeme ins Spiel kommen, wird die Wirklichkeit a priori in Modelle gezwängt, die möglichweise hierfür nur begrenzt tauglich sind. Die Folge: Erst sehr spät fällt im eigentlichen Produktionsprozess der Software auf, dass bestimmte Aspekte so nicht abbildbar sind oder mühevoll ergänzt werden müssen. Dies kann erheblichen Mehraufwand während der Produktion, aber auch im anschließenden Lifecycle erzeugen. Ebenso kann es schnell qualitätsmindernd wirken, da bestimmte notwendige Funktionalitäten unberücksichtigt bleiben. 42

Eine solch strukturierte Beschreibung kann z. B. durch Businessprozess-Modellierung und/oder Use Cases erfolgen.

4 Hilfsmittel aus der Krise

4.1 Nieder mit den binären Zöpfen Hin und wieder ist es sinnvoll, ein Fragezeichen hinter Dinge zu setzen, die wir schon lange für selbstverständlich nehmen. Bertrand Russell Sie mögen sich beim isolierten Lesen der nächsten Abschnitte möglicherweise fragen, was die nachfolgenden Themen mit Softwareproduktion zu tun haben. Ich möchte Ihnen diese Frage nicht abnehmen, Ihnen allerdings in Anlehnung an Gerald Weinbergs Buch „Are your Lights on“ (Gause and Weinberg 1990, S. 65) eine Denksportaufgabe anbieten: Bitte betrachten Sie hierzu Abb. 4.1 genau und beantworten Sie folgende Frage: „Die Abbildung zeigt ein sehr bekanntes Objekt. Welches ist es?“

Abb. 4.1. Eine Denksportaufgabe

116

4 Hilfsmittel aus der Krise

Ihre Antwort wird vermutlich umgehend da sein und Sie werden denken: „Wie primitiv …“ Wie hätten Sie reagiert, wenn wiederum in Bezug auf Abb. 4.1 die Frage jeweils nur um – sagen wir – ein Wort modifiziert worden wäre, also wenn ich Ihnen die nachfolgende Formulierung angeboten hätte: „Die Abbildung zeigt ein Objekt. Welches ist es?“ Vermutlich hätten Sie in den meisten Fällen immer noch die richtige Antwort gegeben, die Bedenkzeit hätte aber messbar zugenommen. – Wie aber wäre wohl die Antwort ausgefallen, wenn die Frage gelautet hätte: „Die Abbildung zeigt ein sehr wenig bekanntes Objekt. Welches ist es?“ Um es vorwegzunehmen: Studien dieser Art an vielen Probanden mit solchen Fragen belegen, dass neben sehr phantasiereichen Antworten, wie etwa „Hula-Hoop-Reifen“ oder „Spitze eines Füllfederhalters“, eine überraschend große Gruppe der Probanden keine Antwort gab. Auf Nachfrage begründeten sie dies damit, dass sie sich von dieser Fragestellung im Kontext mit den beiden anderen Fragen überfordert gefühlt hätten. – Allen Teilnehmern wurde anschließend noch eine letzte Frage vorgelegt: „Die Abbildung zeigt ein sehr wenig bekanntes Objekt. Denken Sie sich das Abwegigste aus, was dies sein könnte!“ Diese Frage wiederum wurde mit Leichtigkeit von allen beantwortet, weil auf einmal keine Erwartungshaltung mehr da war, etwas falsch oder richtig zu beantworten, jedoch die persönliche Meinung uneingeschränkt gefragt war. Dieses kleine Experiment verdeutlicht, welche Macht in der Sprache und Wortwahl, selbst bei so simplen Dingen wie dem oben gezeigten Objekt liegt. Wirklichkeitssuche

Nicht nur die Wahl der Worte hat einen erheblichen Einfluss auf unsere Interpretation, sondern auch der inhaltliche Problemkontext, in dem wir uns bewegen, prägt den Lösungsraum. Im Sinne des kleinen Eingangs-Experimentes hätten Sie als Neurobiologe sehr viel eher eine Zelle vermutet, während Sie als Techniker sehr viel eher an Objekte gedacht hätten, die Ihrem technischen Arbeitsumfeld entsprechen. Damit verknüpft ist eine zweite Ebene, nämlich das sogenannte Präsentierproblem. Hierunter ist zu verstehen, dass die Wünsche, die z. B. ein Kunde einbringt, nicht notwendigerweise sein eigentliches Problem beschreiben, sondern nur denjenigen Teil, der ihm selbst als Problem auffällt.

4.1 Nieder mit den binären Zöpfen

117

Das dahinterliegende tatsächliche Problem – und hier unterscheidet sich Softwarebau in vielen Fällen von anderen Ingenieurdisziplinen – ist den Betroffenen nicht notwendigerweise in vollem Umfang bewusst, kann aber mit diesem erarbeitet werden, soweit hierfür die notwendigen Kompetenzen vorhanden sind. Insbesondere für gutes Anforderungs-Management ist es daher unerlässlich, nicht nur sklavisch die vermeintlichen Wünsche der Stakeholder aufzunehmen und diese zu sammeln, sondern die eigentlichen Bedürfnisse und somit notwendigen Anforderungen mit dem Kunden zu erarbeiten. Dies wiederum verlangt von denjenigen Personen, die diese aufnehmen, dass sie in der Lage sind, „in die Schuhe“ der Stakeholder zu steigen, aus deren Sicht das Problem wahrzunehmen und hieraus im Dialog auf die entscheidenden Themen zu kommen. – Wie, um es konkret zu machen, werden Sie sonst als IT-Auftragnehmer erfahren, das Ihr Auftraggeber ein Produkt möchte, das quasi betriebssystemneutral arbeitet, wenn er explizit nur zwei Betriebssysteme benannt hat? An diesem Beispiel wird erneut deutlich, dass es eben nicht in erster Linie die noch so genialen Tools sind, die hier zur tatsächlichen Lösung führen, sondern die kommunikative Geschicklichkeit derjenigen, welche die Anforderungen zu ermitteln haben. Nahezu einem Coach gleich besteht die primäre Aufgabe darin, die eigentlichen Fragestellungen im KundenDialog zu finden und gemeinsam die Zielanforderungen zu definieren. Wenn dieser Prozess vorgeschaltet ist, können Anforderungen an ein zukünftiges System bereits auf dieser Stufe erheblich konsistenter und vollständiger festgelegt und dokumentiert werden. Dieser Ansatz – das wurde bereits gesagt – wird sicher nicht für Programme der Größenordnung „Hello world“ notwendig sein, sondern betrifft Themenbereiche, die als nicht-trivial identifiziert wurden (vgl. 103ff.). Geht man allerdings davon aus, dass strukturiertes Wissen und SoftwareEngineering sich immer mehr miteinander verzahnen, so wird diese Vorgehensweise immer notwendiger. Dies hat übrigens einen mehrfachen Charme: Zum einen kann der Softwareproduzent durch diese Vorgehensweise in den meisten Fällen zu einer sehr viel klareren thematischen Abgrenzung gelangen, was die spätere technische Realisierung ungemein vereinfacht (vgl. Hamilton 2006), zum anderen wird darüber hinaus implizit die Kundenbindung gestärkt, da der Kunde sich „abgeholt“ und verstanden fühlt. Kurz: Sie als Lieferant gewinnen in mehrfacher Hinsicht!

118

4 Hilfsmittel aus der Krise

Von der Wirkung der Worte

„Auf Französisch kommen mir Verallgemeinerungen in den Sinn und regen mich zu Straffheit und Vereinfachung an. Im Englischen sieht man den praktischen Sinn; Deutsch neigt dazu, einen eine Tiefe suchen zu lassen, die gar nicht immer da ist. Im Polnischen und Russischen bietet sich die Sprache an, die Gedanken wie Tee ziehen zu lassen, sodass sich die Gedanken immer weiter verdichten. Die slawischen Sprachen neigen zu Nachdenklichkeit, sie sind seelenvoll, umfassend, eher psychologisch als philosophisch, aber nicht so nebulös oder wort-gebunden wie Deutsch, wo sich Worte und Silben verketten. Sie verknüpfen Gedanken, die manchmal gar nicht gut zusammenpassen.“ Stanislaw Ulam, polnischer Mathematiker (1909–1984) Vor über 100 Jahren formulierte der deutsche Philosoph und Linguist Ludwig von Wittgenstein den folgenden Satz: „Durch Worte werden Taten möglich“. Durch das gesprochene oder geschriebene Wort und die daraus gebildeten Sätze treten wir mit anderen in Austausch, aber leiten daraus auch die inhärente Logik unserer Computerprogramme ab. Worum es in diesem Abschnitt geht, lässt sich mit einem Zitat des berühmten Mathematikers Henri Poincaré formulieren: „Mathematik ist die Sprache, in der man keine ungenauen oder verschwommenen Gedanken äußern kann“ – und das gilt implizit auch für die Logikkonstrukte der IT! Allerdings bleibt Poincaré nicht bei dieser Aussage stehen, sondern stellt im Sinne des vorangestellten Zitats des großen polnischen Mathematikers Stanislaw Ulam weiter fest, dass er die Probleme seines Fachs höchst unterschiedlich wahrnähme, je nachdem, ob die Sprache seiner Gedanken Französisch oder Englisch sei. Ein Problemkreis tut sich hier auf, der in vielen Handbüchern über Softwarebau nicht vermerkt ist, geht man doch in aller Regel nur von dem ersten Teil des Poincaré’schen Satzes aus. Hier genau aber beginnen die eigentlichen Schwierigkeiten, die letztendlichen in vielen, vor allem größeren Kultur- bzw. Sprachgrenzen überschreitenden Softwareprojekten plötzlich zum Thema werden! Bereits das kleine Experiment von S. 115 hat die Tatsache verdeutlicht, wie sehr unsere eigene Wortwahl, die Wahl der Formulierung und deren Kontextualisierung Einfluss darauf nimmt, ob und wie der Dialogpartner antworten wird. Wenn schon eine so einfache Situation so weit gefächerte Antworten und Reaktionsmuster liefert, wie viel mehr wird dies bei der fachlichen Erfassung und technischen Beschreibung ganzer Applikationen eine Rolle spielen?

4.1 Nieder mit den binären Zöpfen

119

Die Vorstellung, dass Sprache Ausdrucksmittel reiner Vernunft und Logik sei, mag für manche Größe der Weltgeschichte zutreffen, für den verbleibenden Rest der Menschheit ist davon auszugehen, dass das, was wir ausdrücken, erheblich von dem Kontext geprägt und beeinflusst ist, in welchem es artikuliert wird. 4.1.1

Weiche Worte schaffen harte Fakten Das Aussprechen eines Wortes ist gleichsam ein Anschlagen einer Taste auf dem Vorstellungsklavier. Ludwig Wittgenstein

Gerade Software Engineering hängt in der Interaktion mit den Stakeholdern in sehr hohem Maß von der Fähigkeit der Kommunikation ab. Zum Beispiel: „Habe ich wirklich verstanden, was der Kunde braucht?“; „Kenne ich tatsächlich seine und meine Randbedingungen?“. Auch wenn digitale Hilfsmittel hier eine enorme Unterstützung bieten, um diese Details zu sammeln, zu strukturieren und am Ende sicherzustellen, dass sie entsprechend berücksichtigt werden, so bleibt eines: Nur dann, wenn in den Interaktionen richtig kommuniziert wurde, sind diese Informationen valide und können in richtiger Weise aufgezeichnet werden. – Somit ist klar: moderne Werkzeuge oder Collaborationsplattformen alleine helfen wenig, wenn die Kunst der Kommunikation nicht wirklich beherrscht wird. Das klingt einfach, aber Vorsicht: Kommunikation und die Fähigkeit reden zu können werden gerne auf eine Ebene gesetzt, was definitiv nicht der Fall ist. (Pawlowski 2003) Richtige Kommunikation

Die einzige Möglichkeit, Menschen zu motivieren, ist die Kommunikation. Lee Iacocca, amerik. Automobilmanager Wir schreiben Emails, telefonieren, halten Videokonferenzen und man sagt uns, dass wir im Kommunikationszeitalter leben würden. Das hat seine Berechtigung und Begründung, gleichwohl möchte ich dies ein wenig hinterfragen. Wie groß ist bei dieser Form der „Kommunikation“ der Anteil an „Daten- und Faktenaustausch“, vielleicht auch des Monologisierens, und wie gering wohl der Anteil echter bilateraler Verständigung? Im arabischen Raum gab es die Tradition der Erzähler (Peseschkian 1979) und die weit verbreitete Fähigkeit diesem so gut zuzuhören, dass man nach einiger

120

4 Hilfsmittel aus der Krise

Zeit wortwörtlich das wiedergeben konnte, was der Erzähler berichtet hatte. Über Generationen hinweg wurden auf diesem Weg Texte wortgenau übermittelt. Diese Tradition liegt weit vor unserer Epoche, dennoch gibt es Aspekte, die in dieser zunehmend komplexeren und vor allem serviceorientierten Zeit immer wichtiger werden. Viele Zeitgenossen in- und außerhalb der IT agieren gerne in der Weise, dass sie von ihrem Stakeholder einige wenige Sätze aufschnappen, diese in eine bereits vorgefertigte Schablone stecken und danach das so Aufgenommene für sich weiter verwerten, ohne im eigentlichen Sinne dem Gegenüber noch die ganze Aufmerksamkeit zu schenken. Es ist interessant, dass gerade jüngste Erkenntnisse aus der Gehirnforschung unterstreichen, was erfahrene Projektmanager schon längst beobachtet haben: Über Mimik und Gestik wird ein ganz erhebliches Maß an Information ausgetauscht. Fehlt diese Information, werden Projekte oftmals zum Krampf und Kampf, da es fast nicht mehr möglich ist zwischen Sein und Schein zu unterscheiden. Wie anders als durch eigene Wahrnehmung können sonst Schwachstellen oder Problemzonen im Projektalltag wahrgenommen und in den Griff bekommen werden? Gerade die Gestik wurde innerhalb der Kommunikation lange unterschätzt. Inzwischen, so belegen aktuelle Berichte (Wachsmuth 2006), zeigt sich aber, wie hoch der kommunikatorische Anteil über die Körpersprache ist. Forscher gehen dabei von der Tatsache aus, dass die körperlichen Gesten mehr als nur ein nettes Beiwerk zur Gesamtkommunikation darstellen. Fragen Sie sich einmal selbst, wie Sie Dinge beschreiben würden, für die Ihnen die Worte ausgehen – vermutlich werden Sie unter Einsatz Ihres gesamten Körpers die entsprechende Botschaft zu vermitteln suchen. Hier sei nur an die Beschreibung einer simplen Wendeltreppe zu denken für jemanden, der so etwas noch nie gesehen hat. Wie viel mehr wird dies erst gelten, wenn die Rede von sehr viel abstrakteren Dingen ist, die nur noch in unserer Gedankenwelt Raum finden. Paul Watzlawick drückte es einmal so aus: Wir können nicht nicht kommunizieren. Damit wird Sprache einerseits zum individuellen Daumenabdruck des jeweiligen Menschen, zugleich aber auch zu dessen Performanzfaktor: Sie hilft uns andere besser zu verstehen, Sachzusammenhänge zu beschreiben und Lösungen zu formulieren. Sie ist dabei Brücke und Zugang zu den betroffenen Personen, hilft – wenn richtig eingesetzt – Missverständnisse aus dem Weg zu räumen und kompetente Lösungen zu umschreiben. Dabei wird die Machbarkeit dessen, was jemand wünscht, anstrebt oder entscheidet, durch dessen Sprechweise ermöglicht oder auch verunmöglicht.

4.1 Nieder mit den binären Zöpfen

121

Von dieser Warte betrachtet überrascht es nicht länger, dass Emails – oder genauer gesagt: deren Inhalte – mit der Fragestellung „Komplexität im Softwarebau“ einiges zu tun haben, sind sie doch schlechthin das Arbeitspferd der ganzen Projektorganisation, über welche ein Großteil der Informationen ausgetauscht wird. Wo immer Arbeiten über mehr als einen Raum hinausgehen, also in größeren Einheiten, mehr aber noch, wenn standortübergreifend gearbeitet wird oder sogar Off- oder Nearshoring ins Spiel kommen, wird das Leben durch Emails zwar erheblich schneller, jedoch nicht einfacher. Wird Sprache richtig eingesetzt, so kann Kommunikation gezielt dazu verwandt werden, um eine Win-Win-Situation (Fuller 2000) herzustellen und so zu effektiven und für alle befriedigenden Lösungen zu gelangen. Diese Vorgehensweise ist dort, wo es um Verhandlungen geht, vielen vertraut, gilt aber für den technischen Bereich in gleicher Weise, sobald verinnerlicht wurde, dass es reine Sachdiskussionen nicht wirklich gibt! Wenn sich also der Kunde oder – allgemeiner – Stakeholder in seinen Problemen nicht nur fachlich-technisch verstanden sieht, sondern wahrnimmt, dass er mit seinen Anliegen ernst genommen wird und man gemeinsam an einer für Auftraggeber und -nehmer optimalen Lösung arbeitet, so ist hier ein wichtiger Teilsieg errungen! Eine solche Situation ist kein Zufallsprodukt, sondern erfordert, dass die entsprechenden fachlichen Mitarbeiter entsprechend ausgebildet sind, um den Kunden hier entsprechend „abholen“ zu können. Dieses Abholen braucht allerdings ausreichend Zeit. Insbesondere bei größeren und komplexeren Softwareprojekten hängt die Qualität der geleisteten Arbeit zu einem erheblichen Teil an der aktiven Kooperation der beteiligten Gruppen. Gerade das Vieraugen-Prinzip im agilen Softwarebau, bei dem Entwickler und nach Möglichkeit Kunde direkt vor dem Bildschirm kooperieren, belegt dies deutlich. Dabei spielen – auch bei Technikern – die ersten Eindrücke vom anderen eine zentrale Rolle und so gilt auch hier die Drei-Sekunden-Regel. Sie besagt, dass die ersten drei Sekunden einer neuen Begegnung wesentlich über den Antipathie- bzw. Sympathiefaktor entscheiden. Die gerne getätigte Aussage mancher Manager: „Arbeiten Sie als Professionals zusammen“ wird hier zur Farce. Warum? Weil diejenigen, die ein solches Projekt letztendlich umsetzen – also auf der Arbeitsebene miteinander zu tun haben –, in erheblich stärkerem Maße auf die störungsfreie Zusammenarbeit angewiesen sind. Letztendlich lässt sich aus der Individualpsychologie eine wichtige Erkenntnis ableiten: Sachprobleme sind einfach lösbar, wenn es keine vorgelagerten Beziehungsprobleme gibt.

122

4.1.2

4 Hilfsmittel aus der Krise

Kommunizieren – eine Kunst! Die meisten fragen, um herauszubekommen, was eine Person nicht weiß; während die wahre Fragekunst sich darauf richtet, zu ermitteln, was der andere weiß oder zu wissen fähig ist. Albert Einstein

Über Kommunikation an sich ist viel geschrieben worden (Schulz von Thun 1981, und andere) – zählt sie doch zu den Schlüsselkompetenzen schlechthin. Bezogen auf die IT und die Vernetztheit datenverarbeitender Maschinen wird dieser Begriff allerdings zum Synonym von Informationsaustausch per Email, Datenbankeintrag, Trackingtool oder Collaborationsoftware reduziert. Könnte es sein, dass wir hier zwar über Kommunikationsmittel sprechen, nicht aber über die Art der notwendigen Kommunikation? Im Gegensatz zur technisch definierten Kommunikation, in der es um den Austausch von Informationen zwischen zwei technischen Geräten mit Hilfe definierter Protokolle geht, gibt es bei interpersoneller Kommunikation die drei folgenden Schwerpunkte (von Schlippe/Schweitzer 2003): • Gesprächsführung • aktives Zuhören • richtiges Fragen Sind dies Fähigkeiten, die Ihre Mitarbeiter beherrschen – oder leben Sie in einer Art postkommunikativem Zeitalter, welches davon geprägt ist, riesige Mengen an Daten in bestimmte Schemata und Tabellen zu übertragen und diese dann mit anderen auf digitalem Wege auszutauschen? Liegt hier womöglich eine weitere Ursache dafür, warum Softwarebau – trotz hohem Mitteleinsatz – oftmals so ineffizient ist? Immerhin: Sowohl die Kunst des Zuhörens, wie auch diejenige des Fragens sind fast so alt wie die Menschheit selbst. Gleichwohl ist sie in unserem multimedialen Zeitalter bei vielen Zeitgenossen, trotz einer Vielzahl von Kommunikationskanälen, nur als „Light“-Version im Einsatz. Zuhören, ebenso wie richtige Fragen zu stellen, will gelernt sein, genauso wie die Bewertung dessen, was wahrgenommen wurde. Wie würden sich wohl die Ergebnisse im Softwarebau verbessern, wenn diese Sparte Anleihen bei solchen Berufsgruppen machen würde, die seit langem viel Übung und Praxiswissen gerade hier nachzuweisen haben? Könnte es sein, das z. B. Coaches oder Therapeuten hier über die notwendigen Methodiken verfügen? Mit zunehmender Komplexität der informationstechnischen Fragestellungen wird es immer notwendiger, genau hier Arbeitsweisen zu übernehmen, um hinreichend tragfähige Antworten zu erhalten. Gleichwohl ist die Anwendung dieser Hilfsmittel in der vor allem ingenieur-techniklastigen IT-Welt bisher wenig verbreitet (Rupp 2003).

4.1 Nieder mit den binären Zöpfen

123

Oder um es praxisnah zu formulieren: Wie wollen Sie, sei es aus der Rolle eines IT-Architekten oder eines Anforderungs-Spezialisten heraus, immer komplexere Software für Kunden erfassen, definieren, planen und bauen, wenn Sie nicht zuvor diesem die richtigen Fragen gestellt haben bzw. nicht mitbekommen haben, was der Kunde eigentlich zur Lösung seiner (technischen) Probleme gebraucht hätte. Was Sprache leistet

Wenn jemand etwas tut, so hat er zwei Gründe dafür: einen guten Grund und einen wirklichen Grund. John Pierpont Morgan, amerikanischer Banker Wenn von Kommunikation die Rede ist, so geht es hier vor allem um sprachliche Kommunikation. Dabei ist unsere Sprache keineswegs eindeutig und täuschungsfrei, wie es z. B. bei Formeln oder technischen Zeichnungen der Fall ist. Leicht können wir ihr daher auf den Leim gehen, in die Irre geführt, getäuscht oder mit falschen Tatsachen konfrontiert wurden (Latour 2005, S. 44ff.). Wir reden miteinander, um zu informieren, was richtig und was falsch ist, oder um Fakten zu vermitteln. Dabei geht es um objektivierbare Informationen, an deren Richtigkeit es nichts zu zweifeln gibt. Wenn z. B. gesagt wird, dass ein Bildschirmelement die Farbe „Rot“ habe, dann wird durch diese Aussage der entsprechende Sachverhalt vermutlich ziemlich genau wiedergegeben – es sei denn, dass dieser Aussage widersprochen wird. Dieser Anspruch an Sprache wird im Softwarebau oft unbewusst gestellt, da dies genau die Art und Weise ist, wie „Programmiersprachen“ aufgebaut sind. Anders als bei Computerprogrammen tauschen Menschen jedoch nicht nur faktische Informationen miteinander aus, sondern handeln mit Hilfe der Sprache auch voneinander divergierende Sichtweisen miteinander aus, gleichen diese ggf. miteinander ab oder vermitteln hierüber unsere soziale Stellung zueinander. Sprache gibt also nicht nur Fakten weiter, sondern leistet erheblich mehr! Wenn etwa die Rede von Fabelwesen, Fantasien oder auch zukünftigen Softwareprodukten ist, Dingen also, die es zunächst nur in der gedanklichen Vorstellungswelt gibt, dann werden die gewählten Worte jeweils eigene Realitäten umschreiben, die selbst für diejenige Person, die sie ausspricht, nur in Grenzen definiert sind. So wird z. B. Ihre Vorstellung von „perfekter Software“ vermutlich deutlich von meiner Vorstellung abweichen. Trotzdem kann es sein, dass wir uns bei einer gemeinsamen Abstimmung darauf geeinigt haben, gemeinsam genau so etwas haben zu wollen, obschon wir nicht einmal voneinander wissen, was dies konkret bedeutet.

124

4 Hilfsmittel aus der Krise

– Was aber bedeutet dies für den Softwarebau an sich? Ist nicht z. B. das Erfassen von Anforderungen nichts anderes als der Spaziergang auf der Grenzlinie zwischen dem, was fiktiv ist, und dem, was Wirklichkeit werden soll, von dem, was Stakeholder sagen, und dem, was sie damit verbinden? Und liegt nicht genau hier die wahre Meisterschaft derjenigen, die Anforderungen zusammentragen? Die Kunst zu beherrschen, das Weltbild der Kunden/ Stakeholder (in Bezug auf das Produkt) möglichst vollständig herauszuarbeiten und dann in geeigneter Weise Sinnvolles von Unsinnigem, Notwendiges von Wünschenswertem und Fiktives von Wirklichem zu trennen – keine leichte Aufgabe für solche Zeitgenossen, die nur die reine Faktenebene vor Augen haben. Analyse eines Dialogs

Mit diesen Vorbemerkungen möchte ich als Nächstes einen Blick auf die Kommunikation an sich werfen und das betrachten, was bei einem sachlichen Austausch zwischen zwei Personen stattfindet. In Abb. 4.2 sind die wichtigsten Aspekte sprachlicher Kommunikation zusammengefasst. Ein wichtiges Hilfsmittel bildet hierbei das sog. Johari-Fenster. Es ist ein grafisches Schema zur Darstellung bewusster und unbewusster Persönlichkeitsund Verhaltensmerkmale. Entwickelt wurde es 1955 von den amerikani-

Abb. 4.2. Personelle Interaktion – Schlüssel zum Verständnis

4.1 Nieder mit den binären Zöpfen

125

schen Sozialpsychologen Joseph Luft und Harry Ingham. Mit Hilfe des Johari-Fensters wird vor allem der so genannte blinde Fleck im Selbstbild eines Menschen illustriert. Mit Hilfe des Johari-Fensters gilt dabei für jeden der beteiligten Personen, dass der Kontext, aus dem er selber denkt, redet und handelt, anders ist als derjenige, dessen er sich bewusst ist. Daraus ergeben sich im Sinne der Quadranten-Darstellung in Abb. 4.2 jeweils die folgenden vier Bereiche: Freies Handeln: Dieser Bereich beschreibt die nach außen hin sichtbare, also öffentliche Person. Dieser Bereich ist einem selbst sowie anderen bekannt. Es ist der Bereich freier Aktivitäten, öffentlicher Sachverhalte sowie harter Fakten. Blinder Fleck: Hierbei handelt es sich um den blinden Fleck der Selbstwahrnehmung. Dieser Bereich beherbergt den Anteil des Verhaltens, den man selbst wenig, andere aber sehr wohl wahrnehmen. Verborgener Bereich: Hier handelt es sich um den Bereich der privaten Person. Nur der eigenen Person sind diese Aspekte bekannt. Diese Teile des Handeln und Denkens werden vor allen anderen ganz bewusst verborgen gehalten. Unbewusster Bereich: Dieser Bereich ist weder der eigenen Person, noch anderen zugänglich. Hier können verborgene Talente und Begabungen schlummern. Auch im Softwarebau findet kein reiner Austausch von Fakten und Zahlen statt. Die Wirklichkeit sieht oft anders aus. Verfügen die betroffenen Mitarbeiter über die Kompetenz dies zu erkennen und professionell damit umzugehen? Nehmen Sie als ein simples Beispiel die folgende Debatte, bei der mehrere Fachleute aus derselben beruflichen Sparte versuchen, ein und denselben technischen Prozess zu beschreiben. Es braucht Stunden, man redet sich die Köpfe heiß und man kann sich nicht einigen – bis letztendlich die Erkenntnis kommt, dass man zwar über dasselbe Sachgebiet redet und dieselben Begriffe benutzt, aber keineswegs dieselben Begriffe mit denselben Bedeutungen belegt hat. Komplizierter wird dieser Sachverhalt, wenn Sie z. B. im internationalen Kontext operieren und zum einen der Dialog nicht in der eigenen Muttersprache geführt wird und zum anderen die Begriffe unterschiedlich lauten bzw. mit unterschiedlichen Definitionen belegt sind. – Ein Beispiel aus der Praxis macht deutlich, worum es geht: Nehmen Sie z. B. die Definition des Begriffes „Brennstoffverbrauch“ verschiedener renommierter Fluggesellschaften, so werden Sie nach kurzer Zeit feststellen,

126

4 Hilfsmittel aus der Krise

dass dieser Begriff nicht nur unterschiedliche Namen trägt, sondern auch aufgrund unterschiedlicher nationaler Gegebenheiten jeweils verschieden definiert ist. Wenn nun zwei Personen miteinander, etwa bei der Erfassung von Anforderungen, von „Brennstoffverbrauch“ sprechen, um hieraus eine technische Spezifikation vorzubereiten, so benutzen beide denselben Begriff, verbinden damit jedoch voneinander abweichende Sachverhalte. Für den Fall, dass hier Software gebaut wird, die z. B. den Brennstoffverbrauch von Flugzeugen erfassen soll, so hätte dies die fatale Folge, dass die Software nicht für alle Beteiligten richtig wäre, obschon bei der Planung die beteiligten Personen mit denselben Begriffen operiert haben. Zugegeben: Dies ist ein recht extremes Beispiel, verdeutlicht aber die Gesamtproblematik begrifflicher Definitionen, die nicht im notwendigen Maß mit anderen Beteiligten abgeglichen und dann hinterlegt wurden. In diesem Sinne verstanden ist es lobenswert, dass viele IT-Projekte Glossare verwenden, in denen entsprechende Begrifflichkeiten und deren Definition hinterlegt werden können. – Allerdings: wenn die beteiligten Mitarbeiter keine Strategie haben, wie sie auf Begriffe stoßen, die „glossarwürdig“ sind, diese nicht wohldefiniert dort hinterlegen und es nicht Teil der eigenen Vorgehenskultur geworden ist, die einmal festgelegten Definitionen aktiv zu nutzen, so haben Sie nicht mehr als eine Art Feigenblatt geschaffen, nicht aber das eigentliche Problem gelöst! Die Folge: zwischenmenschliche Projektkommunikation wird zum direkten Einflussfaktor auf das spätere Gesamtprodukt, egal ob Sie die gewonnenen Erkenntnisse nach Altväter Sitte oder in hochmodernen Tools aufzeichnen, da die Frage nach dem, was aufzuzeichnen ist und wie diese Informationen möglichst effektiv gewonnen werden können, nicht in erster Linie an die gewählten Werkzeuge gekoppelt ist! Dass wir uns in einem Gespräch mit jemandem über etwas verständigen, ist nicht selbstverständlich. Jeder von uns nimmt das, was der andere sagt, durch seinen eigenen Wahrnehmungsfilter wahr, versteht und interpretiert es nach seinen persönlichen Möglichkeiten und Interessen. Dieser Filter setzt sich aus unserem Sachwissen, unseren Einstellungen und Wertungen, unseren Sprach- und Hörmustern, unserer augenblicklichen Befindlichkeit, aber auch unserer Fähigkeit zu reflektieren zusammen. Was der eine meint und sagt, ist vermutlich nie genau das, was der andere versteht. Ein Gespräch ist somit immer ein Prozess des Suchens nach gemeinsamer Sprache und nach Übereinstimmungen und führt oft an Klippen des Missverstehens vorbei. Das ist ein Grund dafür, dass wir den Verlauf eines Gesprächs zwar bis zu einem gewissen Grade planen, niemals aber genau vorhersehen können. In Anlehnung an die Gesprächstheorie lassen sich Gesprächstypen, wie sie in unserem Kontext in Frage kommen, wie folgt unterscheiden:

4.1 Nieder mit den binären Zöpfen

127

Öffentliches Gespräch: Hierbei reden Dialogpartner als Träger von sozialen Rollen miteinander, etwa als Chef, Kollege, Entwickler oder Kunde. Privates Gespräch: Dieses steht im Gegensatz dazu, da die Gesprächspartner aus ihren Rollen aussteigen und sich als Individuen begegnen, die sich über ihre individuellen Bedürfnisse und Interessen austauschen. Ein Blick auf den realen Softwarealltag bringt hier übrigens ein interessantes Phänomen zum Vorschein. Im Kontext von quasi privaten Gesprächen findet oft eine Vorklärung oder gar Lösung von Krisensituationen statt: Man steigt aus der eigenen Rolle, man begegnet sich auf Augenhöhe ohne Rolle und man sucht von Mensch zu Mensch – und nicht von Rolle zu Rolle – eine gemeinsam tragbare Lösung. Dies setzt allerdings voraus, dass die „Chemie“ stimmt, also bereits eine Atmosphäre der gegenseitigen Wertschätzung aufgebaut wurde und die Vorrollen auf ähnlichem Niveau liegen. Eine weitere sinnvolle Klassifizierung bezieht sich auf symmetrische bzw. komplementäre Gespräche. Symmetrische Gespräche: Hier hat jeder Partner prinzipiell die gleichen Handlungsmöglichkeiten. Er kann und darf fragen, Fragen zurückweisen, auffordern, sich weigern, behaupten bzw. Behauptungen in Frage stellen. Dies ist die Ausgangsbasis für Informations- und Planungsgespräche, deren Ziel darin besteht, dass Informationsaustausch stattfindet bzw. eine gemeinsame Handlungsbasis erarbeitet wird. Allerdings – und das leitet sich ebenfalls aus Abb. 4.2 ab –, wenn gegenseitiges Vertrauen und Akzeptanz nicht wenigstens minimal vertreten sind, dann können solche Gespräche leicht für eine eigene, dem anderen verborgene Agenda missbraucht werden. Man führt scheinbare Sachgespräche miteinander, aber versucht dabei den anderen oftmals recht subtil auf den Pfad der eigenen Vorstellungen und Überzeugungen zu ziehen. Verkaufsverhandlungen, aber auch das Festlegen von Anforderungen sind hier im Kontext von Softwarebau zwei außergewöhnlich gute Beispiele, da es in beiden Fällen schnell um sehr viel Geld bzw. zu erbringende Leistung geht. Komplementäre Gespräche: Anders sieht es bei dieser Gesprächsform aus. Hier haben die Dialogpartner unterschiedliche Handlungsmöglichkeiten, die sich z. B. aus einer unterschiedlichen Hierarchiestufe oder unterschiedlicher Kenntnis ableiten. Dies drückt sich z. B. in solchen Gesprächsformen aus, in denen der eine das Recht hat, Fragen zu stellen, und von dem anderen erwartet wird, diese zu beantworten. – Dabei kann es sich um Situationen wie etwa bei Audits etc. handeln. Ein anderes Beispiel sind hierarchiebedingte Gespräche: Der eine hat das Recht, Anweisungen oder Befehle zu erteilen, während der andere diesen Folge zu leisten hat.

128

4 Hilfsmittel aus der Krise

Abb. 4.3. Symmetrisch-komplementäre Beziehungsnetzwerke

Auch hier gibt es wiederum einen sehr wichtigen Praxisbezug. Effektiver Softwarebau lebt erheblich von echter Teamarbeit (Hamilton 2006, S. 179ff.), also vorwiegend symmetrisch gestalteten Gesprächen (vgl. Abb. 4.3). Ist der Leiter einer solchen Truppe wirklich in der Lage, den Mitarbeitern eigene Sichten und Diskussionen zu gestatten (= symmetrisch) oder macht er seine Sicht zum Maßstab aller Dinge und erwartet deren Umsetzung (= komplementär)? Gerade solche Personen in Führungsrollen, die aufgrund ihrer hierarchischen Position durch komplementäre Vorgehensweisen ihre Meinungen in Projekten durchsetzen, stellen ein sehr hohes Projektrisiko dar, weil hier Position und Fachkompetenz miteinander in ungesunder Weise vermischt werden. Interessant und zugleich wichtig ist übrigens in diesem Zusammenhang die Betrachtung, wie sich das Ganze zwischen Kunden und Lieferant gestaltet (vereinfacht dargestellt). Im oberen Bereich befinden sich die Mitarbeiter der Kunden-Organisation, im unteren Bereich diejenigen der Entwicklungs-Organisation. Die Beziehung der jeweiligen Mitarbeiter zum betreffenden Manager ist aufgrund der Hierarchie komplementär, diejenige zwischen den Managern unter sich bzw. den Mitarbeitern unter sich sollte im Idealfall symmetrisch sein. Dies stellt eine wichtige Voraussetzung für einen effizienten Wissensabgleich gerade im Kontext der Erfassungen von Anforderungen dar!

4.1 Nieder mit den binären Zöpfen

4.1.3

129

Mäeutik – oder die Kunst zu fragen Die Sprache wurde dazu erfunden, um Fragen zu stellen. Die Geburtsstunde der Menschheit war gekommen, als der Mensch seine erste Frage stellte. Stillstand rührt nicht von mangelnden Antworten her, sondern von der mangelnden Fähigkeit, Fragen zu stellen. Eric Hofer

Mäeutik (griech. Hebammenkunst) nennt man die Methode der Wahrheitsfindung, wie sie Sokrates vorschlug. Seine Kunst bestand darin, dass mit Hilfe geschickt gestellter Fragen und der erhaltenen Antworten der Gesprächspartner zu wahrem Wissen geführt werden sollte. Für Sokrates gab es hierbei die Methode der Ironie (= den Gesprächspartner in Widersprüche verwickeln), die Methode der Induktion (= nach Alltagsbeispielen fragen), sowie die Methode der Definition (= definitorische Festlegung bzw. Einordnung des Gesagten). Diese drei Methoden mögen im Bereich Softwarebau nicht unbedingt zielführend sein; was aber seine Gültigkeit behalten hat ist die Tatsache, dass durch geschicktes Fragen der Lösungsraum für die kommende Applikation sehr viel besser präzisiert werden kann. Dies gilt umso mehr, als Software an sich der klassischen Logik folgt, im Prozess der Informationserhebung jedoch häufig eine eher modale Logik zu finden ist. Modale Logik statt schwarz-weißem Denken

Lassen Sie mich den Begriff der modalen Logik mit Hilfe der nachfolgenden Geschichte zunächst einführen: Drei Weise treffen sich vor ihrem Herrn, um ihre Weisheit unter Beweis zu stellen. Die Aufgabe, die ihnen gestellt wird, ist einfach: der Herrscher hat drei völlig gleich gestaltete Trinkgefäße, die entweder hell oder dunkel sind, wobei bekannt ist, dass mindestens ein dunkles Gefäß dabei ist. Ohne dass diese für alle sichtbar sind, lässt der Regent hinter jeden der im Kreis stehenden Weisen eines dieser drei Gerätschaften so platzieren, dass das jeweils eigene Gefäß nur von den anderen gesehen werden kann, nicht aber von der Person, hinter der es sich befindet. – Der König möchte nun wissen, welches Gefäß hinter jedem Einzelnen steht, ohne dass sich die drei Männer beratschlagen oder austauschen dürfen. Der erste Weise erklärt nach Betrachtung der beiden für ihn sichtbaren Objekte, dass er es nicht wisse, ebenso geht es dem zweiten. – Nachdem der Dritte sich diese beiden Aussagen angehört und darüber nachgesonnen hat, kommt er zu einem klaren Ergebnis: „Ich weiß dass sich hinter mir ein dunkles Gefäß befindet.“ – Die Frage lautet nun: Mit welcher Art von Logik konnte diese dritte Person das Problem lösen?

130

4 Hilfsmittel aus der Krise

Was uns hier begegnet ist eine Spielart der Logik, die zunächst so gar nicht zu unseren TRUE-FALSE-gesteuerten Denkmodellen zu passen scheint. Trotzdem – und das macht diesen Bereich gerade für das Software Engineering so wichtig – handelt es sich hier um eine Betrachtungsform, bei der zwei weitere logische Zustände ergänzend eingeführt werden. Im Ansatz der Modallogik sind neben „falsch“ und „richtig“ zwei weitere Zustände definiert, nämlich der Zustand „möglich“ sowie der Zustand „notwendig“. Somit lassen sich in diesem logischen Denkmodell nicht nur Aussagen formulieren wie „der Kreis ist rund“ oder „Diese Aufgabe kann als Use Case abgebildet werden“, sondern auch solche im Sinne von „Normalerweise ist diese Aufgabe als Use Case abbildbar“ oder „Notwendigerweise ist ein Kreis rund“. Um dies zu ermitteln und anschließend hinreichend genau abgrenzen zu können sind Fragetechniken, wie sie aus dem systemischen Umfeld angeboten werden, das Mittel der Wahl. Fragen, Fragen, nichts als Fragen

Die Kunst zu fragen ist nicht so leicht als man denkt; es ist weit mehr die Kunst des Meisters als die des Schülers. Man muss viel gelernt haben, um über das, was man nicht weiß, fragen zu können. Jean-Jacques Rousseau (1712–1778) Wenn Fragen als ein zentrales Handwerkszeug für den Bereich der Softwareplanung zu betrachten sind, dann gilt es zu klären, was sie zu leisten haben, welche Bereiche sie abdecken sollen und von welcher Qualität sie zu sein haben. Dies gilt umso mehr, als es nicht damit getan ist, nur an der richtigen Stelle eines Templates ein Kreuzchen als Antwort auf die jeweilige Frage zu platzieren, um so entsprechend einer Bestellliste festzulegen, was man gerne haben möchte und was nicht. Fragen in dem hier betrachteten Kontext heißt, sich selbst und den Befragten dabei zu helfen, bis zur eigentlichen Problemstellung durchzudringen, und nicht an dem Wunsch nach einem Softwareprogramm mit rosa Knöpfchen und universellen Fähigkeiten stehen zu bleiben. Dazu einige Vorbemerkungen, ehe ich diesen Bereich konkreter beleuchte: 1. Da es in der Natur solcher Fragen liegt, das Gehirn zu neuer Denkleistung anzuspornen, braucht sowohl die Findung/Vorbereitung solcher Fragen durch den Fragenden, wie auch deren Beantwortung Zeit. Fehlt sie auf der einen oder anderen Seite, so werden höchstwahrscheinlich die gewünschten Ergebnisse nicht eintreten. – Es ist das erklärte Ziel dieser Fragen, Zukünftiges – also z. B. eine in Planung befindliche Soft-

4.1 Nieder mit den binären Zöpfen

131

ware – bereits in eben dieser Planungsphase zu optimieren, und damit auch auf eine Position in der Zukunft gerichtet zu sein. 2. Diese Fragen sind nicht dazu bestimmt, auf suggestive Art und Weise zu klären, ob jemand die eigene Meinung vertritt oder in bestimmten Punkten Recht hat. Je mehr Spielraum der Befragte in der Gestaltung seiner Antworten erhält, umso mehr kann durch diese Frage/Antwort-Technik gewonnen werden. Somit ist klar: Geschlossene Fragen, die vom Befragten nur eine JA- oder NEIN-Antwort verlangen, sind hier nicht sonderlich glücklich gewählt, da sie dem anderen keinen wirklichen Gestaltungsspielraum für seine Antwort lassen. Eine Frage im Stil von „Möchten Sie LINUX als Betriebssystem?“ liefert zwar gezielte Informationen, verhindert aber zugleich auch, dass andere Optionen bedacht werden (z. B. andere Betriebssysteme). 3. Es geht nicht darum, dass Befragte anfangen ihre „Weihnachtswunschlisten“ auszupacken – was ja gerade bei der Erfassung von Anforderungen äußerst beliebt ist! Statt also zu fragen, was „man“ alles in der neuen Applikation brauche, kann die sprachlich kleine Nuancierung im Sinne von: „Wenn Sie die Verantwortung für das neue Produkt hätten, was müsste alles darin vorhanden sein …“ sehr viel klarere Ergebnisse liefern. Im ersten Fall liefert der Befragte eine lose Folge von Wünschen, während er im zweiten Fall diese Wünsche mit einer Rollensicht assoziiert! 4. Wie bereits gezeigt, kann kein System – auch kein neu zu bauendes technisches System – isoliert betrachtet werden, sondern steht immer im Bezugsrahmen seines Umfeldes (vgl. S. 89ff.). Dies können das Entwicklungsteam, die betroffenen Stakeholder oder technische Abhängigkeiten sein. Somit ist immer wieder zu berücksichtigen, wie vorgeschlagene Lösungen hiermit korrelieren. Um hier konkret zu werden, sind im Folgenden die wichtigsten Fragetypen zusammengestellt und mit Beispielfragen konkretisiert (vgl. auch Braun, Gawlas et al. 2005, S. 114ff.). Offene Fragen: Bei diesem Fragetyp wird das Gegenüber dazu bewegt, über die gestellten Fragen nachzudenken, und muss erheblich langatmiger darauf antworten, z. B.: • Auf welchen Betriebssystemen soll die Software laufen? • Welches werden die künftigen Anwender Ihrer Applikation sein? Dieser Fragetyp ist ideal, wenn Sie ein Spektrum an Antworten ermitteln wollen. Er ist allerdings nicht sonderlich geeignet, wenn Sie einfach nur Checklisten mit Häkchen versehen möchten.

132

4 Hilfsmittel aus der Krise

W-Fragen: Hierbei handelt es sich um Fragen nach dem „Wann“, „Was“, „Wer“, „Wie“, „Wo“. Dieser Fragetyp mit seinen Sonderungsfragen ist ideal um mehr Klarheit über bestimmte Themenbereiche zu erhalten. Etwa: • Warum meinen Sie, dass Sie unbedingt die Datenbank von Hersteller XY brauchen? Differenzierungs-Fragen: Hierbei handelt es sich um Fragen, die eine Abgrenzung bzw. Unterscheidung ermöglichen. Gerade diese Differenzenbildung ist ein sehr effizientes Mittel, um den eigentlichen Problembereich auszuleuchten. Um zu klären, wie sich bestimmte Wirkzusammenhänge definieren, wie Einflussfaktoren abgegrenzt werden können bzw. wie Interessenssphären zu erkennen sind, hilft dieser Fragetypus. Es geht um Fragen im Stile von: • Wer ist innerhalb der eigenen Organisation oder auch beim Kunden gegen dieses Projekt eingestellt – und warum? • Wer hält das neue Projekt für unnötig und aus welchen Gründen? • Was ist der Unterschied zwischen dem Projektstart und jetzt? Was haben Sie schon erreicht? Was wollen Sie noch erreichen? Skalenfragen: Eine Sonderform der Differenzierungsfragen ist die Gruppe der Skalenfragen. Hier wird eine Skala z. B. von 0 bis 10 vorgegeben und damit eine subjektive Einschätzung ermittelt. Dies könnte etwa so aussehen: • Wenn 0 der Fertigstellungsgrund zu Projektbeginn war und 10 das fertige Produkt beschreibt wo stehen Sie gerade jetzt? Und ergänzend hierzu: Was müsste geschehen, damit Sie mit diesem Projekt eine Stufe höher auf dieser Skala kämen? —

Lösungsorientierte Fragen: Üblich ist es, dass wir auf die Probleme schauen, um so zu den Lösungen zu gelangen. Um aber diese Begrenzung linearen Denkens zu umgehen, ist eine andere Fragetechnik sehr hilfreich, nämlich mit Hilfe fiktiver Lösungen auf mögliche nachgelagerte Probleme zu stoßen. Dies könnte dann fragetechnisch betrachtet etwa so aussehen: • Einmal angenommen, dass das kompliziertere Feature XY vollständig implementiert worden wäre und in Betrieb sei, wären dann alle Probleme beseitigt – oder würde es dann weitere Punkte zu bedenken geben? • Einmal angenommen, wir wollten später einmal neben dem jetzt entstehenden Premiumprodukt eine abgespeckte Version anbieten, was würde beim Umbau der Premiumsoftware auf eine Lowcost-Variante zum Problem werden? (Diese Art zu fragen führt in den Bereich des systemischen Fragens und wird dort noch weiter betrachtet werden.)

4.1 Nieder mit den binären Zöpfen

133

Ausnahme-Fragen: Bei diesem Fragetypus geht es darum, Verallgemeinerungen ausfindig zu machen, Abhängigkeiten zu eruieren bzw. Differenzierungen herbeizuführen, z. B.: • War das schon immer so? • Wer hätte eine andere Meinung hierzu? • Welche Ausnahmen wurden beobachtet? Kontextbezogene Fragen: Das Ziel dieser Art zu fragen besteht darin, das Umfeld zu verstehen, Einflussfaktoren zu erkennen und Wirkungsfaktoren zu identifizieren. Ebenso lassen sich so innere und äußere nicht-technische Abhängigkeiten aufspüren. Hier zwei Beispiele für den Bereich der Softwareentwicklung: • Wer hat alles Einfluss auf das Projekt und wie kann sich dies im besten bzw. schlechtesten Fall ausdrücken? • Gibt es in diesem Umfeld Showstopper und wenn ja, was müsste man tun, um diese aus dem Wege zu schaffen? 4.1.4

Fragen für Fortgeschrittene „Wer fragt, ist für fünf Minuten dumm; wer nicht fragt, bleibt ein Leben lang dumm.“ Chinesisches Sprichwort

Die zuletzt präsentierten Fragen helfen bereits effektiv dabei den Lösungsraum abzuklopfen. Vielfach verwenden wir sie in unserem Sprachgebrauch intuitiv, ohne dass wir groß über ihre Systematisierung nachdenken. Mit den zuletzt vorgestellten Fragetypen wurde jedoch ein Bereich betreten, der aus einer Vogelperspektive, also einer Meta-Ebene, auf die eigentliche Thematik schaut. Mit den nachfolgend präsentierten Fragetypen möchte ich diesen Bereich ein wenig mehr ausweiten und zugleich verdeutlichen, wie wichtig die eingangs postulierte Coaching-Kompetenz in solchen Dialogsituationen ist, um in den tatsächlichen Lösungsraum vorzudringen (vgl. Braun, Gawlas et al. 2005, Tomaschek 2006, S. 55ff.). Das Ziel systemisch orientierter Fragen besteht darin, den eigenen Standpunkt verlassen zu können (Möller-Brix 2002, S. 46ff.) und aus der Perspektive einer anderen Person oder einem völlig anderen Blickwinkel (anderer Zeitpunkt, andere Rolle, andere Umstände) das eigentliche Problemfeld zu betrachten und hierdurch zu neuen Erkenntnissen über das Gesamtsystem zu gelangen. Es sind Hilfsmittel, die dabei unterstützen das Unmögliche zu denken – also in diejenigen Bereiche vorzustoßen, die jen-

134

4 Hilfsmittel aus der Krise

seits linearer Zusammenhänge bzw. bereits festgelegter Annahmen liegen. Um dies zu konkretisieren sollen zunächst die allgemeinen Charakteristika systemischer Fragen ein wenig genauer betrachtet und zusammengefasst werden (vgl. Radatz 2004, S. 170ff.). Offene Fragen: Systemische Fragen sind immer offene Fragen, können also nicht direkt mit JA oder NEIN beantwortet werden. Offene Antworten: Die Fragen haben nicht den Charakter, dem Fragenden recht zu geben, sondern lassen die Antwort offen. Auch sind systemische Fragen niemals suggestiv, haben also nicht zum Ziel, eine eigene Antwort oder Lösung dem Befragten „unterzuschieben“. Das gilt in ganz besonderem Maß gerade bei Stakeholder- oder Kundenbefragungen in frühen Planungsphasen des Softwarebaus. In Anlehnung an Heinz von Foerster geht es vor allem darum, mit Hilfe der gewählten Fragen die Handlungsalternativen für den Befragten zu erhöhen. Es geht somit zunächst nicht um die Excludierung43 von Optionen, sondern um die Includierung44 zunächst nicht wahrgenommener Möglichkeiten. Dies wiederum ist gerade im Softwarebau essenziell, da nur so frühzeitig auf Bereiche gestoßen werden kann, die man bisher nicht betrachtet hat und die andernfalls zu Projektende als Wünsche eingebracht werden. Folgendes Beispiel macht den Unterschied bei dieser Art zu fragen deutlich: „Benennen Sie die wichtigsten Features der gewünschten Software“ ist eine einschränkende Fragestellung. Die Frage „welches müssten die Kriterien an Features für die kommende Software sein?“ ist hingegen eine Frageform, die weitere Lösungsbereiche aufschließt. Fragen zum Nachdenken: Statt die Neugier des Fragenden direkt zu stillen (= „Reporterfragen“), wird der Gefragte zunächst zum Denken angeregt (= „Denkfragen“). – Reporterfragen bringen dem Fragenden, nicht aber dem Gefragten neue Erkenntnisse! Meist kann der Befragte eine solche Frage spontan beantworten. (Beispiel: Welche Rolle haben sie in diesem Projekt?) – Anders sieht dies bei den Denkfragen aus! Sie dienen dazu, den Erfahrungshorizont des Befragten zu erweitern, alte Sichtweisen zu verlassen und maßgeschneiderte Lösungen zu finden. Folgen solchen Denkfragen im Anschluss Reporterfragen, z. B. über bestimmte technische Details, so werden die Antworten sehr viel fundierter ausfallen und liefern deutlich bessere Informationen für die Planung! 43

44

Excludierung in diesem Sinne entspricht dem „Housewifery“-Ansatz von S. 108. Includierung in diesem Sinne entspricht eher dem „künstlerischen“ Ansatz von S. 108.

4.1 Nieder mit den binären Zöpfen

135

Innen- und Außenaspekte: Systemisches Fragen unterscheidet zwischen Innen- und Außenaspekten – dabei hat es vor allem die Innenaspekte im Blick. Heinz von Foerster hat diese Aufteilung mit folgendem Satz umschrieben: „Es sind nicht die Dinge, die uns beunruhigen, sondern die Meinungen, die wir von den Dingen haben.“ Daraus ergeben sich für nach „außen“ gerichtete Fragen z. B. gegebene Aspekte, wie jemand etwas bezeichnet oder wie etwas von jemandem erklärt wird. Die nach „innen“ gerichteten Fragen hingegen liegen im Bereich der individuellen Bedeutung, etwa welche typischen Eigenschaften von einer Rolle, einer Person oder auch einer Maschine erwartet werden. Hier wird eine „Meta“-Ebene im Sinne der Kybernetik zweiter Ordnung betreten, bei der es um die angelegten Bewertungsmaßstäbe geht. – Ein kleines Experiment verdeutlicht, worum es bei den Innenaspekten geht: Schritt 1: Schreiben Sie Ihre persönliche Definition eines guten Anforderungserfassers auf. Lesen Sie bitte hier erst weiter, wenn Sie sich diese Punkte aufgeschrieben haben! Schritt 2: Bei genauer Betrachtung des soeben Niedergeschriebenen werden Sie hier Folgendes wiederfinden: Es sind diejenigen Merkmale, die Sie stillschweigend an einen guten Requirements Engineer haben. Ohne dass dieser Ihre ganz persönliche Definition kennt, wird er ständig an genau dieser Meßlatte von Ihnen gemessen werden. Schritt 3: Fragen Sie sich nun einmal, welche Vorstellungen der Requirements Engineer selbst wohl über z. B. einen guten IT-Architekten hat. Vermutlich wird auch hier Ähnliches gelten wie im ersten Teil des kleinen Experiments. An diesem Beispiel wird der Unterschied zwischen Innen (Ihre Definition) und Außen (die erwartete Definition eines anderen) deutlich! Es verdeutlicht ebenso, wie viele Informationen uns verschlossen bleiben und durch persönliche, nicht weiter hinterfragte Annahmen ersetzt werden – was gerade bei der Erfassung von Fakten ein sehr hohes Maß von Vermutungen in ein Projekt bringt! Wenn Sie dieses Experiment gedanklich auf Softwarekunden übertragen, so wird rasch deutlich, wie notwendig es ist, die Innenaspekte der Kunden gut zu kennen und bei der Lösungsplanung zu berücksichtigen. Hier existieren bereits unausgesprochene Messlatten, an denen die Kunden die Qualität des entstehenden Produktes messen werden45. 45

Wie bereits zuvor diskutiert ist dies allerdings nicht der einzige Maßstab für gute Software, wenn auch ein wichtiger Teil.

136

4 Hilfsmittel aus der Krise

Fragen und nochmals Fragen

Bei systemisch orientiertem Fragen besteht ein wichtiges Hilfsmittel darin, sich in die Rolle einer unsichtbaren, aber definierten dritten Person zu begeben und zu versuchen, Dinge aus deren Warte zu beschreiben. Auch bietet es sich immer wieder an, den Befragten in eine solche Position zu bringen, damit er nicht nur die eigene Sichtweise, sondern auch diejenige anderer Stakeholder wiedergibt. Aufgrund der Tatsache, dass wir uns selbst – wie bereits gezeigt (vgl. S. 82ff.) – in einer durch Außenparameter festgelegten Wirklichkeit bewegen, sind genau hier eigene blinde Flecken zu suchen. Ein Ausstieg aus dieser Wirklichkeitswahrnehmung z. B. durch zirkuläre Fragestellungen hilft dabei, solche blinden Flecken zu umgehen und zugleich zu erwirken, dass die eigene subjektive Befangenheit hierdurch stark zurückgedrängt wird. Zirkuläres Fragen: Bei dieser Art zu fragen geht es darum, aus der Sicht eines anderen auf das Problem oder die Situation zu schauen und nachgelagerte Effekte zu bewerten. Diese Frageweise hat Ähnlichkeiten mit lösungsorientierten Fragen, geht aber darüber hinaus, da es hier um die Vorwegnahme der erwarteten Wahrnehmung einer anderen Person geht. Dabei gehört die Technik des zirkulären Fragens zum systemischen Coaching46. Hierzu ein Beispiel: • Gesetzt den Fall, das gerade vorgestellte Feature ist in Ihrer Software fertig gestellt und läuft wunschgemäß, für wie praktikabel würde wohl ein wenig erfahrener Anwender diese Funktion halten? Was fände er wohl gut oder was wäre störend für ihn? Verallgemeinerungs-Fragen: Die Fragetechnik der Verallgemeinerungen ist hier – anders als im klassischen Coaching – in genau entgegengesetzter Weise zu nutzen. Während im Coachingprozess Menschen dazu bewegt werden sollen, hinter ihre eigenen Verallgemeinerungen47 zu schauen, geht 46

47

Systemisches Coaching: Beim systemischen Coaching wird ein System als Ganzes betrachtet. Es geht nicht nur um den Klienten, sondern um das Beziehungsnetzwerk, in welchem er handelt. Gleiches lässt sich methodisch auch auf technische Bereiche übertragen, wo bei Anwendung systemischer Methoden im Mittelpunkt z. B. die Software steht, der Fragenkreis sich aber beispielsweise auf den betroffenen Anwenderkreis bezieht und das, was dort durch das Produkt ausgelöst wird. Ein klassisches Beispiel hierzu ist: Klient: „Mir geht es immer schlecht!“, Coach: „Verstehe ich das richtig: Ihnen geht es in 100% aller Fälle schlecht?“ – Der Klient hat die Chance zu erkennen, dass hier die eigene Wahrnehmung und die Realität voneinander abweichen.

4.1 Nieder mit den binären Zöpfen

137

es im Entwicklungsprozess von Software darum, genau solche Verallgemeinerungen herauszuarbeiten. Dies ist für die technische Realisierung hilfreich, weil hierdurch eine viel konsequentere und allgemeingültigere Modularisierung möglich wird. Ein Beispiel für solch eine Fragestellung: • Sie sind sich absolut sicher, dass diese Funktionalität ausschließlich hier zum Einsatz kommt? Absurde Fragen: Ziel dieser Fragen ist es, das Gegenüber aus seinem Denktrott zu holen und dazu anzuregen, über solche Aspekte bewusst nachzudenken, die aufgrund der eingefahrenen Gleise keine Berücksichtigung fanden. Zwei Beispiele: • Sie haben Ihre Daten bisher über ein Dialogsystem im Stil einer Datenbank eingegeben. Gesetzt den Fall, Sie würden keine klassische Tastatur mehr einsetzen können – wie könnten Sie sich alternativ eine sinnvolle Interaktion mit dem Gerät vorstellen? • Angenommen, wir hätten keine modernen Projekt-Kommunikationstools – wie würden Sie dann den zeitnahen Austausch an Informationen in der notwendigen Qualität sicherstellen? Wunderfragen: Ähnlich den absurden Fragen geht es auch an dieser Stelle darum, eingefahrene Gleise zu verlassen und Problemkreise noch einmal aus einer völlig anderen Perspektive zu beleuchten. Hier ein Beispiel: • Gesetzt den Fall, Ihre Software wäre hyperintelligent, welche Eingaben dürfte dann die Maschine machen und welche würden Sie nach wie vor machen wollen oder müssen? Dissoziationsfragen: Auch dies ist eine Form zirkulären Fragens, allerdings ist dieses Mal nicht der Zukunftsaspekt berücksichtigt, sondern es geht darum, die aktuelle Sichtweise einer anderen Person zu ermitteln und somit zu eruieren, wie Außenstehende einen bestimmten Umstand wohl wahrnehmen. Hier ein paar Beispiele: • Wie würde ein Unbeteiligter Ihre Wünsche formulieren? Was würde er wohl als erstes erwähnen? • Wie würden Sie die Situation aus meiner Perspektive schildern? Was würden Sie dann tun? Was keinesfalls? • Was würde Ihnen jemand raten, der mit dieser Projektsituation nichts zu tun hat? Hypothetische Fragen: Mit Hilfe dieses Fragetypus geht es u. a. darum, den Befragten in eine andere Rolle zu versetzen und hierdurch dessen Per-

138

4 Hilfsmittel aus der Krise

spektive und Wahrnehmung zum gesetzten Thema auszuloten. Fragen hierzu lauten: • Angenommen, Sie wären Projektleiter und ich Ihr Mitarbeiter: Was würden Sie mir raten? • Wie müsste Ihre Traumsoftware aussehen? • Angenommen, Zeit und Geld würden keine Rolle spielen: Was würden Sie dann projekttechnisch tun? Paradoxe Fragen: Um einseitige Sichtweisen zu verlassen, also zu ganzheitlichen Ergebnissen zu gelangen, aber auch gegensätzliche Aspekte analysieren zu können, sind diese Fragen ein probates Hilfsmittel, wie die folgenden Beispiele zeigen: • Was müsste getan werden, damit das Projekt scheitert? • Wenn Sie Ihre Workflows so und so gestalten – wer wird in einigen Jahren am meisten darunter leiden? • Angenommen, Sie würden tatsächlich diese überholte Methodik einsetzen – was wäre das Gute an der Situation? Zukunftsfragen: Um neue Blickwinkel zu entwickeln kann es hilfreich sein einen Schritt in die Zukunft zu wagen, damit die eigene Gegenwartsposition zu verlassen und somit zu neuen Ideen oder Einsichten über das entstehende Produkt zu gelangen. Typische Fragen hierzu sind: • Angenommen, die Software ist so gebaut worden, wie es derzeit geplant ist und wäre bereits im Einsatz. – Wo würden Sie wohl Schwachstellen finden? • Einmal fünf Jahre weitergedacht … was wird Ihre Software dann leisten müssen? • Wenn Sie sich das Feature XY Ihrer kommenden Applikation anschauen und es mit dem Wettbewerb vergleichen, worin liegen dann die Unterschiede bzw. Vorteile? Triadische Fragen: Mit diesen Fragen wird ein äußerst spannender Bereich betreten. Es geht hierbei vor allem darum, die Sichtweisen anderer ins eigene Bewusstsein einzublenden sowie die eigene Wahrnehmung im Hinblick auf Lösungsansätze zu erweitern. Solche Fragen, die zugegebenermaßen im buchstäblichen Sinne um die Ecke gedacht sind, könnten lauten: • Was denkt Ihr IT-Architekt über die Wünsche des Kunden? • Was wird der Geschäftsführer dem Vorstand in Bezug auf das Projekt berichten? • Welche Erwartungen hat der Kunde an die Geschäftsleitung in Bezug auf das Projekt?

4.2 Kreativität, Wissen und Lernen

139

4.2 Kreativität, Wissen und Lernen Kreativität, Wissen und Lernen stellen die Schlüsselfaktoren für wissensintensive Dienstleistungen, also gerade auch den Softwarebau dar. Nur wenn diese Faktoren gezielt in einer Organisation ausgebaut werden, kann hier entsprechend an Wettbewerbsfähigkeit gewonnen werden, wie verschiedene Studien48 auch der Fraunhofer Gesellschaft (Bullinger and Hermann 2000) belegen. Gemäß diesen Untersuchungen liegen die größten Defizite von Unternehmen gerade im Umgang mit Wissen und Kreativität. Es fehlt an einer entsprechenden organisatorischen Verankerung sowie an einer kontinuierlichen Förderung der Kreativität. Ebenso wenig wird technologische Unterstützung kollektiver kreativer Prozesse oder kollektiven Lernens angeboten. 4.2.1

Kreative Softwareproduzenten

Im Oktober 2006 erschien im Magazin „Wirtschaftswoche“ ein Artikel darüber, dass viele der größten Unternehmen die Kreativität für die eigenen Unternehmungen neu entdecken. Nachdem man jahrelang durch möglichst hohe Prozesstreue und Sparen zu konsolidierten Ergebnissen hatte kommen wollen, steht für viele europäische und amerikanische Konzerne dieser Begriff neu im Mittelpunkt des eigenen Handelns. Ziel ist es dabei, sich dem immer schnelleren Innovations-Rhythmus anzupassen und somit dem Wettbewerbsdruck zu begegnen. Sollten Sie sich jetzt fragen, was das mit Softwarebau zu tun hat, wo man doch so hart daran arbeitet, immer mehr Prozesstreue zu gewinnen, so möchte ich Sie hier auf einen interessanten Eintrag ins Guinessbuch der Rekorde hinweisen. Er stammt vom 24. Juli 2006 und wurde durch das Weltunternehmen IBM erreicht. Eingegangen ist es als das größte Brainstorming aller Zeiten, bei dem 140 000 IBM-Mitarbeiter, Angehörige und Kunden aus 75 Ländern an dem 72 Stunden dauernden Kreativmarathon per Internet teilnehmen konnten. IBM veranstaltete diese Kreativoffensive nicht um einen Platz bei Guiness zu finden, sondern um auf diese Weise herauszubekommen, mit welchen Produkten, Dienstleistungen und Geschäftsmodellen Big Blue künftig im globalen Wettbewerb bestehen kann. Innovation hat inzwischen für viele Unternehmen erste Priorität. – Wie aber lassen sich Innovation und Kreativität, die insbesondere Neues und Unbekanntes nutzbringend hervorbringen sollen, mit erfahrungsbasiertem Handeln sinnvoll kombinieren? Gerade in der IT-Branche wird über zu 48

Z.B. LIKE-Projekt aus dem Jahr 2004 (Institute for Human Factors and Technology Management, University of Stuttgart)

140

4 Hilfsmittel aus der Krise

lange Entwicklungszeiten, Schwierigkeiten mit der Koordination bzw. dem Herausfiltern der „richtigen“ Ideen und zugleich mangelndes Wissen über die Kunden oft geklagt. Sind wir auf einmal doch wieder bei der bereits geführten Diskussion gelandet, der zufolge innovativ/kreatives und erfahrungsgetriebenes Handeln in sehr viel aktiverer Weise zusammengeführt werden müssen? Auch im Tagesgeschäft wird Kreativität zum wichtigen Faktor und muss dementsprechend Berücksichtigung finden. Fragen wie die folgenden sind andernfalls nicht zu beantworten: • Wie lassen sich Innovation und schlanke Produktion miteinander sinnvoll verknüpfen? • Wie kann Bewährtes (Best Practices) genutzt, aber nicht zum Bremsklotz für Innovation werden? • Wie können Modellwelten und unstrukturiertes Wissen miteinander verknüpft werden? • Wie kann Softwarebau kreative Meisterleistungen erbringen, dabei aber nicht an Qualität einbüßen oder unnötig aufwändig werden? • Wie kann Softwareproduktion von kreativen Teams vorangetrieben und zugleich eine Produktpflege gleichbleibender Güte gewährleistet werden? 4.2.2

Kreativität und Softwarebau Kreativität ist die hervorragende Denkfähigkeit zur Lösung schlecht strukturierter und definierter Probleme. Helmut Schlicksupp

Nachdem die Notwendigkeit bewusst kreativen Handelns verdeutlicht worden ist, möchte ich näher auf das eingehen, was sich hinter dem oft nur als Schlagwort verwendeten Begriff verbirgt. Kreativität beginnt mit Neugierde, setzt aber fundiertes Fachwissen voraus. Wissenschaftler wie der Münchner Gehirnforscher Ernst Pöppel, Professor für Medizinische Psychologie, weisen hierbei auf den klaren Bezug zwischen Kreativität und Wissen hin: Nur wer weiß, was prinzipiell möglich oder machbar ist, kann dieses Wissen in Ideen umsetzen. Dabei gelten beide Bereiche, insbesondere aber deren Schnittmenge, als Basisfaktoren für den Projekterfolg. „Kreativ“ zu sein bedeutet dabei, bisher Bestehendes neu zu kombinieren. Die meisten Ideen verändern Vorhandenes, formen es um, erneuern Teile, stoßen alte Lösungen um und machen Gewohntes fragwürdig. In diesem Zusammenhang definieren verschiedene Kreativitätsforscher Produkte dann als kreativ, wenn sie gut und neu sind. Hierbei bedeutet „neu“,

4.2 Kreativität, Wissen und Lernen

141

wenn bisher Bestehendes auf eine innovative und ungewöhnliche Art und Weise miteinander kombiniert wurde. Somit stehen auch Kreativität und Innovation in direktem Bezug zueinander. Während Innovation als ein am Markt erfolgreiches und somit profitables Produkt verstanden werden kann, das sich durch Verbesserungen oder aber auch Neuartigkeit auszeichnet, ist Kreativität die schöpferische Leistung, mit der ein solches Produkt neu- oder weiterentwickelt werden kann. Dabei wird das Wort „Kreativität“ als wissenschaftliches Konstrukt der seit den 1950er Jahren von den USA ausgehenden Kreativitätsforschung verstanden und kann als eine Umschreibung für kreatives Denken und Handeln betrachtet werden. Übertragen auf die Praxis verbindet sich mit diesem Begriff, aus festgefahrenen und festgelegten Denkmustern auszusteigen sowie in möglichst weitem Umfang individuelle Problem- und Lösungsräume zu erschließen. Dies wird möglich, indem auf einer Ebene jenseits der aktuellen Problemebene nach Antworten gesucht wird. Aus dieser Meta-Position heraus gilt es nach anderen Lösungs- und Vorgehensstrategien zu suchen, was einen sehr engen Bezug zum systemischen Ansatz aufweist (Gharajedaghi 1999). Indem Zusammenhänge verändert und Perspektiven gewechselt werden, wird ein wichtiger Weg beschritten, um kreativ und innovativ zu werden. Erst die Erkenntnis, unterschiedliche Perspektiven wahrnehmen zu können, erschließt den Raum der tatsächlichen Lösungsmöglichkeiten. Dies hat zur Folge, dass z. B. sehr einfache Lösungen gefunden werden können, sobald aufgehört wurde, in bekannten und komplizierten Bahnen zu suchen. Ein Beispiel: Stellen Sie sich vor, Sie sollten an ein Team, bestehend aus sieben Mitgliedern, fünf große Kartoffeln möglichst gleichmäßig verteilen. Wie würden Sie dieses Problem unter Berücksichtigung Ihrer mathematischen Vorkenntnisse angehen? – Die Mehrzahl der solchermaßen beauftragten Personen wird mit Hilfe komplizierter Überlegungen nach einem Weg suchen, wie man mit möglichst genialen Schnitten die Kartoffeln so zerteilt, dass jeder mit der gleichen Kartoffelmenge bedient werden kann. Neben dieser Vorgehensweise gibt es mindestens eine kreative Lösung, mit der Sie sogar erheblich mehr erreichen, als bei der genialsten Formel im ersten Lösungsansatz: Warum nehmen Sie nicht einfach alle Kartoffeln, verarbeiten diese zu einem wohlschmeckenden Kartoffelsalat und verteilen diesen gerecht an alle beteiligten Personen? Mit dieser Vorgehensweise löst sich zum einen das Verteilungsproblem sehr viel einfacher. Zum anderen ist Kartoffelsalat für die meisten Zeitgenossen sehr viel schmackhafter als rohe Kartoffeln. Dieses Beispiel verdeutlicht, was eine kreative Handlung sein kann. Nun hat Softwarebau natürlich nichts mit Kartoffeln zu tun, dafür aber mit komplexen, oftmals miteinander verwobenen Funktionalitäten, die genauso von Kreativprozessen profitieren. Unter Berücksichtigung dessen, was bereits über die Abgrenzung zwischen künstlerischem und ingenieurmäßi-

142

4 Hilfsmittel aus der Krise

gem Vorgehen gesagt wurde (vgl. S. 107ff.), wird deutlich, dass im realen Softwarebau Kreativität gerade in der Phase der Anforderungserfassung sowie den frühen Planungsphasen hohe Bedeutung hat, möchte man nicht im Kano’schen Sinne (vgl. S. 74ff.) zu langweiligen Lösungen von der Stange oder unbefriedigenden Ergebnissen kommen. Kreativlinge gesucht

Du gräbst kein zweites Loch, indem Du das erste tiefer gräbst. Edward de Bono Kreativität galt lange als etwas Unbeeinflussbares, etwas das vor allem Genies zugesprochen wurde. Inzwischen weiß man jedoch, dass dieser Genius – zumindest im Ansatz – in jedem Menschen vorhanden ist und in unterschiedlichem Ausmaß freigesetzt werden kann (Csikszentmihalyi 2007, S. 19ff.). Bereits im Jahr 1926 erarbeitete der Amerikaner Graham Wallas ein Erklärungsmodell für kreatives Handeln (Wallas 1926), das trotz verschiedener Modifikationen bis heute seine Gültigkeit behalten hat. Vorbereitungsphase: Hierbei handelt es sich um die bewusste oder unbewusste Auseinandersetzung mit einem Problem. In dieser Phase findet die intellektuelle Vorbereitung statt: Maler studieren Kunstgeschichte oder befassen sich intensiv mit anderen Malern. Komponisten beschäftigen sich über lange Zeit hinweg mit anderen Komponisten. Auch Softwarebauer mit ihrem meist großen fachlichen und methodischen Wissen brauchen eine solche Vorbereitungsphase, um kreativ im definierten Sinne handeln zu können. Wie aber findet hier diese notwendige Vorbereitung bei ihnen statt? Sind es nicht gerade die „weichen“ Faktoren, die für eine solche kreative Phase notwendig sind? (In diesem Sinne verstanden, hat Vorbereitung durchaus etwas mit Aus- und Weiterbildung zu tun und muss nicht als „Kreativmeditation“ zu Anfang eines Projektes verstanden werden.) Inkubations- oder Reifungsphase: In dieser Phase setzen sich die Gedanken, allerdings noch unterhalb der bewussten Wahrnehmungsschwelle, in Gang. Dies ist ein intuitiver Prozess und er liegt außerhalb der klassischen Logik. Es ist ein Prozess übrigens, der durch Außenfaktoren wie z. B. Stress sehr schnell blockiert, negativ beeinflusst, ja sogar gestoppt werden kann. Einsichtphase: Es kommt zu dem berühmten „Aha-Effekt“, von dem so viele bekannte und weniger bekannte Menschen berichten – etwa der fallende Apfel bei Isaac Newton oder die tanzenden Kohlenstoff-Moleküle bei der Entdeckung des Benzolrings.

4.2 Kreativität, Wissen und Lernen

143

Bewertungsphase: Nach dem mentalen „Klick“ im eigenen Hirn wird der Gedanke auf den Prüfstand gestellt und von allen Seiten in Bezug auf seine Brauchbarkeit untersucht und hinterfragt. Mit Hilfe eigener Bewertungsmaßstäbe oder entsprechendem Fachwissen schält sich langsam heraus, ob hier tatsächlich ein neuer und zugleich brauchbarer Gedanke das Licht der Welt erblickt hat. Ausarbeitungsphase: In dieser letzten Phase des Kreativprozesses geht es geschäftig zu, auch nimmt diese Phase meist eine ganze Menge Zeit in Anspruch, geht es doch nun darum die Idee praxistauglich zu machen. Brauchten die ersten Phasen vor allem eine gewisse innere Entspanntheit, so bedarf es hier konkreter methodischer Werkzeuge, um diesen Prozess so effizient wie möglich zu gestalten. Freunde und Feinde der Kreativität

Menschliche Kreativität ist etwas hoch Sensibles und so wundert es nicht, dass Entspanntheit oder Stress direkten Einfluss darauf haben, wie kreativ eine Person ist. Werden kreative Höchstleistungen verlangt, so bedingt dies ein geeignetes Umfeld, um so aus einem Zustand der Entspanntheit heraus zu neuartigen Lösungen zu gelangen. Dies gilt sowohl individuell, als auch in Gruppen wie auch Organisationen (vgl. Heers 2006, S. 65). Stress, aber auch zu eng gefasste Arbeitsvorschriften oder Prozessvorgaben blockieren das kreative Denken (Adams 2005) und verhindern so das Auffinden angemessener Lösungen. Gerade diese beiden Größen gehören aber im Softwarebau zu den zentralen Tagesthemen: Hoher Termindruck und nicht geplante Projektverzögerungen ziehen die Beteiligten leicht in einen Teufelskreis, der einen Ausstieg aus der Stressspirale und einen stärkeren Einstieg in innovatives Arbeiten verhindert, da gestresste Menschen nur sehr begrenzt innovative bzw. kreative Lösungen erbringen können. Auch wenn derzeit viele IT-Firmen ihr Heil in der Etablierung von Prozessen suchen, so ist dies auch im Sinne dessen, was bereits gesagt wurde, für manche Arbeitsschritte in der Softwareproduktion durchaus eher kontraproduktiv: Das Problem besteht darin, eine Balance zwischen Kreativität und Kontrolle zu finden. Zu viel Kontrolle kann dazu führen, dass eine Organisation nicht innovativ genug ist und so den Anschluss an die Zeit verpasst. Ist andererseits zu wenig Kontrolle vorhanden, so besteht die Gefahr, in Unordnung und Ineffizienz zu versinken. Gerade hier zu einer sinnvollen Balance zu finden wird zur eigentlichen Herausforderung, da viele IT-Organisationen dieser Thematik zu wenig Aufmerksamkeit schenken, viele Formalismen und Prozessschritte im Namen der Qualität einführen und dabei nicht registrieren, dass sie zugleich die notwendigen Freiräume für den Innovationsmotor Kreativität immer mehr einengen.

144

4 Hilfsmittel aus der Krise

Wie sensibel individuelle Kreativität dabei ist, wird deutlich, wenn man zur Kenntnis nimmt, dass bereits kleine äußere Störfaktoren zum Kreativitätskiller werden können. Diese können sehr einfach, ungewöhnliche Ideen und neuartige Gedanken blockieren. Implikationen für den Alltag

Ist hier also doch wieder ein Platz für die „Dichter und Denker“ im Softwarebau notwendig, an dem diese ohne Druck und vorgegebene Prozesse in höheren Sphären verweilen dürfen, um so die Innovationen von morgen vorzubereiten? Ganz von der Hand zu weisen ist dies nicht, auch wenn wirtschaftlicher Druck und gesetzte Termine die vollständige künstlerische Freiheit sicherlich nicht möglich machen. Immerhin wird es sich wohl kaum eine softwareproduzierende Organisation leisten können, auf die zentralen Handlungsfelder von Kreativprozessen zu verzichten. Diese lassen sich wie folgt zusammenfassen: Visionen entwickeln: Was wollen wir? Wie könnten individuelle Lösungen (z. B. Produkte) aussehen? Was wäre ideal bzw. optimal? Explorieren: Welche bisher getroffenen Annahmen können wir in Frage stellen, hinterfragen oder verändern? Wo gibt es Lernschleifen, die kein zweites Mal durchlaufen werden müssen? Experimentieren: Wie lassen sich aus den vorhandenen Teilen neue Lösungen komponieren? – Oder was wäre zu tun, um in Zukunft besser mit entstandenen Teilen (etwa Softwaremodulen) auf der Suche nach neuen Lösungen zu experimentieren? Modifizieren: Wie können – und das gilt für Arbeitsweisen, technische Abläufe oder auch Lösungen – Dinge so modifiziert werden, dass sie effektiver und zugleich „schlanker“ die ihnen zugewiesene Rolle erfüllen können? Obwohl industrieller Softwarebau meist wenige Freiräume hierfür lässt, gibt der enge Bezug zwischen Kreativität und Innovation zu denken. Dies wirft einige Fragen auf, die sich eine Organisation aktiv zu stellen hat: • Ist den zentralen IT-Mitarbeitern das notwendige Handwerkszeug zum kreativen Arbeiten im oben verstandenen Sinne vermittelt worden? • Ist die Struktur der Organisation so ausgelegt, dass diese Art von Eigendynamik entsprechend integriert werden kann?

4.3 Denken, wissen und kommunizieren

145

• Findet (frühe) Planungsarbeit in solch einer Weise statt, dass kreative Prozesse aktiv unterstützt werden? • Ist die eigene Organisation innovationsgetrieben und wenn ja, wie schlägt sich dies in den Arbeitsmethodiken und Resultaten (also Applikationen) wieder? • Gibt die eigene Unternehmensstruktur ausreichend Raum für kreatives Handeln?

4.3 Denken, wissen und kommunizieren Wissen kann heute nicht mehr als eine lineare Anhäufung isolierter Fakten begriffen werden. Auch in der Wirtschaft ist das große Ganze mehr als die Summe seiner Teile. (unbekannt) Es mag trivial klingen: Die Begriffe „Denken“, „Wissen“ und „Kommunizieren“ stehen in engem Zusammenhang zueinander und beschreiben drei Aspekte, die es in den Kontext von Softwareproduktion möglichst optimal zu integrieren gilt. Weil wir denken, können wir Wissen und Erfahrungen aufbauen. Aus diesem Wissen heraus werden wir in die Lage versetzt zu kommunizieren und dies ermöglicht z. B. ein optimiertes Zusammenspiel im Team oder mit Kunden, aber auch gemeinschaftliche Planungsarbeit. Zugegeben: Bereits bei der Fähigkeit zur direkten Kommunikation wird vielen Softwareentwicklern immer wieder unterstellt, dass sie zwar hervorragende logische Denker seien, die bravourös mit Bits und Bytes jonglieren können, aber häufig nicht zu den Hochbegabten zählen, soweit es die erstgenannte Fähigkeit betrifft. Somit ist zu fragen, ob diese drei Begriffe und die damit assoziierten Themen doch nicht so trivial sind, wie zunächst angenommen. Um hier zu einem gemeinsamen Verständnis zu gelangen möchte ich wichtige Aspekte dieser Begriffstrias betrachten, um dann Bezüge zum eigentlichen Softwarebau und hieraus resultierende Implikationen aufzuzeigen. Zunächst geht es um den Bereich des „Wissens“, der untrennbar mit dem Begriff des „Lernens“ verknüpft ist. Dabei entsteht Wissen, wenn Informationen in einen Praxiszusammenhang einbezogen werden und daraus eine neue oder abgeänderte Vorgehensweise bzw. Erkenntnis folgt. Somit ist Wissen eine auf Erfahrung gegründete kommunikative konstituierte und konfirmierte Praxis (Willke 2004, S. 33ff.), bei der Entstehung und Transfer immer einen Erfahrungskontext voraussetzen.

146

4.3.1

4 Hilfsmittel aus der Krise

Universum des Wissens Wir suchen das Wissen, das wir durch Information verloren haben. Thomas Stearns Eliot

Inzwischen ist Wissen neben Innovation zu einem der wichtigsten Wettbewerbsfaktoren avanciert und spielt gerade in der Implementierung von Software eine immer zentralere Rolle. Dabei ist an dieser Stelle nicht nur die Rede von demjenigen Wissen, welches benötigt wird, um eine konkrete Applikation zu bauen (dies ist eine Untermenge des hier angesprochenen Wissens), sondern es geht um das Wissen, das es aus einer Organisation oder von einzelnen Personen zu extrahieren gilt, um es dann in eine entsprechende digitale Lösung zu überführen. (Schütt 2000) Gerade durch die Möglichkeit gigantische Datenspeicher betreiben zu können, neigen viele IT-begabte Zeitgenossen dazu, „Lernen“ zum Synonym von Datensammeln und Wissen zum Synonym für Datenspeicherung zu machen: Dabei werden alle Daten, die irgendwie Sinn machen könnten, einfach gespeichert nach der Devise: Wenn ich die Daten einmal habe, dann brauche ich ja nur noch mit Hilfe geschickter Filter nach den entsprechenden Informationen zu suchen. – Diese Vorgehensweise erinnert ein wenig an die berühmte Geschichte mit dem Heuhaufen und der Nadel. Man legt die Nadel ganz bewusst in diesem gigantischen Heuhaufen ab – dann weiß man hinterher genau, wohin man sie gelegt hat … oder etwa nicht? Mit Blick auf Abb. 4.4 wird deutlich, dass Wissen weit mehr ist als nur ein großer Datenfriedhof. Der obere Teil der Grafik zeigt im Sinne der dort wiedergegebenen Wissenspyramide, wie sich Wissen aus einzelnen Informationen und diese wiederum aus Daten zusammensetzen. Links daneben sind dabei solche Aktivitäten vermerkt, die mit der jeweiligen Stufe dieser Pyramide korrelieren, sowie mögliche derzeit gängige Applikationenstypen. Dabei ist der sprachliche Umgang mit den Begriffen „Daten“, „Information“ und „Wissen“ oft nicht sorgfältig gewählt. Umgangssprachlich sind sie nur unscharf gegeneinander abgegrenzt oder werden sogar als Synonyme verwendet. Folgt man Meyers Lexikon, so wird dort „Information“ wie folgt definiert: „Auskunft, Nachricht, Belehrung, Mitteilung, Hinweis, Aufklärung, Unterrichtung über eine bestimmte Sache. Im streng mathematischen Sinne bleibt der Inhalt einer Information unberücksichtigt, entscheidend ist der Informationswert einer Nachricht. …“ Wissen hingegen wird im gleichen Nachschlagewerk als kognitives Schema verstanden, das (an der Erfahrung orientiert) die Handhabung von Sachverhalten, Situationen sowie den Bezug zur Umwelt auf eine zuverlässige Basis von Informa-

4.3 Denken, wissen und kommunizieren

147

Abb. 4.4. Wissenspyramide und Wissenssphären

tionen und Regeln gründet, die sich ihrerseits anhand der Kriterien Prüfbarkeit, Nachvollziehbarkeit und Begründbarkeit bestimmen lassen. Mit diesen Definitionen wird klar: Wissen ist erheblich mehr, als nur Informationen strukturiert gesammelt und diese in dafür geeigneten Schemata abgelegt zu haben. Bezogen auf den IT-Alltag, etwa im Bereich IT-Servicemanagement, wo es u. a. darum geht, in Betrieb befindliche Software beim Kunden am Laufen zu halten, sind solchermaßen aufgebaute Datenbanken von großem Vorteil, da rasch nach bereits bekannten Lösungen für bestimmte Probleme gesucht werden kann. – Die Sammelwut von Informationen, die fälschlicherweise mit der Sammlung von Wissen gleichgesetzt wird, bringt allerdings in anderen Bereichen auch Risiken mit sich. So werden die Datenbanken im Bereich des Anforderungsmanagements leicht zum Datengrab für Kundenwünsche. Lange Listen mit all dem, was der Kunde gerne hätte, sind dort thematisch gegliedert wiederzufinden, ohne dass die für das Wissen so notwendigen Verknüpfungen und inhärenten Strukturen bzw. wechselseitigen Abhängigkeiten vorhanden sind. Was dies für den Bereich des Anforderungsmanagements konkret bedeutet, wird noch zu betrachten sein. Aber noch einmal zurück zu Abb. 4.4 (unten): Wissen entsteht, indem wir bewusst oder unbewusst aus verschiedenen Quellen (z. B. Umwelt, Theorie

148

4 Hilfsmittel aus der Krise

etc.) lernen. Damit gewinnt die bewusste Wahl dieser Quellen gerade auch bei der qualifizierten Planung von Software sehr schnell an Bedeutung: • Wie wird sichergestellt, dass in der Planungsphase einer Applikation tatsächlich die eigentlichen Wissensträger, nicht notwendigerweise aber die Funktionsträger befragt werden? • Oder wie kann im Verlauf des Planungsprozesses die Vollständigkeit und Qualität dieser Quellen verifiziert werden? Immerhin gilt es zu bedenken, dass kontextbezogenes „Wissen“ auch falsch sein kann! Menschen geben in bester Absicht das weiter, was sie selbst falsch oder subjektiv eingefärbt gelernt haben. In diesem Sinne verstanden kann hier von „Antiwissen“ oder auch „Halbwissen“ gespochen werden. Es sind diejenigen erlernten Sachverhalte, die manche Manager dazu bewegen, vorschnell IT-Lösungen einzufordern, weil das Wissen über die Konsequenzen eigenen überstürzten oder wechselhaften Handelns fehlt. Genauso ist diese Form von Wissen auch dort zu suchen, wo ITMitarbeiter sich auf spezifische Arbeitsmethoden, Verfahren oder Werkzeuge versteifen – und darauf beharren, dass diese allein die besten und effektivsten wären, obwohl das ganze Umfeld hier anders denkt und handelt! Diese Art von Wissen und hieraus resultierendes Handeln wird somit zum Projektrisiko! Neben diesen externen Quellen ist gerade für den Bereich des internen kollektiven Wissens (also in Teams, Organisationen, etc.) wichtig, wie dieses vorliegt (vgl. Abb. 4.4 unten) und in welcher Weise es zugänglich ist: Explizites Wissen: Dieses Wissen ist auf unterschiedlichste Weise gespeichert und vor allem gut zugänglich. Implizites Wissen: Hierbei handelt es sich um das Erfahrungswissen der Mitarbeiter. Dieses ist naturgegeben eher privat und lässt sich nur sehr schwierig formalisieren oder sogar in explizites Wissen überführen. Strukturiertes Wissen: Hierbei handelt es sich um all das, was sich in Ihren Datenbanken oder auch digitalen Archiven verbirgt. Die Tatsache, dass es strukturiert ist, löst allerdings ein Problem nicht: Finden Sie es auch wieder? Unstrukturiertes Wissen: Auch dieses gibt es in den meisten Organisationen zuhauf. Hierbei handelt es sich um Präsentationen, die täglichen Emails und alles, was die Mitarbeiter nicht in vorgefertigten Strukturen abgelegt haben.

4.3 Denken, wissen und kommunizieren

149

Kollektives Wissen: Dies ist Wissen, das nicht nur für einzelne Personen, sondern für eine ganze Gruppe, am besten für die gesamte Organisation, verfügbar ist. Privates Wissen: Hier gibt es einige interessante Schnittmengen mit dem Wissen Ihrer Organisation, doch handelt es sich zunächst einmal um das Wissen von Privatpersonen. Wie gut – oder auch wie schlecht – sind Sie in der Lage, dieses private Wissen, soweit es mit den Belangen Ihrer Organisation zu tun hat, für diese zu nutzen? Auch emotionales Wissen gehört grundsätzlich dazu, spielt aber in diesem Kontext eine nachgeordnete Rolle. Um Wissen in strukturierter Weise nutzbar zu machen ist eine weitere Klassifizierung sinnvoll, wobei jede dieser Formen eigene Zugänge, also Wege des Erfragens braucht, um ergründet werden zu können. Deklaratives Wissen: Oder „wissen, dass …“ Hierbei handelt es sich um das Wissen über Fakten, gedankliche Konzepte oder auch semantische Beziehungen. Prozedurales Wissen: Oder „wissen, wie …“ Die Rede ist vom Wissen über Abläufe und Prozesse. Diese Art von Wissen braucht man, um Handlungen ausführen zu können. Konditionales Wissen: Oder „wissen, wann …“ Hier wird die situative Abhängigkeit von Handlungen beschrieben. Dieses Wissen schreibt uns vor, wann wir etwas tun oder wann eine bestimmte Handlung die richtige wäre. Negatives Wissen: Oder „wissen, was nicht …“ In diesem Fall handelt es sich um die Negation der bisherigen Formen von Wissen. Es besagt, was wir nicht tun sollen, und stellt sozusagen Verbote auf Grundlage der gegebenen Informationen dar. In gewisser Weise verhält sich Wissen an sich wie die Oberfläche des Meeres. Es ist nicht statisch, sondern unterliegt einer eigenen Dynamik, die von Außenumständen abhängt. In Abhängigkeit von diesen Faktoren (z. B. Individualwissen der Mitarbeiter, Hierarchiefaktoren oder soziales Klima) wird sich die Topologie verändern und zugleich unsichtbare Strömungen, die zunächst nur mittelbar wahrgenommen werden, triggern. Dabei ist es ein sich ständig erweiterndes Netzwerk von Kompetenzen, somit nichts Statisches. Wie aber lässt sich genau diese Eigenschaft konstruktiv in technische Systeme übertragen?

150

4 Hilfsmittel aus der Krise

Auch müssen die folgenden Fragen gestattet sein: • Wie viel Prozent dieses Wissens und seiner Dynamik werden tatsächlich in die Planungsarbeit aktiv einbezogen? • Wie wird sichergestellt, dass ungewollte Quellen (z. B. Halbwissen) erkannt und ausgeschlossen werden? • Und wie stellen Sie sicher, dass wirklich wichtige Informationen rechtzeitig kommuniziert werden und nicht viel zu spät bei Ihnen ankommen? Die späte Reaktion auf diese nicht mitgeteilten Aspekte lautet im Nachgang häufig „Daran haben wir nicht gedacht!“ – Dies führt im wirklichen Leben oft zu teuren Nacharbeiten oder ungeliebten technischen Kompromissen. Das beste Rezept, um diese Art von Wissensdefiziten in der Planung – übrigens nicht nur von Software – zu vermeiden, besteht darin, die Bereiche des individuellen und kollektiven Wissens zu explorieren, was die Brücke zum systemischen Vorgehen schlägt. 4.3.2

Piaget lässt grüßen

Im Hinblick auf die Vorgänge des Lernens möchte ich zunächst einen kurzen Exkurs zu dem Schweizer Psychologen Jean Piaget unternehmen. Dieser hat in seinen Studien über die Entwicklung (kindlichen) Denkens zwei Begriffe geprägt, nämlich Assimilation und Akkomodation. Assimilation: Hierbei handelt es sich um einen Lernprozess, bei dem in ein bereits vorhandenes Wissensschema (also z. B. die Anwendungskenntnisse über eine Vorgängersoftware oder die Art und Weise, wie bisher Software gebaut wurde) die neu angebotene Information integriert wird. Diese Form von Lernprozessen ist wichtig (= Lernen aus Erfahrungen, Verbesserungsprozessen, etc.), aber auch nicht ohne Begleiteffekte, wie an dem Gedankenexperiment mit dem „kreativen Kartoffelsalat“ (vgl. S. 141ff.) leicht nachzuvollziehen ist. Das Risiko dabei ist folgendes: Da das Grundgerüst des Wissens ja bereits existiert, entstehen hier sehr leicht mentale Hexenhäuschen bzw. Gedankenkonstrukte, die subjektiv und verzerrt sein können. Man blickt auf das Alte, versucht dieses zu extrapolieren bzw. zu ergänzen, steigt aber nicht aus alten Metaphern oder technischen Konzepten aus. Akkomodation: Hierunter wird ein Vorgang verstanden, bei dem Erinnerungen, Gesetzmäßigkeiten oder Vorbilder an eine wahrgenommene Realität angepasst werden. Die wahrgenommene Realität wird den vorhandenen Strukturen angepasst. Es werden neue Objekte in die eigene Welt integriert, um dann quasi spielerisch diese Objekte mit den eigenen Erwartungen

4.3 Denken, wissen und kommunizieren

151

abzugleichen und ggf. weiterzuverwerten. Diesen Effekt kennen Sie vermutlich von sich selbst, wenn Ihnen jemand ein völlig neues Gerät oder ein Programm über einen für Sie bisher unbekannten Bereich anbietet – und Sie erst einmal „ausprobieren“, was hiermit möglich ist. Lernen ist mehr als Daten zu sammeln

Indem das genutzt wird, was bereits über den systemischen Ansatz gesagt wurde, lässt sich dies direkt auf das Lernen im Sinne von Neuaufnahme von Wissen anwenden. Wird ein konstruktivistischer Ansatz (Reich 2006) zugrundegelegt, so ergeben sich daraus die folgenden Schritte: Konstruktion: Hierbei geht es um die Konstruktion neuer Wirklichkeiten sowie der Aneignung neuer Wissensbestände, aus denen die Zuschreibung von Bedeutungen (= Definitionen) und deren Viabilitätsüberprüfung49 stattfinden (z. B. anhand eines Gedankenexperiments mit welchem das Ganze durchgespielt wird). Rekonstruktion: Hierbei geht es um den Rückgriff auf bereits gewonnene Erkenntnisse, kulturelle Kontexte oder zielgruppenbezogene Bedeutungsmuster, die mit dem neu erworbenen Wissen in Referenz gebracht werden. Ebenso ist hierunter ggf. eine Neudeutung zu verstehen, etwa indem Begriffe mit anderen Außengrenzen versehen werden. Dekonstruktion: An dieser Stelle ist Veränderung von vorhandenem Wissen angesagt: Es handelt sich um das Aufweichen von verfestigten Überzeugungen, Lehrmeinungen oder Wahrheitsansprüchen, aus denen die eigene Wirklichkeit in Beton gegossen wird. Um neues Wissen aufzubauen, müssen diese in geeigneter Weise in Frage gestellt werden und sind mit neuem Leben zu füllen. Es ist also bei weitem nicht damit getan, die Anforderungen als solche zu erfassen, indem man sich dem „Experten“ des Kunden gegenübersetzt und dessen Bedarf aufzeichnet, als sei man der Gesandte eines Supermarktes, der sich vom Kunden diktieren lässt, wie viel Pfund Kaffee, Zucker und Mehl er braucht, um ihm anschließend diese Waren zu liefern. Versteht man das Erleben von Anforderungen als denjenigen Lernprozess, bei welchem das für eine Produktentwicklung notwendige Wissen erhoben wird, so ergibt sich mit Hilfe der Piaget’schen Begriffe und dem 49

Der Begriff Viabilität wurde von Glaserfeld im Kontext seines radikalen Konstruktivismus geprägt und bedeutet zunächst einmal funktional, passend oder brauchbar.

152

4 Hilfsmittel aus der Krise

Abb. 4.5. Aus Individualwissen wird formales Wissen

Ansatz von Reich das in Abb. 4.5 wiedergegebene Kreislaufmodell. Es beschreibt eine effiziente Vorgehensweise, um vorhandenes Wissen, etwa jenes in den Köpfen der betroffenen Mitarbeiter, schrittweise in strukturiertes Wissen zu überführen. Dieses wiederum kann direkt in modelliertes Wissen, also z. B. Domainmodelle, überführt werden. Im Einzelnen werden in diesem Prozess die vier folgenden Phasen durchlaufen: Informationen aufnehmen: Durch geeignete Methoden werden Informationen erfasst und zusammengetragen: Beteiligte werden befragt, Geschäftsvorfälle aufgenommen, Situationen durchgespielt oder miterlebt. Ebenso werden (Gedanken-)Experimente und Überlegungen, wie sie sich z. B. aus den Themenfeldern des Systemischen Handelns und Fragens oder auch der Kreativmethoden ableiten, als weitere Quellen der Information herangezogen. Wissen abgleichen: Auf Grundlage dieser Informationen erfolgt ein Abgleich mit dem bereits vorhandenen Wissen. Ist das vorhandene Wissen so noch relevant? Gibt es Ergänzungen hierzu? Lassen sich Dinge zusammenführen oder sind gar Widersprüche aufgetreten? Ein Beispiel: Es war bekannt, dass der Kunde bisher von mehreren Betriebssystemen gesprochen

4.3 Denken, wissen und kommunizieren

153

hat – die neu hinzugekommenen Erkenntnisse beschränken das Ganze explizit auf Betriebssystem A und B. – Welche Implikationen hat dies und welche Aspekte des bisher aufgebauten Wissens sind davon betroffen? Erweitertes Wissen abstrahieren: Dies führt schrittweise zur Modellabstrahierung. Das neu hinzugewonnene Wissen ergänzt oder korrigiert das bereits vorhandene – und wird dieses, soweit möglich, verdichten, was einer Abstraktion gleichkommt. Dies ist insofern von großer Wichtigkeit, als nur durch eine solche Abstraktion der Komplexitätsgrad in Grenzen gehalten werden kann. Strategien ableiten: Aus den neuen oder erweiterten Wissensclustern werden nun Fragen und Vorgehensweisen abgeleitet, mit deren Hilfe weitere Informationen in einer nächsten Exploration generiert werden können. Dabei geht es nicht ausschließlich um wissensbezogene Fragen, sondern vor allem um das Wie. Mit welchen Vorgehensweisen/Methoden können die erkannten Lücken oder Unklarheiten bereinigt werden und woran ist zu messen, ob dies auch tatsächlich stattfand? – Dies liefert letztendlich die Regieanweisungen für eine weitere Informationsaufnahme. Angewandt auf die Anforderungserhebung wird mit jedem Durchlauf dieses Zyklus das Wissen über den Lösungsraum der künftigen Anwendung klarer. Dabei ist es eine der wichtigsten Aufgaben bei dieser Art von Wissenserfassung, unterschiedliche Quellen zusammenzuführen und diese zu moderieren. Auf diese Weise werden die Abgrenzungen, was dazu gehört und was nicht eindeutig ist oder unberücksichtigt blieb, aufgedeckt. Insgesamt findet hierbei ein Prozess statt, der sich als Wissensmediation bezeichnen lässt und bei dem eine entsprechend geschulte Person diese divergierenden Begriffswelten zusammenführt und abgrenzt. – Dies hat eine wichtige Implikation: Software für einen speziellen Zweck zu bauen heißt immer, ein vorhandenes System möglichst genau zu ermitteln, zu definieren und abzugrenzen, um genau dieses dann technisch zu realisieren.

5 Wege zum Softwarebau von morgen

5.1 Systemischer Softwarebau 5.1.1

Vom Gedanken zum Produkt

Unter Berücksichtigung der vorangegangenen Überlegungen lässt sich die inhaltliche Entwicklung von Software wie folgt zusammenfassen (vgl. Abb. 5.1). Am Anfang steht eine meist vage und somit unvollständige Produktidee. Sie ist – wie wir sahen – Teil einer nicht-kausalen Realität. Dabei ist diese zunächst von Wünschen, Absichten und nachgelagerten neuen Ideen geprägt. Durch Gespräche, gezieltes Hinterfragen und Überdenken von Einzelheiten kristallisieren sich schrittweise Zielvorstellungen heraus, die als Prosa oder auch stärker formalisiert als umgangssprachliches Modell im Sinne einer Ontologie oder anderen formalen Darstellungsformen (z. B. Use Cases) abgebildet werden kann.

Abb. 5.1. Vom Gedanken zum Produkt

156

5 Wege zum Softwarebau von morgen

Abb. 5.2. Von der Idee zur technischen Lösung

Hat diese Beschreibung stattgefunden, so liegt eine kausale Repräsentation vor, die mit den bekannten Mitteln des Softwarebaus (z. B. Modellierung) in ein Produkt umgesetzt werden kann. Dieser zweite Teil ist gängige Praxis und soll daher nicht weiter beleuchtet werden. Ein zweites wird anhand von Abb. 5.1 deutlich. Wenn in der beschriebenen Weise tatsächlich eine Unterscheidung zwischen kausaler und nichtkausaler Welt notwendig ist, so liegt es auf der Hand, dass hierfür jeweils angepasste Arbeitsmethoden zum Tragen kommen müssen (vgl. S. 112ff.). In einer anderen Repräsentation betrachtet (vgl. Abb. 5.2) lässt sich dieser Transformationsprozess in einer Quadranten-Darstellung wiedergeben. Zunächst existieren kundenseitige Ideen und Überlegungen sowie bewusste wie auch unbewusste Erwartungen an ein künftiges Produkt. Auch wenn der Kunde/Auftraggeber zu diesem Zeitpunkt in technischen Lösungsdetails denkt (z. B. die berühmten rosa Buttons), so ist es letztendlich der nicht immer transparente Versuch den eigentlichen Problemraum zu umschreiben. Um diese Ansätze in strukturiertes und vollständiges Problemwissen zu überführen, die den Problemraum des Auftraggebers im notwendigen Maß abdecken, braucht man adäquate Wege der Interaktion, also Fragen, Hinterfragen, Lösungsoptionen durcharbeiten und Konsequenzen aufzeigen. Dies ist notwendig, um so zu einer möglichst vollständigen Repräsentation zu gelangen. Dabei sind Fragen wie die folgenden zu klären:

5.1 Systemischer Softwarebau

157

• Wie kann wichtiges von unwichtigem Wissen differenziert werden? • Wie können unvollständige Bereiche erkannt werden und wann sind diese vollständig? • Wie können die gewonnenen Wissenskomponenten sinnvoll zueinander in Bezug gesetzt werden und was bewirken diese Abhängigkeiten? Ist ein solches fachliches Wissensmodell möglichst vollständig und sauber abgegrenzt vorhanden, so kann dieses vollständig und widerspruchsfrei in strukturiertes Lösungswissen, etwa ein UML-Diagramm o. Ä., überführt und mit einer IT-technischen Lösungsarchitektur kombiniert werden. Die Ergebnisse dieses Prozesses entscheiden in hohem Maß über die Produktions- wie auch Lifecycle-Kosten des entstehenden Produktes. Von daher – obwohl im lösungsnahen Bereich – sind auch hier, neben den ITtechnischen Fähigkeiten, in hohem Maße solche Eigenschaften notwendig, die es gestatten Risiken, Konsequenzen und Abhängigkeiten im Lösungsraum frühzeitig zu erkennen bzw. diese zu ermitteln. Die Überführung der technischen Modellwelt und der zugehörigen Lösungsarchitektur in ein fertiges Produkt sowie die notwendigen Tests und Qualitätskontrollen auf dem Weg dorthin sind State of the Art und werden hier nicht weiter betrachtet. Die IT-technische Lösung, also die fertige Software, steht danach dem Kunden zur Verfügung. Dieser entscheidet dann letztendlich, was er von dem entstandenen Produkt hält (vgl. hierzu Kano-Prinzip S. 68ff.) und ob es seinen Wünschen und Bedürfnissen genügt. Hieraus lassen sich drei unterschiedlich geprägte Handlungszonen ableiten: Im zentralen Bereich von Abb. 5.3 spielen solche Aspekte eine zentrale Rolle, die sich unter dem Begriff „Flow“ (vgl. Csikszentmihalyi 2007) zusammenfassen lassen. Hierunter fallen ganzheitliche Handlungsparadigmen, die aktive Nutzung von Kreativität, systemische Fragetechniken, aber auch fachliche Erfahrungen. Umgeben ist diese Flow Zone von einer – selbst im agilen Softwarebau – als „statisch“ zu bezeichnenden Zone. Hier geht es um klar definierte und eindeutig fixierte Regeln, Vorgehensmodelle, Arbeitstechniken oder Strukturen. Soll effektiv Software entstehen, so ist dieser Bereich möglichst vollständig und eindeutig zu definieren. – Praktisch sind hier Best Practices wie etwa Tracebility, Wege zur redundanzfreien Projektdokumentation, aber auch prozessuale Vorgaben verankert. Während die „statische Zone“ letztendlich durch das jeweilige Projekt kontrolliert und gesteuert wird, entzieht sich der äußerste Bereich, die „unkontrollierbare Zone“ einer solchen Art von Beeinflussung: Der ProduktLifecycle ist nicht vorhersagbar, genauso wenig ist es möglich die technische Weiterentwicklung von Werkzeugen oder Komponenten, aber auch zukünftiger Kundenbedürfnisse hinreichend sicher vorherzusagen oder gezielt zu beeinflussen.

158

5 Wege zum Softwarebau von morgen

Abb. 5.3. Handlungszonen im Softwarebau

5.1.2

Schwachstellenbeseitigung Nicht weil die Dinge schwierig sind, wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig. Seneca, 65 n. Chr., römischer Philosoph

In Anlehnung an die Ansätze des Konstruktivismus (Foerster, Glasersfeld et al. 2006) und des systemisches Denkens führen die hier vorgestellten Überlegungen und Hintergründe zu folgendem Gesamtergebnis: Wenn Softwarebau im Sinne eines Gesamtsystems50, bestehend aus den beteiligten Personen, Organisationsformen, Tätigkeiten und Hilfsmitteln verstanden wird, so ist es notwendig diese Abhängigkeiten in geeigneter Weise in Software-Entwicklungsprojekten zu berücksichtigen. Hierzu müssen die einzelnen Teile sowie deren Wechselwirkungen bekannt, die jeweiligen Einflüsse bewertet und diese Abhängigkeiten im jeweiligen Projekt individuell berücksichtigt werden. Auf diese Weise ist es möglich, aus der „Einbahnstraßenlogik“ (= Kausalzusammenhänge) in eine zirkuläre und wechselwirkende Logik zu gelangen, mit deren Hilfe es wiederum möglich ist, nicht-triviale Aspekte in kausalen Modellen nachzubilden. 50

Definition eines Systems: Jede Gruppe von interagierenden, voneinander abhängigen, verwandten Teilen, die ein komplexes Ganzes formen, das gemeinsam zielgerichtet ist. Ein System hält seine Existenz durch die Interaktion seiner Teile aufrecht.

5.1 Systemischer Softwarebau

159

Abb. 5.4. Herkömmlicher und systemischer Softwarebau

In Abb. 5.4 sind herkömmlicher Softwarebau und systemischer Softwarebau gegenübergestellt. In Bezug auf den herkömmlichen Softwarebau (Abb. 5.4 oben) ist festzustellen, dass sofern nach klar definierten Vorgehensmodellen konsequent gearbeitet wird, die Hauptfehlerquellen in den Übergangsbereichen zwischen Kundenwünschen und Anforderungen sowie Anforderungen und Architektur zu suchen sind. Aufgrund der hier zugrundliegenden kausal begründeten Paradigmen sind nur begrenzt Verbesserungen möglich. Systemischer Softwarebau stellt in diesem Sinne eine Erweiterung des herkömmlichen Ansatzes dar und deckt gezielt diejenigen Bereiche durch nicht ausschließlich kausale Paradigmen ab. Somit wird die Lücke geschlossen, ohne dabei auf bewährte Verfahren und methodische Vorgehensweisen aus dem klassischen Softwarebau zu verzichten. Mehr noch: Durch gezielte Integration solcher Verfahren, wie sie sich aus der auf den Softwarebau übertragenen Lean Production (Hamilton 2006), der Forderung nach Total Quality Management (TQM), Vermeidung von Wissensredundanzen, sowie kontinuierlichen Verbesserungsprozessen (Senge 1994) ableiten, wird dieser Ansatz in sich sinnvoll ergänzt und verstärkt. Beim systemischen Ansatz kommen folgerichtig den Requirementserfassern sowie auch den IT-Architekten Schlüsselrollen zu. Für sie ist es notwendig in zwei „Welten“ operieren zu können. Zum einen betrifft dies die jeweils fachliche Welt, zum anderen bedarf es in besonderem

160

5 Wege zum Softwarebau von morgen

Maß solcher Fähigkeiten, wie sie in Abb. 5.3 (S. 158) für die „Flow Zone“ definiert wurden. Indem in beiden „Welten“ durch die bezeichneten Schlüsselrollen nacheinander gehandelt wird, ist einerseits der fließende Übergang sichergestellt, zum anderen aber auch, wie in Abb. 5.4 unten wiedergeben, der fehlende Bereich ergänzt. – Mit Blick auf zukünftige Softwareentwicklungen (vgl. S. 26ff.) hat dieser Ansatz übrigens besonderen Charme, da tatsächlich eine äußerst saubere Trennung zwischen (entsprechend qualifizierten) Vorort-Teams und den eigentlichen Entwicklungsmannschaften möglich wird. Vor Ort sind Mitarbeiter, die als fachlich qualifizierte Berater sehr viel besser und klarer die fachlichen und technischen Notwendigkeiten herausarbeiten können und deren Fokus darauf gerichtet ist, die nicht-kausale Welt des Kunden möglichst vollständig zu erfassen, zu beschreiben und in eine kausale Welt zu überführen. Diese Vorarbeiten können dann mit sehr viel größerer Präzision andernorts im Sinne der jeweils angewandten Best Practices und IT-technischen Vorgehensmodelle realisiert werden. Somit kann der Bereich traditionellen Arbeitens sehr wohl dominiert bleiben von Toolorientiertheit und Prozesstreue. Im systemisch orientierten Bereich sind zwar auch Werkzeuge und fachliche Skills notwendig, jedoch liegt der Schwerpunkt auf solchen Fähigkeiten, wie sie in Kap. 4, (S. 115ff.) vorgestellt wurden. Auf diese Weise können zwei Welten, die im klassischen Softwarebau nicht klar voneinander differenziert sind – und damit maßgeblich die Produktqualität beeinträchtigen –, sauber voneinander getrennt werden. Hieraus leitet sich der Ansatz ab, die Rollen der Architekten im Softwarebau neu zu definieren und dies nicht nur im Kontext der reinen Softwareplanung zu sehen, sondern die vorher zu entwickelnden Wissensmodelle als Plattform für die zu entwickelnde Software einzubeziehen.

5.2 Architekten in der Softwareproduktion The ideal architect should be a person of letters, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations. Vitruvius, circa 25 BC Zunächst möchte ich einen eher intuitiven Zugang zur Fragestellung nach Architekten in der IT setzen: Fragt man selbst in renommierten Softwarehäusern nach, was dort unter der Rolle Software-Architekt verstanden werde, so erhält man vielfach zur

5.2 Architekten in der Softwareproduktion

161

Antwort, dass es sich hierbei um diejenigen Zeitgenossen handele, die in UML modellieren, Software-Werkzeuge einsetzen oder technische Subsysteme zusammenstellen und in deren Namensgebung das Wort Architekt vorkommt. Im Übrigen sei ihre Aufgabe der eigentlichen Implementierung vorgelagert. Jeder Teil für sich ist sicherlich richtig, aber ist das wirklich alles? Handelt es sich hierbei um bessere Programmierer, solche Personen also, die gelernt haben, wie man mittels entsprechender Modellierungswerkzeuge Softwarekomponenten fachgerecht miteinander verschraubt, oder sollte hier deutlich mehr dahinter stecken? (Malveau/Mowbray 2001). Aufgrund solch unklarer Vorstellungen ist es zunächst notwendig, zu klaren Begriffsklärungen zu gelangen, andernfalls führen verschwommene Erwartungshorizonte an diese Rolle zu ebenso verschwommenen Arbeitsergebnissen. Wenn also Architektur beim Softwarebau mit bestimmten Handlungsparadigmen einhergeht, so ist es notwendig, dass die entstehende Applikation nicht nur architekturzentriert, sondern architektenzentriert entsteht. Der Begriff „Architekt“ etabliert sich derzeit in immer mehr Bereichen. Nicht nur im Softwarebau, sondern auch im Flugzeug- oder Schiffsbau findet er sich zunehmend häufiger. Ist dies nur eine Modeerscheinung – oder soll hier sprachlich etwas zum Ausdruck gebracht werden, was dem entspricht, wovon auf diesen Seiten die Rede war? Insgesamt fällt auf, dass dieser Begriff zunehmend dort auftaucht, wo es um technisch komplexe Systeme und Zusammenhänge geht, oder unterschiedliche „Gewerke“ harmonisch im Sinne des Auftraggebers zu einem größeren Ganzen zusammengefügt werden sollen. Dabei erwartet der Auftraggeber etwas „ästhetisch“ Ganzheitliches, welches den formalen Auflagen, wie auch funktionalen Anforderungen entspricht. Um deutlich zu machen, worum es hier geht, möchte ich den Hausbau mit dem Softwarebau für einen Augenblick nebeneinander stellen. Dabei denke ich weniger an die industriell betriebene Herstellung von Fertighäusern oder Fabrikhallen, sondern an etwas individuellere Gebäude – etwa Villen: Stellen Sie sich vor, Sie möchten Ihr ausreichend vorhandenes Geld in eine Villa stecken, die schwarzen Marmorboden im Flur, nordische Möbel im Wohnbereich, eine eigene Sauna, diverse Gästezimmer, Fenster mit roten Handgriffen und viel Platz für Ihre Bildergalerie haben soll. Sie wenden sich mit diesen Vorstellungen an eine Baufirma und erwarten von dieser, dass sie Ihnen Ihr Traumhaus realisiert. Firmen im Stile auch mancher Softwarehäuser würden die Realisierung Ihres Wunsches wohl wie folgt angehen: Es werden verschiedene Fachleute zum Kunden geschickt – alles Spezialisten ihres Faches –, die alle Wünsche zum Thema Fußböden, Badausstattung, Fenstertypen usw. aufnehmen. Diese werden sich nach ausreichend vielen Besprechungen auf einen

162

5 Wege zum Softwarebau von morgen

Lösungsweg einigen, bei dem man nach Möglichkeiten gesucht hat, all diese Anforderungen in sinnvoller Art und Weise miteinander zu verbinden. Mehr und mehr werden um diese ganzen Wünsche herum passende Statik, Verrohrungs- oder Schaltpläne entwickelt. Am Ende – und dies ist ein „Heile-Welt“ Szenario – werden all diese Kundenwünsche in ein statisch korrektes Gebäude eingearbeitet worden sein. Wie aber präsentiert sich das Gesamtergebnis? In den meisten Fällen wird Ihnen wohl ein Gebäude angeboten werden, das zweckmäßig ist und soweit wie möglich alle Anforderungen erfüllt. Insgesamt wird dieses Objekt aber wohl mehr den Eindruck eines mustergültigen Industriebaus als den einer Villa hinterlassen. – Obwohl alle Teilaspekte technisch korrekt umgesetzt wurden, fehlt der harmonisch aufeinander abgestimmte Gesamtansatz, der ein Gebäude in ein Objekt mit stimmigen Ambiente verwandelt. 5.2.1

IT-Architekten in Vergangenheit und Gegenwart

Was aber sind nun Architekten außerhalb der IT? – Folgt man entsprechenden Definitionen einschlägiger Nachschlagewerke, so befassen sich diese mit der technischen, wirtschaftlichen, funktionalen und gestalterischen Planung von Bauwerken und Gebäuden aller Art. Ihre Kernkompetenz ist das über das Bauen hinausgehende Schaffen von Architektur. Ebenso werden Architekten oft als Beauftragte des Ausschreibers/Auftraggebers oder des Bauherrn beschrieben und wickeln an dessen Stelle die Ausschreibung und in Zusammenarbeit mit dem Auftraggeber auch die Vergabe ab. Für den Begriff „Architektur“ (griech. Anfang, Ursprung und lat. tectum = Haus, Dach) finden sich überdies die folgenden Beschreibungen: • Architektur steht im Allgemeinen für die Auseinandersetzung mit Mensch und gebautem Raum und für die Kunst oder Wissenschaft des planvollen Entwurfs der gebauten menschlichen Umwelt. • Demgegenüber beschreibt eine Architektur in der Informatik meist das Zusammenspiel eines komplexen Systems. Sie definiert die Struktur und gegenseitige Beziehungen der Systemkomponenten, einschließlich der Schnittstelle zur Systemumgebung. • In Anlehnung an (Königswieser and Exner 2006, S. 48ff.) lassen sich Architektur und Design wie folgt voneinander abgrenzen: Die Architektur entscheidet, dass etwas stattfindet und was stattfindet, bildet also gewissermaßen die Überschriften, Eckpfeiler und Grobplanung. Mit dem Design hingegen wird entschieden, wie die inhaltliche, soziale, zeitliche und räumliche Dimension im vorgegebenen Rahmen gestaltet wird. Das Design ist also mit der Raumgestaltung, der Inneneinrichtung eines Gebäudes vergleichbar.

5.2 Architekten in der Softwareproduktion

163

Historische Betrachtungen

Modelle sind niemals wahr, aber zum Glück ist es bereits ausreichend, wenn sie nützlich sind. George Box Wie aber hat nun die Rolle des Architekten Zugang zu der IT gefunden und welche Erwartungen werden derzeit an diese Rolle geknüpft? Zu den ersten Pionieren in diesem Bereich gehörten Edgar Dijkstra, Fred Brooks Jr. sowie David Lorge Parnas. Sie führten den Begriff „Architektur“ damals in erster Linie für solche Software ein, die auf mehr als einer Maschine lief. Ihr Verständnis war es, die IT-Architektur als die konzeptionelle Struktur eines Computersystems aus der Sicht eines Programmierers zu definieren. Im Jahr 1968 stellte Edgar Dijkstra klar, wie wichtig es sei vom Spagetticode wegzukommen und stattdessen Software zu segmentieren und zu strukturieren, anstatt einfach nur ein richtiges Resultat zu erzeugen. Als Konsequenz aus diesem Ansatz schlug er Schichtenmodelle etwa für Betriebssysteme vor, um auf diese Weise zu einer hohen Wiederverwendbarkeit zu gelangen. Um 1975 definierte Fred Brooks Jr. System-Architektur wie folgt: „Unter der Architektur eines Systems versteht man die vollständige und detaillierte Spezifikation der Benutzerschnittstelle …“ Etwa seit Beginn der 1990er Jahre hat dieser Bereich der IT erheblich an Bedeutung gewonnen, wobei allerdings der Schwerpunkt auf Architekturstilen (z. B. Patterns), Sprachen und Dokumentationsformen für die Architektur (z. B. Modellierungssprachen) sowie anderen formalen Ansätzen bestand. Bereits in seinem eingangs zitierten Klassiker „The mystical manmonth“ (Brooks 1995) gibt Brooks eine sehr einfache, dafür aber prägnante Definition für Software-Architekten ab: „Der Architekt eines Systems ist wie der Architekt auf dem Bau: er ist der Vertreter des Kunden“. – Gestatten Sie mir daher die Zwischenbemerkung: Wie viele IT-Architekten tragen diesen Namen, sind aber letztendlich bestenfalls Bauzeichner oder Konstrukteure? Seit Mitte der 1990er Jahre spielen auch wissenschaftliche Institute eine zunehmend wichtigere Rolle bei der inhaltlichen Ausgestaltung dieser Thematik. So definierten Mary Shaw und David Garlan, beide von der Carnegie Mellon Universität, USA (Shaw and Garlan 1996), die Konzepte der Software-Architektur wie Komponenten, Konnektoren, Styles u.v.a., während man am „Irvine’s Institute for Software Research“ an den Architecture Styles, der Architekturbeschreibung, Sprachen oder auch dynamischen Architekturen arbeitete.

164

5 Wege zum Softwarebau von morgen

Brooks assoziierte sehr früh mit dem Stichwort „Einfachheit und Direktheit“ die Notwendigkeit einer solchen Rolle. Er schrieb dazu: „Es ist nicht genug, die Elemente und Regeln der Kombination zu lernen; man muss auch idiomatischen Gebrauch, eine ganze Überlieferung lernen, und wie die Elemente gemeinsam in der Praxis sind. Einfachheit und Direktheit gehen von begrifflicher Integrität aus. Jeder Teil muss dieselben Philosophien und dasselbe Abwägen von Desiderata reflektieren. Benutzerfreundlichkeit diktiert dann Einheit des Entwurfs, begriffliche Integrität.“ Sein Ansatz ist geprägt von der Aussage: „Ein Verstand, viele Hände“. Ihm ging es darum, dass es weniger zentraler Personen bedarf, um den Gesamtplan aufzustellen, auch wenn es später viele sind, die einen solchen Entwurf in die Wirklichkeit überführen. Sein Vorschlag zur Realisierung basierte auf zwei Techniken. Zum einen schlug er vor, die architektonische Planung von der Durchführung zu trennen, und zum anderen sprach er sich für eine neue Strukturierung der Softwareteams aus. Aus diesen Überlegungen heraus entwickelte später David Parnas seine Grundsätze zur Softwaretechnik: • Verbergen von Informationen, um so bessere Wartung und Wiederverwendbarkeit zu ermöglichen • Trennung der Schnittstelle von der Komponentenimplementierung • Beobachtungen an den unterschiedlichen separaten Charakteren von verschiedenen Programmelementen Derzeitiges Verständnis von IT-Architekten

Gegenwärtig wird das Verständnis von Architektur wohl am stärksten durch Kruchten und seinen 4 & 1-Ansatz geprägt. Dieser Ansatz betrachtet das entstehende Softwarekonstrukt aus den folgenden Perspektiven: der Prozesssicht, der logischen Sicht, der Implementierungssicht sowie der physikalischen Sicht des Projektes. Diese hiermit assoziierten Aufgabenbereiche der IT-Architektur genießen derzeit eine weite Verbreitung. Was allerdings an dieser Stelle anzumerken ist: Dieser Ansatz ist sehr technisch orientiert und berücksichtigt nicht die bereits bei Brooks anklingende Ganzheitlichkeit, die der Architektur zukommen sollte. Folgt man den Definitionen von Sewell (Sewell/Sewell 2002) bzw. Rechtin (Maier and Eberhardt 2002), so wird diese Lücke ebenfalls geschlossen. Hier werden die wichtigsten Aufgaben eines Architekten wie folgt zusammenfasst: Seine primäre Aufgabe besteht darin, „die Augen auf einen Punkt am Horizont weit über den architektonischen Phasen und der Fertigstellung der Blaupause oder des Modells gerichtet“ zu halten. Kunde, Architekt und Auftragnehmer haben letztendlich alle ein gemeinsames Ziel – und das besteht darin, Software im Sinne eines in sich geschlossenen

5.2 Architekten in der Softwareproduktion

165

Gesamtproduktes zu planen, zu realisieren und betriebsfähig zu machen. Es geht hier also um die Erstellung einer werthaltigen Lösung, die den Bedürfnissen seiner Nutzer in vollem Umfang gerecht wird. Um dies realisieren zu können bedarf es einer ganzen Menge Detailkenntnisse und Fähigkeiten, welche die Schnittstellen, Komponenten und Beziehungen der notwendigen technischen Systeme im Auge hat. Der (technische) Systemgedanke erlangt somit zentrale Bedeutung. Die Architektur muss immer wieder die Frage stellen, in welcher Form und wo ein System z. B. aus wiederverwendbaren Teilen einen höheren Nutzen bringt als die Generierung von Einzelkomponenten. Dabei ist zu klären, wie diese vernetzten Module am effizientesten und sichersten zusammenspielen, wie die Schnittstellen zur Außenwelt (Anwender, wie auch andere technische Systeme) möglichst effizient gestaltet werden können und wie das Ganze qualitativ hochwertig produziert werden kann. Um dies zu erreichen, müssen solche Systemarchitekten verschiedene übergeordnete Aufgabenbereiche abdecken: Aus der Menge aller Anforderungen und Randbedingungen muss ein Gesamtsystem vorstrukturiert und geplant werden, das in überschaubare, unabhängig voneinander realisierbare Einheiten zerlegt wurde. Dabei gilt es die wechselseitigen Einflussgrößen aufzuspüren und zu berücksichtigen. Immer wichtiger wird dabei, gerade in dieser frühen Phase sicherzustellen, dass geforderte Standards (z. B. Anforderungen an Sicherheit, Zugangsberechtigungen, Reaktionszeiten) an das kommende System planerisch berücksichtigt wurden. – Aus einer solch topologischen Planung heraus sind all diejenigen Detailarbeiten abzuleiten, die für den Nachrichtenaustausch zwischen Komponenten (etwa mittels Sequenzdiagrammen) notwendig sind oder die für die Definition von Funktionalitäten, Komponenten und Schnittstellen gebraucht werden. Sicht für das Ganze

Neben diesen eher softwaretechnisch orientierten Aspekten ist zu beobachten, dass sich schrittweise ein inhaltlicher Wandel dieser Rolle vollzieht und die Ansätze im Sinne von Brooks oder Rechtin an Bedeutung gewinnen und zunehmend das Berufsbild von IT-Architekten prägen. Dies drückt sich in der expliziten Forderung nach einer ganzen Reihe auch nichttechnischer Skills aus, die insbesondere bei komplexen Softwareprojekten von großer Bedeutung sind (vgl. Abb. 5.5). Die wichtigsten Aspekte lauten dabei: Visionär sein: Architekten müssen den anderen die Architektur vermitteln und sie von den Architekturentscheidungen überzeugen. Dazu gehört sowohl der Wille als auch die Fähigkeit, technische Sachverhalte für unterschiedliche Stakeholder angemessen aufzubereiten, zu präsentieren und zu

166

5 Wege zum Softwarebau von morgen

Abb. 5.5. Architekten – Meister mit Blick auf das Ganze

diskutieren. Dazu gehört es, dass der Architekt dem Auftraggeber sehr früh eine flexible Vorstellung von dem vermittelt, was das Endprodukt leisten kann und wie es ausschauen wird. Wenn Sie an die großen Bauwerke unserer Zeit denken, dann beginnen diese meist mit kleinen Modellen, anhand deren sich die Auftraggeber ein Bild über die Ergebnisse machen können. Solche Modelle bilden letztendlich die Diskussionsgrundlage bei der Detaillierung der Kundenwünsche, da ähnlich wie im Softwarebau der Kunde viele Ideen erst mit Hilfe eines solchen Demo-Objektes formulieren kann. Zuweilen ist zu fragen, wie viele späte Anforderungen wohl hätten vermieden werden könnten, wenn gerade der Architekt eines Softwareprojektes hier in geeigneter Weise mit den Auftraggebern kommunizieren würde. Vereinfacherer sein: Die wichtigste Regel für Architekten lautet: Vereinfache! Vereinfache! Vereinfache! Eine andere Lesart lautet: Weniger ist (manchmal) mehr! Einfache Strukturen sind leichter und günstiger realisierbar, einfacher verständlich, weniger fehleranfällig. Die zuverlässigste, preiswerteste und robusteste Komponente eines Systems ist diejenige, die erst gar nicht realisiert werden muss! Überzeuger sein: Sie müssen das Projektteam von Strukturen und Schnittstellen überzeugen, indem sie Vor- und Nachteile transparent darstellen und unter den Rahmenbedingungen und Einflüssen des konkreten Projektes gegeneinander abwägen.

5.2 Architekten in der Softwareproduktion

167

Berater sein: Software-Architekten beraten andere Projektbeteiligte in architekturrelevanten Fragestellungen. Dies betrifft Management und Auftraggeber bei der Projektplanung und -organisation, aber auch Auftraggeber und Analyseteams hinsichtlich der Machbarkeit von Anforderungen. Dazu unterstützen sie bei der Bewertung von Kosten und Nutzen von Anforderungen. Sie klären die Auswirkungen von Anforderungen auf die Struktur, die Realisierung und den Betrieb von Systemen. Sie informieren die Projektleitung zu (technischen) Risiken und müssen in der Lage sein, das Implementierungsteam entsprechend zu führen. Überdies beraten und informieren sie die Qualitätssicherung hinsichtlich der Kritikalität und Testbarkeit von Systembestandteilen. Qualitätsexperte sein: Architekten müssen die Güte der Architekturen bewerten können, um jederzeit den Grad der Zielerreichung zu kennen. Sie müssen wissen, ob und an welchen Stellen der Systeme nichtfunktionale Anforderungen (wie etwa Performance) riskant oder kritisch sind. Aus dieser objektiven Bewertung heraus können Architekten Maßnahmen zur Optimierung oder Risikominderung ableiten – in der Regel gemeinsam mit anderen Projektverantwortlichen. Entscheider sein: Am Ende eines erfolgreichen Projektes ist es sehr einfach, Entwurfsentscheidungen zu kritisieren. Zu diesem Zeitpunkt weiß man viel über Techniken, Produkte und auch Anforderungen, was Architekten mitten im Projektstress teilweise nur vermuten können. Architekten verfügen aus reinen Zeitgründen oftmals nicht über genügend Informationen, um optimale Entscheidungen zu treffen. Damit das Projekt weiterlaufen kann, müssen Architekten in solchen Fällen Mut zu (möglicherweise) suboptimalen Entscheidungen aufbringen. Partnering: In Anlehnung an die Erkenntnisse aus der Lean Production ist es notwendig, dass alle beteiligten Seiten in einem fairen Miteinander stehen. Folglich ist es sinnvoll, ja sogar notwendig, in enger Abstimmung und im Austausch miteinander zu bleiben. Hier betreten wir das bereits angedeutete dünne Eis in Bezug auf manche Produktionsmodelle, die zu prozesslastig sind und daher die „weichen“ Faktoren in einem Projekt vernachlässigen. Sowohl nach innen wie auch nach außen ist hiermit zu erreichen, dass sich die Menschen der jeweiligen Zielgruppe mit der Vorgehensweise bzw. den Inhalten identifizieren. Vereinfacher sein: Komplexität ist einer der größten Feinde im Softwarebau. Aus diesem Grunde fällt gerade den Architekten immer wieder die Rolle zu, Lösungen weiter zu abstrahieren, zu vereinfachen und abzurunden. Ein isoliertes Konzept zu erstellen ist dabei relativ einfach;

168

5 Wege zum Softwarebau von morgen

schwieriger wird es, wenn es darum geht, vernetzte, also systemische Zusammenhänge als solche zu durchschauen und hierin Lösungen zu finden. Multitalente gesucht

Nun ist klar, dass solche Multitalente nicht einfach aus dem Nichts entstehen. Möchte man den bereits zitierten „Oberschraubendreher-Effekt“ (Rieckmann 2000, S. 82) vermeiden und eben nicht aus guten IT-Designern oder Use-Case-Erfassern durch Änderung der Stellenbeschreibung einen schlechten Architekten machen, so bedarf es deutlich mehr! Was gebraucht wird sind Persönlichkeiten, die neben fachlicher Expertise und Erfahrung ein hohes Maß an sozialen Fähigkeiten mitbringen, die es weiterzuentwickeln gilt. Dies belegt übrigens auch die nachfolgende Studie: Folgt man Untersuchungen von Goleman (Goleman 1997; Goleman 2006), so kommt dieser zu dem Ergebnis, dass nur zu 33% die analytischen Fähigkeiten für herausragende Erfolge im Beruf verantwortlich sind, der deutlich größere Teil ist auf emotionale Intelligenz zurückzuführen. Dabei beschreiben die folgenden vier Bereiche für Goleman diese Form von Intelligenz: Selbsteinschätzung: Also die realistische Einschätzung der eigenen Persönlichkeit, das Erkennen und Verstehen eigener Motive, Bedürfnisse und Ziele sowie die Kenntnis um eigene Stärken und Schwächen. Selbstmanagement: Bestehend aus Selbstkontrolle, Anpassungsfähigkeit an sich ändernde Situationen, die Fähigkeit, die Initiative zu ergreifen und sich selbst zu motivieren. Empathie: Dies ist die Fähigkeit sich in andere Menschen hineinzuversetzen, angemessen auf deren Sicht zu reagieren und abweichende Sichten anderer zu akzeptieren. Soziale Kompetenz: Hierunter verbirgt sich ein Konglomerat an Fähigkeiten: die Fähigkeit an sich, zu kommunizieren, Führungsfähigkeiten zu haben sowie die Fähigkeit funktionierende Teams zu bilden und diese auch zu führen, generell Beziehungen zu knüpfen und diese – auch in Konfliktsituationen – zu pflegen. Damit wird deutlich: Nicht jeder technisch qualifizierte IT-Mitarbeiter bringt die Voraussetzungen mit, um diesem Rollenanspruch gerecht zu werden.

5.2 Architekten in der Softwareproduktion

5.2.2

169

IT-bewanderte Systemiker und Coaches gesucht Als wir das Ziel völlig aus den Augen verloren hatten, verdoppelten wir unsere Anstrengungen. Mark Twain

Stellen Sie sich vor, Sie haben Ihr Ziel längst erreicht und merken es nicht! Vage Ziele führen zu schwachen Ergebnissen, ebenso führt Orientierungslosigkeit zu Aktionismus und dies wiederum endet oftmals im berühmten GIGO-Prinzip51. Dabei gilt für den Projektalltag, dass dieser nur dann zu bewältigen ist, wenn eindeutig umrissene Ziele existieren, deren Erreichung in einem definierten Zeit- und Kostenrahmen realistisch ist. Das Definieren von Zielen und deren Erreichung beinhaltet somit mehr als nur Projektpläne zu schreiben oder pünktlich an definierten Meilensteinen anzukommen. Auch geht es hier nicht in erster Linie darum, zu Projektbeginn ein „Vision“-Dokument zu verfassen, dem zu entnehmen ist, was man in groben Zügen innerhalb dieses Projektes realisieren möchte. (Ein solches Dokument ist sinnvoll und ganze Prozessmodelle (z. B. der RUP) legen größten Wert darauf, dass ein solches Dokument frühzeitig erstellt wird!) Ebenso wenig geht es an dieser Stelle um die Durchsetzung und Überprüfung definierter Ziele. Stattdessen geht es um die Systematik dessen, was notwendige bzw. sinnvolle Ziele sind. Systemisch zu arbeiten bedeutet, sich mit Lösungsräumen zweiter Ordnung auseinanderzusetzen und genau hierfür auch Ziele zu formulieren. In diesem Sinne verstanden sind Fähigkeiten durch die betroffenen Mitarbeiter zu entwickeln, mit deren Hilfe diese geeignete Ziele auf der Metaebene erkennen und formulieren können. Konkret bedeutet dies den Wechsel von Lösungsorientiertheit hin zu Problemorientiertheit, wie es z. B. auch von CMMI (vgl. S. 51ff.) oder von Six Sigma52 (vgl. S. 58ff.) gefordert wird. Um neben den IT-fachlichen, wie auch sozialen Kompetenzen diese Handlungsparadigmen aktiv und effektiv anwenden zu können, ist es notwendig, dass die betroffenen Mitarbeiter hier über zusätzliche Kompetenzen verfügen. In Anlehnung an Arbeiten von Richmond über diejenigen Aspekte, die zu systemischem Denken und Handeln notwendig sind (Richmond 2000), ergeben sich die nachfolgenden Handlungs- und Kompetenzfelder:

51

52

GIGO steht für „Gargabe in, Garbage out“ – was ein Synonym für die folgende Aussage ist: „Unklare Ziele werden zwangsläufig unklare Ergebnisse liefern“ Six Sigma fordert u.a. die Überwindung der „Just do it“-Mentalität.

170

5 Wege zum Softwarebau von morgen

Vernetztes Denken und Handeln: Hierunter ist zu verstehen, dass die Fähigkeit vorhanden sein muss, weiter als nur in Ursache-Wirkungsbeziehungen zu denken. Vielmehr gilt es auch indirekte Wirkungen, insbesondere Rückwirkungen von den Wirkungen auf die „Ursachen“ (d. h. Rückkoppelungskreise) zu erkennen. Dynamisches Denken und Handeln: Der Zeitablauf spielt in Systemen eine entscheidende Rolle. Rückkopplungen können eskalierend oder stabilisierend wirken, sie können (insbesondere in Zusammenhang mit Zeitverzögerungen) zu Schwingungsprozessen führen. Eine dynamische, den Zeitablauf berücksichtigende Sichtweise ist im Allgemeinen auch notwendig, um Rückkoppelungen überhaupt erkennen zu können. Bei einer statischen Momentaufnahme werden meist nur einfache Ursache-Wirkungsbeziehungen wahrgenommen. Dabei beziehen sich solche Rückkopplungen nicht nur auf das aktuell entstehende Produkt, sondern schließen auch solche Bereiche mit ein, die sich als Folge der realisierten Produktidee zukünftig ableiten können (z. B. die Erkenntnis, dass statt eines Einzelproduktes eine Produktfamilie erstellt werden sollte). Modellbezogenes Denken und Handeln: Die Fähigkeit, nicht-kausale Zusammenhänge möglichst umfassend in kausale Abbildungen überführen zu können. Modelle brauchen auch stets entsprechende Darstellungsformen und so ist ein modellorientiertes Denken auch stets ein Denken, das sich um adäquate Darstellungsformen (z. B. Wirkungsdiagramme, Ontologien, etc.) bemüht. Systemorientiertes Denken und Handeln: „Systemisches Denken“ ist stets in der Gefahr, entweder zu einer philosophisch-esoterischen Kunst oder zu einer rein handwerklichen Modellier- und Simulationstechnik zu degradieren. Da Pragmatismus im Mittelpunkt stehen muss, geht es hierbei um die ganzheitliche Wahrnehmung und die Bewertungsfähigkeit der jeweiligen Wechselwirkungen. Kreatives Denken und Handeln: Wie wir bereits sahen, ist es notwendig eingefahrene Gleise verlassen zu können, gegebene Strukturen zu hinterfragen und nicht ausschließlich normativ zu handeln. Aktives Einbringen von kreativen Vorgehensweisen (vgl. S. 139ff.) spielen hierbei eine wichtige Rolle. Wissenschaftliches Denken und Handeln: Wissenschaftlich zu denken bedeutet, die Fähigkeit zu besitzen, durch Variantenbildung ähnlich wirkende Fälle durchzuspielen und diese im Nachgang überprüfen zu können. Somit steht quantitativ orientiertes Denken im Mittelpunkt, das in der Lage ist, rigoros die eigenen Hypothesen zu hinterfragen.

5.2 Architekten in der Softwareproduktion

171

Denken und Handeln in Kontinuen: In Kontinuen zu denken bedeutet, sich von einer Entweder-Oder-Welt gedanklich verabschiedet zu haben und stattdessen die Gesamtheit an Optionen in ihrem Variantenreichtum erkennen und nutzen zu können. Oder anders formuliert: Wurde der gedankliche Übergang aus einer schwarz-weißen Welt in eine Welt mit Grautönen vollzogen? Generisches Denken und Handeln: Diese Denkkompetenz bezieht sich auf die Möglichkeit, Dinge zu abstrahieren und zu verallgemeinern. Statt sich an speziellen Details festzumachen, ist es hierdurch möglich, innerlich einen Schritt zurückzutreten und einem Prozess zugrundeliegende generischen Strukturen und Handlungsmuster wahrzunehmen. Circulares Denken und Handeln: Dieser Bereich steht in enger Verbindung mit dem dynamischen Denken. Er schließt nicht nur Selbstreflexion ein, sondern gestattet auch Verhaltensmuster von Systemen zu studieren und zu bewerten. Auf diese Weise können systemimmanente Wirkfaktoren erkannt und bewertet werden. Ursachenforschung fängt intern an und fragt zunächst nach den eigenen Gründen, ehe nach externen Ursachen geforscht wird. Strukturelles Denken und Handeln: Hier geht es um Einheiten und Maße. Gesetzmäßigkeiten, Richtlinien und Vorgehensweisen spielen in dieser Form zu denken eine wichtige Rolle. Gleiches gilt für die Fähigkeit, abstrahierte Dinge in strukturierte Formen zu überführen. Insbesondere an der Schnittstelle zwischen nicht-kausaler und kausaler Welt ist diese Fähigkeit von großer Bedeutung, da andernfalls eine geordnete Abarbeitung von erkannten Problemen/Aufgaben nicht möglich ist. Operationales Denken und Handeln: Bei dieser Art zu Denken geht es um die Fähigkeit reale Dinge in Modellwelten zu überführen, also letztendlich aus einem abstrakten Ansatz ein möglichst allgemeingültiges praxistaugliches Modell abzuleiten. Coach sein

Nun war auf S. 166ff. die Rede von einer ganzen Reihe an Fähigkeiten, die ein Architekt im Softwarebau beherrschen sollte. Eine Fähigkeit ist dort allerdings nicht zu finden – und gerade diese ist notwendig, will man die hier vorgestellten Aspekte in die Praxis überführen. Es handelt sich hierbei um das Fähigkeitsprofil (nicht die Rolle!) eines Coaches. Wenn dieser Begriff hier verwendet wird, so steht er nicht für Beratung, Verhandlungsgeschick und die Fähigkeit Menschen zu führen, sondern definiert sich wie folgt:

172

5 Wege zum Softwarebau von morgen

Coaching ist in diesem Sinne verstanden keine fachliche Beratung, auch ersetzt sie diese nicht. Vielmehr geht es darum, dem jeweiligen Kunden professionell dabei zu helfen die eigenen, für ihn optimalen Lösungen herauszufinden. Dabei wird der Coach zum Sparringspartner und zum Gegenüber des Kunden. Er wirft Fragen auf, hinterfragt Positionen und legt verdeckte Ressourcen (oder Abhängigkeiten) offen. So wie klassisches Coaching (Rauen 2005) zum Ziel hat, die Optimierung der menschlichen Potentiale bei Einzelpersonen bzw. die wertschöpfende und zukunftsgerichtete Entwicklung von Organisation zu fördern, lässt sich dieses Konzept direkt auf die Erfassung der tatsächlichen Kundenbedürfnisse sowie der nachgelagerten IT-technischen Lösungsbeschreibung übertragen. 5.2.3

Erweitertes Rollenverständnis

Ist im traditionellen Softwarebau die Rolle des Architekten auf denjenigen Bereich beschränkt, bei welchem es um die reine Überführung von Anforderungen in IT-technische Lösungen geht, so sollte die vorangegangene Diskussion verdeutlicht haben, dass hier letztendlich zwei unterschiedliche Rollen in zwei ebenso unterschiedlichen Welten Architektur-Arbeit zu leisten haben. Dies betrifft zum einen den klassischen Bereich der IT-Architekten. Sie sind für die Erstellung der technischen Modellwelt zuständig (vgl. Abb. 5.2, S. 156ff.). Zum anderen betrifft es aber auch diejenigen, welche die Anforderungen zu erfassen haben. Ihnen obliegt die Modellierung der fachlichen Modellwelt. Insbesondere um eine bessere Abgrenzung zwischen solchen Tätigkeitsbereichen in den kausal geprägten Aufgabenfeldern beim Softwarebau von denen im nicht-kausalen Bereich zu erzielen, schlage ich daher den Begriff „Architekten“ als Synonym für diejenigen Rollen vor, die im nicht-kausalen Raum zu agieren haben. Somit ergeben sich zwei unterschiedliche Aufgabenfelder im Bereich Architektur: Anforderungsarchitekt: Seine primäre Aufgabe besteht darin, im Dialog mit dem Kunden bzw. den Stakeholdern das „strukturierte und vollständige Problemwissen“ zu ermitteln und dieses angemessen abzugrenzen und zu modellieren (vgl. S. 156ff.). Darüber hinaus obliegt es ihm, diese Modellwelt an den IT-Architekten so zu kommunizieren, dass er in der Lage ist, hieraus ein strukturiertes Lösungsmodell abzuleiten. – Seine Zielvorgabe besteht darin, die möglichst widerspruchsfreie und klar abgegrenzte Repräsentation der benötigten fachlichen Inhalte sowie deren wechselseitigen Abhängigkeiten zu ermitteln und zu modellieren.

5.2 Architekten in der Softwareproduktion

173

IT-Architekt: Seine Rolle ist hinreichend bekannt und wurde bereits ausführlich diskutiert. Die primäre Zielvorgabe des IT-Architekten besteht darin, eine möglichst klar strukturierte und auch in Zukunft einfach zu pflegende IT-technische Lösungsstruktur zu entwerfen, die in der Lage ist, die fachliche Repräsentation des Anforderungsarchitekten vollständig abzubilden. Wichtig ist bei diesem erweiterten Rollenverständnis, dass von Anfang an eine möglichst hohe Interaktion – nach Möglichkeit auch beim Kunden – zwischen beiden Architekten existiert. Sind diese beiden Rollen, die jeweils über dieselben systemischen Fähigkeiten verfügen sollten, bereits sehr früh bei der Anforderungsaufnahme beteiligt, so ist es sehr viel einfacher, zunächst verdeckte Fragestellungen zu adressieren. Ebenso kann auf diese Weise eine evolutionäre IT-Architektur bereits frühzeitig entwickelt werden. Dies ist für die frühe Projekt- und Kostenplanung von großer Bedeutung. Überdies kann ein solches Konzept schrittweise mit dem jeweils vorliegenden Kenntnisstand verfeinert werden. Herausforderung oder Anforderungen

Füge eine Kleinigkeit zu anderen und es wird am Ende ein großer Haufen sein. Ovid Dass dabei die Rolle eines solchen Anforderungsarchitekten keineswegs einfach ist, möchte ich anhand einiger Szenen aus dem ganz normalen Projektalltag deutlich machen. In einem solchen Prozess ist es wichtig, dass der Anforderungsarchitekt nicht nur die (technischen) Anforderungen herausarbeitet, sondern diese auch durch geeignete Interaktionsweisen hinterfragt und validiert, um so ggf. auf nachgelagerte Anforderungen zu stoßen. Dies ist übrigens eine Thematik, die im Bereich des Coachings sehr wohl bekannt ist und für die dort entsprechende Arbeitsweisen zur Verfügung stehen, um nicht bei den vordergründig angebotenen Anforderungen stecken zu bleiben, sondern durch entsprechende Interaktionen auf die tatsächlich notwendigen Anforderungen zu stoßen53: Der Kunde meint seine Anforderungen bzw. seine Wünsche recht genau zu kennen und hat sich hierfür schon einen Lösungs53

Im Coaching wird dies als „Präsentierproblem“ bezeichnet: der Coachee liefert eine ganze Reihe ihm wichtig erscheinender Fakten, ohne zunächst selbst zu erkennen, was als größeres Ganzes dahinter eigentlich verborgen liegt. Aufgabe des Coaches ist es daher zunächst, zusammen mit dem Coachee dieses nachgelagerte Thema herauszuarbeiten.

174

5 Wege zum Softwarebau von morgen

weg ganz oder teilweise überlegt. Dies ist sein Erwartungshorizont an ein zu entwickelndes Produkt und bildet somit die Basis seiner Anforderungen. Statt mit dem Erfasser von Anforderungen über finale Aspekte zu sprechen, also darüber, wofür die abzulösende Software derzeit gut ist (wenn es sie gibt), was sie kann oder nicht kann, in welchen Bereichen sie eingesetzt wird und was wiederum von diesen Bereichen an Leistungen erwartet wird, liefert der Kunde oftmals (halb-)fertige Wünsche, die ein Konglomerat seines fachlichen, wie auch technischen Wissens repräsentieren. Findet hier eine geeignete Interaktion zwischen Kunden und Anforderungserfassung statt, so können die eigentlichen Bedürfnisse, wie auch Problemzonen des Kunden herausgearbeitet werden und eine einvernehmliche IT-technische Planung stattfinden. Wird dieser Weg nicht in dieser Form beschritten, so werden in recht vielen Fällen die eigentlichen technischen, wie auch organisatorischen Problemzonen nur unzureichend ans Licht gebracht. Dies hat in der Praxis schnell fatale Folgen, da kurz vor Fertigstellung des Produktes oder sogar erst bei Inbetriebnahme auffällt, was fehlt bzw. wo nicht der Erwartungshorizont des Auftraggebers erreicht wurde. Dies hätte nicht geschehen müssen, wenn schon während der Anforderungserfassungsphase die tatsächlichen Bedürfnisse sauber herausgearbeitet worden wären. Statt also Fragen im Sinne von: „warum haben Sie diese Ziele?“ oder „wie löst Ihre derzeitige Applikation diese Aufgabe?“ zu stellen, sind Fragen im Stil von: „wozu verfolgen Sie diese Ziele?“ oder „welche Ergebnisse benötigen Sie von Ihrer Applikation?“ sehr viel zielführender. Nur dann, wenn die tatsächlichen Ziele des kommenden Systems möglichst vollständig bekannt sind, lassen sich hieraus nachhaltige Lösungen erarbeiten. Dies entspricht übrigens in erster Näherung dem Sinn von Vision-Dokumenten, wobei jedoch den Erstellern dieser Artefakte oftmals nicht in notwendigem Maß klar ist, warum sie ein solches Dokument abzufassen haben. Dabei geht mit der Zielermittlung einher, dass die inneren und äußeren Grenzen des (realen) Systems so explizit wie möglich zu klären sind. Dies ist notwendig, da nur auf diese Weise auch eine passgenaue technische Lösung ermittelt werden kann. Lassen Sie uns noch ein wenig tiefer in das wirkliche IT-Leben eintauchen und aus der Rolle eines Anforderungsspezialisten ein neu entstehendes Produkt betrachten. Sein Job besteht darin, Anforderungen für ein neues IT-System zu sammeln, diese zu gewichten und zu strukturieren. Gesetzt den Fall, die Aufgabe besteht darin, dass eine vorhandene Applikation durch ein Nachfolgemodell abgelöst werden soll, weil die vorhandene Software am Ende seines Life Cycle angekommen ist. Allein schon die Aussage „Ende des Life Cycle“ wird gerne als Absolutum betrachtet, ist aber ein Begriff so fest wie brüchiges Eis. Warum? Nun, lassen Sie uns diese Aussage aus verschiedenen Rollensichten betrachten.

5.2 Architekten in der Softwareproduktion

175

Die Domainspezialisten werden vermutlich stöhnen, da sie zwar eine alte, eher umständliche Technik vor Augen haben, die sicherlich renovierungsbedürftig ist – aber Ende des Life Cycle? „Nein, niemals! Endlich haben wir all die von uns als richtig betrachteten Features in dieser Software eingebaut – und jetzt wollt ihr gerade wieder bei Null anfangen? Es wird uns Jahre kosten, bis wir inhaltlich da wieder angekommen sind, wo wir jetzt stehen. Im Übrigen haben sich die meisten Kunden, die ja auch aus dieser Fachdomaine kommen, daran gewöhnt. Also definitiv kein Ende des Life Cycle, sondern vielmehr ein wenig Politur – aber bitte mehr auch nicht.“ Die IT-Kollegen sehen die Welt mit völlig anderen Augen. Bei der Vorstellung, dass sie noch länger mit Techniken arbeiten sollen, die ihrer Meinung nach schon fast völlig vom Markt verschwunden sind, nehmen sie oft unbefriedigt zur Kenntnis, dass von ihnen verlangt wird mit längst überholter Technik zu arbeiten. Sie sind begeistert von all den guten Nachrichten, die ihnen die Fachmagazine Monat für Monat ins Haus spülen und die von einer nahezu heilen Welt berichten, in der sich (fast) alle, eben nur nicht die eigene Firma, bewegen. Ihr Plädoyer ist daher oft sehr klar und einfach: „Die eingesetzte Basistechnologie ist schon längst hinfällig. Umstieg auf neueste Technologie – am besten ab morgen!“ Eine dritte Sicht könnte – neben vielen anderen – diejenige der Firmenleitung sein. Hier sieht man das Produkt aus Sicht der Verkaufszahlen und der Maintainance-Kosten. So lange es sich gut verkauft, ist die Welt in Ordnung, sinkt jedoch der Gewinn aufgrund wachsender Wartungskosten bzw. schlechterem Absatz, so ist Veränderung angesagt: Soll ein wenig bezahlbare Kosmetik betrieben werden, die mit einem Werbefeldzug gekoppelt wird? Muss man tatsächlich in eine Grundrenovierung investieren – oder ist es tatsächlich notwendig ein Nachfolgeprodukt zu entwickeln? Und auf wessen Aussagen hört man hier am besten; auf die der Domainspezialisten (= alter Stil, darunter verbesserte Technik) oder lieber auf die der IT-Kollegen (= alles mit neuester Technik)? Es ließen sich noch erheblich mehr Sichten zusammentragen. Ebenso werden diese unterschiedlichen Sichten in jeder einzelnen Gruppe intern neue Subvarianten aufweisen. Die zentrale Frage lautet daher: Wenn diese und weitere Sichten in einer Organisation vorhanden sind, wie stark werden dann die hieraus abgeleiteten Anforderungen von eben diesen Sichten eingefärbt sein? Und könnte es vor lauter Sichtenstreit passieren, dass die nachgelagerten Hauptprobleme, die zu zentralen Anforderungen umgemünzt werden müssten, nicht oder zu später erkannt werden? Aber zurück zur Ausgangssituation mit der Software, von der gesagt wird, man müsse daran etwas tun. – Wenn nun klar ist, dass etwas zu geschehen hat, so lassen sich aus den verschiedenen Interessensgruppen ein

176

5 Wege zum Softwarebau von morgen

Haufen unterschiedlich geprägter Ideen einsammeln. Es entsteht dabei so etwas wie eine Wunschliste! Jeder will am liebsten das aus seiner Sicht Beste – und dies natürlich in möglichst hoher Vollkommenheit, weil er die Ansicht vertritt, wenn schon Neu- oder Umbau, dann sollten wenigstens die zusätzlichen Funktionalitäten, von denen die eigene Fraktion schon immer träumte, mit integriert sein (die Domainspezialisten), dann muss das fertige Produkt technologisch unter den Top-Ten in den nächsten IT-Nachrichten erscheinen (die IT-Kollegen) – oder es muss so universell sein, dass es quasi als Gelddruckmaschine verwendet werden kann (der Vertrieb/das Management). Ist eine solche Sammlung von Wünschen tatsächlich dazu geeignet vernünftige Software zu einem vertretbaren Preis zu entwickeln? Ich fürchte nein! – Warum aber nein? – Da vorwiegend in Lösungen gedacht und argumentiert wurde, sind aus diesen heraus die oft langen Anforderungslisten entstanden, die jedoch nicht notwendigerweise zu smarten IT-technischen Lösungen führen müssen. – Was aber ist notwendig, um aus diesem Dilemma auszusteigen? Ist es letztlich nicht genau die bereits angesprochene Notwendigkeit, zunächst die Probleme hinter den Problemen zu ermitteln und hieraus dann Anforderungen zu formulieren? (Gause and Weinberg 1990). Anforderungserfassung ist also weit mehr als nur die Auflistung von Kundenwünschen. Es bleibt allerdings zu fragen, was dieses „Mehr“ ausmacht. Aufgrund der Komplexität von Softwareprojekten und der Unmöglichkeit, bestimmte Aspekte vorhersagen zu können, wird Anforderungs-Management, aber auch die Definition einer entsprechenden IT-Basistechnologie, zum „Hellsehen für Fortgeschrittene“, wie es Chris Rupp in einem Vortrag zur OOP 2006 formulierte (Rupp 2006). Dabei steckt ganz allgemein etwa 80% des Wissens eines Unternehmens in den Köpfen der Mitarbeiter und kann somit nur direkt von dort abgerufen werden. Somit muss eine Reihe zentraler Fragen geklärt werden: • Wie kann das notwendige Wissen aus den Köpfen der Mitarbeiter, wie auch aus Unterlagen gewonnen werden? • Wie kann das Durcheinander an Ideen, Gedanken und Wünschen geordnet und strukturiert werden? • Wie können Widersprüche und wechselseitige Behinderungen solcher Wünsche erst gefunden und danach aufgelöst werden? • Wie kann das gewonnene Wissen mit dem fachlichen Domainwissen abgeglichen und durch IT-technisches Domainwissen ergänzt werden? • Wie kann das gewonnene Wissen schrittweise mit den IT-Kollegen sinnvoll kommuniziert und abgeglichen werden?

5.3 Systemisches Arbeiten in der IT

177

Neben den eigentlichen Inhalten sind überdies eher formale Aspekte wie die folgenden zu berücksichtigen: Integration: Da die Anforderungen ein zentrales Element des weiteren Entwicklungsprozesses darstellen, sind sie in hohem Maße mit diesem integriert zu halten. Sie leiten sich vielfach aus Geschäftsmodell-Analysen ab, müssen in geeigneter Weise das Domain-Wissen der Aufgabenstellung mit anbieten, stellen die Grundlage für die IT-Architektur zu Verfügung und bilden für die eigentliche Umsetzungsphase das entscheidende Ausgangsmaterial für Test Cases und qualitative Überprüfungen. Flexibilität: Da jedes Projekt anders ist, lässt sich kein Schema für Anforderungs-Management ableiten. Infolgedessen gilt es die Meta-Strukturen bzw. -charakteristika zu erfassen. Änderbarkeit: Anders als beim Hausbau kommen viele wichtige Gedanken und Impulse erst während der eigentlichen Projektarbeit. Aus diesem Grund ist es notwendig zu solchen Anforderungen zu gelangen, die über ausreichende Flexibilität verfügen und so auch im laufenden Prozess nicht nur ihrem Inhalt nach, sondern auch mit den zugrunde liegenden Methoden in einem definierten Rahmen modifiziert werden können. Kurz: Wie kann eine strukturierte Wissensarchitektur erstellt werden, in der Wichtiges von Unwichtigem, sichtbare Abhängigkeiten von nicht sofort durchschaubaren Abhängigkeiten getrennt oder einfach nur Strukturen über das notwendige Wissen widerspruchsfrei zusammengetragen werden? Alles in allem also eine Aufgabe mit Herausforderung, bei der der Mensch im Mittelpunkt steht und bei der es darauf ankommt, dass hochkomplexe Zusammenhänge als solche freigelegt und dann erfasst werden, um zuletzt einen Wissenstransfer von Menschen auf Maschinen zu ermöglichen.

5.3 Systemisches Arbeiten in der IT Nachdem bereits der letzte Abschnitt aus der Praxis kam, möchte ich in diesem letzten Kapitel eine praxistaugliche Vorgehensweise vorstellen, die auf der Basis dessen operiert, was in diesem Buch diskutiert wurde. Der zugrunde liegende Prozess ist angelehnt an Vorgehensmodelle aus dem systemischen Coaching (Tomaschek 2006, S. 36ff.). Diese lassen sich in idealer Weise auf Interaktionen zwischen Kunden und Architekten der Anforderungserfassung bzw. Softwareplanung übertragen.

178

5.3.1

5 Wege zum Softwarebau von morgen

Ein Fallbeispiel

Ausgangssituation: Zwei Expertengruppen arbeiten zusammen, wobei die eine Gruppe aus den Architekten besteht, welche für die Erfassung der Anforderungen sowie die IT-Architektur herstellerseitig zuständig sind. (Der Kernsatz für die IT-Architekten lautet dabei: „Wir wissen, wie man Software baut, möchten aber lernen, was für eine Software hier konkret notwendig ist“). Die zweite Expertengruppe besteht aus denjenigen Personen (= Kunde), die die Expertise über den eigentlichen Problemraum haben. („Wir haben bisher diese oder jene Probleme so oder so gelöst und möchten hierfür künftig eine geeignete Software haben.“) Um zu einer für beide Seiten optimalen planerischen Lösung zu gelangen ist es notwendig, dass beide Gruppen ihr Expertenwissen in einem interaktiven Prozess miteinander austauschen und hierdurch schrittweise Anforderungen an die kommende Lösung entwickeln. Dieser Prozess lässt sich in den folgenden Schritten beschreiben: Kundenprobleme verstehen: Der Kunde präsentiert sein Problem (nicht seine Wünsche an die Technik!), die Hintergründe, warum dieser meint, hierfür Software einsetzen zu wollen und die Verbesserungen, die er sich hiervon erhofft. Die Aufgabe der Herstellungsexperten besteht darin, hier nachzufragen und die Sicht des Kunden zu verstehen, aber auch den Kontext zu ergründen, in dem der Wunsch nach einer IT-technischen Lösung besonders wichtig ist. Hierbei – und das ist eine wichtige Anleihe aus dem Coaching – legt der Kunde subjektiv die Wertigkeit seiner Problemfelder fest und nicht der Hersteller. Dieser hat vielmehr zu diesem Zeitpunkt die Aufgabe, diesen subjektiven Problemkreis auszuloten und zu verstehen, wo überall „der Schuh drückt“, bzw. ob es benachbarte Bereiche gibt, die möglicherweise hiermit in Bezug zu setzen sind. Ebenso ist es Bestandteil dieses Prozessschrittes herauszuarbeiten, was und wie sich Dinge aus Kundensicht ändern sollten, was explizit so bleiben muss und was möglicherweise die Ursache der aktuellen Engpässe ist. In jedem dieser Punkte stecken für den Hersteller bereits ungemein viele Detailinformationen über den Kontext einer zukünftigen Applikation, die in den späteren Planungsphasen von äußerster Wichtigkeit sind! Problemkreise verdichten: In diesem Folgeschritt geht es nun darum, die bisher erhobenen Informationen zu verdichten. Insbesondere interessiert hier, was bisher unternommen wurde, um kundenseitig auftretenden Problemen oder Engpässen entgegenzuwirken. Selbst wenn dies „nur“ mit Bordmitteln geschah, können hierdurch u. U. wichtige Hinweise über bisher unbenannte wechselseitige Abhängigkeiten oder andere zu berücksich-

5.3 Systemisches Arbeiten in der IT

179

tigende Ressourcen etc. zur Sprache kommen. Aus diesem Grund geht es an dieser Stelle keineswegs nur um technik- und prozesslastige Fragestellungen. Im Sinne des Systemgedankens sind auch solche Fragen von Wichtigkeit, die Aufschluss darüber geben, wie bestimmte Veränderungen, Engpässe oder auch Lösungen von den betroffenen Mitarbeitern oder dem Management aufgenommen wurden. Dies liefert weitere wichtige Randinformationen. Zu diesem Zeitpunkt können übrigens besonders zirkuläre54 oder projektive55 Fragen deutlich weiterhelfen. Mit Hilfe dieser Fragetechniken wird man in die Lage versetzt, auch in solche Bereiche vorzustoßen, an die der Kunde zunächst gar nicht denkt. Das Team des Herstellers hat also in diesem Prozessschritt die wichtige Aufgabe, den Kunden aus den eigenen Begrenzungen seines Präsentierproblems herauszuheben und ihm einen sehr viel breiteren Zugang zu seiner eigenen Auftragsthematik zu verschaffen. Dies ist insofern ein sehr wichtiger Schritt, als es beiden Seiten dabei hilft, die tatsächlichen Problemfelder besser einzukreisen und abzugrenzen. Auf diese Weise ist es bereits im Vorwege möglich, sehr viel sauberere Vorarbeiten für die spätere Definition eines technischen Lösungskonzeptes zu erzielen. Technische Ideen entwickeln: Hier nun kommt das erste Mal die Technik ins Spiel. Natürlich hat der Kunde fast immer Vorstellungen, Erwartungen oder Vorgaben in Bezug auf technische Lösungen. Diese gilt es aufzunehmen und im Dialog durchzuspielen. Da fast kein technisches System in ein IT-Vakuum hinein appliziert wird, geht es hier in erster Linie darum, technische Lösungselemente und -wege (auf einer groben Ebene) in solch eine Diskussion einzubringen und mit dem Kunden durchzuspielen, wie sich ein solches System wohl in der eigenen Infrastruktur verhalten würde56. Durch diesen Dialog wird letztendlich die vorhandene bzw. geplante technische Infrastruktur ausgelotet, die möglicherweise Einfluss auf oder auch Schnittstellen mit dem zu entwickelnden Produkt haben 54

55

56

Eine zirkuläre Frage könnte hier sein: „Stellen Sie sich vor, Sie seien Mitarbeiter XY, was meinen Sie wohl, wie der über dieses Feature denken würde?“ oder: „Gesetzt den Fall, Sie würden für die Konkurrenz arbeiten – wie würden Sie dann an das Problem herangehen?“ Eine projektive Frage wäre in diesem Zusammenhang: „Gesetzt den Fall, Sie hätten dieses Feature in Ihrer Applikation und Sie würden jetzt damit arbeiten – würde es tatsächlich Ihre Probleme lösen oder möglicherweise neue Probleme bzw. Wünsche aufwerfen?“ Ein Satz wie etwa folgender: „Stellen Sie sich vor, Ihre Applikation läuft dann hier mit der Datenbank des Herstellers XY …“ kann z.B. beim Kunden auslösen: „Ach ja, wir hatten da doch Probleme mit der XY-Software in einem ganz anderen Zusammenhang, nämlich …“

180

5 Wege zum Softwarebau von morgen

kann. Diese Vorgehensweise reduziert deutlich die sonst häufige späte und somit teure Entdeckung: „Ach, daran hatten wir ja gar nicht gedacht!“ Hier also entsteht bereits in einer recht hohen Systematik ein technischer Lösungsraum, der die Grundlage für das zu entwickelnde IT-Architekturkonzept darstellt. – Es wird hieran übrigens deutlich, weshalb es wichtig ist, dass bei dieser Vorgehensweise ein IT-Architekt direkt beteiligt ist. Zum einen kann dieser von Anfang an das Gesamtproblem besser verstehen, zum anderen erhält er jetzt bereits aus erster Hand erste technische Rahmenbedingungen, die er klären bzw. berücksichtigen muss. Ideallösung entwickeln: Oftmals können Projekte gerade auch aus monetären oder zeitlichen Gründen nicht in voller Schönheit realisiert werden. – Allerdings ist es häufig so, dass nachgelagert dann doch noch die eine oder andere Ergänzung beauftragt und letztendlich als „Erker“ an die vorhandene Applikation angebaut wird. In diesem Schritt geht es darum, ein größeres Ganzes zu entwickeln – also sich in einer idealen Welt zu überlegen, wie in einem übernächsten Schritt wohl die Endausbaustufe im Kontext mit anderen Systemen, der hauseigenen Strategie etc. aussehen würde. – Der Hintergrund zu diesem Schritt liegt auf der Hand. Sehr viele Applikationen wachsen generisch: Man möchte am Anfang nur eine kleine Applikation. Hat man diese jedoch, dann beginnen die Wünsche zu sprudeln. Durch die teilweise Vorwegnahme dieses Wunscherzeugungsphänomens ist selbst dann, wenn nur ein Teil dieser Wünsche im ersten Ansatz Wirklichkeit werden, ein sehr viel klareres IT-technisches Planungskonzept möglich, das von vornherein Wildwuchs eindämmt. Dies ist für die Lifecyclekosten der zukünftigen Applikation wichtig, da mit zunehmender „Vererkerung“ die Kosten für Produktpflege und Weiterentwicklung stetig steigen. Vorgehensweisen festlegen: Aus der – immer noch, auch anforderungstechnischen – Ideallösung ist nun der Weg zurück in die Wirklichkeit zu finden. Jetzt gilt es mit dem Wissen um das optimale Zielprodukt zu fragen, wie dieser Kuchen sinnvoll zu schneiden ist, damit die primären Kundenwünsche bald und im definierten Kostenrahmen erfüllt werden können, die zu entwickelnde technische Infrastruktur aber weit genug ausgelegt ist, um auch für zukünftige Entwicklungsschritte tragfähig zu sein. – Auch in diesem Prozessschritt geht es nicht nur um eine rein sachlich-fachliche Diskussion, sondern es gilt auch zu klären, ob diese Vorgehensweise die Akzeptanz der Stakeholder finden wird. Zu diesem Zweck hilft wieder zirkuläres oder projektives Fragen, wie es bereits weiter oben genutzt wurde.

5.3 Systemisches Arbeiten in der IT

181

Inhaltlich detaillieren und dokumentieren: Nun ist der Punkt erreicht, von welchem aus schrittweise klassisches Anforderungs-Management wieder zum Zug kommt. Nun gilt es den groben Rahmen zu detaillieren und im Dialog mit dem Nutzer Detailantworten zu finden. Zugleich ist es an der Zeit, das erworbene Wissen in entsprechend strukturierter Form, etwa in Anforderungsdiagrammen, Ontologien oder auf andere Weise zu hinterlegen. Dabei hat ein alter Satz immer noch seine Berechtigung: „Architektur zu definieren bedeutet das Finden des besseren Übels“. Dies gilt sowohl für die Anforderungs-Architektur, wie auch die IT-technische Architektur. 5.3.2

Der Weg ist das Ziel

Der Nutzen, den ein Unternehmen aus der konsequenten Integration von den hier vorgestellten Ansätzen zur Anforderungs- und IT-Architektur ziehen kann, geht deutlich über Einzelprojekte hinaus. Durch deren Wiederverwendung, Strukturierung bzw. Standardisierung werden Wege vorbereitet, die im Blick auf neue Produkte innerhalb einer bestimmten Wissensdomaine, aber auch im Blick auf Produktfamilien zu sehr viel vollständigeren Lösungen führen. Diese Lösungen lassen sich sehr viel umfassender und schneller implementieren. Mit Blick auf die Zukunft sind derart gewonnene und aufbereitete Informationen sehr viel mehr dazu geeignet, automatisierte Verfahren zur Softwareerstellung einzusetzen, mit deren Hilfe Einzelprodukte oder auch Produktfamilien generiert werden können. Warum? Durch die Ganzheitlichkeit der gewählten methodischen Ansätze sind die verwendeten Architekturen in Sachen Flexibilität und Vollständigkeit optimiert, auch sind sie in einem hohen Maß bei ähnlichen Projekten wiederverwendbar. Somit bündelt die mit systemischen Mitteln gewonnene Architektur optimal projektübergreifendes, unternehmensweites Know-how in Form explizit aufgezeichneter Modelle oder Dokumente und zeigt zugleich sinnvolle Grenzen oder aber Schnittstellen zu anderen Wissensdomainen oder IT-technischen Lösungen auf. Damit ist das realisierbar, wovon David Parnas sprach, als er sagte, dass dieser „… sehr undurchsichtige Kuchen immer wieder neu geclustert und geschnitten …“ werden müsse. Ein Ordnen und Abgrenzen also, das mit Hilfe systemischen Denkens und Handelns sehr viel effektiver und umfassender vollzogen werden kann.

6 Epilog

„Selbstverantwortliche Mitarbeiter handeln innovativer und kreativer, zuverlässiger und kostenbewusster.“ Roland Benz Haben Sie sich jemals gefragt, wie die Wal- und Delfintrainer des Vergnügungsparks Sea World es schafften, dass Shamu, ein fast zehn Tonnen schwerer Wal, Kunststücke macht und sieben Meter aus dem Wasser springt? Die Trainer bringen den Wal dazu, über ein Seil zu springen, das höher über der Wasseroberfläche ist, als es sich die meisten vorstellen können. Es ist eine große Herausforderung – genauso groß wie die Herausforderung, vor die wir uns als Eltern, als Coach oder als Führungskraft gestellt sehen. Können Sie sich vorstellen, wie ein typischer amerikanischer Manager an solch eine Situation herangehen würde? Zuallererst würde er das Seil an der Sieben-Meter-Marke aufhängen – damit man gleich sieht, wo es langgeht. Diese Vorgehensweise nennt er „Ziele setzen“ oder „strategische Planung“. Ist das Ziel erst einmal klar definiert, muss er sich nur noch Gedanken machen, wie er den Wal am besten motiviert. Er nimmt einen Eimer voll Fische und hängt ihn über das sieben Meter hohe Seil. Der Wal bekommt erst etwas, wenn er tatsächlich so hoch springt. Dann gibt er ihm Anweisungen. Er ruft von seinem trockenen Hochsitz aus: „Los, Wal, spring!“ Aber der Wal bleibt da, wo er ist. Wie gehen nun die Trainer bei Sea World vor? Ihr wichtigster Grundsatz besteht darin, das gewünschte Verhalten – in diesem Fall den Sprung des Wals oder Delfins über das Seil – von Anfang an zu bestärken. Sie gestalten also die Umgebung so, dass der Wal niemals versagen kann. Sie fangen mit dem Seil unter der Wasseroberfläche an, in einer Position, in der der Wal gar nicht anders kann, als das zu tun, was von ihm erwartet wird. Jedes Mal, wenn der Wal über das Seil schwimmt, bekommt er eine positive Verstärkung: Er bekommt Fisch und wird gestreichelt und wird dadurch – und das ist das Wichtigste – in seinem Tun bestärkt. Was aber geschieht, wenn der Wal unter dem Seil hindurchschwimmt? Nichts – kein elektrischer Schock, keine konstruktive Kritik, kein entwick-

184

6 Epilog

lungsförderndes Feedback und keine Eintragung in die Personalakte. Walen wird einfach nur beigebracht, dass ihr negatives Verhalten keine Beachtung findet. Positive Verstärkung ist die Basis dieses einfachen Prinzips, das solche spektakulären Resultate hervorbringt. Und wenn der Wal anfängt, öfter über das Seil zu schwimmen, als unter ihm hindurch zu tauchen, fangen die Trainer damit an, das Seil immer höher zu halten. Dies muss jedoch allmählich und in kleinen Schritten erfolgen, damit der Wal nicht physisch oder emotional unter Stress gerät. So manche Veränderung – gerade auch im beruflichen Alltag – braucht viel Geduld, viele kleine Schritte und viel Ermutigung der beteiligten Mitarbeiter. Viel Erfolg! Ihr Patrick Hamilton

7 Anhang

7.1 Abbildungsverzeichnis Abb. 2.1. Folgen fehlender Ziele............................................................... 17 Abb. 2.2. Organisatorische Voraussetzungen für gute Software............... 38 Abb. 2.3. Passung oder Anpassung ........................................................... 41 Abb. 2.4. Softwaretechnik gestern, heute und morgen.............................. 47 Abb. 3.1. Was Kunden wünschen und Entwickler oft nicht liefern .......... 63 Abb. 3.2. Das Eisbergprinzip .................................................................... 67 Abb. 3.3. Anforderungen und Kundenzufriedenheit nach Kano ............... 71 Abb. 3.4. Was gute Software berücksichtigen muss ................................. 74 Abb. 3.5. Softwarebau als System verstanden........................................... 90 Abb. 3.6. Scheinbar einfache Systeme ...................................................... 91 Abb. 3.7. Fähigkeitsbereiche für den Bereich der Softwareplanung ....... 102 Abb. 3.8. Ingenieure und „Künstler“ im Duett........................................ 112 Abb. 4.1. Eine Denksportaufgabe............................................................ 115 Abb. 4.2. Personelle Interaktion – Schlüssel zum Verständnis ............... 124 Abb. 4.3. Symmetrisch-komplementäre Beziehungsnetzwerke .............. 128 Abb. 4.4. Wissenspyramide und Wissenssphären ................................... 147 Abb. 4.5. Aus Individualwissen wird formales Wissen........................... 152 Abb. 5.1. Vom Gedanken zum Produkt................................................... 155 Abb. 5.2. Von der Idee zur technischen Lösung...................................... 156 Abb. 5.3. Handlungszonen im Softwarebau ............................................ 158 Abb. 5.4. Herkömmlicher und systemischer Softwarebau ...................... 159 Abb. 5.5. Architekten – Meister mit Blick auf das Ganze....................... 166

7.2 Weiterführende Literatur Softwareentwicklung Agrawal, D. P., United States. Army Research Office. Scientific Services Program, et al. (1986). Proceedings of the workshop on future directions in computer architecture and software: May 5–7, 1986, Seabrook Island, Charlston sic, SC. Research Triangle Park, NC, U.S. Army Research Office. Aksit, M. (2002). Software architectures and component technology. Boston; London, Kluwer Academic Publishers.

186

7 Anhang

Albin, S. T. (2003). The art of software architecture: design methods and techniques. Indianapolis, Ind., Wiley Computer Publisher. Ambler, S. W. (1998). Building object applications that work: your step-by-step handbook for developing robust systems with object technology. Cambridge, UK; New York NY, Cambridge University Press. Ambler, S. W. (2003). The elements of UML. New York NY, Cambridge University Press. Braude, E. J. (2001). Software engineering: an object-oriented perspective. New York, J. Wiley. Braude, E. J. (2004). Software design: from programming to architecture. New York, J. Wiley. Carroll, J. M. (2002). Human Computer Interaction in the New Millenium. New York, ACM Press. Cooper, A. and R. Reimann (2003). About Face 2.0: The Essentials of Interaction Design. Indianapolis, Wiley Publishing. Dikel, D. M., D. Kane, et al. (2001). Software architecture: organizational principles and patterns. Upper Saddle River, NJ, Prentice Hall PTR. Evans, E. (2004). Domain-Driven Design. Boston, Pearson Education Inc. Farmer, D. and W. Venema (2005). Forensic Discovery. Upper Saddle River, NJ, Pearson. Frankel, D. (2003). Model driven architecture: applying MDA to enterprise computing. Indianapolis, Ind., Wiley. Gamma, E. (1997). Design Patterns, Elements of reusable Object oriented Software. Reading, Mass., Addison Wesley. Garrett, J. J. (2003). The Elements of user experience. New York, AIGA, New Riders. Hatley, D., P. Hruschka, et al. (2003). Komplexe Software-Systeme beherrschen. Bonn, mitp-Verlag. Heers, R. (2006). Just do it. Göttingen, Cuvillier Verlag. Jackson, P. (1986). Experten-Systeme. Bonn, Addison Wesley. Larman, C. (2002). Applying UML and Pattern; an introduction to object-oriented analysis and design and the unified process. New York, Prentice Hall PTR. Larman, C. (2004). Agile & Iterative Development, A managers guide. Boston, Pearson Education. Maguire, S. (1995). Strategien der Softwareentwicklung. Unterschleißheim, Microsoft Press. Maier, M. W. R. E. (2002). The Arts of systems Architecting. London, New York, CRC Press. Malveau, R. and A. Bower (1999). Software architecture a programmer’s field manual. Indianapolis, IN, Macmillan Technical Publishing. Malveau, R. C. and T. J. Mowbray (2001). Software Architect Bootcamp. Upper Saddle River, NJ, Prentice Hall PTR. Mechler, B. (1995). Intelligente Informationssysteme. Paris, Addison-Wesley. Oestereich, B. (2001). Objektorientierte Softwareentwicklung: Analyse und Design mit der Unified modelling language. München, Oldenbourg. Rupp, C. (2004). Systemanalyse kompakt. Heidelberg, Elsevier.

7.2 Weiterführende Literatur

187

Seacord, R. C., D. Plakosh, et al. (2003). Modernizing legacy systems: software technologies, engineering processes, and business practices. Boston, AddisonWesley. Sewell, M. T. and L. M. Sewell (2002). The Software Architects Profession. Upper Saddle River, NJ 07458, Prentice Hall PTR. Skambraks, J. and M. Lörcher (2002). Projekt Marketing. Offenbach, GABAL Verlag. Starke, G. (2005). Effektive Software-Architekturen. München, Wien, Carl Hanser Verlag. Subramanian, N. and L. Chung (2003). Adaptable software architectures. Amsterdam, Elsevier. Subramaniam, V. (2006). Practices of an Agile Developer. Pragmatic Programmers. Raleigh, NC, Pragmatic Bookshelf. Watson, M. (1993). Portable GUI development with C++. Blue Ridge Summit, PA, McGraw Hill. Qualität und Prozesse George, M., D. Bowlands, et al. (2004). What is lean Six Sigma. New York, McGraw-Hill. George, M. L., D. Rowlands, et al. (2005). Lean Six Sigma Pocket Toolbook. New York, Mc Graw Hill. Grundmann, M. (2005). „A CMMI Maturity Level 2 assessment of RUP.“ The Rational Edge, 12/2005. James Herbsleb, A. C., et al. (1994). Benefits of CMM-Based Software Process Improvement: Initial Results, Software Engineering Institute. Köhler, P. T. (2005). ITIL. Heidelberg, Springer. Rifkin, S. (2001). „Climbing the SEI CMM Makes a Difference on Software Projects.“ IT Metrics Strategies, The Cutter Consortium 04/2001. Versteegen, G., P. Kruchten, et al. (2000). Projektmanagement mit dem Rational Unified Process, Xpert.press, Springer. Versteegen, G. et al. (2003). Software-Management. Beherrschung des Lifecycles. Heidelberg, Springer. Gesprächsführung und Linguistik Finke, J. (1999). Beziehung und Intervention. Stuttgart, New York, Georg Thieme Verlag. Galli, J. (2004). Die Kunst sich selbst zu präsentieren, Galli Verlag Europa. Heller, R. (2002). Richtig Kommunizieren. London, Dorling Kindersley. Jackson, A. (2001). Jetzt habe ich genug! Kreative Konfliktbewältigung. Zürich, Oesch. Motamedi, S. (1999). Konfliktmanagement: vom Konfliktvermeider zum Konfliktmanager. Offenbach, GABAL Verlag. Pawlowski, K. R., Hans (2003). Konstruktiv Gespräche führen. Hamburg, Rowohlt Taschenburg Verlag. Schneider, W. (2006). Wörter machen Leute. München, Piper Verlag.

188

7 Anhang

Schulz von Thun, F. (1981). Miteinander Reden – Störungen und Klärungen. Reinbek, rororo. Schulz von Thun, F. (1989). Miteinander Reden – Stile, Werte und Persönlichkeitsentwicklung. Reinbek, rororo. Schulz von Thun, F. (1998). Miteinander Reden – Das „Innere Team“ und situationsgerechte Kommunikation. Reinbek, rororo. Psychologie Adams, J. (2005). Think! Berlin, Uhlstein. Asendorpf, J. (1996). Psychologie der Persönlichkeit – Lehrbuch. Berlin, Heidelberg, New York, Springer Verlag. Busch, B. (2002). Denken mit dem Bauch. Hannover, Kösel Verlag. Dutke, S. (1994). Mentale Modelle: Konstrukte des Wissens und Verstehens. Göttingen, Verlag für angewandte Psychologie. Frankl, V. E. (2006). Das Leiden am sinnlosen Leben. Freiburg, Basel, Wien, Herder Verlag. Frankl, V. E. (2006). Man’s search for meaning. Boston, Beacon Press. Hobson, P. (2002). Wie wir denken lernen. Düsseldorf, Walter Verlag. Lefrancois, G. R. (1994). Psychologie des Lernens. Berlin, Heidelberg, New York, Springer Verlag. Lukas, E. (2003). Psychotherapie in Würde. Weinheim, Basel, Berlin, Beltz Taschenbuch. Solms, M. and O. Turnbull (2007). Das Gehirn und die innere Welt. Düsseldorf, Patmos Verlag. Spitzer, M. (2007). Lernen, Gehirnforschung und die Schule des Lebens. München, Elsevier Verlag. Watzlawick, P. (2005). Wie wirklich ist die Wirklichkeit. München, Piper Verlag. Wheeler, G. (2006). Jenseits des Individualismus, Für ein neues Verständnis von Selbst, Beziehung und Erfahrung. Wuppertal, Peter Hammer Verlag. Coaching Lippmann, E. (2006). Coaching, Angewandte Psychologie für die Beratungspraxis. Heidelberg, Springer Medizin Verlag. Logan, R. S. C. (2003). Das Coaching 1x1. Gießen, Brunnen Verlag. Möller-Brix, G. (2002). Systemisch Beraten: das Praxisbuch mit Methodenanleitung und Beispielen. Hamburg, Books on Demand, Norderstedt. Morgan, H., P. Harkins, et al. (2004). The Art and Practice of Leadership Coaching. Hoboken, NJ, Wiley. Radatz, S. (2004). Beratung ohne Ratschlag. Wien, Verlag systemisches Management. Radatz, S. (2006). Einführung in das systemische Coaching. Heidelberg, Carl Auer Verlag. Radatz, S. (2007). Coaching-Grundlagen für Führungskräfte. Wien, Verlag Systemisches Management. Spieß, E. (2003). Effektiv kooperieren. Weinheim, Beltz.

7.2 Weiterführende Literatur

189

Schoenaker, T. (2006). Mut tut gut – das Encourageing-Training. Sinntal, RDI Verlag. Tomaschek, N. (2006). Systemic Coaching. Heidelberg, Auer-Verlag. Veränderungsmanagement Braun, R., H. Gawlas, et al. (2005). Die Coaching-Fibel. Wien, Linde Verlag. Covey, S. R. (2004). The 7 habits of highly efficient people. London, Syndey, FranklinCovey. Covey, S. R. (2004). The 8th habit. New York, Free Press. Gardner, H. (2004). Changing minds. Boston, MA, Harward Business School Press. Gauthier, G., C. Frasson, et al. (2000). Intelligent tutoring systems: 5th International Conference, ITS 2000, Montreal, Canada, June 19–23, 2000: proceedings. Berlin; New York, Springer Verlag. Kaminski, E. (2004). 30 Minuten für mehr Erfolg durch Coaching. Offenbach, GABAL Verlag. Koch, R. (2000). Die Powergesetze des Erfolgs. Frankfurt, Campus Verlag. Lermer, S. (2004). „Erfolgs Coaching Training 2005.“ Lippmann, E. (2006). Coaching, Angewandte Psychologie für die Beratungspraxis. Heidelberg, Springer Medizin Verlag. Logan, R. S. C. (2003). Das Coaching 1x1. Gießen, Brunnen Verlag. Morgan, H., P. Harkins, et al. (2004). The Art and Practice of Leadership Coaching. Hoboken, NJ, Wiley. Radatz, S. (2004). Beratung ohne Ratschlag. Wien, Verlag systemisches Management. Scott-Morgan, P., E. Hoving, et al. (2001). Stabilität durch Wandel. Frankfurt/Main, Campus Verlag. Stähle, M. (2003). Die vier Phasen für erfolgreiche Veränderungen. So steigen Sie auf. Konstanz, Aufsteiger Verlag. Konfliktmanagement Conrad, B., B. Jacob, et al. (2003). Konflikt-Transformation, Konflikte werden gelöst – Unterschiede bleiben. Paderborn, Junfermann Verlag. Fisher, R., W. Ury, et al. (2004). Das Harvard-Konzept. Frankfurt/Main, Campus Verlag. Jackson, A. (2001). Jetzt habe ich genug! Kreative Konfliktbewältigung. Zürich, Oesch. Jiranek, H. and A. Edmüller (2007). Konfliktmanagement. Planegg, Rudolf Haufe Verlag. Motamedi, S. (1999). Konfliktmanagement: vom Konfliktvermeider zum Konfliktmanager. Offenbach, GABAL Verlag. Oboth, M. and G. Seils (2006). Mediation in Gruppen und Teams. Paderborn, Junfermann Verlag. Wittschier, B. N. (2004). 30 Minuten für erfolgreiche Mediation in Unternehmen. Offenbach, GABAL Verlag.

190

7 Anhang

Fragen/Fragetechniken Csikszentmihalyi, M. (2003). Flow im Beruf. Stuttgart, J.G. Cotta'sche Buchhandlung. Csikszentmihalyi, M. (2007). Kreativität: Wenn Sie das Unmögliche schaffen und Ihre Grenzen überwinden. Stuttgart, Klett Cotta. Eales-White, R. (1998). Ask the right questions: how to get what you want every time and in any situation. New York, McGraw-Hill Companies. Scherer, H. (2005). 30 Minuten für eine gezielte Fragetechnik. Offenbach, GABAL Verlag. Simon, F. B. and C. Rech-Simon (2007). Zirkuläres Fragen, systemische Therapie in Fallbeispielen. Heidelberg, Carl Auer. Tanaka, Y. (2003). Meme media and meme market architectures: knowledge media for editing, distributing, and managing intellectual resources. Hoboken, NJ, Wiley-Interscience. Kommunikation/Wissensmanagement Aschoff, F. R., F. Schmalhofer, et al. (2004). Knowledge Mediation. ECAI-2004. Eales-White, R. (1998). Ask the right questions: how to get what you want every time and in any situation. New York, McGraw-Hill Companies. Heilmann, H., L. J. Heinrich, et al. (1996). Information Engineering. München, Oldenbourg Verlag. Jackson, P. (1986). Expertensysteme. Bonn, Addison Wesley. Koenig, M. E. D. S., T. Kanti (2004). Knowledge management – Lessons learned. Medford, NJ, asis&t, American Society for Information Science and Technology. Konar, A. and L. Jain (2005). Cognitive Engineering. London, Springer. Mérö, L. (2002). Die Grenzen der Vernunft, Kognition, Intuition und komplexes Denken. Reinbek, rororo. Nichols, M. P. (2000). Die wiederentdeckte Kunst des Zuhörens. Stuttgart, KlettCotta. Rupp, C. (2003). Reden Sie Klartext, Psychotherapie für Anforderungen in der Softwareentwicklung. manage it. 06/2003: 38 – 42. Rupp, C. (2004). Requirements-Engineering und -Management. München, Wien, Carls Hanser Verlag. Rupp, C. (2004). Systemanalyse kompakt. Heidelberg, Elsevier. Rupp, C. (2006). Hellsehen für Fortgeschrittene: Die Kunst Anforderungen professionell zu ermitteln. OOP 2006, München, SIGS DATACOM. Schütt, P. (2000). Wissensmanagement. Niedernhausen/Ts., Falken Verlag.

7.3 Quellenübersicht

191

7.3 Quellenübersicht Adams, J. (2005). Think! Berlin, Uhlstein. Adler, A. (1984). Praxis und Theorie der Individual-Psychologie; Vorträge zur Einführung in die Psychotherapie für Ärzte, Psychologen und Lehrer. Frankfurt am Main, Fischer Taschenbücher. Belbin, R. M. (1996). Team Roles at Work. Oxford, Butterworth-Heinemann. Boehm, B. (1988). A Spiral Model of Software Development and Enhancement. Braun, R., H. Gawlas, et al. (2005). Die Coaching Fibel. Wien, Linde Verlag. Brooks, F. P. (1995). The Mystical Man Month. Essays on Software Engineering. New York, Addison Wesley. Bullinger, H. J. and S. Hermann (2000). Wettbewerbsfaktor Kreativität. Wiesbaden, Gabler Verlag Citrin, J. M., R. A. Smith, et al. (2003). Das Geheimnis außergewöhnlicher Karrieren. Frankfurt, New York, Campus Verlag. Csikszentmihalyi, M. (2007). Kreativität: Wenn Sie das Unmögliche schaffen und Ihre Grenzen überwinden. Stuttgart, Klett Cotta. Damasio, A. (2004). Descartes’ Irrtum. Fühlen, Denken und das menschliche Gehirn. Berlin, Ullstein Buchverlage GmbH. de Shazer, S. (2006). Der Dreh. Heidelberg, Carl-Auer-Systeme Verlag. Dörner, D. (2006). Die Logik des Misslingens, Strategisches Denken in komplexen Situationen. Reinbek, rororo. Dröschel, W. and M. Wiemers (1999). Das V-Modell 97, Oldenbourg. Eckes, G. (2001). The six sigma revolution: how General Electric and others turned process into profits. New York, John Wiley. Festinger, L. (1962). A theory of cognitive dissonance. Stanford, Calif., Stanford University Press. Foerster, H. v., E. v. Glasersfeld, et al. (2006). Einführung in den Konstruktivismus, Piper Verlag. Fuller, G. (2000). Win-Win-Management – Führen mit Gewinn. Landsberg/Lech, mvg – verlag moderne industrie. Gates, W. H. (2007). „Roboter für jedermann.“ Spektrum der Wissenschaft 3/07: 36 – 45. Gause, D. C. and G. M. Weinberg (1990). Are your lights on? How to figure out what the problem really is. New York, NY, Dorset House Publishing. George, M., D. Bowlands, et al. (2004). What is lean Six Sigma. New York, McGraw-Hill. George, M. L., D. Rowlands, et al. (2005). Lean Six Sigma Pocket Toolbook. New York, Mc Graw Hill. Gharajedaghi, J. (1999). Systems thinking. Boston Oxford, Butterworth Heinemann. Glasersfeld, E. v. (1997). Radikaler Konstruktivismus. Ideen, Ergebnisse, Probleme. Frankfurt, Suhrkamp Verlag. Goleman, D. (1997). Emotionale Intelligenz. München, Wien, Deutscher Taschenbuch Verlag. Goleman, D. (2006). Soziale Intelligenz. München, Droemer Verlag.

192

7 Anhang

Hamilton, P. (2006). Dynaxity. Heidelberg, New York, Springer Verlag. Heers, R. (2006). Just do it. Göttingen, Cuvillier Verlag. Herzlieb, H.-J. (2005). Von der Führungskraft zum Coach. Berlin, Cornelson Verlag. Katzenbach, J. R. and D. K. Smith (2003). Teams, der Schlüssel zur Hochleistungsorganisation. Frankfurt, Wien, Redline Wirtschaft bei Ueberreuter. Koch, R. (2000). Die Powergesetze des Erfolgs. Frankfurt, Campus Verlag. Köhler, P. T. (2005). ITIL. Heidelberg, Springer. Königswieser, R. and A. Exner (2006). Systemische Intervention. Stuttgart, J.G. Cotta'sche Buchhandlung. Kruchten, P. (1998). Introduction into RUP. Kruse, P. (2004). next practice. Erfolgreiches Management von Instabilität. Offenbach, GABAL Verlag. Kuhn, D. (2007). Gegen die Logik. Gehirn&Geist. 11/2007: 34–39. Kuhnt, B. and A. Huber (2001). Verändertes Berufsbild des IT-Projektleiters: vom Design technischer Lösungen zur sozialen Mediation. INFORMATIK • INFORMATIQUE 4/2001: 9–13. Lange, L. (2007). Einblicke in die Dynamik des Denkens. Gehirn&Geist. 10/2007: 39–43. Larman, C. (2004). Agile & Iterative Development, A managers guide. Boston, Pearson Education. Latour, B. (2005). Was soll die blöde Frage? Gütersloh, Gütersloher Verlagshaus. Lippmann, E. (2006). Coaching, Angewandte Psychologie für die Beratungspraxis. Heidelberg, Springer Medizin Verlag. Maier, M. W. and R. Eberhardt (2002). The Arts of systems Architecting. London, New York, CRC Press. Maturana, H. R. (1997). Was ist Erkennen? München, Piper Verlag. Möller-Brix, G. (2002). Systemisch Beraten: das Praxisbuch mit Methodenanleitung und Beispielen. Hamburg, Books on Demand, Norderstedt. Nadler, G. and W. J. Chandon (2004). Smart Questions. San Francisco, CA, John Wiley & Sons. North, K. (2002). Wissensorientierte Unternehmensführung. Wiesbaden, Gabler Verlag. Pawlowski, K. R., Hans (2003). Konstruktiv Gespräche führen. Hamburg, Rowohlt Taschenburg Verlag. Peseschkian, N. (1979). Der Kaufmann und der Papagei. Frankfurt/Main, Fischer Taschenbuch Verlag GmbH, Frankfurt am Main. Radatz, S. (2004). Beratung ohne Ratschlag. Wien, Verlag systemisches Management. Radatz, S. (2006). Einführung in das systemische Coaching. Heidelberg, Carl Auer Verlag. Reich, K. (2006). Konstruktivistische Didaktik. Weinheim, Basel, Beltz Verlag. Richmond, B. (2000). The „thinking“ in systems thinking. Waltham, MA, Pegasus Communications. Rosenblueth, A., N. Wiener, et al. (1943). „Behavior, Purpose, and Teleology.“ Philosophy of Science 10(10/1943): 18–24.

7.3 Quellenübersicht

193

Rupp, C. (2003). Reden Sie Klartext, Psychotherapie für Anforderungen in der Softwareentwicklung. manage it. 06/2003: 38–42. Rupp, C. (2006). Hellsehen für Fortgeschrittene: Die Kunst Anforderungen professionell zu ermitteln. OOP 2006, München, SIGS DATACOM. Scheer, A.-W. (2001). ARIS – Modellierungsmethoden, Metamodelle, Anwendungen. Berlin, Heidelberg, New York, Springer Verlag. Schulz von Thun, F. (1981). Miteinander Reden – Störungen und Klärungen. Reinbek, rororo. Schütt, P. (2000). Wissensmanagement. Niedernhausen/Ts., Falken Verlag. Scott-Morgan, P., E. Hoving, et al. (2001). Stabilität durch Wandel. Frankfurt/Main, Campus Verlag. Senge, P. M. (1994). The fifth discipline: the art and practice of the learning organization. New York, Currency Doubleday. Sewell, M. T. and L. M. Sewell (2002). The Software Architects Profession. Upper Saddle River, NJ 07458, Prentice Hall PTR. Simon, F. B. (2004). The Organisation of Self-Organisation. Heidelberg, CarlAuer-Verlag. Stoll, C. (2007). „Als Rechner noch verschoben wurden.“ Spektrum der Wissenschaft 04/07: 92–99. Tomaschek, N. (2006). Systemic Coaching. Heidelberg, Carl-Auer-Verlag. Versteegen, G., P. Kruchten, et al. (2000). Projektmanagement mit dem Rational Unified Process, Xpert.press, Springer. von Schlippe, A. and J. Schweitzer (2003). Lehrbuch der systemischen Therapie und Beratung. Göttingen, Vandenhoek & Ruprecht. Wachsmuth, I. (2006). „Der Körper spricht mit.“ Gehirn & Geist 04/2006: 40–47. Wallas, G. (1926). The Art of Thought. New York. Weinberg, G. M. (2004). Die Psychologie des Programmierers. Bonn, mitpVerlag. Willke, H. (2004). Einführung in das systemische Wissensmanagement. Heidelberg, Carl-Auer-Systeme Verlag. Womack, J. P., D. T. Jones, et al. (1991). The machine that changed the world: the story of lean production. New York, HarperPerennial.

Stichwortverzeichnis

6

E

6M-Methode 28

Effekt Mehr desselben ... 16 Oberschraubendreher- 26 Eisbergprinzip 66 Emergenz 30

A Akkomodation 150 Akzeptanzmanagement 66 Analyse Kano- 68 Architektur evolutionäre 173 Artifact 23, 174 Ärztemodell 110 Assimilation 150 Autopoisis 99

B Bacon, Francis 108 Ballmer, Steve 27 Bateson, Gregory 96 Best Practice 10, 43 Business Case 97

C Change-Prozess 92 CMMI 52, 169 Coaching systemisches 136

D Damasio, Antonio 82, 94 Deming-Cycle 60 Descartes, René 108 Dijkstra, Edgar 5 Dissonanz kognitive 84 Dokument Vision- 174

F Festinger, Leon 84 Forster, Norman 3

G Gates, Bill 7 Gesprächstheorie 126 Gestalttheorie 95

H Hawthorne-Effekt 18 HTML 4

I Intelligenz emotionale 168 Ishikawa, Karou 28 ISO 9241-11 62 ITIL 55

J Johari-Fenster 125

K Kaizen 59 Kano, Noriaki 68 Kausalität, zirkuläre 92 Kernprozess 41

196

Stichwortverzeichnis

Kognitionswissenschaft 1 KPI 76 Kreativität 141 Kuhn, Deanna 87 KVP 59 Kybernetik 92

L Lean Production 22, 159 Lethologie 101 Logik modale 129 wahrgenommene 82 Lösungsraum Zweiter Ordnung 107, 169 Luhmann, Niklas 97

M Mäeutik 129 Management Service- 40 Modallogik 130

N Newton, Isaac 6, 142

O Ontologie 35 Organisation lernende 42

P Palo-Alto-Gruppe 96 Parnas, David 164, 181 Passung 41 Piaget, Jean 150 Poincaré, Henri 118 Pöppel, Ernst 140 Präsentierproblem 116 Prinzip GIGO 169 Ursache-Wirkungs- 96 Produktlinie 72 Projektmarketing 92

RUP 169 agiler 55

S Schrödinger 32 Scrum 24 Sequenzdiagrammen 165 Servicemanagement 147 SFIA 43 Six Sigma 58 SOA-Architektur 34 Software Entropie 72 Lifecycle 40 Spezifikation 89 Stakeholder 54, 180 Swimlane 30 Systemtheorie 95

T Teleologie 92 Test Case 84 Theorie Gesprächs- 126 Gestalt- 95 Total Quality Management 159 TQM 15, 59 Tracebility 157

U Ulam, Stanislaw 118 UML 30 Ursache-Wirkungs-Prinzip 96 Usability 61 Use Case 31, 97

V Viabilität 151 von Neumann John 34 Maschine 85 von Wittgenstein, Ludwig 118

R

W

Refactoring 72 Roth, Gerhard 81

Wallas, Graham 142 Watzlawick, Paul 16, 96

Stichwortverzeichnis Wiener, Norbert 92 Win-Win 121 Wissen kollektives 148 Wissenslandkarte 33 Wissensmediation 153

Z Zweiter Ordnung Kybernetik 93 Lösungsraum 107, 169 Systemtheorie 98

197