Was macht IT so kompliziert?
IT finden wir heute überall. Teilweise wird sie von uns bewusst wahrgenommen, z.B. wenn wir über ein Smartphone Nachrichten verschicken. Die IT in einem Auto oder in Geräten, wie einem Staubsauger, nehmen wir meist nur dann wahr, wenn sie nicht funktioniert oder kompliziert zu bedienen ist. Die komplizierte Bedienung von IT möchte ich in diesem Artikel jedoch nicht betrachten.
Ich möchte den Blick auf IT-Projekte werfen. Projekte, in denen IT so zum Einsatz gebracht werden soll, dass sie die individuellen Bedürfnisse eines Unternehmens unterstützt. Diese Bedürfnisse werden dabei von der Fachseite festgelegt und von den IT-Spezialisten umgesetzt. Eine Arbeitsteilung, wie sie in anderen Bereichen auch zu finden ist, z.B., wenn eine Förderanlage in eine Lager eingebaut wird. Warum wird jedoch die IT in Projekten als so kompliziert wahrgenommen. Woran liegt das? Hierzu sind mir einige Ursachen aufgefallen:
IT ist mit den Sinnen nur eingeschränkt wahrnehmbar
Von einem Softwaresystem können wir uns nur die Benutzeroberfläche am Monitor anschauen. Die eigentliche Verarbeitung der Informationen passiert unsichtbar im Hintergrund. Das Softwaresystem bleibt eine Blackbox, deren innere Struktur man als Laie sowieso nicht verstehen kann. Das behaupten zumindest viele IT-Experten.
Im Maschinenbau ist dies anders. In die Druckmaschine einer Zeitung können sowohl die Ingenieure als auch die Drucker hineinschauen. Man kann Bauteile erkennen, die eine bestimmte Aufgabe erfüllen. Dies hilft zu verstehen, wie die Maschine funktioniert. Alle sehen das Gleiche, wenn sie in die Maschine schauen.
Wenn man einen Rechner im Serverraum aufschraubt, sieht man zwar Bauteile, anhand derer man erklären kann, wie ein Computer funktioniert. Wie die Unternehmenssoftware funktioniert, kann man dort jedoch nicht sehen. Dies spielt sich auf einer Ebene ab, die für unser Auge unsichtbar ist: der informationellen Ebene. Informationsverarbeitung ist nichts Gegenständliches. Deshalb fällt es uns auch so schwer, uns die Strukturen der Informationsverarbeitung vorzustellen.
Fast keine physikalischen Grenzen
Alltägliche Maßstäbe wie Entfernung, Größe oder Gewicht spielen im Informationellen keine Rolle. Bei einer Maschine oder einem Gebäude können auch Nicht-Experten meist intuitiv erkennen, dass etwas wackelig oder zerbrechlich ist. Im IT-Umfeld ist es schwer nachzuvollziehen, warum gewisse Dinge machbar sind oder nicht. Die Wirkungen von Entscheidungen sind meist schwer nachvollziehbar.
Extreme Variabilität
Software ist extrem schnell änderbar. Ein Programm ist nichts anderes als ein Text. Diesen muss man nur umschreiben, muss ihn dann noch für die Computer übersetzen und auf diese verteilen. Schon ist neue Funktionalität umgesetzt. Lange Bauzeiten sind nicht erforderlich. Was man gestern wollte, kann man heute wieder rückgängig machen.
Eine Druckmaschine kann man auch umbauen, verbessern, anpassen. Aber immer nur in Grenzen. Es wird immer eine Druckmaschine bleiben.
Bei Software gibt es fast keine Grenzen für individuelle Anpassungen. Der große Vorteil der hohen Variabilität hat aber auch einen gravierenden Nachteil: die Komplexität der Systeme (siehe „Ist IT komplex?“) bleibt nicht mehr alleinig die Herausforderung der Techniker. Sie wird zu einer oft unüberwindbaren Hürde für die Fachseite als Auftraggeber.
Fehlende Kommunikationskultur
In Technikdisziplinen wie die Architektur, der Maschinenbau und die Elektrotechnik hat sich über die Jahrzehnte/Jahrhunderte eine Kommunikationskultur entwickelt. Fast jeder kann einen Grundriss oder eine Seitenansicht eines Hauses verstehen. Wer einen Elektriker beauftragt, muss nicht viel von Elektrotechnik verstehen. Was ein Kurzschluss ist, warum man nicht zu viele Geräte an eine Leitung anschließen darf und wofür eine Sicherung da ist, kann man auch als Laie verstehen. Viel mehr muss man auch nicht, selbst wenn man die Elektrik für ein großes Lager in Auftrag gibt.
In IT-Projekten werden die Auftraggeber mit einer Sprache konfrontiert, die für sie unverständlich ist. Sie müssen Entscheidungen fällen, die das System als Ganzes betreffen, ohne dieses System als Ganzes je gesehen zu haben. Die Wirkungen ihrer Entscheidungen sind oft nicht erkenntlich. Deshalb fokussiert man sich auf die Teilbereiche, die man überschauen kann. Der Blick darauf, dass diese Bausteine am Ende auch alle zusammenpassen müssen, fehlt sehr häufig.
Der Fokus liegt zu sehr auf dem Mittel, statt auf dem Zweck
Bei einem Symphoniekonzert kann man sich für den Schall und die Akustik interessieren. Wieviel Dezibel kann man wo messen? Gibt es irgendwo ein störendes Echo? Oder man fokussiert sich auf die Musik. Welche Stimmung hinterlässt die Musik bei den Hörern? Ist sie lustig oder traurig? Reißt sie mit oder beruhigt sie? Beide Blickwinkel sind wichtig für ein gutes Konzert. Aber es ist bei der Betrachtung ganz klar, die Akustik ist nur das Mittel, die Musik ist der Zweck, auf den es letztendlich ankommt.
Genauso verhält es sich bei der IT. IT ist lediglich eine Technik, die bei der Verarbeitung von Information hilft. Informationen werden schon seit Jahrhunderten verarbeitet, lange bevor es Computer gab – man denke nur an die Buchhaltung der Kaufleute. Und fast genau so lange gibt es technische Hilfsmittel, wie z.B. der Abakus. Diese sind jedoch immer nur Mittel zum Zweck.
Durch die Erfindung des Computers und seine enorm schnelle Weiterentwicklung wurden die technischen Hilfsmittel enorm leistungsfähig. Dinge die vor wenigen Jahren noch unvorstellbar waren, sind heute mit Computern möglich.
Nach meiner Meinung steht zu oft die Technik im Vordergrund und der eigentliche Zweck der Informationsverarbeitung gerät in den Hintergrund. Richtet sich die IT- Sprache zu sehr auf die Technik aus?
Der Komplexität im Bereich des eigentlichen Zwecks, also der Verarbeitung der Informationen, wird sich kaum gewidmet. Teilweise auch aus Resignation (siehe „Drei Möglichkeiten mit Komplexität umzugehen“). Von Projektaufträgen verstehen die Experten der Fachseite oft nur die Teile, die sie direkt betreffen. Der Auftrag im Ganzen wird nur von wenigen überblickt.
Man kann nicht von weitem drauf schauen
Um einen Überblick über etwas Gegenständliches zu bekommen, muss man einfach nur Schritte zurück treten und sich die Sache von der Ferne anschauen. Bei IT geht das nicht. Für den Übergang vom Feinen zum Groben muss man abstrahieren. D.h. man muss das Erkannte interpretieren und das Wesentliche erkennen. Hierfür gibt es keine Regeln, die man einfach nur kochbuchmäßig befolgen muss. Die in der Praxis zu findenden Überblicksdarstellungen sind häufig unbrauchbar. Statt die grob die wichtigen Strukturen zu zeigen, sind sie einfach nur ungenau.
Was macht aus Ihrer Sicht IT so kompliziert? Fallen Ihnen noch weitere Ursachen ein? Ich freue mich auf Ihre Kommentare.
Kann es sein, dass Software-Hersteller, und nicht zuletzt SAP, die Möglichkeiten, die es gibt, die Komplexität zu reduzieren und zu erfassen, absichtlich von der Öffentlichkeit zurückhalten? Nach dem Motto, je komplizierter, je abhängiger der Kunde? Als Beispiel das in diesen Seiten erwähnte Buch „The Architecture of SAP ERP“: warum erst jetzt?
@Dr. Bungert: Sehr gelungener Artikel.
@Frau Reinsberg: Meiner Erfahrung nach sind die Spezialisten in den Softwarehäusern oft zu nah an ihren Produkten dran. Auch gebe ich zu bedenken, dass sich diese Systeme durch langjährige Weiterentwicklung, Zukauf von Softwaremodulen und branchenspezifische Module häufig in unglaubliche Dimensionen aufblähen. SAP ist da eher noch ein Positivbeispiel für gutes Management. Daher gelingt es ihnen (den Spezialisten) häufig nicht, die Komplexität ihrer eigenen Software kundenbezogen zu reduzieren. Auch Projektleiter (intern wie extern) sind häufig nicht darin geschult, Komplexitäten zu reduzieren (ich meine an dieser Stelle nicht Simplifizierung). Mir sind in der Praxis nur sehr selten SAP-Projektleiter (SAP ist da austauschbar) begegnet, die das konnten, weil es einfach nicht vermittelt und geübt wird. Erfahrenere Projektleiter lernen das mit den Jahren – leider oft über Schmerzen in Projekten.
Es wäre sicherlich ein genialer Ansatz, wenn die Anbieter von komplexen Systemen dies in ihre Implementierungsmethode und die Vertriebsschulungen integrieren könnten. Leider sind es aber oft die Kunden, die den Feature- und Komplexitätswahnsinn eher verschlimmern. Viele Unternehmen haben bis heute nicht begriffen, dass man sich mit dem Kauf von Software keine Prozesse und Organisationsstrukturen kauft, sondern diese Leistung selbst erbringen muss.
Herzliche Grüße,
Ghania Ibelaidene
Von Berhard Groene gibt es einen interesanten Artikel zur Einführung der Architekturmodellierung bei SAP: http://qfam.gi.de/fileadmin/user_upload/PraxiforumModellierung2012/Introducing-architecture-modeling-at-a-big-software-product-company_Groene.pdf
Ich war damals im Team von Prof. Wendt und habe die ersten internen Architektur-Blue-Books mit geschrieben. Einge fanden die Blue-Books sehr gut, für andere waren sie unnötig. Bis sie dann auch einmal in neue Bereiche einsteigen mussten und froh waren, eine gute und schnelle Einführung in ein neues Thema zu bekommen. Es hat dann fast 20 jahre gebraucht, bis diese Methode intern in der Entwicklung zum Standard wurde. Das Buch wurde nach meiner Kenntbnis von den Support-Abteilungen mit vorangetrieben, da diese auch ein großes Interesse an einer verständlichen Dokumentation haben. Ob und wann dies in die Implementierungsmethode der SAP einfließen wird, muss sich noch zeigen. Ich wage hier keine Prognose.