Die Komplexität von Software aus soziologischer Perspektive: Modelle, Unsicherheiten und Rekursivität

Zusammenfassung

In diesem Kapitel nutze ich die Komplexität von Software, die in diesem Zitat aus dem „Duden Informatik“ thematisiert wird, als Ausgangspunkt, um die Probleme zu skizzieren, die im Kern einer Soziologie der Software stehen, wie sie in der vorliegenden Arbeit verstanden wird. Zu diesem Zweck lege ich erstens die Grundprinzipien dar, auf denen Software basiert. Ich stelle zweitens verallgemeinert vor, wie die sozialen Prozesse ablaufen, in denen Software entwickelt und genutzt wird, welche Akteur*innengruppen daran beteiligt sind und wie diese Prozesse durch die sozialen Systeme, also Organisationen, Projekte o.ä., beeinflusst werden, in denen sie stattfinden.

„Größere Software ist in der Regel nicht ein wenig, sondern immer extrem komplex. Merkwürdigerweise ist sich aber fast niemand dieser Komplexität bewusst, weshalb die Erstellung und die Wirkung von Software ständig unterschätzt wird. […] Die Undurchschaubarkeit der Systeme macht Fehler prinzipiell unvermeidlich.“ (Claus und Schwill 2003, S. 603 f.)

In diesem Kapitel nutze ich die Komplexität von Software, die in diesem Zitat aus dem „Duden Informatik“ thematisiert wird, als Ausgangspunkt, um die Probleme zu skizzieren, die im Kern einer Soziologie der Software stehen, wie sie in der vorliegenden Arbeit verstanden wird. Zu diesem Zweck lege ich erstens die Grundprinzipien dar, auf denen Software basiert. Ich stelle zweitens verallgemeinert vor, wie die sozialen Prozesse ablaufen, in denen Software entwickelt und genutzt wird, welche Akteur*innengruppen daran beteiligt sind und wie diese Prozesse durch die sozialen Systeme, also Organisationen, Projekte o.ä., beeinflusst werden, in denen sie stattfinden. Drittens zeige ich, welche Wechselwirkungen und Abhängigkeiten durch Software zwischen diesen Prozessen geschaffen werden und erläutere, wie diese Wechselwirkungen aus den Grundprinzipien folgen, auf denen Software basiert. Dieser dritte Punkt ist in der soziologischen Forschung zu Software bisher nur selten behandelt worden. Er wird in meinem Beitrag zur Soziologie der Software im Mittelpunkt stehen.

Über Software wird die Vieldeutigkeit, die soziale Phänomene aus konstruktivistischer Perspektive charakterisiert, mit der eindeutigen Funktionslogik vermittelt, nach der Mikroprozessoren arbeiten. Diese Vermittlung ist aufwändig und gelingt nur, weil Softwareentwickler*innen und andere, die sich an der Softwareentwicklung beteiligen, dabei eine Vielzahl an Einzelentscheidungen treffen: Wozu soll die Software dienen? Wer soll sie unter welchen Bedingungen nutzen? Welche Funktionen soll sie haben? Wie sollen diese Funktionen erzeugt werden? Was darf die Entwicklung kosten? Wer soll sie durchführen? Wann soll sie abgeschlossen sein? etc. Auch wenn Software fertig programmiert ist, müssen Entscheidungen getroffen werden, bevor und während sie genutzt werden kann: Welche Software soll für die Nutzung beschafft werden? Wer darf oder muss sie wozu nutzen? Welche Daten sind nötig, damit sie funktionieren kann? Wie muss mit ihr umgegangen werden? etc. Wer mit einer soziologischen Perspektive auf Software blickt, dem springt ins Auge, dass die Umstände, unter denen diese Einzelentscheidungen getroffen werden, und die Prozesse, in denen sie getroffen werden, Themen für soziologische Untersuchungen sind. Im Folgenden gehe ich von der Annahme aus, dass Software technisch und sozial komplex ist. Ich stelle diese Komplexität in drei Dimensionen vor und diskutiere dabei jeweils, wie diese Dimensionen aus Sicht von Akteur*innen erscheinen, die sich vor allem für die technische Seite der Software interessieren, und welche Fragen diese Dimensionen für diejenigen aufwerfen, die an den sozialen Aspekten dieser Komplexität interessiert sind. Ich zeige, wie einzelne dieser Fragen in der bestehenden soziologischen Forschung zu Software aufgegriffen werden. Ich schließe die Skizze einer soziologischen Perspektive auf die Rolle von Software im Sozialen an, in der diese Fragen gemeinsam berücksichtigt werden können.

Software entsteht aus einer Vielzahl an Einzelentscheidungen, die in Wechselwirkung miteinander stehen und von denen jede durch das Verhältnis von sozialer Ordnung und sozialem Handeln im Entscheidungsprozess beeinflusst wird. Diese Tatsache hat Konsequenzen, die ich hier vereinfacht unter dem Oberbegriff „Komplexität“ zusammenfasse. Die Komplexität von Software und die Folgen, die diese Komplexität für den Umgang mit Software hat, bilden den Rahmen, in dem ich meinen Forschungsgegenstand in diesem Kapitel beschreibe. Als Umgang mit Software wird dabei jede Art des Handelns verstanden, bei der Software eine Rolle spielt; insbesondere ist damit nicht nur die Nutzung gemeint, sondern auch das, was Softwareentwickler*innen tun, wenn sie Software herstellen.

Nach Arthur sind alle Technologien durch drei grundlegende Prinzipien charakterisiert: Sie basieren auf Phänomenen, bestehen aus einer Kombination von Einzelteilen, und sind rekursiv strukturiert (Arthur 2011).¹ In Anlehnung an diese Prinzipien identifiziere ich drei Dimensionen der Komplexität von Software, die ich im Folgenden nutzen werde, um die Fragen, die Software für die Soziologie aufwirft, aufzuspannen. Die Dimensionen lassen sich auf die Art und Weise zurückführen, in der sich die technologischen Prinzipien im Fall von Software ausprägen. Die erste Dimension ist aus dem Phänomen abgeleitet, das durch Software ausgenutzt wird: Software basiert auf der Nutzung von Mikroprozessoren, die diskrete und eindeutige Eingaben auf deterministische Weise verarbeiten, bildet aber kontinuierliche und mehrdeutige Prozesse ab, die vor der Verarbeitung so übersetzt werden müssen, dass die Prozessoren damit etwas anfangen können. Die zweite Dimension entsteht aus dem Konstruktionsprozess: Software entsteht aus einer Vielzahl einzelner Modelle, die miteinander verbunden werden, um gemeinsam einen übergeordneten Zweck zu erfüllen. Die dritte Dimension lässt sich auf die Rekursivität der Konstruktionsprozesse zurückführen: Die Elemente, die bei der Softwareentwicklung verbunden werden, basieren alle auf dem gleichen Phänomen und entstehen in ähnlich strukturierten Konstruktionsprozessen, wodurch sich die Komplexität der Software insgesamt über Wechselwirkungen steigern kann.

Im Umgang mit Software stehen die Akteure vor einer Reihe typischer Handlungsprobleme, die sich ebenfalls diesen Dimensionen zuordnen lassen: Wie lässt sich eine unbekannte Anzahl mehrdeutiger Gegenstände in eindeutige Anweisungen für eine deterministische Verarbeitung übersetzen? Welche Einzelteile ergeben zusammen das gewünschte Ganze, woher kann man sie bekommen und wie müssen sie kombiniert werden, um den übergeordneten Zweck zu erfüllen? Und wie ist mit den Unsicherheiten umzugehen, welche die Einzelteile und ihre Kombination mit sich bringen? Im Rahmen dieses Kapitels werden die hier sehr allgemein bestimmten typischen Handlungsprobleme und etablierte Strategien² zum Umgang mit ihnen ausgearbeitet. Diese liegen der sozialen Komplexität von Software zugrunde. Es wird gezeigt, wie und in welchem Ausmaß diese Handlungsprobleme und Strategien bisher in der Soziologie thematisiert werden und welche soziologisch relevanten Fragen dabei nicht berücksichtigt werden. Am Ende des Kapitels wird ein Konzept vorgeschlagen, mit dem der sozialen Komplexität von Software besser Rechnung getragen werden kann, als dies bisher in der Soziologie geschieht.

Im folgenden Abschnitt 2.1. wird vorgestellt, wie die Komplexität von Software entsteht, welche Handlungsprobleme sich daraus ergeben und wie Akteur*innen mit den Unsicherheiten umgehen, die diese Handlungsprobleme erzeugen. Dadurch wird der Raum aufgespannt, in dem die Forschungsfragen einer Soziologie der Software liegen. In Abschnitt 2.2. wird dargestellt, welche dieser Fragen bisher in der soziologischen Forschung aufgenommen und wie sie bearbeitet worden sind. Dabei zeigt sich, dass der Fokus bisher auf einzelnen Prozessen im Lebenszyklus von Software liegt, während die Wechselwirkungen zwischen diesen Prozessen, aus denen die soziale Komplexität entsteht, eine Forschungslücke darstellen. In Abschnitt 2.3. entwickle ich einen Vorschlag dafür, wie in der soziologischen Forschung mit dieser Komplexität umgegangen werden kann. Dabei steht die Erkenntnis im Mittelpunkt, dass die sozialen Prozesse, in denen Software konstruiert wird, in den Einzelteilen der untersuchten Artefakte Spuren hinterlassen. Forschende können daher durch die Analyse von Elementen der Software etwas über die Konstruktionsprozesse herausfinden, ebenso wie sie durch die Untersuchung der Prozesse Schlüsse über die Artefakte und deren Einfluss auf die Nutzung ziehen können.

2.1 Dimensionen der Komplexität von Software

Die Komplexität von Software wirkt sich zwar auf jeden sozialen Prozess aus, in dem mit Software umgegangen wird, entsteht jedoch erst aus den Wechselwirkungen zwischen all diesen Prozessen und lässt sich nicht auf einzelne zurückführen. Während einige Aspekte der Entwicklung, Einführung oder Nutzung von Software soziologisch gut untersucht sind, gibt es nur wenige Arbeiten, in denen die unterschiedlichen sozialen Prozesse, in denen ein und dieselbe Software generiert und in der mit ihr umgegangen wird, im Zusammenhang betrachtet werden.³ Eine solche Betrachtung macht Software zum zentralen Untersuchungsgegenstand, da sie das einzige verbindende Element der verschiedenen sozialen Prozesse ist. Die in den Software Studies verbreitete Herangehensweise, bei der Software als Träger einer abgeleiteten oder erweiterten Handlungsfähigkeit („secondary agency“, Kitchin und Dodge 2011; Mackenzie 2006) behandelt wird, erkennt das Problem der Komplexität an, hilft aber nicht dabei, es zu bearbeiten (vgl. Einleitung). In dieser Arbeit werde ich die Rolle von Software im Sozialen stattdessen als Performativität beschreiben. Performativität beschreibt das folgende Verhältnis zwischen einer Theorie und der von ihr beschriebenen Praxis:⁴ Eine Theorie wirkt auf einen Prozess performativ⁵, wenn sie den Prozess beschreibt, in diesem zur Anwendung kommt und der Prozess sich durch diese Anwendung der Theorie verändert (MacKenzie 2006). Performativ können nicht nur Theorien, sondern allgemein Modelle wirken, die soziale Prozesse beschreiben.

Softwareentwicklung wird in der Informatik unter anderem als eine Form der Modellbildung verstanden (Ludewig und Lichter 2013). Anders als bei wissenschaftlichen Theorien ist Performativität bei den Modellen der Softwareentwicklung intendiert – sie sollen die sozialen Prozesse verändern, die sie beschreiben (zur Performativität von Software vgl. auch Orlikowski 2005). Moderne Software lässt sich jedoch nicht auf ein einziges performatives Modell zurückführen, sondern entsteht aus einer Kombination solcher Modelle, wie die folgende Rekonstruktion der Komplexität von Software zeigen wird. Dabei zeichne ich nach, wie die Prozesse der Modellbildung ineinandergreifen und dadurch Kontrolle über deren Ergebnis innerhalb der Software verteilt wird. Aus soziologischer Perspektive ist dieses Ineinandergreifen der Prozesse von Bedeutung, weil dadurch die Art und Weise, wie Handeln und Ordnung in jedem einzelnen Prozess aufeinander abgestimmt sind, mit allen anderen Prozessen in Verbindung gebracht wird. Für die Rekonstruktion der Komplexität von Software muss zuerst der Begriff des Modells definiert und aufgezeigt werden, welche Fragen Modellbildung für die Soziologie aufwirft.

Informationstechnisch betrachtet ist ein Modell das Ergebnis einer Transformation, bei der ein Teil der Eigenschaften (Reduktion) eines Urbilds oder Originals so abgebildet wird (Abbildung), dass das Modell für einen bestimmten Zweck eingesetzt werden kann (Nützlichkeit) (Ludewig 2003; Stachowiak 1973). Die Reduktion entfernt einige Eigenschaften des Originals, die Abbildung erweitert jedoch das Modell um sogenannte abundante Attribute, also Eigenschaften, die das Original nicht besitzt und die durch das Verfahren der Transformation hinzugefügt werden (Ludewig und Lichter 2013). Soziologisch lassen sich die Prozesse der Modellbildung, die bei der Softwareentwicklung stattfinden, als Prozesse betrachten, in denen die Beteiligten versuchen, durch Entscheidungen über Eigenschaften des Modells Unsicherheit zu reduzieren, wobei sie neue Unsicherheiten generieren. Die Unsicherheiten sind eine unvermeidliche Folge der Möglichkeiten, die die Modellierung mit sich bringt: Unsicherheit besteht hinsichtlich der Frage, welches Original zu welchem Zweck und mit welchem Verfahren modelliert werden soll. Dies ist nicht festgelegt, sondern muss ausgehandelt werden. Das Ergebnis dieser Aushandlungen hängt von den sozialen Bedingungen ab, unter denen sie stattfinden, und von den Akteur*innen, die an den Aushandlungen beteiligt sind. Jede Entscheidung für eine bestimmte Interpretation des Originals, einen bestimmten Teil aller möglichen Eigenschaften, eine bestimmte Form der Abbildung oder einen bestimmten Zweck, kann einen Teil der Unsicherheit (zeitweise) verstecken. Denn: Im Modell sind die Alternativen nicht mehr sichtbar, gegen die sich die Akteur*innen in den Aushandlungen entschieden haben. Durch das Verstecken wird die Unsicherheit kontrolliert, d. h. sie kann (vorerst) von Akteur*innen, die mit dem Modell umgehen, ignoriert werden. Wie die folgenden Ausführungen zeigen werden, kann die so kontrollierte Unsicherheit aber jederzeit wieder auftauchen, wenn Entscheidungen in Frage gestellt werden.

Eine Gemeinsamkeit aller Aushandlungsprozesse liegt in den technischen Grundlagen der Programmierung, die dafür sorgen, dass jedes für Software entwickelte Modell einige der abundanten Attribute teilt. Diese werden zuerst vorgestellt. Im Anschluss werden der Softwarelebenszyklus und die Aushandlungsprozesse behandelt, mit denen die Akteur*innen in den einzelnen Phasen versuchen, Unsicherheit zu reduzieren. Die in beiden Abschnitten vorgestellten Prozesse bauen jeweils analytisch linear aufeinander auf, auch wenn sie in der Praxis zeitlich oft verschränkt stattfinden. Im letzten Abschnitt geht es dann um die rekursiven Aspekte der Softwareentwicklung. Diese verknüpfen die Ergebnisse der vorher als linear beschriebenen Aushandlungen so miteinander, dass Software für Informatiker*innen wie Soziolog*innen zum komplexen Gegenstand wird.

2.1.1 Modellierung des Prozessors

Die Entwicklung der Informatik als eigene Disziplin und die Entwicklung von Software als zentrales Element heutiger Gesellschaften beruht auf einer grundlegenden Annahme: Jeder Prozess, der als Algorithmus beschrieben werden kann, lässt sich im Prinzip durch eine universelle Turingmaschine ausführen (Davis 1995). Eine solche Maschine kann zu jedem Zeitpunkt nur eine von wenigen sehr einfachen deterministischen Operationen ausführen, bei denen ein Datum (das Eingabedatum) durch ein anderes (das Ausgabedatum) ersetzt wird. Die Frage, welche Operation wann mit welchem Ergebnis ausgeführt wird, hängt von der Operation, dem Eingabedatum und den Ergebnissen aller vorangegangenen Operationen ab. Die Maschine ist dadurch theoretisch frei von Unsicherheit für jeden, der ihre Operationen kennt, allerdings nur, wenn auch alle Eingaben und die Reihenfolge bekannt sind, in der die Operationen aufgerufen werden.

Auch moderne Computer sind auf der Grundlage universeller Turingmaschinen konstruiert. Die Annahme, dass sich alle algorithmischen Prozesse mit solchen Maschinen beschreiben lassen, bildet die Grundlage dafür, dass Software heutzutage in beinahe allen Lebensbereichen zum Einsatz kommt. Die Informatik ist durch diese Annahme darauf ausgerichtet, den Anwendungsbereich von Software als formalisierbaren Gegenstand zu behandeln, der durch systematische Analyse und Abstraktion auf ein mathematisches Modell abgebildet werden kann (Mahoney 2002). Soziologisch stellt sich die Frage, wie soziale Phänomene, die voller Unsicherheit sind – aus informationstechnischer Sicht die „Originale“ der Modellierung – in solche unsicherheitsbefreiten Modelle übersetzt werden und welche Auswirkungen die Verarbeitung solcher Modelle auf die sozialen Phänomene und auf die Unsicherheit der sie tragenden sozialen Prozesse hat.

In der Informatik werden häufig Anwendungs- und Systemsoftware voneinander unterschieden. Zweck⁶ der Anwendungssoftware ist die Bearbeitung menschlicher Handlungsprobleme in sozialen Prozessen. Systemsoftware stellt die Verbindung zwischen Anwendungssoftware und Hardware her (Patterson und Hennessy 2016). Sie ermöglicht es damit unter anderem, dass die statischen Codezeilen der Anwendungsprogramme in die dynamischen Funktionen der Software überführt werden. Für die Soziologie ist Anwendungssoftware mit Abstand der bedeutsamere Gegenstand, weil diese deutlich häufiger und direkter in soziale Prozesse eingebunden ist als Systemsoftware. Auch in dieser Arbeit wird sie im Mittelpunkt stehen. Ein grobes Verständnis der Schnittstelle zwischen Hard- und Software ist jedoch notwendig, um zu verstehen, welche Folgen die Annahme, jeder algorithmische Prozess lasse sich durch einen mathematischen Formalismus beschreiben, für den Umgang mit Software im Sozialen hat.

2.1.1.1 Übersetzung von Maschinensprache in Softwarecode

Der Übergang zwischen Hard- und Software lässt sich als eine Übersetzung betrachten, bei der ein Mechanismus zum Einsatz kommt, der die Verbindung zwischen beiden Seiten herstellt. Dieser Übersetzungsmechanismus und die eine Seite der Übersetzung werden in diesem Abschnitt kurz eingeführt, um den Leser*innen das notwendige Hintergrundwissen für ein Verständnis der Prinzipien zu vermitteln, auf denen Software aufbaut. In allen weiteren Abschnitten der Arbeit werden diese grundlegenden, aber für die soziologische Betrachtung von Software nicht weiter bedeutsamen Themen keine Rolle mehr spielen.

Als Hardware werden alle physischen Elemente von Informationstechnik bezeichnet.⁷ Das zentrale Element ist der Prozessor. Ein Prozessor besteht aus Transistoren, elektronischen Bauteilen, die Elektronenströme ein- und ausschalten und durch komplexe Kombinationen dieser Vorgänge vordefinierte Operationen verursachen können. Die Operationen des Prozessors überführen als Binärzahlen codierte Eingabedaten auf deterministische Weise in ebensolche Ausgabedaten oder transformieren sie anderweitig in vorgegebener Weise. Ebenfalls binär codierte Befehle aktivieren bestimmte Elemente des Prozessors und verursachen so die Operationen. Alle möglichen Operationen des Prozessors können in einer Sprache beschrieben werden, die als Maschinensprache bezeichnet wird (Herold et al. 2011). Die Maschinensprache ist ein mathematischer Formalismus, mit dem Programme als universelle Turingmaschinen beschrieben werden können. Jedes Programm muss vor der Ausführung in diese Maschinensprache überführt werden. Alles was die Funktion der Software in irgendeiner Weise beeinflussen soll, muss durch Wörter der Maschinensprache dargestellt werden, egal ob es sich um Anweisungen handelt, die in den Codezeilen direkt beschrieben werden, um Ergebnisse vorangegangener Arbeitsschritte der Software, die vom Prozessor selbst erzeugt wurden, oder um Eingaben aus der Umwelt des Computers, die durch andere Elemente der Hardware aufgenommen und weitergeleitet werden.

Aus soziologischer Perspektive werden mit der Maschinensprache die Unsicherheiten, die in der Funktion der Hardware liegen (z. B. Verschleiß, Schwankungen der Stromstärke, …) hinter der absoluten Gewissheit einer formalen Sprache versteckt.⁸ Die Maschinensprache ist ein mathematisches Konstrukt. Sie besteht vollständig aus wohldefinierten Elementen. Das bedeutet: Das Ergebnis jeder Anweisung, die in Maschinensprache ausgedrückt wird, ist durch die Daten determiniert, auf denen die Anweisung operiert. Formale Sprachen wie die Maschinensprache sind damit in ihrer Funktionsweise frei von Unsicherheit, da sie genau dafür konstruiert werden. Sie werden jedoch in sozialen Prozessen mit ihren Unsicherheiten generiert und verwendet.

Der Umgang mit Maschinensprache also ist keineswegs frei von Unsicherheit: Übertragen Menschen Anweisungen und Eingabedaten für den Prozessor in Maschinensprache, ist zwar sichergestellt, dass dieser genau das definierte Verhalten zeigen wird. Aber welche Elemente dabei wie kombiniert werden, ist nicht durch das Ergebnis festgelegt. Das bedeutet, es gibt eine Vielzahl an verschiedenen Möglichkeiten, die Anweisungen zusammenzustellen, ebenso eine Vielzahl an sozialen Rahmenbedingungen (professionelle oder organisationale Prozeduren, Entscheidungsstrukturen u.ä.), die die Zusammenstellung beeinflussen. Hinzu kommt: Der Code, also die in Maschinensprache formulierte Übersetzung von Anweisungen und Daten, ist für Menschen extrem schwer zu verstehen, da er nur aus einer Reihe von Nullen und Einsen besteht. Bei praktisch allen Kombinationen von Anweisungen und Daten ist damit für Verfasser*innen und Leser*innen gleichermaßen unsicher, ob der Code genau das enthält, was die Verfasser*innen damit ausdrücken wollten.

Die Maschinensprache ermöglicht es, Computer zu steuern, ohne sich mit ihren materiellen Bedingungen auseinandersetzen zu müssen.⁹ Die Nutzer*innen der ersten Computer, die gleichzeitig deren einzigen Programmierer*innen waren, konnten mathematische Aufgaben in Maschinensprache formulieren und Computer so als Rechenmaschinen verwenden. Dadurch ersetzten sie ein Handlungsproblem – die Kontrolle der Funktionen des physischen Geräts – durch ein anderes – die Formulierung von Programmen in einer formalen Sprache. In der Maschinensprache sind solche Programme jedoch umständlich zu verfassen und schwer zu durchschauen. Die Binärdarstellung bringt Unsicherheiten mit sich: können die Codezeilen vom Computer ausgeführt werden (syntaktische Unsicherheit) und tut der Computer dabei das, was sich die Programmierer*innen vorgestellt haben (semantische Unsicherheit)? Die Strategien zum Umgang mit diesen beiden Unsicherheiten unterscheiden sich ebenso wie ihre Folgeprobleme und deren Relevanz für eine soziologische Perspektive auf moderne Software.

Betrachtet man Software als Mittel zur Übergabe von Informationen an die Hardware, so stellt sich bei der syntaktischen Unsicherheit die Frage, ob diese Informationen ankommen und wie sie interpretiert werden. „Versteht“ der Computer, was die Programmierer*innen mit der Software sagen? Eine Strategie zur Kontrolle dieser Unsicherheit im Softwareentwicklungsprozess ist die Automatisierung der Übersetzung: Statt in Maschinensprache schreiben Programmierer*innen Code in einer für Menschen einfacher verständlichen, aber immer noch formalen Sprache. Ferner nutzen sie einen Compiler¹⁰, also ein Programm, das in der neuen Sprache verfasste Software in Maschinensprache übersetzt. Die automatisierte Übersetzung soll sicherstellen, dass die Software syntaktisch korrekt ist und von der Hardware akzeptiert wird. Selbst in den Frühphasen des Computers haben nicht alle Softwareentwickler*innen auch Compiler entwickelt. Aus soziologischer Perspektive trennen solche Programmiersprachen soziale Prozesse, in denen Software (Compiler) entwickelt und gestaltet wird, von solchen, in denen sie nur genutzt wird. Ein Teil der Unsicherheit darüber, ob der Code Fehler hat, wird aus dem Softwareentwicklungsprozess ausgelagert und in den Prozess der Entwicklung des Compilers verschoben.

So wie die Maschinensprache es erlaubt, Details der Hardware auszublenden, erlauben es andere Programmiersprachen, von den Details der Maschinensprache zu abstrahieren. Programmiersprachen sind Modelle für das, was mit Software ausgedrückt (und damit vom Computer getan) werden kann. Programmierer*innen können mit Hilfe dieser Programmiersprachen Probleme auf einer höheren Abstraktionsebene bearbeiten, weil die Details auf niedrigerer Abstraktionsebene bereits bei der Entwicklung der Programmiersprache selbst bearbeitet worden sind.¹¹ Auch ein Teil der semantischen Unsicherheit wird dadurch aus dem Softwareentwicklungsprozess ausgelagert: Das Vokabular der Sprachen ist für Menschen leichter verständlich als das der Maschinensprache. Programmierer*innen können den Code, den sie in diesen Sprachen verfasst haben, im Nachhinein besser verstehen und damit darauf vertrauen, dass die Grundbausteine ihrer Programme genau die Funktionen verursachen, die sie erwarten. Sie können dadurch komplexere Probleme bearbeiten, was sowohl in der Frühphase des Computers als auch bei der späteren Entwicklung sogenannter problemorientierter oder höherer Programmiersprachen geschehen ist (Herold et al. 2011). Höhere Programmiersprachen sind wie die Maschinensprache formale Sprachen, also künstliche Konstrukte mit wohldefinierten Elementen (Claus und Schwill 2003). Die Übersetzung zwischen höheren Programmiersprachen und der Maschinensprache basiert auf mathematischen Transformationen, die ein Programm in einer Programmiersprache auf Basis bekannter Regeln in ein Programm in Maschinensprache überführen. Die Frage, wie einfache Details (wie z. B. die Ablage von Listen im Speicher) in Code umgesetzt werden können, wird über eine mathematische Modellierung dieser Probleme gelöst. Diese Modellierung ist Gegenstand des Compilerbaus.

Die Funktionen von Compilern und anderer Systemsoftware werden bei der Entwicklung von Anwendungssoftware in der Regel als gegeben betrachtet. Aus der Perspektive der Informatik ist dies eine notwendige Bedingung für die Entwicklung von Software, die komplexe Probleme bearbeiten kann. Aus der Perspektive der Soziologie werden damit die sozialen Prozesse, in denen Systemsoftware entwickelt wird, bei der Entwicklung von Anwendungssoftware ausgeblendet. Es stellt sich die Frage, inwieweit die Akteur*innen dabei Annahmen über die Eigenschaften der Maschinensprache in Annahmen über die Eigenschaften der Anwendungssoftware übertragen. Eine soziologische Perspektive auf Software erlaubt es, solche unhinterfragten Annahmen aufzudecken und zu untersuchen, wie bei der Konstruktion von Systemsoftware Unsicherheit reduziert wird, die beim Umgang mit Anwendungssoftware eine Rolle spielt.¹²

2.1.1.2 Übersetzung von Daten in Informationen über soziale Prozesse

Die Entwicklung von Systemsoftware bringt zwar Unsicherheit mit sich, die gelegentlich bedeutsame Auswirkungen auf den Umgang mit Anwendungssoftware hat, bildet aber aus soziologischer Perspektive nicht die Hauptgrundlage der Komplexität von Software. Die Tatsache, dass die Funktionen von Anwendungssoftware auf Systemsoftware basieren, ist eine Folge der Modellierung des Prozessors (oder allgemeiner: der Hardware) durch mathematische Abstraktionen. Programmiersprachen sind jedoch nicht nur Modelle des Prozessors, sondern vor allem Werkzeuge zur Modellierung von Phänomenen, die mit Hilfe der Funktionen der Software verändert werden sollen¹³. Frühe Programmierung diente vor allem der Bearbeitung von mathematischen Problemen, deren Modellierung anspruchsvoll sein mochte, die aber an sich wenig interpretationsoffen waren. Ganz anders sieht dies bei der Modellierung von sozialen Phänomenen aus. Soziale Phänomene sind grundsätzlich komplex; weder ist es möglich, eindeutig nicht weiter unterteilbare Grundelemente zu identifizieren, aus denen alle sozialen Phänomene bestünden, noch lassen sie sich vollständig abbilden, ohne dass dabei Informationen verloren gingen. Soziale Phänomene enthalten immer Unsicherheit, da sie auf unterschiedliche Art und Weise wahrgenommen werden können und ihre Wahrnehmung daher Entscheidungen verlangt (Luhmann 2009). Die Modellierung sozialer Phänomene mit Hilfe von Programmiersprachen stellt damit die Softwareentwickler*innen grundsätzlich vor die Frage, welche Eigenschaften das Phänomen eigentlich besitzt, welche davon für die intendierten Funktionen der Software relevant sind und wie sie in das Modell übertragen werden sollen. Je komplexer das Phänomen, desto mehr Entscheidungen müssen getroffen werden, um den Code in Programmiersprachen zu produzieren, die wenig Raum für diese Unsicherheit bieten.

Die Funktionen der Software, die mit Programmiersprachen beschrieben werden können, basieren zwar auf deterministischen Operationen des Prozessors, ihre konkreten Ergebnisse sind bei der Programmierung aber nur schwer vorhersehbar. Dies hängt damit zusammen, dass die Funktionen hauptsächlich von den Daten bestimmt werden, die der Prozessor verarbeitet. Daten sind zum größten Teil nicht im Code festgelegt, sondern entstehen erst zur Laufzeit der Software, also dann, wenn sie genutzt wird. Wird Code als statischer und Funktionen als dynamischer Aspekt von Software betrachtet, so bilden Daten das Element, das zwischen beiden Aspekten vermittelt. Code wird ausschließlich in Prozessen der Softwareentwicklung hergestellt. Die Produktion von Daten basiert ebenfalls zum Teil auf diesen Prozessen, und zwar insofern dabei (nämlich im Code) die Struktur der Daten festgelegt sowie bestimmt wird, wann und wie diese von der Software verarbeitet werden. Zum Teil basiert sie aber auch auf dem, was während der Nutzung der Software geschieht, und zwar insofern die vordefinierten Datenstrukturen erst bei der Nutzung mit konkreten Werten gefüllt werden. Ein einfaches Beispiel: Bei der Programmierung einer Software zur Verwaltung von Krankenakten wird im Code festgeschrieben, dass Patient*innen über ihren Name und ihr Geburtsdatum identifiziert werden. Diese (und viele andere) statische Festlegungen bilden die Datenstruktur. Zur Laufzeit, also bei der Nutzung der Software, wird diese Struktur mit den Namen und Geburtsdaten konkreter Patient*innen gefüllt. Diese Namen und Geburtsdaten bilden die Daten, auf denen die Software dann operiert.

In den Nutzungsprozessen entstehen eine Unmenge an Informationen über die sozialen Phänomene, in denen die Software zum Einsatz kommt. Um bei dem Beispiel zu bleiben: Patient*innen sind Menschen mit Haar- und Augenfarbe, Berufen, Hobbies und Vorlieben, Körpergeruch, besonderen Fähigkeiten, Stimmungen und unzählbaren weiteren Eigenschaften. Das informationstechnische Modell sorgt dafür, dass nur der Teil der Informationen über das soziale Phänomen von der Software aufgenommen wird, der bei der Entwicklung als für die intendierten Funktionen relevant festgelegt wurde, und dass dies in genau einer der vielen möglichen Interpretationen geschieht. Für die Identifikation der Patientin in der Krankenakte in unserem Beispiel wären dies zum Beispiel Vor- und Nachname sowie Geburtsdatum wie auf der Versichertenkarte vermerkt, nicht Beruf und Haarfarbe und auch nicht ein selbstgewählter Spitzname und das Alter in Jahren. Nur durch diese Festlegungen lassen sich die Informationen als wohldefinierte Elemente der Programmiersprache ausdrücken. Damit aus den ausgewählten Informationen Eingabedaten werden können, die der Prozessor verarbeiten kann, müssen sie anschließend ebenso wie der Code selbst die automatischen Übersetzungen durchlaufen, die die Systemsoftware bereitstellt. Aus soziologischer Perspektive wirkt der Code als Filter, der die Vielfalt der möglichen Informationen reduziert, mit der das soziale Phänomen beschrieben werden kann, und damit Unsicherheit (temporär) verringert. Mit Hilfe des Filters wird kontrolliert, wie das soziale Phänomen in Daten übersetzt wird.

Software übernimmt jedoch nicht nur Daten, die direkt aus Informationen über den Nutzungsprozess übersetzt worden sind, sondern produziert aus diesen auch neue Daten, die dann Grundlage neuer Verarbeitungsschritte werden. Auf der Ebene des Prozessors lassen sich beide Arten von Daten nicht voneinander unterscheiden. Auch für die Funktionen der Software ist dieser Unterschied nicht relevant. Wird Software in sozialen Prozessen eingesetzt, ist dadurch für die Nutzenden nicht mehr ohne weiteres nachvollziehbar, worauf die Daten zurückzuführen sind, auf denen die Funktionen der Software beruhen. Geben die Funktionen Daten an den Nutzungsprozess zurück (zum Beispiel, indem sie auf dem Bildschirm angezeigt werden), gewinnen sie wieder Unsicherheit, da sie nun erneut interpretiert werden müssen. Die Ergebnisse dieser Interpretation gehen wieder als Informationen in den Nutzungsprozess ein. Dieser Ablauf ist in Abbildung 2.1 dargestellt.

Soziologisch stellen sich dazu vor allem zwei Fragen, nämlich

• 1. Inwiefern verändert die Software, wie das Soziale interpretiert wird? und

• 2. Wie, wann und von wem wird Einfluss auf die Interpretationsmöglichkeiten genommen?

Abbildung 2.1

Reduktion und Produktion von Unsicherheit bei der Nutzung von Software

Die erste Dimension der Komplexität von Software wird hier als Übersetzungsdimension bezeichnet. Software übersetzt soziale Prozesse, die voller Unsicherheiten sind, in die deterministischen, aber für Menschen undurchschaubaren Operationen des Prozessors. Durch den Umgang mit Software werden die Ergebnisse dieser Operationen wieder zum Teil sozialer Prozesse und gewinnen neue Unsicherheiten. Die Software wird im Sozialen performativ, weil die Nutzenden mit den Daten, die sie produziert, konfrontiert werden und sie als Informationen über soziale Prozesse interpretieren. Die Akteur*innen, die mit Software umgehen, wissen in der Regel nichts (oder nur sehr wenig) über all die sozialen Prozesse, die diese Übersetzung möglich machen und übertragen somit Erwartungen über die Funktionsweise des Prozessors unhinterfragt auf die Funktionen der Software. Für eine soziologische Perspektive auf Software sind daher die Prozesse bedeutsam, die die Übersetzung zwischen der Maschine und dem Sozialen ermöglichen. Diese Prozesse werden im nächsten Abschnitt beschrieben.

2.1.2 Software-Lebenszyklus

Im vorigen Abschnitt wurden Programmiersprachen als Modelle des Prozessors betrachtet. Die Funktionen des Prozessors (Original) werden mit Hilfe von Programmiersprachen durch mathematische Transformationen (Abbildungen) so umgeformt, dass sie von Menschen einfacher verstanden werden können (Zweck). Im Folgenden wird dargestellt, wie die sozialen Prozesse modelliert werden, die durch Software beeinflusst werden sollen. Programmiersprachen stehen aus diesem Blickwinkel nicht mehr als Modelle im Fokus, sondern als Abbildungsverfahren, mit denen ein soziales Phänomen in mehreren Schritten in ein Modell, den statischen Code der Software, überführt wird.

Aus der Perspektive von Informatiker*innen besteht der Softwareentwicklungsprozess aus einer Kette von Abbildungen, in denen unterschiedliche Verfahren nacheinander kombiniert werden und so ein soziales Phänomen auf ein Modell in Form von Softwarecode abgebildet wird. Gegenstand der Forschung und Ausbildung im Bereich der Softwareentwicklung ist die Frage, wie die Verfahren gestaltet und auf welche Art und in welcher Reihenfolge sie am besten kombiniert werden müssen, um ein soziales Phänomen so abzubilden, dass die Funktionen, die der Code hervorruft, den Zweck erfüllen, der Anlass für die Modellierung war. Aus soziologischer Perspektive stellen sich hingegen andere Fragen: Wie, von wem und unter welchen Bedingungen wird festgelegt, was der Zweck der Modellierung ist, welches soziale Phänomen in Software abgebildet werden soll, welche Eigenschaften für die Abbildung ausgewählt werden und wann die Software gut funktioniert? In anderen Worten: Wie, wann und wo werden die Unsicherheiten kontrolliert, die der Umgang mit Software aufwirft? Im Folgenden stelle ich dar, an welchen Stellen im Softwareentwicklungsprozess diese Fragen aufkommen, wie die Akteure mit ihnen umgehen und welche Auswirkungen dieser Umgang auf die Software und ihre Nutzung hat.

2.1.2.1 Rationalistische Tradition der Softwareentwicklung und Softwarelebenszyklus

Trotz eines lange etablierten, von den Sozialwissenschaften beeinflussten und eher konstruktivistisch orientierten Diskurses in der Informatik (vgl. z. B. Floyd 1989; Rolf 1990; Floyd 1992; Rönkkö et al. 2005; Wulf et al. 2018) folgt Softwareentwicklung in der industriellen Praxis größtenteils einer rationalistischen Tradition (Floyd 1989, S. 4). Diese basiert auf der Grundannahme, dass eine objektiv gegebene Realität existiert, die zumindest in der Theorie richtig und vollständig erkannt werden kann, auch wenn dies in der Praxis möglicherweise nicht immer gelingt. In dieser Realität stellen sich eindeutig kommunizierbare Probleme, die von Softwareentwickler*innen analysiert, modelliert und durch die Konstruktion eines Informationssystems gelöst werden können (a.a.O.). Diese Tradition spiegelt sich auch in den klassischen Verfahrensanweisungen für den Softwareentwicklungsprozess, den sogenannten Vorgehensmodellen der Softwareentwicklung. Diese Vorgehensmodelle beschreiben, welche Aufgaben in welcher Reihenfolge erfüllt und welche Methoden eingesetzt werden sollen, um möglichst effizient möglichst fehlerfreie Software herzustellen. Sie sollen Softwareentwickler*innen dabei helfen, die Unsicherheiten des Entwicklungsprozesses durch Regeln so weit unter Kontrolle zu bekommen, dass sie die zu lösenden Probleme richtig identifizieren und dafür die unter den gegebenen Rahmenbedingungen bestmögliche Lösung konstruieren können. Klassische Vorgehensmodelle unterscheiden sich untereinander vor allem darin, wie die vorgesehenen Aktivitäten zeitlich arrangiert sind, welche Akteur*innen wann wie stark beteiligt werden und wie und wann Übergänge zwischen den Aktivitäten vorgesehen sind. Alle Verfahren „presuppose a pre-given object domain (including organizations, functions and processes) which can be represented through the neutral (observation) language of conceptual modelling, data flow diagramming or data modelling and the like […]“ (Bloomfield 1995, S. 493).¹⁴ Eine für soziologische Fragen offenere Haltung kommt in den innerhalb der vergangenen Jahre populärer gewordenen agilen Ansätzen zur Softwareentwicklung zum Ausdruck. Diese Alternativen zu klassischen Vorgehensmodellen basieren auf der Annahme, dass Unsicherheit im Sozialen unvermeidbar ist und in Softwareentwicklungsprozesse integriert werden muss, weil alle Versuche, sie durch Regeln möglichst auszuschließen, zu einem schlechten Entwicklungsprozess und schlechter Software führen. Zentrale Unterschiede zwischen der klassischen und der agilen Perspektive werden im Anschluss an die klassischen Verfahren kurz vorgestellt.

Der Zeitraum vom Beginn der Planung bis zum Ende der Nutzung einer Software an irgendeinem Einsatzort wird in der Informatik als Softwarelebenszyklus¹⁵ bezeichnet (Herold et al. 2011). Der Lebenszyklus unterteilt diesen Zeitraum in verschiedene Phasen, die durch die jeweils zentralen Aufgaben für Informatiker*innen bestimmt werden. Während über die Anzahl der Phasen und die genaue Grenzziehung keine Einigkeit besteht,¹⁶ liegt in allen Varianten deutlich mehr Gewicht auf den Aktivitäten der Produktion vor der ersten Nutzung. Wie Nutzer*innen, Administrator*innen oder Entwickler*innen nach der Fertigstellung der ersten funktionsfähigen Version mit der Software umgehen, wird wenig differenziert betrachtet. Die Phasen des Lebenszyklus und die Aufgaben, mit denen klassische Vorgehensmodelle die Arbeit im Softwareentwicklungsprojekt strukturieren, sind daher zu großen Teilen identisch (eine typische Darstellung des Softwarelebenszyklus zeigt Abbildung 2.2). Da diese Aufgaben in modernen Softwareentwicklungsprojekten in der Regel zeitlich nicht eindeutig getrennt werden können (a.a.O., S. 56), werden sie in den meisten Vorgehensmodellen nicht als Phasen bezeichnet. Für die soziologische Perspektive ist das Konzept der Phasen jedoch hilfreich, da es erlaubt, die Abhängigkeiten zwischen den einzelnen Modellen des sozialen Phänomens in linearer Reihenfolge sichtbar zu machen. Diese Abhängigkeiten entstehen, da in jeder Phase das Modell, das im Rahmen der vorangegangenen Phase geschaffen wurde, als Vorlage für eine weitere Modellierung genutzt wird, in deren Rahmen einige der noch interpretationsoffenen Eigenschaften der Vorlage (z. B. „Schriftfarbe Blau“) in wohldefinierte Eigenschaften des Modells (z. B. „Schriftfarbe #5F9EA0“) übersetzt werden. Der Softwarelebenszyklus wird daher hier anhand der Phasen vorgestellt, auch wenn die Aktivitäten sich in der Praxis oft zeitlich überlappen.

Abbildung 2.2

(Eigene Darstellung in Anlehnung an Balzert 2011, S. 1)

Software-Lebenszyklus.

2.1.2.2 Softwareentwicklung im Projekt

Aus soziologischer Perspektive können Softwareentwicklungsprojekte als temporäre Organisationen betrachtet werden (Lundin und Söderholm 1995). Sie können innerhalb der Grenzen einer Organisation gegründet werden oder auch durch Kollaboration mehrerer Organisationen entstehen. Sie besitzen eine im Voraus festgelegte Lebenszeit, innerhalb derer eine bestimmte Aufgabe (hier die Produktion von Software oder die Modellierung eines sozialen Phänomens für den Computer) von einem dezidiert dazu abgestellten Team erfüllt werden soll. Wie alle Projekte sind auch Softwareentwicklungsprojekte auf vielfältige Weise mit den Organisationen verbunden, aus denen sie hervorgehen: Diese setzen die Projekte in Gang und geben initial Aufgaben und Lebenszeit vor, sie stellen eigene Mitglieder für das Team ab und finanzieren die Mitarbeit von Externen, sie legitimieren und unterstützen die Arbeit in den Projekten und bewerten, ob die Aufgabe erfüllt wurde oder noch erfüllt werden kann (a.a.O., S. 439–444). Zentrale Fragen für die Modellierung im Softwareentwicklungsprozess stellen sich damit bereits vor der Initiierung des Projekts. Um die Modellierung zu ermöglichen, müssen Organisationen verschiedene Unsicherheiten kontrollieren: Der Zweck, den die neue Software für die Organisationen erfüllen soll, muss festgelegt, das zu modellierende Phänomen ausgewählt und beides ebenso wie die dafür aufzuwendenden Ressourcen legitimiert werden. Die Initiator*innen müssen dazu innerhalb ihrer Organisation(en) durchsetzen, dass der Zweck als relevantes organisatorisches Problem und das Projekt als realistische Lösung für dieses Problem anerkannt wird. Mitarbeiter*innen müssen freigestellt, Zeitrahmen und Budget festgelegt und (unter Umständen) Verträge mit anderen Organisationen ausgehandelt und unterschrieben werden. Die Organisationssoziologie zeigt, dass solche Fragen nicht unproblematisch anhand übergeordneter Organisationsziele beantwortet werden können, sondern Gegenstand von Auseinandersetzungen sind, die von den Interessen und Machtressourcen der Mitglieder (Perrow 1986; Crozier und Friedberg 1979), gesellschaftsweiten oder feldspezifischen Institutionen (Scott 2014; Friedland und Alford 1991) und der Historie der Organisation (Luhmann 2000) abhängen, in denen sie stattfinden. Die Kontrolle über Zweck, Rahmenbedingungen des Softwareprojekts, Mitglieder und Bewertung wird in sozialen Prozessen ausgeübt, die vor der Initiation des eigentlichen Modellierungsprozesses stattfinden. Welche Software entsteht, hängt damit unmittelbar davon ab, wie diese vorgelagerten Prozessen aussehen.

2.1.2.3 Spezifikation

In der Logik klassischer Vorgehensmodelle wird zu Beginn der Softwareentwicklung in der Phase der Spezifikation (s. Abbildung 2.2, S. 40) festgelegt, welche Leistungen die Software erbringen und unter welchen Rahmenbedingungen sie arbeiten soll. Dazu wird zuerst ein Systemmodell erstellt, wobei als System in diesem Fall nicht allein das technische Artefakt, sondern das gesamte sozio-technische System bezeichnet wird, in dem dieses zum Einsatz kommen soll (Pressman 1997). Als sozio-technisches System kann je nach Einsatzzweck eine Abteilung, eine Organisation oder auch ein Zug mit Passagieren betrachtet werden. Anhand des Systemmodells sollen die Probleme des sozio-technischen Systems identifiziert und festgelegt werden, welche davon durch Software gelöst werden sollen. Elemente, Eigenschaften und Leistungen der Software sowie ihre technische Umgebung (z. B. Vorgaben zur Hardware, bereits vorhandene Software) sollen dann in einem Spezifikationsdokument (kurz: Spezifikation) möglichst genau beschrieben werden. Die Spezifikation ist damit ein Modell, das die für die Funktionen der Software als relevant erachteten Eigenschaften des sozialen Phänomens enthält, die anhand des Systemmodells und der Vorgaben der Initiationsphase des Projekts festgelegt wurden. Bei der Entwicklung von Individualsoftware¹⁷ bildet die Spezifikation häufig die Basis des Vertrags zwischen Kund*innen- und Entwickler*innenorganisation.

Technisches und sozio-technisches System werden in der Informatik als „zweckgerichtete Sammlung von miteinander verbundenen Komponenten“ betrachtet, „die zusammenwirken, um ein bestimmtes Ziel zu erreichen“ (Sommerville 2012). Diese Sichtweise verweist darauf, dass die Funktionen der Software und der Kontext, in dem sie zum Einsatz kommt, einander beeinflussen und dass auch einzelne Veränderungen auf einer Seite auf die andere Seite zurückwirken. Sie blendet aus, dass das Soziale in sozio-technischen Systemen nicht in klar umrissene Komponenten zerlegbar ist, deren Zweck feststeht, sondern Unsicherheiten mit sich bringt. Widersprüchliche und ambivalente Ziele, Konflikte und wechselnde Koalitionen zwischen Akteur*innenn und Abteilungen, routiniertes statt zweckorientiertes Handeln und differierende Interpretationen dessen, was Ziel, Zweck oder angezeigtes Zusammenwirken in konkreten Situationen bedeuten, kurz, ein großer Teil der sozialen Eigenschaften des sozio-technischen Systems werden bei der Abbildung auf das Systemmodell reduziert. Diese Reduktion ist zum Teil Ergebnis der Vorgaben der Initiator*innen, die vor Projektbeginn ausgehandelt wurden, zum Teil das Produkt des Modellierungsprozesses selbst. Mögliche Auseinandersetzungen über viele der Fragen, die sich aus solchen Facetten der Unsicherheit des Sozialen ergeben, können in diesem Prozess durch einen Verweis auf das Projektziel, den Zeitplan oder die verfügbaren Ressourcen beendet werden (Lundin und Söderholm 1995). Damit werden Unsicherheiten des aktuellen Prozesses gezielt an den vorangegangenen ausgelagert. Aufgelöst sind sie dadurch aber nicht! Es kann nicht ausgeschlossen werden, dass die gleichen Fragen zu einem späteren Zeitpunkt oder in einem anderen Kontext wieder aufgegriffen werden. In so einem Fall kommt die scheinbar an den vorgelagerten Prozess abgeschobene Unsicherheit in einem nachfolgenden Prozess unerwartet wieder zum Vorschein. Auch wenn solche Spätfolgen möglich sind: Die immer temporäre Kontrolle, die durch solche Verweise auf den Rahmen des Projekts ausgeübt wird, verhindert, dass der Modellierungsprozess unmittelbar zum Erliegen kommt, und sichert damit das Fortbestehen des Projekts.¹⁸

In klassischen Vorgehensmodellen des Software Engineerings setzt sich das Projektteam in dieser Phase aus Repräsentant*innen der zukünftigen Benutzer*innen¹⁹, den Stakeholder*innen, und Informatiker*innen, den Systemanalyst*innen, zusammen. Nach der Logik der Vorgehensmodelle gibt es eine klare Arbeitsteilung zwischen den Gruppen: Die Stakeholder*innen sollen Wissen über das soziale Phänomen und den Zweck der Modellierung bereitstellen. Die Systemanalyst*innen sollen dieses Wissen erheben, es in Anforderungen an die Software und ein Systemmodell übersetzen und daraus die Spezifikation entwickeln. In der Spezifikation sollen die Anforderungen der Stakeholder*innen in Form von eindeutig messbaren Eigenschaften dargestellt sein, deren Einhaltung später bei der Validierung überprüft werden kann (Pfleeger und Atlee 2006).

Unsicherheiten im Modellierungsprozess, die zum Beispiel durch widersprüchliche und unvollständige Aussagen der Stakeholder*innen über das System oder die Funktionen, die von der Software erwartet werden, entstehen, sind in der Informatik vorgesehen (Herold et al. 2011). Sie werden aber als Probleme betrachtet, die sich mit Hilfe geeigneter Methoden auf Dauer kontrollieren lassen (Sommerville 2012).²⁰ Ebenso problematisiert wird, dass die in der Spezifikation enthaltene Beschreibung der Anforderungen immer einen gewissen Grad an Interpretationsspielraum lässt, der von Akteur*innen in späteren Phasen unterschiedlich ausgelegt wird (z. B. a.a.O., S. 118). Aus soziologischer Perspektive ist im Zusammenhang mit diesen Fragen vor allem interessant, dass die Auswahl des Projektteams zur Kontrolle einiger dieser Unsicherheiten beiträgt, andererseits aber dazu führt, dass andere verstärkt werden. Einer dieser Kontrollmechanismen ist die Einbettung der Projektmitglieder in weitere soziale Kontexte. Projektmitglieder sind in aller Regel nicht nur gleichzeitig Mitglieder der Mutterorganisation, sondern gehören auch einer Abteilung, Hierarchiestufe, informellen Koalition u.ä. an. Die Auswahl der Teammitglieder macht es wahrscheinlich, dass bestimmte Fragen und Deutungen im Projekt (nicht) zum Vorschein kommen. Dies vereinfacht zunächst, dass das Modell überhaupt entsteht. Es begünstigt auch, dass einige Eigenschaften des sozialen Phänomens als relevanter eingeschätzt und damit eher in das Modell übernommen werden als andere. Dadurch wird nicht nur Unsicherheit im Modellierungsprozess kontrolliert, sondern auch für alle weiteren Phasen im Lebenszyklus der Software – so zumindest die implizite Annahme. Ein anderer Mechanismus, der einige Unsicherheiten kontrolliert und andere verstärkt, ist die Ausbildung in den Methoden des Software Engineering. Die Methoden des Software Engineering verhindern viele Unklarheiten und mögliche Auseinandersetzungen von vorneherein, indem sie Stakeholder*innen von Systemanalyst*innen systematisch voneinander trennen,²¹ allen bestimmte Aufgaben zuweisen und für jede Gruppe Handlungsvorlagen bereitstellen. Die in der Ausbildung vermittelte rationalistische Grundhaltung sorgt andererseits aber auch dafür, dass z. B. Unterschiede in den Perspektiven der Stakeholder*innen für die Systemanalyst*innen systematisch ausgeblendet werden. Soziologisch lässt sich in diesem Zusammenhang sowohl fragen, wie sich die unterschiedlichen Zugehörigkeiten der Akteur*innen auf ihre Interpretation des Modellierungsgegenstands auswirken, als auch, welche Möglichkeiten sie dadurch haben, diese Interpretationen im Modellierungsprozess zur Geltung zu bringen.

Bei der Entwicklung von Standardsoftware können Mitglieder der Organisation, die die Software herstellt, die Rolle der Stakeholder*innen übernehmen. Es stellen sich ähnliche Fragen wie bei Individualsoftware, selbst wenn das Projekt hauptsächlich von einer einzigen Organisation getragen wird. Häufig werden in diesem Fall jedoch Repräsentant*innen der zukünftigen Kund*innengruppe in irgendeiner Form einbezogen (Pollock et al. 2007) oder die Softwarehersteller*in erweitert ein als Individualsoftware entwickeltes Produkt zum Standardprodukt weiter (Schmidt 2008). In solchen Fällen ist aus soziologischer Perspektive nicht nur interessant, wie Teammitglieder innerhalb ihrer Organisationen konkret ausgewählt werden, sondern auch, welche Gruppen oder Organisationen als repräsentativ für die Kund*innengruppe definiert werden und dadurch Einfluss auf die Softwareentwicklung nehmen können. Zudem stellt sich die Frage, wie, von wem und zu welchem Zeitpunkt im Modellierungsprozess die Anforderungen von spezifischen Erfahrungen der Teammitglieder zu repräsentativen Eigenschaften eines generischen Modells werden. Gerade bei Standardsoftware, die in vielen unterschiedlichen sozialen Kontexten eingesetzt wird, ist später nur schwer nachvollziehbar, welche möglichen Alternativen durch solche Entscheidungen ausgeblendet worden sind und an welchen sozialen Prozess die Kontrolle über diese Unsicherheiten damit ausgelagert worden ist. Bei der Nutzung ist damit häufig unmöglich festzustellen, welcher Logik konkrete Eigenschaften der Software folgen, welche Zwecke damit verbunden sind und an wen Fragen zu oder Kritik an den Entscheidungen, die zu diesen Eigenschaften geführt haben, überhaupt adressiert werden könnten.

2.1.2.4 Entwurf

Im ersten Schritt des Modellierungsprozesses wird laut klassischer Vorgehensmodelle festgelegt, was die Software tun soll, bevor im zweiten Schritt die Frage geklärt wird, wie dies zu geschehen hat. In dieser zweiten Phase des Softwarelebenszyklus (Abbildung 2.2, S. 40), dem Entwurf, soll ein neues Modell konstruiert werden, in welchem alle Eigenschaften aus dem Spezifikationsdokument abgebildet sind, die in Softwarecode überführt werden können. Diese Eigenschaften aus dem Spezifikationsdokument werden als Systemanforderungen bezeichnet (Sommerville 2012).²² Ergebnis dieses Modellierungsschritts soll eine sowohl fachlich als auch technisch detailreiche und möglichst eindeutige Beschreibung der Software sein, die dann programmiert (also in Code überführt) oder aus bereits bestehenden Teilen zusammengesetzt werden kann. Zwar gibt es unterschiedliche Paradigmen und Methoden für den Entwurf von Software, sie teilen sich aber die zentrale Grundannahme, dass sich alle Systemanforderungen in irgendeiner Form durch das Verhältnis von statischen (Daten) und dynamischen (Funktionen) Elementen beschreiben lassen (Rolf et al. 1998).²³

Der Umgang mit verschiedenen Aspekten der Unsicherheit des Sozialen wird auch in klassischen Vorgehensmodellen der Softwareentwicklung problematisiert. Dies betrifft allerdings nur die Spezifikationsphase. Mit der Fertigstellung des Spezifikationsdokuments verschwindet der Umgang mit diesen Unsicherheiten aus dem offiziellen Aufgabenbereich der Softwareentwickler*innen. In der Entwurfsphase geht es nur noch um die Modellierung der Spezifikation, nicht mehr um die des sozio-technischen Systems (Sommerville 2012). Unsicherheiten im Entwurf beruhen damit auf Ungenauigkeiten in der Spezifikation. Soziologisch ist dies anders zu bewerten: Für die Überführung der Anforderungen in den Entwurf gibt es keine eindeutig definierte Vorgabe, es sei denn, man bezeichne das Fehlen einer solchen als eben diese. Vielmehr gilt der Entwurf im Software Engineering als kreativer Prozess, der vor allem Erfahrung verlangt (Sommerville 2012). Damit entstehen zusätzlich zu den in der Entwurfsphase ausgeblendeten (aber nicht aufgelösten) Unsicherheiten aus der Phase der Spezifikation neue Unsicherheiten darüber, auf welche Weise die Spezifikation am besten in den Entwurf zu überführen ist. Wie das erfolgen soll, muss daher neu ausgehandelt werden. Wer diesen Prozess gestalten kann, ist bedeutsam. Soziologisch interessant ist daher, wie das alles zwischen den Organisationen, die das Projekt tragen, zwischen den Organisationen und dem Projektteam und zwischen den Mitgliedern innerhalb des Teams ausgehandelt wird und wie dies den weiteren Prozess und damit auch die nächsten Modelle beeinflusst.

Eine der grundlegenden Fragen, über die im Rahmen des Entwurfsprozesses verhandelt wird ist, aus welchen Komponenten sich die Software zusammensetzen soll und welche Verbindungen zwischen diesen bestehen sollen. Diese als Software-Architektur bezeichnete Grundstruktur wird im Entwurfsprozesses als erstes modelliert. Alle weiteren Modellierungsschritte werden auf dem Architekturmodell aufgebaut. Die Architektur kann später, wenn überhaupt, nur mit großem finanziellen, zeitlichen und häufig auch mikropolitischen Aufwand verändert werden, da mit ihr auch ein großer Teil des Codes geändert oder zumindest auf seine Funktion überprüft werden müsste. Aus diesem Grund bleibt sie üblicherweise auch in ansonsten auf Flexibilität ausgelegten Entwicklungsprojekten dauerhaft stabil (Sommerville 2012). Soziologisch betrachtet ist die Modellierung der Software-Architektur in ihrer Bedeutung für alle folgenden Phasen des Lebenszyklus darin dem Prozess der Initiation des Softwareprojekts gleichzusetzen. Durch die Architekturentscheidung zu Beginn wird der Teil der Aufgabe des Softwareprojekts, der noch nicht als gelöst angesehen wird, in Einzelaufgaben unterteilt, die im weiteren Verlauf von Entwurf und Implementierung größtenteils unabhängig voneinander bearbeitet werden sollen. Der Verweis auf die Software-Architektur, die bei ihrer Modellierung getroffenen Entscheidungen und die Kosten, die Veränderungen daran mit sich bringen würden, kann damit in allen späteren Phasen des Lebenszyklus genutzt werden, um Auseinandersetzungen über die Softwareentwicklung abzuwehren. Gelingt dies, werden Unsicherheiten (temporär) kontrolliert, indem sie an den Entwurfsprozess ausgelagert werden – wie immer ohne dass sie dadurch dauerhaft aufgelöst werden könnten.

2.1.2.5 Implementierung

Auf den Entwurf, Phase 2 im Softwarelebenszyklus, folgt die Phase der Implementierung (s. Abbildung 2.2, S. 40). In dieser Phase soll aus dem Modell, das im Entwurfsdokument festgehalten ist, die funktionsfähige Software programmiert werden. Die Programmierung ist damit der letzte Schritt der Modellierung eines sozialen Phänomens für den Computer, der nicht vollständig automatisiert ist.²⁴ Das Ergebnis der Programmierung ist ein Modell in einer Programmiersprache. In der Phase der Implementierung müssen die letzten am Ende der Entwurfsphase noch im Modell verbliebenen Unsicherheiten geschlossen werden, weil es in den formalen Programmiersprachen nicht möglich ist, Unsicherheiten auszudrücken. Alles Programmierte wird eindeutig in Operationen des Prozessors übersetzt. Ähnlich wie der Entwurfsprozess gilt jedoch auch die Übersetzung des Entwurfs in Programmcode als nicht vollständig formalisierbar: „Die Programmierung ist eine individuell gestaltete Aktivität und es gibt dafür keinen allgemeingültigen Prozessverlauf“ (Sommerville 2012, S. 67). Die einzelnen Programmierer*innen besitzen bei der Implementierung damit trotz aller in den vorangegangenen Phasen erfolgten Festlegungen immer noch einige individuelle Handlungsspielräume zur Mitgestaltung des Endergebnisses. Obwohl jede einzelne Programmierer*in eigene Teile des Codes schreibt, ist die Implementierung primär eine kollaborative Aufgabe. Denn je nach Umfang der Software definieren ein Team oder mehrere Teams von Softwareentwickler*innen zusammen das Gesamtergebnis und leiten aus diesem dann immer kleinere Teilaufgaben ab, die schließlich von Einzelpersonen ausgearbeitet werden.

Soziologisch ist in der Phase der Implementierung vor allem interessant, wie Programmierer*innen mit den Unsicherheiten aus dem Entwurf umgehen und welche Rolle ihre Einbindung in verschiedene soziale Zusammenhänge dabei spielt. Nach Einflussfaktoren kann dabei im Team des (Teil)projekts (Button und Sharrock 1996), innerhalb der Organisation, die Programmierer*innen beschäftigt (Barrett 2004) oder in der Profession (Bloomfield und Vurdubakis 1997; Funken 2001) gesucht werden. Wie in allen vorangegangenen Phasen bringt die Einbettung in diese sozialen Zusammenhänge einerseits Mechanismen mit sich, über die sich Unsicherheit verringern lässt, andererseits aber auch solche, die neue Unsicherheit in den Prozess hineinbringen. Ein Beispiel für ersteres sind Stellenbeschreibungen, die verschiedenen Teammitgliedern eindeutige Aufgaben und Entscheidungsbefugnisse zuweisen. Beispiel für zweiteres ist die Mitgliedschaft in einem Professionsverband, der Prinzipien für gute Programmierung festlegt und seine Mitglieder dazu animiert, ihre eigene Arbeitspraxis zu hinterfragen. Während im ersten Fall das Auftreten von Unsicherheit (bei der Aufgabenverteilung) im Voraus verhindert wird, erzeugt die Kritik an den Programmierprinzipien im Projekt neue Unsicherheit durch den Anstoß von außen. In beiden Fällen versuchen Akteur*innen aber, Unsicherheit an andere soziale Prozesse auszulagern, indem sie sich auf die sozialen Zusammenhänge beziehen, in die sie zusätzlich zum Projekt eingebettet sind.

Moderne Software wird in der Implementierungsphase praktisch nie vollständig neu programmiert. Stattdessen werden mehr oder weniger bereits vorhandene Programme oder Programmbausteine mit neu programmiertem Code verbunden (Claus und Schwill 2003). Die Folgen der Wiederverwendung für die soziale Komplexität der Software werden im Abschnitt 2.1.3 diskutiert. Sie bilden ein wesentliches Moment eines soziologischen Verständnisses von Softwareentwicklung.

2.1.2.6 Test

Am Ende der Implementierungsphase ist aus dem Entwurf eine Sammlung an Teilmodellen entstanden. Diese müssen nun für ein komplettes Modell in Form des vollständigen Softwarecodes noch zusammengefügt werden. In die Phase des Tests (s. Abbildung 2.2, S. 40) fallen die Aktivitäten nach der Implementierung und vor der Fertigstellung der Software. In dieser Phase wird geprüft, ob die Modellierung des sozialen Phänomens für den Computer die Aufgabenstellung des Softwareprojekts erfüllt. Tut sie das nicht, werden Modell oder Aufgabenstellung so lange verändert, bis beides übereinstimmt. Gelingt es nicht, diese Übereinstimmung herzustellen, gilt das Projekt als gescheitert. Klassisch wird beim Test lapidar gesagt festgestellt, ob die Software das tut, was sie tun soll. Dazu müssen zwei Fragen beantwortet werden, die zumindest theoretisch klar voneinander getrennt werden können: Hat die Software Fehler? Und stimmt sie allgemein mit den Erwartungen überein? (Sommerville 2012).²⁵ Als Fehler gilt dabei etwa, wenn Funktionen nicht ihrer Beschreibung in einem der Modelle entsprechen, z. B. wenn die Software unter bestimmten Bedingungen anders funktioniert, als es in der Spezifikation festgelegt wurde. Fehler bilden damit eine relevante Teilmenge aller unerfüllten Erwartungen, die an die Software gerichtet werden. Andere unerfüllte Erwartungen sind solche, die absichtlich oder unabsichtlich nicht in das Modell aufgenommen worden sind, aber beim Ausführen der Software gleichwohl als Erwartungen adressiert werden. Für diese Restkategorie unerwarteter Funktionen gibt es in der Informatik keinen einheitlichen Begriff. In klassischen Vorgehensmodellen steht stehen das Auffinden und Beheben von Fehlern im Mittelpunkt der Testphase.²⁶

Aus soziologischer Perspektive ist nicht nur der Umgang mit Fehlern und anderen unerfüllten Erwartungen interessant, sondern auch die Frage, wie zwischen den beiden Formen unerwarteten Verhaltens unterschieden wird. Beim Test werden die Funktionen der Software wieder und wieder ausgelöst, wobei die Bedingungen systematisch verändert werden. Die Testenden versuchen dabei, Rand- und Extrembedingungen der Anwendung nachzustellen und dadurch Unterschiede zwischen erwarteten und beobachteten Funktionen zu entdecken, die dann, so als relevant und behebbar eingestuft, von den Entwickler*innen beseitigt werden sollen. Es stellt sich dabei nicht nur die Frage, ob die beobachtete Funktion ein Fehler ist, sondern auch, ob der Fehler überhaupt behoben werden muss, damit das Projekt erfolgreich abgeschlossen werden kann. Bei den Verhandlungen darüber, wer was wann und warum verändern muss, um Erwartungen und Funktionen in Einklang zu bringen, können die Unsicherheiten, die in vorangegangenen Phasen bereits bearbeitet worden sind, erneut zum Thema gemacht werden.

In klassischen Vorgehensmodellen wird zwischen verschiedenen Arten von Tests unterschieden, die sich auf unterschiedliche Ebenen des Modells beziehen. Dazu werden die Modellierungsschritte rückwärts nachvollzogen und überprüft, ob die produzierten Codeteile und, nach deren Integration, die gesamte Software die Funktionen zeigt, die sie dem Modell zu Folge zeigen soll (Abbildung 2.3 zeigt diese Logik vereinfacht am Beispiel des V-Modells).

Abbildung 2.3

Beziehung von Modellebenen und Testebenen nach dem V-Modell (Brandt-Pook und Kollmeier 2015, S. 24)

Programmierer*innen oder Softwaretester*innen testen einen großer Teil der Software schon während der Programmierung der Komponenten oder während ihrer Integration. Softwaretester*innen sind so Teil des Entwicklungsteams. Sie haben aber weder den Code verfasst, dessen Funktionen sie überprüfen, noch sind sie Stakeholder*innen der fertigen Software. Letztere kommen beim klassischen Vorgehen erst ganz am Ende der Testphase zum Zug. Die Akteur*innen, die die Software testen, sind also alle vorher in unterschiedlichem Ausmaß an den Prozessen der Entwicklung beteiligt gewesen. Die nun zu testende Software bildet also zunächst die Ergebnisse früherer Modellierungsprozesse ab. Bedeutsam ist ferner: Fehler zu beheben kostet Zeit, die im Projekt immer knapp ist (Lundin und Söderholm 1995). Der Verweis auf die Zeit kann damit auch strategisch genutzt werden um durchzusetzen, dass statt des Codes die Erwartung angepasst und eine Funktion nicht als Fehler, sondern als akzeptables Ergebnis der Modellierung angenommen wird. Das Modell bleibt gleich, die Vorlage wird verändert, und schon stimmen beide doch noch überein. So kann die bestehende Software als „Zwang des Faktischen“ im Nachhinein Kontrolle zwischen den Phasen des Lebenszyklus verschieben: Im Entwicklungsprozess werden Unsicherheiten des Sozialen durch Entscheidungen über die Eigenschaften des Modells kontrolliert. Die Entscheidungen sind das Ergebnis von Aushandlungen, die von den beteiligten Akteur*innen und den Bedingungen abhängen, unter denen verhandelt wird. Wenn eine Entscheidung, die in der Spezifikationsphase getroffen worden ist, in der Testphase in Frage gestellt wird, beginnt die Aushandlung erneut. Die fertig programmierte Software und die verstrichene Zeit bilden dabei neue Bedingungen für die Aushandlung. Selbst wenn die Akteur*innen und ihre Verhandlungsziele gleichbleiben, kann sich dadurch das Kräfteverhältnis so verschieben, dass die Entscheidung nun anders ausfällt als beim ersten Mal. Ein Beispiel dafür ist, wenn Mitglieder der Finanzabteilung, die bei der Erhebung der Anforderungen nicht verhindern konnten, dass eine Funktion nach dem Wunsch der Fachabteilung in das Modell aufgenommen wird, nun im Test keine weiteren Mittel für die Behebung des Fehlers bewilligen und so die unbeliebte Funktion doch noch verhindern. Wenn auf diese Weise eine Entscheidung aus der Spezifikationsphase revidiert wird, so verschiebt sich damit auch die Kontrolle über die Unsicherheit aus der Spezifikations- in die Testphase.

2.1.2.7 Übergang in die Nutzung

Mit dem Abschluss der Testphase endet das Softwareentwicklungsprojekt.²⁷ Die soziologisch bedeutsamen Fragen lassen sich nun immer weniger an die Phasen des Softwarelebenszyklus anlehnen, weshalb die weitere Betrachtung nun nicht mehr an Hand der Phasen aus Abbildung 2.2 strukturiert wird. Klassischen Vorgehensmodellen zu Folge kann die Software nun in die Nutzung übergehen. Soziologisch ist dagegen auch die Evaluation des Projekts durch die initiierende(n) Organisation(en) bedeutsam. Dabei werden die Funktionen der Software, Dauer und Kosten des Projekts sowie andere Ergebnisse der Projektarbeit (z. B. die Dokumentation der Software oder eventuelle Schulungsunterlagen) begutachtet, bewertet und mit den vor Beginn des Projekts getroffenen Festlegungen verglichen. Genau genommen sind die Grenzen zwischen Softwaretest und Evaluation des Softwareentwicklungsprojekts fließend: Die am Prozess der Softwareentwicklung beteiligten Akteur*innen antizipieren während der Testphase, welche Auswirkungen ihre Handlungen auf die Evaluation des Projekts haben. Die nicht am Projekt, aber an der Evaluation beteiligten externen Stakeholder*innen antizipieren, wie und in welcher Qualität ihre Anforderungen im Projekt aufgenommen worden sind – oder entwickeln zumindest diesbezüglich Erwartungen. Dies kann – wie üblich – strategisch genutzt werden, wenn Akteur*innen die Unsicherheit über die zukünftige Evaluation des Gesamtprojekts ausnutzen, um eine Einigung zum Umgang mit Fehlern herbeizuführen.

Entscheidend ist nun: Für Akteur*innen außerhalb des Softwareprojekts sind die Modelle, auf denen die Funktionen beruhen, in der Regel nicht zugänglich. Software wird als ausführbarer Code ausgeliefert, der veränderbare Quellcode verbleibt bei der Herstellerin bzw. beim (Nachfolge)Projekt.²⁸ Mit dem Übergang in die Nutzung entsteht eine neue Form des Umgangs mit Software: Auf der einen Seite besteht Software als Objekt der Modellierung in den Prozessen der Weiterentwicklung fort. Auf der anderen Seite wird Software als Trägerin von Funktionen Teil von sozialen Prozessen, in denen diese Modellierungsprozesse und die dabei ausgeblendeten Unsicherheiten nicht oder nur sehr eingeschränkt nachvollzogen werden können. Die Performativität der Software, die sich mit jedem Schritt der Softwareentwicklung weiter spezifiziert und in Ansätzen vor allem bereits in der Testphase aufscheint, tritt in diesen Prozessen in den Vordergrund; dies geschieht nun allerding im Kontext eines neuen Sozialsystems, nämlich der anwendenden Organisation.

Damit die neu entstandene Software genutzt werden kann, muss sie nun in ein anderes sozio-technisches System integriert werden, welches im Systemmodell antizipierend abgebildet worden ist. Im Softwarelebenszyklus wird diese Phase als Installation bezeichnet. Damit wird betont, dass die zentrale Aktivität für Informatiker*innen die Einbindung der ausführbaren Software in die technische Infrastruktur des Nutzungskontexts ist. Veränderungen am Code der Software – vor allem grundlegender Art – sind in dieser Phase nicht mehr vorgesehen. Eine Ausnahme stellt das unten diskutierte Customizing dar. Aus Sicht der Informatik müssen für die Einbindung in den Nutzungskontext lediglich die Daten, deren Verarbeitung im Code beschrieben ist, hinzugefügt oder deren Werte verändert werden, wenn diese noch auf den Kontext der Softwareentwicklung verweisen (Balzert 2011). Einige dieser Daten (z. B. Benutzernamen, Hardwareinformationen etc.) dienen primär der Integration und werden in der Regel nur im Rahmen von Installationen und Betrieb verändert. Andere (und deutlich mehr) werden von der Software verarbeitet und erzeugen ihre Funktionen. Wie, von wem und im Rahmen welcher sozialen Prozesse diese Daten entstehen, hängt von vielem ab, nicht zuletzt von der Art der Software, den Kompetenzen der zukünftigen Nutzer*innen und der Art, wie der Nutzungskontext organisiert ist.²⁹ Die Fragen, die sich daraus ergeben, werden hier nicht allgemein ausdifferenziert.³⁰ Ich konzentriere mich hier auf Software, die für Organisationen entwickelt ist und in Organisationen eingebunden werden soll.

2.1.2.8 Einführung in sozio-technische Systeme

Bei der Einführung von Organisationssoftware in Organisationen werden Vorgaben dafür entwickelt, wie im Alltag der Organisation mit ihr umzugehen ist. Nach den Vorstellungen, die die klassische Softwareentwicklung prägen, soll durch die Integration von Organisationssoftware in Organisationen aus der bestehenden Organisation ein neues sozio-technisches System entstehen (vgl. die Ausführungen zum Systemmodell in 2.1.2.3). Aus dieser Perspektive sind die Vorgaben nötig um sicherzustellen, dass das neue System möglichst mit dem Systemmodell übereinstimmt und die Software damit den Zweck erfüllen kann, der zu Beginn der Entwicklung festgelegt wurde. Solche Vorgaben sind Modelle der Praktiken der Organisation in Form von Texten in natürlicher Sprache (z. B. in Handbüchern) und Bildern (z. B. Diagramme, Organigramme). Sie beschreiben, welche Tätigkeiten die Nutzer*innen innerhalb der neuen Praktiken ausführen sollen und welche durch Funktionen der Software ersetzt (oder im Vergleich zu den alten Praktiken ergänzt) werden. Soziologisch können die Prozesse, in denen diese Vorgaben entstehen, wie andere Prozesse der Regelbildung in Organisationen als Aushandlungen betrachtet werden, bei denen einige Akteur*innen innerhalb der Organisation versuchen, ihre Kontrolle über die Praktiken der Organisation in formalen Regeln festzuschreiben (Ortmann et al. 1990). Software wirkt in solchen Prozessen insofern performativ, als die Modelle im Code festlegen, welche Funktionen unter welchen Umständen erwartet werden können, welche Eingabedaten diese Funktionen verlangen und welche Ausgaben sie produzieren. Damit wird vorstrukturiert, welche Tätigkeiten durch Software ersetzt oder ergänzt werden können (und welche nicht), welche Art von Daten die Nutzer*innen eingeben müssen, wenn die Software erwartungsgemäß funktionieren soll (und welche nicht), und welche Ergebnisse innerhalb der Organisation weiterbearbeitet werden können (und welche nicht). Die Gegenstände, über die bei der Modellierung der Praktiken zum Umgang mit der Software verhandelt werden kann, sind damit durch die sozialen Prozesse bei der Modellierung der Software vorstrukturiert, sobald die Entscheidung für die Einführung dieser Software gefallen ist. Ob die Kontrolle des Nutzer*innenverhaltens gelingt, ist damit noch nicht entschieden.

Bevor ich mich der Softwarenutzung zuwende, werde ich im folgenden Abschnitt standardisierte Organisationssoftware vorstellen und erläutern, welche Besonderheiten diese Software im Hinblick auf Entwicklung und Integration aufweist. Diese Besonderheiten sind für die vorliegende Arbeit wichtig, da die standardisierte Organisationssoftware SAP Gegenstand der empirischen Analyse in Kapitel 4 ist. Für ein Verständnis dieser Analyse ist Grundwissen über die spezifischen Prozesse bei der Entwicklung und Integration von standardisierter Organisationssoftware daher unabdingbar. Besonders die Integration dieser Form der Software, das sogenannte Customizing, muss eigens erläutert werden.

2.1.2.9 Sonderfall standardisierte Organisationssoftware

In der Informatik wird standardisierte Organisationssoftware als Werkzeug betrachtet, welches Organisationen einsetzen, um ihre Arbeitsprozesse zu optimieren (folgende Zusammenfassung dieser Perspektive nach Rolf et al. 1998). Die Funktionen standardisierter Organisationssoftware sollen Organisationen in die Lage versetzen, die informationstechnische Bearbeitung möglichst aller betriebswirtschaftlich relevanten Vorgänge zu vereinheitlichen und nebenbei sicherstellen, dass diese Vorgänge unterschiedlichen regulatorischen Anforderungen genügen. Standardisierte Organisationssoftware ersetzt einzelne Programme für unterschiedliche Aufgaben (z. B. Lagerhaltung, Produktionsplanung, Rechnungslegung, Personalmanagement etc.) durch spezialisierte Module, die die gleichen Aufgaben erfüllen, aber über eine gemeinsame Datenbank, aufeinander abgestimmte Funktionen und ein einheitliches Erscheinungsbild verfügen. Die Software modelliert eine informationstechnisch integrierte Organisation: Informationen, die in den verschiedenen Bereichen der Organisation produziert werden, können als einheitlich formatierte Eingaben zu Daten der Software werden. Eine Anforderung an alle Komponenten der Software ist, dass die Daten aus verschiedenen Arbeitsprozessen ohne Eingriff der Nutzer*innen von einer Komponente an die andere übergeben werden können. Soziologisch ist vor allem bedeutsam, wie sich die Rahmenbedingungen, Akteur*innen und Prozesse bei der Entwicklung, Integration und Nutzung von standardisierter Organisationssoftware von den bisher beschriebenen unterscheiden. Die grundlegende Aufgabe des Softwareentwicklungsprozesses, Unsicherheit aus dem Sozialen durch Entscheidungen über Eigenschaften des Modells zu kontrollieren, bleibt bestehen. Hinzu kommt aber noch die Anforderung, dabei ein Modell zu konstruieren, welches eine große Bandbreite an konkreten sozio-technischen Systemen möglichst genau abbildet. Diese Anforderung erhöht die Unsicherheit aller Modellierungsschritte deutlich, ebenso wie die Anzahl der (potentiell) beteiligten Akteur*innen und sozialen Zusammenhänge, relevanten Rahmenbedingungen und Aushandlungen.

Besonderheiten der Softwareentwicklung

Die Modellierung standardisierter Organisationssoftware wird primär von einer Softwareherstellerin getragen, die als Initiatorin des Entwicklungsprojekts entscheidet, auf welche Organisationen die Funktionen ausgerichtet sein sollen. Im Rahmen der Initiation des Entwicklungsprojekts wirbt die Herstellerin bestimmte Organisationen, sogenannte Pilotorganisationen, an, die Mitarbeiter*innen entsenden, die als zusätzliche Stakeholder*innen an den Modellierungsprozessen beteiligt werden. In der Logik der klassischen Softwareentwicklung ergänzen die Repräsentant*innen der Pilotorganisationen das Wissen der Softwareherstellerin über typische Anforderungen der Organisationen im anvisierten Markt durch eigene Erfahrungen (Pollock und Williams 2009; Scott und Kaindl 2000). Soziologisch stellt sich die Zusammenarbeit von Softwareherstellerin und Pilotorganisationen weniger eindeutig dar: Softwareherstellerinnen müssen einen bestimmten Ausschnitt des Markts als Zielgruppe auswählen, mögliche Pilotorganisationen identifizieren und sie überzeugen, eigene Mitarbeiter*innen für die Beteiligung am Entwicklungsprojekt bereitzustellen. Die Kooperation muss in beiden Organisationen durchgesetzt, ihr Zweck bestimmt und die Zusammenarbeit während der Entwicklungszeit aufrechterhalten werden. Das Entwicklungsprojekt muss gegenüber Pilotorganisationen und Softwareherstellerin unterschiedlich legitimiert werden: In ersteren soll die Software nach ihrer Fertigstellung angewandt werden, während letztere sie verkaufen will. Für Pilotorganisationen lohnt sich die Beteiligung an der Kooperation daher vor allem, wenn dadurch möglichst viele ihrer konkreten Anforderungen in der entstehenden Software berücksichtigt werden. Für die Softwareherstellerin geht es in der Kooperation hingegen darum, möglichst wenig auf die spezifischen Unterschiede zwischen den Pilotorganisationen einzugehen, sondern herauszufinden, wie sich die konkreten Anforderungen in ein generisches Modell übertragen lassen, welches in möglichst vielen unterschiedlichen Organisationen eingesetzt werden kann (Pollock et al. 2007). Diese unterschiedlichen Ziele führen dazu, dass konkrete Anforderungen einzelner Pilotorganisationen und der Wunsch der Softwareherstellerin, mit dem Produkt einen möglichst großen Markt zu erreichen, während des Modellierungsprozesses in systematischem Konflikt stehen (a.a.O.). Gelingt die Modellierung trotz dieser Schwierigkeiten, so entsteht eine generische Grundform der Software. Diese enthält Vorlagen für Organisationsstrukturen, Arbeitsabläufe, Berechtigungen und ähnliches, die vor der Inbetriebnahme konkretisiert werden müssen, indem Daten über den Nutzungskontext (z. B. die Namen der Mitarbeitenden, Bezeichnungen der Abteilungen etc.) eingegeben und bestimmte Modellelemente (z. B. die für die Organisation relevante Variante der Bilanzierung) aktiviert werden (Davenport 1998). Erst nach dieser Konkretisierung kann die Software in einer konkreten Organisation funktionieren.

Besonderheiten der Integration: Customizing

Diese Konkretisierung der generischen Grundform der Software findet beim Customizing statt. Das Customizing kommt nicht als Phase im allgemeinen Softwarelebenszyklus vor, da es nur für standardisierte Organisationssoftware relevant ist. Customizing kann als eine eigene Form der Modellierung von Software verstanden werden, die den Akteur*innen weniger Kontrolle als Softwareentwicklung, aber mehr als reine Einführung ermöglicht. Der Modellierungsprozess beim Customizing lässt sich insofern mit dem bei der Softwareentwicklung vergleichen, da auch hier ein Modell des sozio-technischen Systems (der Organisation, die die Standardsoftware nutzen will) erstellt und in Software abgebildet werden soll. Customizing wird ebenso im Rahmen eines Projekts ausgeführt, das von der Organisation, in der die Software genutzt werden soll, sowie mindestens einer weiteren Organisation getragen wird. In der Regel ist dies ein IT-Beratungsunternehmen, das auf das Customizing des ausgewählten Standardprodukts spezialisiert ist, oder eine Beratungsabteilung der Softwareherstellerin selbst. Eine der Aufgaben (Lundin und Söderholm 1995) des Customizingprojekts ist es, aus der standardisierten Organisationssoftware in ihrer nicht ausführbaren generischen Grundform eine konkrete Version der Software zu schaffen, die in jener Organisation zum Einsatz kommt, die am Customizing beteiligt ist. Nach Angaben von Herstellerinnen wie SAP geht es im Customizing darum, die Software an die Organisation anzupassen (Boeder und Groene 2014). Tatsächlich geht es beim Customizing jedoch eher darum festzulegen, wann Eigenschaften des Modells in der Software an die entsprechenden Eigenschaften der Organisation angepasst werden und was umgekehrt an der Organisation verändert werden soll, damit diese mehr dem Modell in der Software entspricht. Aus informationstechnischer Sicht handelt es sich dabei um eine Gratwanderung:

„Die Übernahme der angebotenen Funktionen und Prozesse ist softwaretechnisch zwar die einfachere Lösung, sie ist allerdings häufig mit organisatorischen Verwerfungen und Unruhe bei den Beschäftigten verbunden. Anpassungen, die zu stark auf die Betriebshistorie abstellen, verwässern in der Regel das Prozeßmodell und können softwaretechnisch aufwendig werden.“ (Rolf et al. 1998, S. 112)

Soziologisch können bei der Integration und beim Customizing selbst die gleichen Prozesse wie bei der Softwareentwicklung beobachtet werden. Die Frage, welche Eigenschaften der Softwaremodelle übernommen werden und wann stattdessen Eigenschaften der Organisation verändert werden sollen, ist Gegenstand vielfacher Aushandlungen. Da standardisierte Organisationssoftware in der Regel in mehreren (oder allen) Bereichen einer Organisation zum Einsatz kommen soll, treffen in diesen Aushandlungen Akteur*innen mit sehr unterschiedlichen sozialen Einbettungen, Zielen und Machtressourcen aufeinander. Die komplexe und in der Regel zu hohen Kosten eingekaufte Software beeinflusst den Ausgang dieser Aushandlungen erheblich (Pollock und Cornford 2004). Der zentrale Unterschied zwischen Customizingprojekt und allgemeinem Softwareentwicklungsprojekt liegt darin, dass das Customizingprojekt unauflösbar an eine spezifische Software gebunden ist. Deren Modell bietet bestimmte Elemente zur Konkretisierung an (z. B. Art der Organisationseinheiten) und beinhaltet Optionen, zwischen denen im Customizingprozess ausgewählt werden kann (z. B. Abteilung, Arbeitsgruppe oder Team, vgl. SAP AG 2001, D8.16.2.1, S. 15 f.). Andere Elemente des Modells sind als Standardoptionen gesetzt und können, müssen aber nicht bearbeitet werden, damit die Software ausgeführt werden kann. Wieder andere Elemente sind nicht zur Bearbeitung vorgesehen. Um sie zu ändern, muss der Code bearbeitet werden. Selbst wenn die Akteur*innen im Customizing Zugriff auf eine so bearbeitbare Version der Software haben, besitzen sie keine vollständige Beschreibung der Modelle, die den einzelnen Codestellen unterliegen, und ihrer Abhängigkeiten zu einander. Diese Beschreibungen sind geistiges Eigentum der Softwareherstellerin und werden in aller Regel als Teil des Geschäftsgeheimnisses behandelt. Veränderungen im Code von Standardsoftware bringen daher das Risiko mit sich, auch unvorhersehbare Veränderungen an den Funktionen der Software zu verursachen (Light 2001).

Die Ziele und Handlungsoptionen der Akteur*innen beim Customizing werden in vielfacher Hinsicht von ihrer Einbindung in die Organisationen vorgeformt, die sie in das Projekt geschickt haben. Repräsentant*innen der Kundenorganisation treten als Expert*innen für das sozio-technische System auf, unabhängig davon, mit welchen Ausschnitten dieses Systems sie faktisch Erfahrung haben und inwieweit ihre Ziele bei der Modellierung mit den Zielen der Akteur*innen übereinstimmen, die mit der Software später im Alltag Umgang haben werden (Wagner et al. 2006). Auf die gleiche Weise können Berater*innen sich auf überlegene Kenntnis der Modelle in der Standardsoftware sowie Erfahrungen mit vergangenen Customizingprojekten berufen, unabhängig davon, wie akkurat ihr Wissen über die Software oder wie vergleichbar die vergangenen Prozesse mit den aktuellen sein mögen (Mormann 2016). Zukünftige Nutzer*innen können bestimmte Veränderungen mit Verweis auf die Praxis einfordern, Vertreter*innen der Organisationsleitung können andere mit Verweis auf die vorgesehenen Optionen, die Kosten einer Abweichung von Standardoptionen (Benders et al. 2006) oder die Risiken von Codeveränderungen (Light 2001) ablehnen. Die Vorgaben der generischen Form der Standardsoftware dazu, welche Modellelemente wie konkretisiert werden können, strukturieren die Handlungsspielräume der Akteur*innen in diesen Prozessen (Pollock und Cornford 2004). Sie verbinden verschiedene Modellierungsoptionen mit unterschiedlichen Aufwänden und Risiken und definieren, welche Akteur*innengruppen bei welchen Fragen als Entscheider*innen vorgesehen sind. Auch wenn die Akteur*innen im Customizingprozess von diesen Vorgaben abweichen können, müssen solche Abweichungen aufwändig legitimiert werden. Insgesamt wird es dadurch wahrscheinlich, dass die Modelle des sozio-technischen Systems, die im Customizingprozess entstehen, den Modellen der Organisation ähneln, die in der Standardsoftware angelegt sind (Gosain 2004). Die Standardsoftware wirkt damit im Customizingprozess performativ.

Bei der soziologischen Untersuchung von Customizingprojekten stellen sich einerseits Fragen dazu, wie die Akteur*innen im Projekt mit den ihnen von ihren Organisationen zugewiesenen Rollen und mit den von der Software vorgesehenen Handlungsspielräumen umgehen. Wie gehen sie in den Modellierungsprozessen im Projekt und in den Aushandlungen im Außenverhältnis vor, um ihre eigenen Vorstellungen davon, wie Organisation und Software aneinander angepasst werden sollen, durchzusetzen? Andererseits ist zu untersuchen, in welcher Phase und unter Mitwirkung welcher Akteur*innen im Softwareentwicklungsprozess die Festlegungen getroffen werden, die den Akteur*innen im Customizing als unveränderliche Eigenschaften der Software gegenübertreten. Über diese Eigenschaften, also z. B. die Optionen für mögliche Einheiten der Organisation, werden Unsicherheiten, die die konkrete Organisation betreffen, aus dem Customizingprozess in die Softwareentwicklung verlagert. Damit verschiebt sich auch ein Teil der Kontrolle über diese Unsicherheiten hin zu den sozialen Prozessen, in denen Softwarehersteller*in, Pilotorganisationen und andere Akteur*innen Einfluss auf die Entwicklung der Standardsoftware nehmen.

2.1.2.10 Softwarenutzung

Im Softwarelebenszyklus (s. Abbildung 2.2, S. 40) folgt auf die Installation der Software der Betrieb, also eine Phase der technischen Betreuung der Software im veränderten sozio-technischen System.³¹ Soziologisch stellt jedoch die Nutzung den relevanteren Untersuchungsgegenstand in dieser Phase dar. Bei der Nutzung ist die Software technisch und organisatorisch in das sozio-technische System integriert, in das sie in der Phase der Integration eingeführt worden ist. Sie kann nun zum Einsatz kommen. Ob dies tatsächlich geschieht, also ob sich an die Integration eine Phase der Nutzung oder der Nicht-Nutzung anschließt, ist – wie schon vieles in vorangegangenen Phasen – unsicher. Es muss ausgehandelt werden, ob und wie die neue Software in bestehende Prozesse eingebaut wird. Bei diesen Aushandlungen treffen die Modelle eines sozialen Phänomens, die im Laufe des Entwicklungsprozesses geschaffen worden sind, nun zum ersten Mal auf eine reale Version des Phänomens.³² Diese Modelle sind in den Datenstrukturen und Funktionen des Softwarecodes enthalten. Auch die Anleitungen und Vorgaben für die Nutzung, die parallel zur Softwareentwicklung und während der Phase der Integration geschaffen worden sind, stellen Modelle der Anwendung dar. Der Code (und die Vorgaben zur Nutzung der Software) kommen nun innerhalb des Phänomens zur Anwendung, welches sie beschreiben. Nach der Definition der Performativität, die zu Beginn von Abschnitt 2.1. erläutert wurde, wird die Software dann in den sozialen Prozessen, die dieses Phänomen auszeichnen, performativ, wenn diese durch die Nutzung den Modellen ähnlicher werden, durch die sie in der Software beschrieben sind. Dass Software die sozialen Prozesse, in denen sie eingesetzt wird, zumindest in gewissem Ausmaß auf diese Art beeinflusst, dürfte weder in der Soziologie noch in der Informatik ein überraschendes Untersuchungsergebnis darstellen. Interessanter ist, wie diese Veränderungen mit den sozialen Prozessen zusammenhängen, in denen die Software entwickelt und eingeführt wurde, und mit den sozialen Bedingungen, unter denen die Nutzung stattfindet.

Für Informatiker*innen steht bei der Nutzung die Frage im Mittelpunkt, wie gut die Software ihren Zweck erfüllt. In einem guten Modellierungsprozess sind hinreichend viele der Anforderungen, die auf Basis der Zweckbestimmung erhoben worden sind, hinreichend genau in Code übersetzt worden. Durch eine erfolgreiche Integration sind die Nutzer*innen soweit auf die notwendigen Veränderungen in ihren Praktiken eingestimmt worden, dass sie so mit der Software umgehen, dass der Zweck, der zu Beginn des Modellierungsprozesses festgelegt worden ist, hinreichend gut erreicht werden kann. Was genau „hinreichend“ bedeutet, wird vor, während und nach dem Softwareprojekt in immer neuen Akteur*innenkonstellationen und unter sich ständig verändernden Rahmenbedingungen ausgehandelt. Diese Aushandlungen bestimmen sowohl, wie die Software am Ende aussieht, als auch, welche Erwartungen bei der Nutzung an sie gerichtet werden. Diese Aushandlungen, die Softwareentwicklung für Soziolog*innen so interessant machen, werden in der Informatik kaum thematisiert. In einem aber sind sich Vertreter*innen beider Disziplinen einig: Keine Software kann alle Erwartungen erfüllen. Soziolog*innen können dies mit unterschiedlichen Standpunkten und widersprüchlichen Interessen, mehrdeutigen Interpretationen und sich wandelnden Ansichten begründen, also kurz: indem sie auf die Unsicherheiten des Sozialen verweisen. Informatiker*innen gehen davon aus, dass es immer Anforderungen gibt, die im Modellierungsprozess nicht aufgenommen oder darin falsch abgebildet werden, und dass andere Anforderungen erst durch den Umgang mit der Software zu Tage treten. Auch berücksichtigen sie, dass sich das sozio-technische System oder sein Umfeld im Laufe der Zeit verändern und dadurch neue Anforderungen entstehen oder die Software einen neuen Zweck erfüllen soll (Sommerville 2012). Unerkannte und sich verändernde Anforderungen werden in klassischen Vorgehensmodellen als Problem aufgenommen, das vielleicht nicht vollständig aufgelöst, aber dessen Lösung zumindest angestrebt werden soll. Aus der Praxis der Softwareentwicklung heraus haben sich dazu Ergänzungen entwickelt: Methoden, die die Verständlichkeit der Software für die Nutzenden und das Verständnis der Softwareentwickler*innen für die modellierten Gegenstände verbessern sollen.³³ Diese Methoden nehmen auch einige der Fragen auf, die in dieser Arbeit als soziologische Fragen vorgestellt worden sind. Besonders nah an der Thematik dieser Arbeit liegt die sogenannte agile Softwareentwicklung, eine Sammlung von Ansätzen, die auf der Annahme aufbauen, dass Unsicherheit nicht dauerhaft reduziert werden kann. Diese Ansätze verbreiten sich seit Mitte der 2000er Jahre immer stärker in der Informatik (Hoda et al. 2018). Bei großen Softwareprojekten, wie sie für die Entwicklung standardisierter Organisationssoftware nötig sind, kommen sie jedoch erst seit kurzem und keineswegs flächendeckend zum Einsatz. Für die Fragen der vorliegenden Arbeit ist das Verständnis der klassischen Vorgehensmodelle daher deutlich relevanter. Aus diesem Grund stelle ich die Grundideen der agilen Softwareentwicklung hier nur in einem Exkurs vor.

Exkurs: Agile Softwareentwicklung

In der agilen Softwareentwicklung stehen ein früher Kontakt der Nutzer*innen mit der Software und ständige Weiterentwicklung im Mittelpunkt. Der agilen Perspektive liegt die Annahme zu Grunde, dass Softwareentwicklung sich mit veränderbaren Gegenständen befasst und sich ihren Zielen grundsätzlich nur annähern kann. Damit stehen agile Ansätze im Gegensatz zur rationalistischen Tradition der Softwareentwicklung, die auf der Annahme basiert, dass die Unsicherheiten des zu modellierenden Phänomens durch ausgiebige Planung und das Befolgen strukturierter Prozessvorgaben systematisch reduziert werden können. Informatiker*innen, die die agile Perspektive einnehmen, lehnen das Konzept grundsätzlich getrennter Modellierungsphasen mit davon abgeleiteten Plänen, Aktivitäten und Rollenverteilungen ab und setzen auf selbstorganisierte Teams, aus deren Zusammenarbeit gute Software „emergieren“ soll (Beck et al. 2001). Zentral für agile Ansätze sind daher möglichst kurze Entwicklungszyklen, um Funktionen der Software möglichst früh in die Nutzung zu bringen und damit herauszufinden, inwieweit sie die intendierten Zwecke erfüllen. Die Beteiligung von Stakeholder*innen beschränkt sich nicht auf frühe und späte Phasen des Entwicklungsprozesses wie in klassischen Vorgehensmodellen. Stattdessen sind sie dauerhaft notwendiger Teil des Entwicklungsteams und sollen, ebenso wie dessen übrige Mitglieder, jederzeit neue oder geänderte Anforderungen an die Software formulieren und sich an der Erarbeitung von Lösungen beteiligen, mit denen diese Anforderungen erfüllt werden können. Die ideale Steuerung agiler Softwareprojekte fokussiert darauf, die Arbeitsumgebung so einzurichten, dass die Teammitglieder motiviert bleiben, Raum für direkte Interaktionen, gemeinsame Entscheidungen und Reflexion und stetige Weiterentwicklung ihrer Arbeitsprozesse haben. Auf diese Weise soll aus der von außen möglichst wenig kontrollierten Interaktion im Team durch ständiges Nachsteuern Software entstehen, die die Zwecke der Nutzung dauerhaft möglichst gut erfüllt.

Agile Ansätze der Softwareentwicklung sensibilisieren die Beteiligten insofern für soziologische Fragen, als sie den Unsicherheiten sozialer Prozesse gezielt bei der Modellierung selbst Raum geben.³⁴ Trotzdem bleiben auch agile Projekte hochgradig abhängig von den sozialen Bedingungen, unter denen sie stattfinden (Schulz-Schaeffer und Bottel 2018).³⁵

Aus soziologischer Perspektive werden bei der Nutzung zwar auch Aspekte betrachtet, die in der soziologisch inspirierten Informatiker*innenperspektive berücksichtigt werden, es werden aber auch Fragen gestellt, die darüber hinaus gehen. Ob Nutzer*innen mit Software so umgehen, wie es in ihren Modellen vorgesehen ist, wird nicht primär als Verständnisproblem thematisiert. Stattdessen steht im Vordergrund, wodurch die Handlungsspielräume beeinflusst werden, die Nutzer*innen beim Umgang mit der Software haben. Dabei entstehen einerseits Fragen nach den Zusammenhängen zwischen der Nutzung und den Prozessen im sozio-technischen System, in der sie stattfindet: Wie handeln Nutzer*innen miteinander neue Umgangsformen mit der Software aus? Wie gehen sie dabei mit den Modellen neuer Praktiken um, die bei der Einführung entwickelt worden sind? Und welche Rolle spielt die Tatsache, dass sie nicht nur Nutzer*innen der Software sind, sondern auch an anderen Prozessen (in- und außerhalb des sozio-technischen Systems) teilnehmen? Andererseits liegen auch Fragen dazu nahe, wie durch die Software soziale Prozesse, die während der Entwicklungsphasen des Softwarelebenszyklus stattfinden, Einfluss auf die Nutzung nehmen: Welche Handlungsspielräume werden den Nutzer*innen in den Modellen der Software zugedacht, wie sind diese zugeschnitten, welche versuchen die Modelle zu versperren? Welche Aspekte der Unsicherheit des Nutzungsprozesses werden bei der Modellierung vorweggenommen, in welchen sozialen Prozessen werden sie auf welche Gewissheiten reduziert und welche Art von Kontrolle wird dadurch aus der Nutzung in die Entwicklung verlagert?

Die Phase des Betriebs und der Nutzung schließt den Softwarelebenszyklus. Das „Leben“ der Software endet damit jedoch nicht: Wie bereits angedeutet, wird Software in aller Regel über einen längeren Zeitraum weiterentwickelt und verwendet, es werden also neue Versionen der Software erstellt, die bereits genutzt wird. Diese Weiterentwicklung wirft eigene soziologische Fragen auf, weil dabei die bestehende Version der Software ein Element der Modellierungsprozesse wird, in denen die neue Version der Software entsteht. Software kann dadurch bei der Weiterentwicklung Performativität entwickeln. Ebenso gilt dies bei der Wiederverwendung von Softwareelementen, wenn in einem Softwareentwicklungsprojekt einzelne Teile des Modells bereits fertig aus anderen Projekten übernommen werden. Beides sind Aspekte der Rekursivität von Software, mit der sich der nächste Abschnitt beschäftigt.

2.1.3 Weiterentwicklung und Wiederverwendung

Die bisherigen Ausführungen haben zwei Charakteristika von Software vorgestellt, die zu ihrer Komplexität beitragen: Das erste Charakteristikum ist die Tatsache, dass Software soziale Phänomene, die voller Unsicherheit sind, also nicht vollständig und eindeutig beschrieben werden können, weil jede Beschreibung von der Interpretation der Beschreibenden abhängt, in mathematische Formalismen übersetzt, die eindeutig und damit frei von Unsicherheit sind. Durch diese Übersetzung ist für Nutzende schwer nachvollziehbar, dass die Möglichkeiten, das Soziale zu interpretieren, durch den Umgang mit Software verändert werden: Alternative Interpretationsmöglichkeiten und nicht in der Software berücksichtigte Aspekte des Sozialen sind in den mathematischen Formalismen nicht mehr erkennbar. Das zweite sind die Prozesse, in denen Software entsteht und genutzt wird. In jedem dieser Prozesse werden einzelne Aspekte des Sozialen ausgewählt und über soziale Aushandlungen in eindeutige Eigenschaften der Software umgewandelt, die es den Akteur*innen ermöglichen, mit der Software umzugehen. Aspekte der Unsicherheit des Sozialen werden damit aus der Nutzung in die Entwicklung und innerhalb der Entwicklung zwischen den Prozessen verschoben. Welche Unsicherheiten dies sind und wie sie verschoben werden, hängt davon ab, wer sich in den konkreten Aushandlungen der einzelnen Prozesse durchsetzen kann. Selbst wenn Nutzende davon ausgehen, dass der Umgang mit Software Einfluss auf ihre Möglichkeiten hat, Soziales zu interpretieren, wird es durch diese Prozesse schwer nachzuvollziehen, wie, von wem und aus welchen Gründen diese Möglichkeiten beeinflusst werden. Beide Charakteristika können als Schichtungen verstanden werden: Die oberste Schicht, das soziale Phänomen, ist voller Unsicherheiten, voller Alternativen und Handlungsspielräume für die Akteur*innen, die mit Software umgehen. Die unterste Schicht, der Code, ist frei von Unsicherheit,³⁶ Alternativen und Handlungsspielräume gibt es nicht, weil nicht gehandelt wird, nur Operationen ablaufen.

Das dritte Charakteristikum ist die Rekursivität der Softwareentwicklung, also die Tatsache, dass neue Software aus der Kombination und Veränderung bestehender Software entsteht. Dieses Charakteristikum lässt sich am ehesten als Faltung begreifen: Wenn der Umgang mit Software neue Software produziert, entstehen dadurch auf allen Schichten des Produktes Abhängigkeiten zwischen den Elementen, die selbst geschichtete Unsicherheit beinhalten. Dies geschieht, wenn Software weiterentwickelt oder in andere Software eingebaut wird.

2.1.3.1 Bedingungen und Folgen der Weiterentwicklung

Software wird in der Regel über längere Zeiträume weiterentwickelt. Dabei werden zu unterschiedlichen Zeitpunkten einzelne Codezeilen oder ganze Komponenten ergänzt, entfernt oder gegen andere ausgetauscht, um der Software neue Funktionen zu geben oder sicherzustellen, dass ihre Funktionen unter veränderten Bedingungen erhalten bleiben. Der Weiterentwicklungsprozess enthält alle Aktivitäten des ursprünglichen Entwicklungsprozesses (vgl. Abbildung 2.4).

Abbildung 2.4

(Eigene Darstellung)

Software-Lebenszyklus bei der Weiterentwicklung.

Die Entwickler*innen agieren jedoch unter anderen Bedingungen, weil sie die bestehende Software verstehen müssen, um zu entscheiden, welche Änderungen am Code nötig sind und welche Auswirkungen diese Änderungen auf das Gesamtsystem haben (Sommerville 2012). Anders als beim ursprünglichen Entwicklungsprozess ist es bei der Weiterentwicklung deutlich schwieriger, grundlegende Entscheidungen über zu erfüllende Anforderungen oder Architektur der Software zu verändern, da jede Änderung in ein komplexes Ganzes eingreift, das zudem nicht vollständig bekannt oder transparent ist. Grundlegende Änderungen sind daher mit deutlich größerem zeitlichen und finanziellen Aufwand verbunden als bei Neuentwicklungen. Die Veränderungen müssen sich also in der Regel in bestehende Geflechte von Strukturen einfügen. Software wird durch die Weiterentwicklung daher mit der Zeit komplexer, fehleranfälliger und weniger leistungsfähig. Dies wird als Software-Alterung bezeichnet (Ludewig und Lichter 2013).³⁷

Anders als bei der primären Entwicklung ist die Software, die verändert wird, nun selbst Teil eines der sozio-technischen Systeme, die in ihr modelliert sind. Das bedeutet vor allem, dass die Nutzung der Software entscheidenden Anteil an der Weiterentwicklung hat: Probleme der Nutzer*innen, neue Formen der Regulation, Bedingungen der Anwendung und mögliche Lösungen werden in Auseinandersetzung mit vorliegenden Erfahrungen in sozio-technischen Systemen definiert. Daher gilt Weiterentwicklung in inkrementellen Vorgehensmodellen und vor allem in der agilen Softwareentwicklung als der beste Weg zur Modellierung sozialer Phänomene in Code (Sommerville 2012; Beck et al. 2001).

Aus soziologischer Perspektive wirkt Software damit in zweifacher Hinsicht performativ auf die Prozesse der Weiterentwicklung. Weiterentwicklung kann als Modellierungsprozess verstanden werden, bei dem einige Glieder der vorhandenen Kette an Modellen (Spezifikation, Entwurf, Code) so verändert werden sollen, dass sich daraus eine kontrollierte Veränderung des Umgangs mit der Software ergibt. Im Modellierungsprozess gilt es daher, zu verstehen, welche Aspekte des Sozialen bei der Entwicklung der bestehenden Software wie in Eigenschaften des Modells übersetzt worden sind. Daraufhin müssen dann die Unsicherheiten, die aus den neuen Anforderungen entstehen, für die Veränderung des Modells wieder in Eindeutigkeiten umgewandelt werden. Dies alles spielt sich wie bei der initialen Entwicklung im Rahmen von sozialen Prozessen ab. An diesen sind bei der Weiterentwicklung zwar häufig weniger und weniger divers sozial eingebettete Akteur*innen beteiligt als an der ursprünglichen Entwicklung.³⁸ Oft nehmen aber an der Weiterentwicklung andere Akteur*innen Teil als an der Entwicklung früherer Versionen. Diese neuen Teilnehmer*innen können zwar die Modelle früherer Versionen zum Teil einsehen, können aber in der Regel nicht nachvollziehen, unter welchen Bedingungen welche Unsicherheiten wann und von wem reduziert wurden, um diese Modelle zu erschaffen. Unsicherheiten aus dem Prozess der Weiterentwicklung werden damit in den Prozessen der ursprünglichen Entwicklung kontrolliert. Wechselwirkungen zwischen einzelnen Elementen dieser Modelle, die bei der initialen Entwicklung noch nachvollziehbar sind, werden in den Prozessen der Weiterentwicklung mit der Zeit verdeckt (Schmidt 2012).

Die bestehende Version der Software wirkt bei der Weiterentwicklung aber auch dadurch performativ, dass neue Anforderungen aus den Erfahrungen entstehen, die Akteur*innen mit ihrer Nutzung im sozio-technischen System gemacht haben. Diese Nutzung hängt, wie im vorangegangenen Abschnitt dargestellt, nicht nur von der Software selbst ab, sondern auch von den Aushandlungen, in denen darum gerungen wird, das Verhalten der Nutzer*innen im Umgang mit ihr zu kontrollieren. Die Weiterentwicklung wird dadurch auch von Auseinandersetzungen zwischen Berater*innen und Organisationsmitgliedern in Customizingprojekten, zwischen Vorgesetzten und Untergebenen, verschiedenen Abteilungen und unterschiedlichen Nutzer*innen darüber beeinflusst, wie die Software in der Organisation am besten genutzt werden sollte. Mit der Weiterentwicklung können Nutzer*innen Kontrolle über Aspekte ihres Umgangs mit der Software zurückgewinnen, die ihnen durch die alte Version der Software entzogen worden sind. Bei der Weiterentwicklung von Standardsoftware stellen sich zusätzliche Fragen: für die Softwareherstellerin zum Beispiel die, wie mit den Anforderungen verschiedener Kund*innen umzugehen ist, für die Kund*innen, ob und wie sie versuchen, Veränderungen in der Software, die nicht von ihnen selbst angestoßen wurden, in die eigenen Praktiken einzubinden.

Bei der Betrachtung der Performativität von Software bei der Weiterentwicklung zeigt sich, dass sich die Komplexität von Software durch die Weiterentwicklung potenziert, weil immer neue Prozesse der Unsicherheitsreduktion stattfinden, die auf den Ergebnissen vergangener Prozesse aufbauen. Unsicherheit wird damit in einem immer dichteren Geflecht sozialer Prozesse weitergereicht, wodurch undurchschaubare Abhängigkeiten zwischen diesen Prozessen entstehen.

2.1.3.2 Wiederverwendung vorgefertigter „Softwarebausteine“

Den gleichen Effekt erzeugt die Wiederverwendung von Softwarebausteinen. Wiederverwendete Softwarebausteine bilden den Hauptteil moderner Software: „The modern developer no longer builds applications from scratch. Instead, most developers essentially glue different libraries together to perform a task.“ (Wurster und van Oorschot 2008, S. 89). Aus Sicht vieler Informatiker*innen ähnelt die Konstruktion von Software der Konstruktion eines Wolkenkratzers, bei der Gruppen von Spezialist*innen vorgefertigte Bauteile unterschiedlicher Komplexität mit speziell für diesen Bau angefertigten Einzelteilen zu einem neuen Ganzen zusammenfügen.³⁹ Bei der Softwareentwicklung wird dazu das Modell des sozialen Phänomens spätestens ab der Entwurfsphase in Teilmodelle zerlegt, die theoretisch unabhängig voneinander in Code überführt werden können. Zwischen den Teilmodellen werden Schnittstellen definiert, die sicherstellen sollen, dass sich die Einzelteile später wieder zu einem Gesamtmodell verbinden lassen. Auf diese Weise entstehen Modellierungsaufgaben, die denen in anderen Softwareprojekten auf einer bestimmten Abstraktionsebene gleichen. Statt solche Aufgaben immer wieder neu zu lösen, können die entsprechenden Modelle aus einem anderen Projekt übernommen werden, wodurch Teile des eigenen Entwicklungsprozesses entfallen. Dadurch sinken Kosten, Risiken und Dauer von Softwareentwicklungsprojekten, es entstehen aber auch zahlreiche Probleme, die gegen die Vorteile abgewogen werden müssen (Sommerville 2012). Bei dieser Abwägung spielen die Auswirkungen, die Wiederverwendungen auf die Weiterentwicklung haben, eine zentrale Rolle: Die wiederverwendeten Elemente werden unabhängig von der eigenen Software weiterentwickelt. Neue Versionen der Elemente müssen in die Software aufgenommen werden, wenn sichergestellt sein soll, dass Fehlerkorrekturen, Lösungen für neu entdeckte Sicherheitsprobleme und ähnliches übernommen werden. Aus der Weiterentwicklung der Elemente entstehen damit Anforderungen für die Weiterentwicklung der eigenen Software.⁴⁰

Soziologisch betrachtet wird bei der Wiederverwendung ein Teil der Entscheidungen über die Eigenschaften der Modelle, auf denen die eigene Software aufbaut, durch eine Entscheidung ersetzt, nämlich durch die für das zu nutzende wiederverwendete Element. Damit wird auch die Kontrolle über die Unsicherheiten, die diese Entscheidungen darstellt, von einem Softwareentwicklungsprozess in einen anderen verschoben. Oft kennen die Akteur*innen des ersten Prozesses diesen anderen nicht, zumindest nicht im Detail. In der Regel können sie keinen Einfluss auf die Aushandlungen ausüben, in welchen festgelegt wird, wie die Unsicherheit des Sozialen bei der Modellierung reduziert werden soll. Die Entwickler*innen, die fertige Bausteine in ihren eigenen Projekten einsetzen, geben damit nicht nur Kontrolle über die Inhalte des aktuellen Modells ab, sondern (zum Teil) auch über die Prozesse der Weiterentwicklung. Damit schaffen sie mit der Wiederverwendung Unsicherheiten für die Zukunft, die zukünftige Entwickler*innen nicht kontrollieren können.

Auch die Produktion wiederverwendbarer Elemente wird im Software Engineering als eigenes Problem behandelt. Solche „Software-Bausteine“ sollen zwar stabil sein (Ludewig und Lichter 2013), müssen aber auch weiterentwickelt werden. Sind die Nutzer*innen der wiederverwendeten Elemente nicht bekannt, stellen „Ripple effects“ (Yau et al. 1978) Produzent*innen vor Probleme (Robbes et al. 2012). Mit diesem Begriff werden die Auswirkungen bezeichnet, die Veränderungen eines Softwareelements auf andere Elemente haben, die sich in einem gemeinsamen Modell befinden. Soziologisch stellt sich in solchen Fällen die Frage, inwieweit die Produzent*innen der wiederverwendeten Elemente reflektieren, welche Unsicherheiten sie der Kontrolle der Nutzer*innen entziehen, und inwieweit die Reduktionen, bei der Entwicklung der wiederverwendbaren Komponenten vorgenommen worden sind, bei der Nutzung nachvollzogen werden können.

Die grundlegendsten Elemente, die bei der Softwareentwicklung wiederverwendet werden, sind die höheren Programmiersprachen mit ihren Bibliotheken, also Sammlungen von kurzen oder längeren Codebausteinen, die häufig genutzte allgemeine Funktionen erbringen. Elemente von Bibliotheken ermöglichen zum Beispiel die grafische Darstellung von statistischen Daten in Form eines Kreisdiagramms oder eine Eingabeaufforderung in einem Bildschirmfenster. Auch werden sie in aller Regel genutzt, um Daten und Anweisungen mit Ein- und Ausgabegeräten (wie Tastaturen und Bildschirme) oder Datenbanken auszutauschen. Software-Bausteine, die spezifische, aber allgemein anwendbare Funktionen erfüllen, sind in der Regel in so genannten Programmbibliotheken zusammengefasst, die von Softwareentwickler*innen wie Baukästen genutzt werden (Claus und Schwill 2003, S. 603).⁴¹

Auch technische Standards gehören, soziologisch betrachtet, zu den Bausteinen, die bei der Softwareentwicklung wiederverwendet werden. Zwar sind solche Standards selbst keine Software, aber auch in ihnen werden bestimmte Aspekte eines sozialen Phänomens ausgewählt und festgelegt, wie diese ausgeprägt sein müssen, damit ein bestimmter Zweck erreicht werden kann. Wenn zum Beispiel in einem Standard zur IT-Sicherheit vorgegeben wird, dass Emails mit bestimmten Verfahren verschlüsselt werden müssen, ist dadurch festgelegt, dass der Inhalt der Email ein für die Sicherheit der Kommunikation relevanter Aspekt ist, und nicht etwa Eigenschaften des Computers, von dem die Email geschrieben wird. Standards wie dieser sind abstrakte Modelle eines sozialen Phänomens (z. B. der IT-Sicherheit), die in die Modelle der Softwareentwicklung übernommen werden. Sie reduzieren einige Aspekte der Unsicherheit des Sozialen radikal und beeinflussen dadurch erheblich, wie die Akteur*innen das Phänomen im Softwareentwicklungsprozess modellieren können. Am Beispiel: Durch den Standard müssen Entwickler*innen nicht aushandeln, was genau unter IT-Sicherheit zu verstehen ist, sondern nur, mit welchem der festgelegten Verfahren die Emails von ihrer Software verschlüsselt werden sollen.

Programmiersprachen und technische Standards sind bei der soziologischen Betrachtung der Wiederverwendung Extremfälle: Programmiersprachen tragen sehr wenig zur Reduktion von Unsicherheit des Sozialen bei, weil sie vor allem Modelle für wohldefinierte mathematische Phänomene enthalten, kaum für soziale Phänomene.⁴² Die Aufgabe von technischen Standards ist es hingegen, möglichst viele unterschiedliche soziale Phänomene gleichzeitig zu erfassen. Wenn sie erfolgreich sind, verbreiten sie sich weit und können so die Aushandlungen in vielen Folgeprozessen beeinflussen. Die sozialen Prozesse, die zur Entwicklung von Standards führen, sind damit oft komplex und bringen viele Akteur*innen mit sehr unterschiedlichen und oft widersprüchlichen Interessen zusammen. Die Untersuchung von Standardisierungsprozessen ist daher für eine Soziologie der Software ebenso bedeutsam wie die Frage, wie Akteur*innen bei der Softwareentwicklung mit Standards umgehen.

Neben Programmiersprachen, die wenige, und technischen Standards, die viele soziale Phänomene modellieren, existieren verschiedene Arten von Elementen, die in Software wiederverwendet werden. Das in der modernen Softwareentwicklung weit verbreitete Paradigma der Objektorientierung zum Beispiel basiert darauf, dass Programme aus wiederverwendbaren Elementen zusammengebaut werden. Diese sogenannten Objekte fassen Daten und Anweisungen zu deren Bearbeitung zusammen. Bestimmte Eigenschaften und Funktionen dieser Objekte sind bekannt, die genaue Konstruktionsweise bleibt aber allen außer den Konstruierenden verborgen. Diese Kombination von sichtbaren Funktionen und verborgener Funktionsweise, das sogenannte Kapseln von Funktionalität, soll die Wiederverwendung vereinfachen (Herold et al. 2011).⁴³ Wiederverwendet werden aber nicht nur einfache Objekte oder Bausteine mit wohldefinierten Funktionen wie die grafische Darstellung statistischer Daten. Auch strukturierte Kombinationen solcher Bausteine mit eigener Funktionslogik für einen Anwendungsbereich, je nach Ausprägung Frameworks oder Referenzarchitekturen genannt (Ludewig und Lichter 2013), und komplexe Komponenten, die eigenständig spezialisierte Aufgaben (wie Terminplanung, Verwaltung von Kundendaten) erfüllen können, werden bei der Entwicklung neuer Software genutzt (a.a.O., S. 604 ff.).

Da Wiederverwendung ein Grundprinzip aller Softwareentwicklungsprozesse ist, stellen die Aushandlungen rund um diesen Aspekt gute Ansatzpunkte für die soziologische Untersuchung der Software im Sozialen dar. Die hier dargelegten Fragen können dabei helfen zu rekonstruieren, welche Aspekte der Unsicherheit aus dem Nutzungskontext in welchen sozialen Prozessen wie reduziert worden sind, unabhängig davon, ob dies bei der Entwicklung der genutzten Software direkt oder bei der Entwicklung eines ihrer Elemente geschehen ist. Auf der anderen Seite wird durch diese Fragen auch ein Licht auf die Aushandlungen im Softwareentwicklungsprozess geworfen, die durch die Wiederverwendung angestoßen werden: Vor allem bei der Wiederverwendung komplexerer Elemente orientiert sich bereits der Entwurf an deren Eigenschaften; auch die Anforderungen werden zumindest zum Teil daran angepasst (Sommerville 2012). Was für welche Zwecke neu programmiert und was wozu wiederverwendet wird, ist damit von Beginn an ein relevanter Faktor in den sozialen Prozessen, in denen Zweck, Kosten und Bedingungen der Softwareentwicklung festgelegt werden. In diesen Aushandlungen geht es nicht nur um die „offiziellen“ Rahmenbedingungen der Softwareentwicklung, sondern auch darum, welche Handlungsmöglichkeiten sich die Akteur*innen jeweils erhalten wollen und welche Formen von Kontrolle sie dafür bereit sind aufzugeben.

Besonders bedeutsam ist die soziologische Auseinandersetzung mit den Folgen der Wiederverwendung bei der Untersuchung agiler Softwareprojekte. Deren Anspruch ist es, durch dauerhaft enge Zusammenarbeit von Nutzer*innen, Entwickler*innen und anderen Stakeholder*innen und permanente Weiterentwicklung Software zu produzieren, deren Funktionen den Bedürfnissen der Nutzer*innen besonders gut gerecht werden. In der hier entwickelten Perspektive versuchen die Softwareentwickler*innen bei agilen Ansätzen, Nutzer*innen möglichst an den Aushandlungen über die für das soziale Phänomen bedeutsamen Aspekte der Unsicherheit und deren Modellierung zu beteiligen. Besteht ein relevanter Teil der Software aus wiederverwendeten Elementen, wie dies zunehmend der Fall ist, lässt sich dieser Anspruch nicht mehr erfüllen.

Ein ähnlicher Effekt entsteht bei standardisierter Organisationssoftware: Bei langlebigen Produkten dieser Art erzeugen Weiterentwicklung und Wiederverwendung eine charakteristische interne Struktur, die ich in dieser Arbeit als Struktur konzeptioneller Schichten bezeichne. Diese Struktur, schematisch dargestellt in Abbildung 2.5, wird im Folgenden genauer beschrieben.

Abbildung 2.5

Konzeptionelle Schichten standardisierter Organisationssoftware. (Eigene Darstellung)

2.1.3.3 Konzeptionelle Schichten standardisierter Organisationssoftware

Standardisierte Organisationssoftware existiert häufig in verschiedenen Varianten, die für bestimmte Branchen oder Wirtschaftsbereiche entwickelt wurden. Diese Varianten unterstützen zusätzlich zu „allgemein typischen“ Arbeitsabläufen (z. B. Rechnungsstellung) auch „speziell typische“ (z. B. Prüfungsverwaltung im Bildungsbereich). Sie bestehen aus einer Reihe an allgemeinen Modulen, die allgemein typische Prozesse modellieren, und einer Reihe an branchentypischen Modulen, die wiederum in die allgemeinen integriert sind (Davenport 1998). Bei der Entwicklung und Weiterentwicklung branchenspezifischer Varianten der Software werden nur die Aspekte bearbeitet, die die branchenspezifischen Phänomene betreffen. Phänomene, die die Softwareherstellerin als allgemeine Organisationsphänomene einstuft, werden in den Entwicklungsprozessen der allgemeinen Module modelliert. Im Ergebnis kann die Struktur der Modelle in standardisierter Organisationssoftware als geschichtet betrachtet werden: Module, die allgemeinere Phänomene modellieren, bilden das Fundament, auf dem die Module aufbauen, die speziellere Phänomene modellieren. In den Entwicklungsprozessen werden Aspekte bearbeitet, die auf der eigenen und darüber liegenden (also spezielleren) Schichten verortet werden, nicht jedoch solche, die auf niedrigeren (also allgemeineren) Schichten liegen.

Für populäre Produkte wie das in dieser Arbeit untersuchte von SAP gibt es darüber hinaus spezielle Erweiterungen. Diese werden von anderen Herstellerinnen entwickelt und bieten weitere Funktionen an. Die Abhängigkeiten zwischen den Entwicklungsprozessen der Erweiterungen und denen des Standardprodukts entsprechen denen zwischen spezielleren und allgemeineren Schichten.

Standardisierte Organisationssoftware bildet eine informationstechnische Infrastruktur für die Organisationen, die sie einsetzen, da sie einen großen Teil der Prozesse in der Organisation modelliert. Soll sie in der Organisation ihren offensichtlichen Zweck (die weitgehende informationstechnische Integration der Arbeitsabläufe) erfüllen, muss der Rest der Software auf diese Infrastruktur abgestimmt werden. Die Einführung von standardisierter Organisationssoftware wirkt damit performativ auf den Umgang mit (beinahe) jeglicher Software in der Organisation, da die Akteur*innen dadurch gezwungen werden, ihre Arbeitsabläufe mit den Modellen organisatorischer Prozesse in Einklang zu bringen, die das Standardprodukt vorgegeben hat.

Auch bei standardisierter Organisationssoftware können einmal erfolgte Reduktionen in späteren Phasen hinterfragt und die geschlossenen Aspekte der Unsicherheit damit wieder aufgegriffen werden. Bei der Entwicklung branchentypischer Varianten können zum Beispiel Vorschläge für Veränderungen an den Modellen der allgemeinen Module auftauchen. Die Entscheidung darüber, ob und wie solche Vorschläge aufgegriffen werden, verbleibt jedoch in aller Regel in den sozialen Prozessen, in denen die allgemeinere Schicht weiterentwickelt wird. Darüber hinaus ist gerade für die Akteur*innen in Customizing und Nutzung nur schwer nachvollziehbar, auf welcher Schicht die Aspekte der Unsicherheit modelliert (und damit in eindeutige Lösungen übersetzt) worden sind, die in ihren eigenen Prozessen zum Thema werden. Ihre Möglichkeiten, Einfluss auf die Software auszuüben, sind auch durch diese Undurchschaubarkeit eingeschränkt.

2.1.4 Fazit: Soziale Komplexität von Software

In Abschnitt 2.1.1 habe ich dargestellt, dass Programmiersprachen als eine Reihe von Modellen betrachtet werden können, die durch mathematische Transformationen ineinander überführt werden und deren Vorlage der Befehlssatz des Prozessors ist. Dieser Befehlssatz stellt Informatiker*innen ein Modell des Prozessors zur Verfügung, in dem die Unsicherheiten, die die physischen Elemente des Computers mit sich bringen, ausgeblendet werden, so dass deren Funktionen durch Reihen binär codierter Anweisungen dargestellt werden können. Der Code der Software muss dadurch immer eine vollständige und logisch konsistente Beschreibung ihrer Funktionen enthalten. Die Konstruktion von Software wird damit zu einer komplexen Modellierungsaufgabe für Menschen, da ihnen vollständige und logisch konsistente Beschreibungen der meisten Tatbestände schwerfallen. In Abschnitt 2.1.2 habe ich dargestellt, dass Softwareentwicklung als eine Reihe von Modellierungsprozessen betrachtet werden kann, die aufeinander aufbauen. Jeder dieser Prozesse reduziert einige Aspekte der Unsicherheit des Sozialen und ist dabei durch die Reduktionen vorangehender Prozesse vorstrukturiert. Jeder Prozess besitzt als sozialer aber auch eigene Unsicherheiten und sorgt dafür, dass diese die darauffolgenden Prozesse mit strukturieren. Im Modellierungsprozess von Software wird damit die Komplexität des Modells gesteigert, weil die Akteur*innen versuchen, die Komplexität des Phänomens zu reduzieren. Das Ergebnis der Softwareentwicklung ist ein performatives Artefakt, weil die Modelle die Prozesse der Nutzung vorstrukturieren. In Abschnitt 2.1.3 wurde gezeigt, wie Software auch in den Prozessen der Softwareentwicklung performativ wird. Bei der Weiterentwicklung müssen sich Akteur*innen an dem Modell früherer Versionen orientieren, wenn sie den größten Teil der dadurch ausgelösten Funktionen für neue Versionen erhalten wollen. Ihr Verständnis der Modelle wird dabei mit zunehmendem zeitlichen und sozialen Abstand zwischen den Entwicklungsprozessen erschwert, was ihre Handlungsmöglichkeiten zusätzlich einschränkt. Der Umgang mit früheren Versionen der Software lässt neue Anforderungen entstehen, so dass nicht nur die Software an sich, sondern auch die sozialen Prozesse, in die sie innerhalb der sozio-technischen Systeme eingebunden ist, Rückwirkungen auf die Weiterentwicklung haben. Eine andere Form von Unsicherheitsreduktion stellt die Nutzung wiederverwendbarer Softwareelemente dar. Mit diesen tauschen die Akteur*innen in Softwareentwicklungsprozessen eigene Kontrolle über den Modellierungsprozess gegen erprobte Modelle ein, die sie in das eigene Modell integrieren müssen. Dadurch verknüpfen sie ihre eigenen Entwicklungsprozesse mit denen, in denen die wiederverwendeten Modelle weiterentwickelt werden, und erzeugen so Unsicherheit für die Zukunft ihres eigenen Produkts.

Bis hierhin habe ich die Modellierungsprozesse dargestellt, die für die Softwareentwicklung und den Umgang mit Software charakteristisch sind, und auf die soziologischen Fragen hingewiesen, die in diesen Prozessen aufgeworfen werden. Im folgenden Abschnitt wird nun gezeigt, wie diese Fragen bisher in der soziologischen Forschung zu Software aufgegriffen worden sind.

2.2 Soziologische Forschung zu Software

Zwar wird die Komplexität von Software selten zum zentralen Gegenstand soziologischer Forschung gemacht, aber es gibt eine Reihe von soziologischen Arbeiten, in denen Fragen wie die, die im vorangegangenen Kapitel dargestellt wurden, aufgegriffen werden. Software kann dabei immer nur insofern von soziologischem Interesse sein, als in irgendeiner Form in sozialen Prozessen auf sie Bezug genommen wird, insofern sie also entwickelt oder genutzt oder ihre Entwicklung oder Nutzung in irgendeiner Form thematisiert wird. Letzteres gilt zum Beispiel auch für Prozesse, in denen Regulierung, Anschaffung, Bedingungen oder Konsequenzen von Softwareentwicklung oder -nutzung ausgehandelt werden, in denen die Software selbst also gar nicht zum Einsatz kommt. Durch all diese Formen der Bezugnahme entsteht eine Verbindung zwischen Software und sozialen Praktiken, wiederkehrenden, überindividuell geteilten, regelgeleiteten und situativ adaptierbaren Handlungsweisen (Reckwitz 2003).⁴⁴ In soziologischen Arbeiten zum Umgang mit Software werden häufig solche Praktiken untersucht, oder die Praxis, also das, was Akteur*innen tatsächlich tun, wenn sie sich in ihrem Handeln mit den konkreten Bedingungen der Welt um sie herum auseinandersetzen müssen.⁴⁵ Wenn die Software von Soziolog*innen als relevantes Element von Praktiken oder Praxis berücksichtigt wird, greifen diese häufig auf Erkenntnisse der Techniksoziologie zurück.

Techniksoziolog*innen haben sich verhältnismäßig wenig mit der Frage befasst, was das Besondere an der Software sein könnte, sondern allgemein untersucht, wie Technik und Gesellschaft zusammenspielen. Im Gegensatz zum rationalistisch dominierten Diskurs in der Informatik (vgl. Floyd 1989) wird in der Techniksoziologie einerseits davon ausgegangen, dass die Perspektiven, mit denen Technikentwickler*innen auf die Welt blicken, und die Bedingungen, unter denen sie arbeiten, das Ergebnis ihrer Arbeit bestimmen (Winner 1980; Pinch und Bijker 1987; Bijker et al. 1987). Da dieses Ergebnis in sozialen Prozessen eingesetzt wird, gestaltet Technikentwicklung (und die sie kennzeichnenden Perspektiven und Bedingungen) immer auch das Soziale:

„In der technischen Praxis werden nicht nur Probleme technisch effektiv und scheinbar politisch neutral gelöst, sondern neue Problemsichten und neue Praktiken gegenüber alten und eingelebten durchgesetzt. Praktiken der Technikproduktion sind daher so politisch wie andere Praktiken, da sie immer Partei nehmen, zumindest gegen die vorherige Praxis, und da sie immer neue Rahmen und Regeln für die Praxis setzen.“ (Rammert et al. 1998, S. 34)

Technikentwicklung muss damit sowohl der Form als auch ihren Ergebnissen nach als politisch betrachtet werden: Ersteres, weil die Entwickelnden mit der Entscheidung für eine Art und Weise, Technik zu gestalten, „Partei“ in einer Auseinandersetzung ergreifen, in der es nicht eine objektiv beste, sondern verschiedene gleichermaßen mögliche Lösungen gibt. Letzteres, weil zusammen mit der Technik auch Bedingungen des Zusammenlebens gestaltet werden.

Zur soziologischen Perspektive auf Technik gehört andererseits auch die Erkenntnis, dass die Gestaltbarkeit des Sozialen durch Technik begrenzt ist. Technik kann soziale Prozesse nur nachhaltig beeinflussen, wenn sie in diesen längerfristig genutzt wird, wodurch sich in irgendeiner Form geregelte Umgangsformen ausbilden. Wie diese geregelten Umgangsformen aussehen ist davon abhängig, wie Nutzer*innen die Technik interpretieren und wie sie diese konkret in ihren Alltag einbauen (Rammert 2006).

Das Wechselverhältnis zwischen diesen beiden Aspekten wird als Schlüssel zum Verständnis der Rolle von Technik im Sozialen betrachtet (Schulz-Schaeffer 1999). Schulz-Schaeffer bezeichnet dieses in Anlehnung an Giddens’ Strukturationstheorie als Dualität von Ressourcen und Routinen. Technik⁴⁶ ist insofern Ressource des Handelns, als Akteur*innen sie in ihren Handlungsabläufen nutzen, um einen Zusammenhang zwischen Ereignissen herzustellen, der durch Regeln formuliert wird, die der Technik zu Grunde liegen: „Ein Akteur tut A, um B zu erreichen, indem er sich auf einen Ereigniszusammenhang verlässt (seine Ressource), der seiner begründeten Erwartung nach bewirkt, dass die Handlung A mit einiger Zuverlässigkeit die Folge B zeitigt“ (Schulz-Schaeffer 1999, S. 414). Ereigniszusammenhänge im Sozialen entstehen aber durch die Praxis und sind damit immer kontingent. Sie basieren auf Regeln des Sozialen, die ebenso interpretationsoffen sind wie die Praxis, die sie regulieren. Die ausformulierten Regeln für den Ereigniszusammenhang, die der Technik zugrunde liegen, können immer nur eine der vielen möglichen Interpretation dieser sozialen Regeln festhalten (Giddens 2008 [1984]). Diese Regeln und die auf ihnen beruhende Technik können daher die Ereigniszusammenhänge, die Akteur*innen beim Einsatz der Technik erwarten, nicht allein erzeugen. Dies gelingt nur (mit relativer Wahrscheinlichkeit), wenn zusätzlich Praktiken existieren, die die Interpretationen der Akteur*innen, die am Entstehen dieser Ereigniszusammenhänge beteiligt sind, mit den Interpretationen in Einklang bringen, die den formulierten Regeln der Technik zu Grunde liegen.

„Es ist […] nur deshalb möglich, einen Ausschnitt des gesellschaftlichen Lebens explizit zu reglementieren, weil zugleich eine Vielzahl von Handlungspraktiken, die in der einen oder anderen Weise mit dem reglementierten Ausschnitt zusammenhängen, als selbstverständlich vorausgesetzt werden können.“ (Schulz-Schaeffer 1999, S. 415)

Um komplexe Techniken nutzen zu können, müssen Akteur*innen nur einen kleinen Teil der Regeln kennen, auf denen die Technik beruht, nämlich nur den Teil, der sich direkt auf ihr Handeln und das Ergebnis bezieht, das sie erwarten können. Der Rest der Regeln muss nur einer Gruppe von Expert*innen bekannt sein. Er wird in von der Nutzungspraxis getrennten gesellschaftlichen Kontexten, zum Beispiel in wissenschaftlichen Disziplinen oder professionellen Gemeinschaften von Ingenieur*innen, bearbeitet. Für Außenstehende, also Akteur*innen, die sich nicht an der Bearbeitung dieser Regeln beteiligen, werden in diesen Kontexten Systeme aufeinander bezogenen Wissensbestände, Expert*innensysteme, produziert, die regelhafte Ereigniszusammenhänge ermöglichen. Alle komplexen Techniken können als Expert*innensysteme betrachtet werden. Die Entwicklung komplexer Techniken findet in sozialen Kontexten statt, in denen Expert*innen interagieren, muss aber auf die Nutzungspraxis außerhalb dieser Kontexte bezogen werden, um sicherzustellen, dass formulierte Regeln und sie stützende Handlungspraktiken ineinandergreifen. Die Praktiken von Expert*innen und Lai*innen zum Umgang mit der Technik beschränken und ermöglichen einander damit wechselseitig (a.a.O., S. 419).

Der folgende Literaturüberblick konzentriert sich auf Arbeiten aus der Soziologie und verwandter Disziplinen, die Software nicht allein als Beispiel für allgemein techniksoziologische Fragen behandeln, sondern ihre Besonderheiten im Vergleich zu anderen Formen von Technik thematisieren. Wie sich zeigen wird, teilen die meisten Arbeiten in diesem Feld prinzipiell die Grundidee der Dualität, also die Annahme, dass die in die Technik eingebetteten Regeln und die Praktiken des Umgangs mit dieser Technik wechselseitig aufeinander bezogen sind und einander sowohl beschränken als auch ermöglichen. Die wenigstens ziehen daraus jedoch Konsequenzen. In der Zusammenfassung dieses Kapitels werde ich daher auf die Idee der Dualität zurückkommen und herausstellen, welche Gemeinsamkeiten die verschiedenen Arbeiten aufweisen und wo einzelne Arbeiten einander ergänzen. Das Konzept der Expert*innensysteme wird in Abschnitt 3.1.1 weiter ausgeführt. Zunächst wird aber dargestellt, auf welche Weise Soziolog*innen die Fragen aufgegriffen haben, die die drei Dimensionen der Komplexität von Software aufwerfen. Die Darstellung der soziologischen Arbeiten, in denen dieses Fragen thematisiert werden, folgt der gleichen Struktur wie die Darstellung der drei Dimensionen selbst: Als erstes stelle ich Arbeiten vor, in denen Soziolog*innen sich mit der Übersetzung von sozialen Phänomenen in mathematische Formalismen bei der Softwareentwicklung auseinandergesetzt haben. Im Anschluss folgen Arbeiten zu soziologischen Aspekten des Softwarelebenszyklus. Die soziologische Forschung zu Weiterentwicklung und Wiederverwendung wird zuletzt vorgestellt. Der Überblick über die soziologische Forschung zu Software dient als Grundlage für die Herleitung der in dieser Arbeit forschungsleitenden soziologischen Perspektive auf Software, die ich in 2.3 ausführen werde, und der Einordnung des Forschungsrahmens, der in Kapitel 3 entwickelt wird.

2.2.1 Arbeiten zur Übersetzungsdimension

Bei der Softwareentwicklung werden Phänomene aus der sozialen Welt ausgewählt, interpretiert und in mathematische Formalismen übersetzt. In den Modellen, die im Laufe dieser Übersetzung entstehen, sind die Unsicherheiten, die die Auswahl und Interpretation sozialer Phänomene mit sich bringt, nicht mehr sichtbar. Beim Umgang mit der Software repräsentieren diese Modelle die in ihnen abgebildeten Phänomene. Die vielen Entscheidungen, die im Laufe der Modellierungsprozesse getroffen werden müssen, um eine funktionsfähige Software zu entwickeln, sind durch das Endziel der Modellierung vorstrukturiert, also dadurch, dass Mikroprozessoren nur eindeutige, vollständige und widerspruchsfreie mathematische Formalismen verarbeiten können. Zentrale soziologische Fragen, die durch dieses grundlegende Funktionsprinzip von Computern aufgeworfen werden, sind in den Arbeiten von Werner Rammert, Michael Schlese, Gerald Wagner, Josef Wehner und Rüdiger Weingarten (Rammert et al. 1998), von Christiane Funken (2001) und von Jannis Kallinikos (2009) behandelt.

2.2.1.1 Wissensproduktion durch Kombination von Repräsentationsebenen

Aus mehreren empirischen Studien zur Softwareentwicklung setzt sich das Buch von Rammert et al. (1998) zusammen. Dieses ist eine der wenigen soziologischen Arbeiten, in der die grundlegende Funktionsweise von Mikroprozessoren aus einer soziologischen Perspektive, der zu Folge das Soziale grundlegend unsicher ist, systematisch diskutiert wird. Ergebnis dieser Diskussion ist das Konzept des Computers als Wissensmaschine: als Artefakt, das Eigenschaften von Maschine und Medium verbindet. Durch seine besondere technische Struktur ist ein Computer eine Maschine, die zweckgebunden Funktionen auf vorhersehbare Weise erfüllt. Gleichzeitig ist ein Computer aber auch ein Medium, dessen Eigenheiten beeinflussen, wie Wissen im Umgang mit ihm abgebildet, transformiert und neu geschaffen wird (a.a.O., S. 10 f.). Die besondere technische Struktur des Computers, auf der dieser Doppelcharakter beruht, beschreiben Rammert et al. als System aufeinander aufbauender Repräsentationsebenen. Auf jeder Repräsentationsebene werden Zeichen entsprechend jeweils eigener Gesetze transformiert, zum Beispiel wenn Anweisungen in einer höheren Programmiersprache durch automatische Übersetzung in Anweisungen in der Maschinensprache übersetzt werden. Den in Abschnitt 2.1.1 als Basis der Funktionen von Software dargestellten Schichten Hardware, Maschinensprache, und höhere Programmiersprachen entsprechen die Ebenen der physikalischen, logischen und abstrakten Maschine. Sie sind durch deterministische Übersetzungsregeln verbunden und ermöglichen gemeinsam das zweckgebundene und (relativ) vorhersehbare Funktionieren der Computer (a.a.O., S. 19). Bei der Softwareentwicklung entstehen komplexe „Repräsentationsschemata für ‚Fakten‘“ (a.a.O. S. 20) als oberste Ebene, durch die Wissen aus den sozialen Prozessen, in denen der Computer zum Einsatz kommt, in die von der Maschine bearbeitbaren Zeichen übersetzt wird. Über diese Ebenen verbindet der Computer „die Determiniertheit von Kausalbeziehungen mit der Offenheit⁴⁷ von Repräsentationsbeziehungen“ (a.a.O., S. 19). Der Computer bringt also die durch eindeutige Regeln gesteuerten Zeichenmanipulationen der mathematischen Formalismen, auf denen die Maschine basiert, mit den hochgradig unsicherheitsbehafteten sozialen Prozessen der Wissensproduktion zusammen.

Rammert et al. entwickeln ihr Modell anhand mehrerer Studien zur Entstehung und Verbreitung von Expert*innensystemen.⁴⁸ Sie zeigen: Was beim Umgang mit diesen Systemen als Wissen gilt, hängt sowohl davon ab, welche Probleme in den sozialen Prozessen bearbeitet werden, in denen mit den Repräsentationsschemata umgegangen wird, als auch davon, welche Weltanschauungen, professionellen Orientierungen, Einflussmöglichkeiten und andere „soziostrukturelle[n] Merkmale“ die beteiligten Akteur*innen in die Prozesse einbringen (a.a.O., S. 47 ff.). Die Autoren untersuchen die Entwicklung der informatischen Grundlagen der Expert*innensysteme, die Entwicklung konkreter Expert*innensysteme sowie deren Nutzung als aufeinander aufbauende „Wissenswelten“ (a.a.O., S. 50). Diese Wissenswelten sind durch das dominante Problem gekennzeichnet, über dessen Lösung in jeweils charakteristischen Akteur*innenkonstellationen verhandelt wird. Rammert et al. konzentrieren sich in ihrer Untersuchung darauf, welche Folgen die Einbettung der Akteur*innen in die verschiedenen Wissenswelten für die Entwicklung der Expert*innensysteme hat. Dabei kommen sie zu dem Schluss: Während sich die Interpretationen der Akteur*innen, die informatische Grundlagen entwickeln, nach denen Wissen verarbeitet werden soll, vor allem an den Gesetzen der Maschine orientieren, haben die Akteur*innen bei der Nutzung vor allem die soziale Einbettung des Wissens vor Augen. Die Akteur*innen bei der Entwicklung sind durch ihre soziostrukturelle Verortung und die institutionellen Bedingungen der Aushandlungen den Regeln aller Repräsentationsebenen verbunden und müssen sie in ihrer Praxis miteinander vereinbaren (a.a.O., S. 78 ff.). Entwickler*innen und Nutzer*innen bewegen sich dabei in einem Handlungskorridor, der durch die Aushandlungen in den vorgelagerten Wissenswelten geformt, auf Grund der Interpretationsbedürftigkeit des Wissens aber niemals zum Zwang wird (a.a.O., S. 249 ff.).

In dem Konzept des Computers als Wissensmaschine setzen sich Rammert et al. direkt damit auseinander, wie und mit welchen sozialen Folgen Software die deterministische Verarbeitung von Daten mit den kontingenten Interpretationen sozialer Phänomene verknüpft. Damit weisen sie auf den in späteren Arbeiten häufig ignorierten Zusammenhang hin, der zwischen den technischen Grundlagen von Software und ihrer Bedeutung für das Soziale besteht. Dieser Zusammenhang ist für ein Verständnis der Komplexität von Software zentral. In dieser Hinsicht skizzieren Rammert et al. die Grenzen des Raums der sozialen Komplexität von Software, der in Abschnitt 2.1 aufgespannt wird. Konkret binden sie ihre Aussagen aber eng an die spezifischen Akteur*innenkonstellationen, Probleme und Prozesse von zum Untersuchungszeitraum hochgradig wissenschaftsnahen und experimentellen Expert*innensystemen, die sich nicht über einen engen Kreis von an der Entwicklung beteiligten Pilotkund*innen verbreitet haben (a.a.O., S. 259 ff.). Darüber hinaus blenden sie durch den Fokus auf die Wissenswelten aus, dass es bei der Entwicklung von Software auch um die Durchsetzung von (teilweise widersprüchlichen) Interessen geht und dass die Akteur*innen im Entwicklungsprozess nicht nur unterschiedliche Orientierungen, sondern auch unterschiedlich viel Macht haben, um ihre Interessen durchzusetzen. Der Bezug auf die jeweilige Rolle im Prozess und auf die hinter dieser Rolle stehende Wissenswelt kann eine solche Machtressource sein. Beispiele dafür finden sich in Christiane Funkens Buch „Die Modellierung der Welt“ (Funken 2001). Dieses enthält Untersuchungen zu den Auswirkungen der Idee der universellen Turingmaschine auf die Weltanschauungen und Praktiken von Informatiker*innen.

2.2.1.2 Hintergrundordnungen und Repräsentationspraktiken der Informatik

Funken (2001) konzentriert sich in diesen Untersuchungen auf die Anforderungsanalyse, also die erste Phase im Softwarelebenszyklus. Bei der Anforderungsanalyse sollen Softwareentwickler*innen und Repräsentant*innen zukünftiger Nutzer*innen gemeinsam ein Modell nach Vorlage eines sozialen Phänomens erstellen. Dabei werden die Probleme besonders deutlich, die der Versuch mit sich bringt, unsichere soziale Phänomene in Modelle zu übersetzen, die frei von Unsicherheit sind und damit im Prozessor verarbeitet werden können. Der Gegensatz zwischen den beiden Darstellungsformen spiegelt sich ihrer Ansicht nach im Verhältnis zwischen Softwareentwickler*innen und Nutzer*innen. Das Verhalten der Softwareentwickler*innen wird dabei durch professionelle Einstellungen zu ihrer Aufgabe und den Nutzer*innen geprägt. Diese Einstellungen bezeichnet Funken als Hintergrundordnungen der Informatik (a.a.O., S. 89–104). Diese Hintergrundordnungen sind normative Orientierungen der Berufsgruppe, die sich Softwareentwickler*innen während der Ausbildung und im beruflichen Alltag aneignen. Sie finden sich in den Strukturen der Programmiersprachen und Softwareentwicklungswerkzeugen wieder. Softwareentwickler*innen verstehen sich Funken zu Folge vor allem als Ingenieur*innen (a.a.O., S. 71), deren Aufgabe die Konstruktion eines Modells ist, das aus diskreten Einheiten besteht, die in wohldefinierten Beziehungen zu einander stehen und deren Verhalten durch allgemeine Regeln beschrieben werden kann. Soziale Faktoren, die diese Aufgabe verkomplizieren könnten, werden weitgehend ausgeblendet, Nutzer*innen werden als unberechenbare Elemente des Systems betrachtet und ihr Einfluss auf die Modellierung wird möglichst beschränkt (a.a.O., S. 72). Diese formalistische Primärorientierung steht im Widerspruch zu einer Praxis, in der die Softwareentwickler*innen ihre Arbeit als kreativen Prozess wahrnehmen und hohe intrinsische Motivation aus einem als intuitiv empfundenen Arbeiten ableiten (a.a.O., S. 84). Softwareentwicklung ist damit auch aus Sicht der untersuchten Informatiker*innen ein Prozess voller Ambivalenzen.

Funken beschreibt zwar, wie Softwareentwickler*innen sich auf ihre Expertise berufen, um gegenüber Nutzer*innen ihre Interessen durchzusetzen, geht aber ebenso wie Rammert nicht systematisch darauf ein, welche Bedeutung Macht für die Modellierungsprozesse der Softwareentwicklung hat. Die Macht der Informatiker*innen wird bei Brian Bloomfield und Theo Vurdubakis zum Thema. Nicht die handlungsleitenden Orientierungen der Softwareentwickler*innen, sondern die formalisierten Methoden und Werkzeuge der Softwareentwicklung sehen Bloomfield und Vurdibakis (1997) als zentrale Mechanismen der Übersetzung an. Diese Methoden und Werkzeuge betrachten sie als Repräsentationspraktiken, die dafür sorgen sollen, dass die Unsicherheit des Sozialen im Laufe des Softwareentwicklungsprozesses verschwindet. Ziel der Repräsentationspraktiken ist die Konstruktion eines Modells, das die Essenz des sozialen Phänomens enthält (a.a.O., S. 649 f.) – eine Essenz, die von den Auftraggeber*innen der Softwareentwicklung festgelegt worden ist. Unterschiedliche Interpretationen des Phänomens werden im Entwicklungsprozess dabei nur symbolisch berücksichtigt: „[T]hough subjectivity is accorded an important place at the start of the analysis it must eventually be ‘supplemented’ by objectivity.“ (Bloomfield und Vurdubakis 1997, S. 662). Die Behauptung der „Objektivität“ verschleiert dabei, dass Repräsentationspraktiken dabei helfen sollen, das repräsentierte Phänomen entsprechend den Zwecken der Auftraggeber*innen umzugestalten. Die Repräsentation bildet nach Ansicht der Autoren das Phänomen nicht ab, sondern konstruiert eine idealisierte Version davon, die bei der Nutzung als Maßstab dient, an dem das tatsächliche Phänomen gemessen wird (a.a.O., S. 664).

2.2.1.3 Rekonstitution der Realität durch den Filter der Berechnung

Auch Jannis Kallinikos betrachtet die behauptete Objektivität der Repräsentationen, die bei der Softwareentwicklung entstehen, als das zentrale soziologische Problem der Übersetzung sozialer Phänomene in Software. Anders als die Autor*innen der anderen Arbeiten stellt er jedoch die Auswirkungen dieser angeblichen Objektivität in den Mittelpunkt (Kallinikos 2005, 2009). Er befasst sich also mit dem Ergebnis der Modellierung und dem Umgang mit Modellen, nicht mit dem Modellierungsprozess oder seinen Akteur*innen. Die Besonderheit von Software liegt Kallinikos Ansicht nach darin, wie Informationen über die Welt in Daten übersetzt und wie von der Software produzierte Daten von Nutzer*innen interpretiert werden. Die Modelle, die im Softwareentwicklungsprozess konstruiert worden sind, erlauben es, soziale Phänomene digital zu repräsentieren. Bei der digitalen Repräsentation werden analoge Objekte, Subjekte und Prozesse, also Elemente der Welt, die Menschen als Einheiten betrachten, automatisch mit Hilfe von Modellen in mathematische Formalismen übersetzt und damit über mehrere Modellebenen hinweg bis auf eine Binärdarstellung dekonstruiert. Diese Binärdarstellungen, die digitalen Objekte, ersetzen für diejenigen, die die Software nutzen, ihre analogen Vorlagen, also zum Beispiel andere Menschen mit ihren Eigenschaften und Beziehungen, physische Gegenstände oder soziale Prozesse. Software sorgt einerseits für die verlässliche Dekonstruktion, die eine Bearbeitung der digitalen Objekte für den Prozessor erst möglich macht, stellt andererseits gleichzeitig sicher, dass die digitalen Objekte für die Benutzer*innen immer noch als Einheit erscheinen. Wie jede Funktion von Software, die für Menschen wahrnehmbar ist, beruhen Dekonstruktion, Verarbeitung und Darstellung digitaler Objekte auf einem komplexen Geflecht automatisierter Funktionen, welches sich in seiner Gesamtheit dem menschlichen Verständnis entzieht (Kallinikos 2009).⁴⁹ In dieser beinahe vollständigen, nicht nachvollziehbaren Dekonstruktion sieht Kallinikos den Ursprung zweier grundlegender Unterschiede zwischen digitalen Objekten und den durch sie repräsentierten Elementen der Welt, die Auswirkungen auf die sozialen Prozesse haben, in denen Software genutzt wird:

• (1) Alle Eigenschaften der analogen Objekte, die durch die Software verarbeitet oder dargestellt werden sollen, müssen bei ihrer Dekonstruktion im digitalen Objekt nachgebildet werden. Wird zum Beispiel bei der digitalen Modellierung von Patient*innen nicht zu irgendeinem Zeitpunkt gezielt entschieden, dass Ernährungsgewohnheiten eine relevante Eigenschaft sind, so gibt es später keine Möglichkeit, an Hand der digitalen Objekte etwas über ernährungsbedingte Krankheiten herauszufinden. Die digitalen Patient*innen unterscheiden sich in ihren Ernährungsgewohnheiten nicht, denn sie besitzen einfach keine. Weil alle Eigenschaften digitaler Objekte von der Software nachgebildet werden, können sie auch beliebig verändert werden. Digitale Patient*innen können von jemandem, der die Software zu bedienen weiß, mit ein paar Tastendrücken verjüngt und geheilt werden, ihr Geschlecht, ihre Größe oder ihre Behandlungshistorie kann sich verändern, ohne dass die repräsentierte Patient*in davon etwas mitbekommt. Digitale Objekte sind vollständig über Software kontrollierbar; Software kann auch ohne Vorlage neue digitale Objekte produzieren, die nicht von Repräsentationen analoger Objekte unterscheidbar sind.

Während der Umgang mit analogen Objekten vor allem davon abhängt, wie sie von den Akteur*innen im Prozess interpretiert werden, wird der Umgang mit digitalen Objekten stark davon beeinflusst, welche Interpretationen sich bei der Entwicklung der Funktionen durchsetzen, über die ihre analogen Vorlagen dekonstruiert werden. Diese Interpretationsprozesse werden durch die automatisierte Dekonstruktion versteckt. Akteur*innen sehen beim Umgang mit digitalen Objekten nur diese, also das Ergebnis der Transformationen von Eigenschaften einer analogen Vorlage (z. B. bei der Eingabe von Patient*innendaten bei der Aufnahme im Krankenhaus). Was sie nicht sehen, sind die vielen Aushandlungen in den Modellierungsprozessen bei der Entwicklung der Software, die diese Transformation erst möglich macht.

• (2) Auf der untersten Ebene der Dekonstruktion existieren keine qualitativen Unterschiede zwischen den digitalen Repräsentationen verschiedener Objekte; alle werden durch Wörter in der Maschinensprache dargestellt. Die Regeln für die Manipulation analoger Vorlagen beruhen auf unvereinbaren natürlichen Gesetzmäßigkeiten: die Manipulation von Tönen funktioniert anders als die Manipulation von Farben, eins kann nicht durch das andere ersetzt werden und die Regeln der Akustik haben mit den Regeln der Optik nichts zu tun. Die Manipulation aller digitalen Objekte hingegen folgt letztendlich nur den Regeln der digitalen Datenverarbeitung (a.a.O., S. 192).

Einerseits können dadurch Veränderungen an digitalen Objekten durchgeführt werden, die mit ihren analogen Vorlagen unmöglich wären, z. B. bei der Bearbeitung digitaler Bilder.⁵⁰ Andererseits entstehen dadurch neue Möglichkeiten, weitreichende gesellschaftliche Kontrolle auszuüben: Während über den Umgang mit analogen Objekten in unterschiedlichen gesellschaftlichen Bereichen verhandelt wird (Arthur 2011), erstreckt sich der Einfluss von z. B. Standards der Datenverarbeitung potentiell auf digitale Objekte, die in allen Bereichen eingesetzt werden. Über die Regulation der Datenverarbeitung wird damit potentiell Kontrolle über soziale Prozesse in vielen gesellschaftlichen Bereichen ausgeübt. Informatiker*innen und andere Expert*innen für Datenverarbeitung gewinnen dadurch weitreichende Einflussmöglichkeiten in der Gesellschaft.

Software kann soziale Prozesse zwar zum Teil durch automatische ersetzen, doch auch diese bleiben eingebettet in ein Geflecht an sozialen Prozessen. Der Umgang mit Software bleibt daher immer zu einem gewissen Teil unsicher (a.a.O., S. 191 f.). Der Umgang mit digitalen Objekten wird jedoch auf andere Weise und in anderen sozialen Prozessen reguliert als der Umgang mit ihren analogen Vorlagen. Durch die Undurchschaubarkeit der digitalen Dekonstruktion entzieht sich diese Regulation der Kontrolle der Akteur*innen, die Software benutzen (Kallinikos und Hasselbladh 2009). Kallinikos behauptet, dass diese Undurchschaubarkeit auch dazu führt, dass Akteur*innen ihre Erwartungen über das, was mit analogen Objekten möglich ist, an die Möglichkeiten anpassen, die digitale Objekte bieten. Die ubiquitäre Verbreitung von Software würde damit mit der Zeit grundsätzlich verändern, wie Menschen auf die Welt Einfluss nehmen (Kallinikos 2009). Diese Vorhersage passt zu aktuellen gesellschaftlichen Debatten über die Folgen der Digitalisierung⁵¹ ebenso wie zu Erkenntnissen aus verschiedenen Bereichen der soziologischen Digitalisierungsforschung (Grenz und Möll 2014; Kropf und Laser 2019).⁵² Belege dafür, dass die beobachtbaren Veränderungen der „perceptive and action modalities by which human agents confront the world“ (Kallinikos 2005, 2009) auf die von ihm beschriebenen Besonderheiten der digitalen Dekonstruktion zurückzuführen sind, bleibt er jedoch schuldig.

In allen hier vorgestellten Arbeiten wird Software als Artefakt betrachtet, dessen Komplexität sich (zumindest zum Teil) aus der Tatsache ergibt, dass soziale Phänomene in mathematischen Regeln folgende Modelle übersetzt werden und dass Akteur*innen in sozialen Prozessen mit den Ergebnissen dieser Übersetzung umgehen, ohne genau nachvollziehen zu können, wie diese Ergebnisse zu Stande gekommen sind. Alle Arbeiten weisen darauf hin, dass die Übersetzung den Akteur*innen Teile der Kontrolle über den Nutzungsprozess entzieht und diese in die Prozesse verlagert, in denen Software entsteht. Wie in Abschnitt 2.1.2 dargestellt, sind diese Prozesse, in denen Software entwickelt und weiterentwickelt wird, in der Zwecke und Rahmenbedingungen von Softwareprojekten ausgehandelt werden, in denen technische Standards entstehen etc., auf vielfältige Weise voneinander abhängig. Diese Abhängigkeit zwischen den verschiedenen Phasen des Softwarelebenszyklus und den Prozessen, die den Umgang mit Software umrahmen, bildet die zweite Dimension der Komplexität von Software. Auch sie ist Gegenstand soziologischer Forschungsarbeiten, die zentrale Erkenntnisse für eine Soziologie der Software bringen. Sie werden im folgenden Abschnitt vorgestellt.

2.2.2 Arbeiten zum Softwarelebenszyklus

Die Darstellung des Softwarelebenszyklus in Abschnitt 2.1.2 hat gezeigt, dass der Umgang mit Software von einer Kette von Modellierungsprozessen abhängt. Deren Verlauf und Ergebnis wird von den beteiligten Akteur*innen, ihrer Einbettung in Organisationen, professionelle Gemeinschaften und andere soziale Systeme sowie den Rahmenbedingungen beeinflusst wird, die von den vorhergehenden Modellierungsprozessen gesetzt werden. Diese Einflüsse strukturieren den Handlungsspielraum, den Akteur*innen im Umgang mit Software haben, ohne ihn völlig aufzuheben.

2.2.2.1 Spezifikation: Konfliktreiche Modellierung mit professionellem Machtgefälle

Ausgiebig untersucht sind vor allem die Prozesse, in denen Stakeholder*innen und Softwareentwickler*innen versuchen, gemeinsam die Unsicherheit sozialer Phänomene so weit zu reduzieren, dass ein daraus resultierendes Modell mit minimaler Beteiligung der Stakeholder*innen weiterverarbeitet werden kann. Softwareentwickler*innen nutzen in diesen Prozessen professionsspezifische Repräsentationspraktiken (Bloomfield und Vurdubakis 1997), Prozessvorlagen wie Vorgehensmodelle und Software-Werkzeuge, also Software für Softwareentwickler*innen, die zur Unterstützung solcher Praktiken entwickelt wurden (Schulz-Schaeffer und Bottel 2017). Funken (2001) und Rammert et al. (1998) betrachten die Modellierung als Form der Wissensproduktion. Dabei konzentriert sich Funken auf die Unterschiede zwischen den beiden Akteur*innengruppen und beschreibt die Aufgabenanalyse als einen asymmetrischen Aushandlungsprozess. In diesem Prozesse generieren dominante Profis (Softwareentwickler*innen, alternativ auch IT-Berater*innen) mit Lai*innen (Nutzer*innen) Wissen über den durch Software zu unterstützenden Ablauf. Entsprechend des Machtgefälles wird das Ergebnis dieser Wissensproduktion entscheidend durch die Hintergrundannahmen, also das implizite bzw. habitualisierte Erfahrungswissen der Softwareentwickler*innen geprägt. Diesen Hintergrundannahmen zu Folge geht es bei der Aufgabenanalyse darum, formalisierbares Wissen über eine als messbar und problemlos strukturierbar angesehene Wirklichkeit zu generieren. Diese Hintergrundannahmen führen dazu, dass die Softwareentwickler*innen versuchen, einige Aspekte der Unsicherheit, die Stakeholder*innen in den Prozess einbringen, auszublenden, um grundlegende Eigenschaften des Gegenstands aus dem Modell auszuschließen:

„Da bei der Software-Entwicklung bestehende soziale und organisatorische Verhältnisse in digitale Informationssysteme übersetzt und strukturiert werden, sind Entwickler auf Insiderwissen und fachspezifisches know-how angewiesen, das häufig nicht generalisierbar ist. ‘Standortgebundenheit’ und ‘Parteilichkeit’ sind bestimmend für die Charakterisierung des Gegenstandes.“ (Funken 2001)

Während Funken das Machtgefälle zwischen Softwareentwickler*innen und Stakeholder*innen thematisiert, konzentrieren sich Rammert et al. (1998) darauf, wie aus den Erfahrungen der Stakeholder*innen formalisierbares Wissen über den Gegenstand entsteht. Die Orientierungen und Fähigkeiten der Expert*innen für den Gegenstandsbereich (Stakeholder*innen) unterscheiden sich stark von denen der Wissensingenieur*innen (Softwareentwickler*innen): Erstere besitzen zwar tiefgreifendes Wissen über die für die Softwareentwicklung relevanten Eigenschaften des sozio-technischen Systems, aber dieses liegt „wenn überhaupt dann nur teilweise in einer kodifizierten Form (…) vor. Häufig handelt es sich um soziale Praktiken, die erst noch verbalisiert oder in eine andere symbolische Form gebracht werden müssen.“ (Rammert et al. 1998). Bei der Verbalisierung ihrer Praktiken stellen Expert*innen für den Gegenstandsbereich den Einzelfall und die konkrete Situation seiner Behandlung in den Mittelpunkt. Innere Widersprüche der Darstellung sind für sie – anders als für die Softwareentwickler*innen – wenig relevant, da sie sie als unvermeidlichen Teil der Praxis begreifen. Im Aufeinandertreffen dieser unterschiedlichen „Logiken“ werden Informationen über das in der Spezifikation zu modellierende System nicht von den einen Experten*innen an die anderen übermittelt (wie es die rationalistische Tradition vorsieht), sondern in der gemeinsamen Interaktion erst als relevante Informationen konstruiert. Die Konstruktion ist das Ergebnis einer Aushandlung, verstanden als ein Prozess, in dem „zwei Gesprächspartner zu einer, relativ zu ihren gegenwärtigen Zwecken, hinreichenden Übereinstimmung der Deutungen von Ereignissen, die in dem jeweiligen Kontext relevant sind, kommen“ (a.a.O., S. 140). Wie schwierig es in der Praxis sein kann, eine solche Übereinstimmung zu erzielen, zeigen Susan Leigh Star und Karen Ruhleder (1996) in ihrer Studie über die Entwicklung, Anwendung und Weiterentwicklung eines internetbasierten Softwaresystems zur wissenschaftlichen Kollaboration. Unterschiedliche professionelle Hintergrundannahmen können den beiden Forscherinnen zu Folge dazu führen, dass Akteur*innen bei der Softwareentwicklung aneinander vorbeireden, ohne es zu bemerken.

Während Funken, Rammert et al. und Star und Ruhleder sich mit der Reduktion der Aspekte von Unsicherheit befassen, die auf unterschiedlichen professionellen Orientierungen von Softwareentwickler*innen und Stakeholder*innen beruhen, zeigen Edeltraud Egger und Ina Wagner (1993), dass es auch innerhalb dieser Gruppen verschiedene Vorstellungen von dem sozialen Phänomen gibt, die im Softwareentwicklungsprozess auf ein einheitliches Modell reduziert werden müssen. In der Studie, für die die Forscherinnen die Entwicklung einer Individualsoftware zur OP-Planung begleitet haben, wird herausgearbeitet, wie die unterschiedlichen Positionen, die Chirurg*innen, Pflegekräfte und Anästhesist*innen in der professionellen Hierarchie der Medizin einnehmen, die Spezifikationsphase beeinflussen. Angehörige aller drei Berufsgruppen arbeiten gemeinsam an der Operation von Patient*innen im Krankenhaus. Sie sind für unterschiedliche Aufgaben im Operationsprozess zuständig und haben folglich unterschiedliche Vorstellungen von der Gesamtdauer einer Operation (a.a.O., S. 262). Gleichzeitig werden den Berufsgruppen in der professionellen Hierarchie unterschiedliche Grade von Autonomie zugestanden. Dass die an der Studie beteiligten Akteur*innen ihre jeweiligen Ansprüche kennen und anerkennen, zeigt sich zum Beispiel an den unterschiedlichen Erwartungen, die Mitglieder der verschiedenen Berufsgruppen an die Terminplanungsfunktion der zu entwickelnden Software stellen: Während öffentlich einsehbare persönliche Kalender für Pflegekräfte und Anästhesist*innen akzeptable technische Hilfsmittel zur Terminabstimmung darstellen, werden sie von Chirurg*innen als unzumutbare Beschneidung ihrer Freiheit abgelehnt. Nur Chirurg*innen empfinden mögliche Diskussionen über ihren Terminplan als Eingriff in ihre Autonomie. Für Pflegekräfte und Anästhesist*innen ist es hingegen Alltag, dass andere Einfluss darauf nehmen, wann sie welche Aufgaben erfüllen.

In den bisher vorgestellten Arbeiten wird vor allem untersucht, wie sich die professionelle Orientierung und die persönlichen Erfahrungen der Akteur*innen darauf auswirken, welche Unsicherheiten sie im Modellierungsprozess wie reduziert sehen wollen und welche Einflussmöglichkeiten sie innerhalb dieses Prozesses haben. Beides hängt jedoch nicht nur von den individuellen Eigenschaften der Akteur*innen ab, die an der Modellierung mitwirken, sondern auch von den beteiligten Organisationen. Die Orientierungen, Interessen und Erfahrungen von Softwareentwickler*innen und Stakeholder*innen der Softwareentwicklung wird nicht nur durch ihre Einbettung in professionelle Gemeinschaften geprägt, sondern auch durch die Zugehörigkeit zu Organisationen. Softwareentwickler*innen sind zum Beispiel häufig Beschäftigte eines Softwareunternehmens, Stakeholder*innen oft Beschäftigte eines anderen Unternehmens. In Abschnitt 2.1.2 wurde dargestellt, dass diese Zugehörigkeit zu Organisationen beeinflusst, wie Akteur*innen sich in den Aushandlungen rund um die Softwareentwicklung verhalten: Welche Zwecke durch Softwareentwicklungsprojekte erfüllt werden sollen, welche Ressourcen in diesen Projekten zur Verfügung stehen, wie Akteur*innen ihre Positionen in den unterschiedlichen Aushandlungen der Softwareentwicklungsprozesse legitimieren können und welche Machtmittel sie haben, um diese Positionen gegeneinander durchzusetzen – dies alles wird auch von den Organisationen geprägt, die an der Softwareentwicklung beteiligt sind. In der soziologischen Forschung kommt diese Bedeutung von Organisationen nur am Rande vor. Im Folgenden stelle ich dar, in welchen Arbeiten die Rolle von Organisationen in den einzelnen Phasen des Softwarelebenszyklus untersucht worden ist.

2.2.2.2 Das Softwareprojekt: Komplexe Prozesse mit Folgen für das Produkt

Mit der Tatsache, dass Projekte, in denen Individualsoftware entwickelt wird, von den sozialen Prozessen in den Organisationen, die diese Projekte tragen, abhängig sind, befassen sich Friedrich Weltz und Rolf Ortmann (1992). Sie zeigen, dass die Trägerorganisationen von der Initialisierung bis zur Evaluation beeinflussen, welche Aufgaben im Projekt von wem wie ausgeführt werden, wer diese Aufgaben nach welchen Maßstäben bewertet und wie die Ergebnisse vorhergehender Prozesse in folgenden aufgenommen werden. Nicht nur die Auswahl der Teammitglieder, auch die Rahmenbedingungen, unter denen diese arbeiten, beschreiben die Autoren als Ergebnis oft konfliktreicher sozialer Prozesse innerhalb der Organisationen, in denen die Komplexität der Aufgaben oft systematisch unterschätzt wird:

„Unverkennbar war die Kalkulation vielfach ein Politikum: Instrument in der Auseinandersetzung um den Umfang oder gar die Berechtigung des Entwicklungsprojekts […] Bisweilen wurde das Projektvolumen ganz offensichtlich und bewusst zu niedrig angesetzt, um die interne Durchsetzung des Projekts zu erleichtern. […] Nicht die Kostenkalkulation lieferte in solchen Fällen Kriterien für die Entscheidungen, sondern umgekehrt die ‚Berechnungen‘ orientierten sich an den Kriterien der Entscheidung.“ (Weltz und Ortmann 1992, 43 f.)

Obwohl die zu Projektbeginn gesetzten Rahmenbedingungen sich während der Projektlaufzeit regelmäßig ändern, wenn Ereignisse im Projekt Anlass dazu geben, die Bedingungen neu auszuhandeln (a.a.O., S. 46), beeinflussen sie in vielen der untersuchten Fälle dennoch, wie die Software aussieht, die im Rahmen des Projekts entsteht.

„Ob eine opulente Lösung mit einem Übermaß an Funktionalitäten angeboten wurde oder ein karges Miniprogramm, in welcher Weise der Anwendungsbezug, ergonomische Aspekte etc. berücksichtigt wurden, all dies hing bisweilen nicht so sehr von den Zielvorgaben eines Projekts oder von der Planung der einzelnen Arbeitsschritte ab, sondern schlicht auch davon, welcher zeitliche und budgetäre Rahmen mit welcher Verbindlichkeit vorgegeben wurde.“ (Weltz und Ortmann 1992, S. 47)

Mit dem Fokus auf das Verhältnis von Organisationen und Projekten gelingt es Weltz und Ortmann, prinzipiell sichtbar zu machen, dass sich die Komplexität von Software aus soziologischer Perspektive auf die Vielzahl an Abhängigkeiten zwischen den sozialen Prozessen zurückführen lässt, die Einfluss auf die Softwareentwicklung haben. Die Autoren unterscheiden dabei konzeptionell zwischen struktureller Komplexität und prozessualer Komplexität. Strukturelle Komplexität ergibt sich dieser Unterscheidung zu Folge aus der Aufgabe und den Kontextbedingungen, prozessuale Komplexität entsteht daraus, dass im Softwareentwicklungsprozess getroffene Entscheidungen einerseits Bedingungen für spätere Entscheidungen setzen, andererseits aber auch dazu führen können, dass die Bedingungen rückwirkend angepasst werden (a.a.O., S. 16). Aus der in Abschnitt 2.1.2 dargestellten Perspektive dienen Entscheidungen im Softwareentwicklungsprozess häufig dazu, Unsicherheiten bei der Modellierung unter Kontrolle zu bekommen, indem aus verschiedenen möglichen Alternativen nur eine ausgewählt und in das Modell übernommen wird. Mit dem Begriff der prozessualen Komplexität bezeichnen Weltz und Ortmann eine zentrale Beschränkung dieser Strategie, die auch in Abschnitt 2.1.2. erläutert wird: Durch Entscheidungen kann die Unsicherheit niemals aufgelöst, sondern nur die Kontrolle von Unsicherheiten zwischen den einzelnen Prozessen verschoben werden.

2.2.2.3 Einflüsse von Organisation auf den Code

Während sich Weltz und Ortmann vor allem mit den Abhängigkeiten zwischen sozialen Prozessen in der Kund*innenorganisation und denen im Softwareprojekt beschäftigen, untersuchen Graham Button und Wes Sharrock, wie die Prozesse bei Softwareherstellerinnen Arbeit und Arbeitsergebnisse von Softwareentwickler*innen beeinflussen (Button und Sharrock 1998, 1996). Auch diese Prozesse bestimmen grundlegend mit, welche Art von Software entsteht: „The application of technical knowledge could not be divorced from the organizational contingencies within which it was deployed; determinations of the technical design of the machine were entwined with organizational decisions“ (Button und Sharrock 1998). Auch in den von den Autoren untersuchten Fällen ist die Bedeutung scheinbar offensichtlicher Rahmenbedingungen wie Zeitpläne und Budgets eines Entwicklungsprojekts von den Ergebnissen konkreter Aushandlungen in der Organisationen zur Laufzeit des Projektes abhängig. Entwicklungsprojekte, die zu lange dauern oder zu teuer werden, werden zwar gelegentlich ergebnislos beendet (Button und Sharrock 1998). Es kommt aber auch vor, dass Entwickler*innen sich entscheiden, einige der für die Software spezifizierten Anforderungen zu ignorieren, wenn diese nicht innerhalb der allgemeinen Vorgaben der Organisation erfüllbar sind, zum Beispiel weil für die Umsetzung der Einsatz leistungsstärkerer Hardware oder einer von den Richtlinien der Organisation nicht vorgesehene Programmiersprache nötig wäre (Button und Sharrock 1998). Häufig arbeiten die Entwickler*innen an mehreren Projekten gleichzeitig, so dass Verzögerungen dazu führen, dass die Projektverantwortlichen mit denen konkurrierender Projekte um Personal verhandeln müssen (Button und Sharrock 1998). Die Möglichkeit, eine Software wie spezifiziert fertig zu stellen, hängt damit auch davon ab, welche Mittel, welche Gelegenheiten und auch welche Motivation die Projektverantwortlichen haben, um die Bedarfe, die innerhalb des Projekts ausgehandelt werden, außerhalb des Projekts gegenüber der Trägerorganisation durchzusetzen.

Button und Sharrock thematisieren auch, dass aus der grundsätzlichen Unsicherheit, die im Vorgang des Programmierens liegt, neue Unsicherheiten für die Phase der Implementierung entstehen. Diese Phase kann nur erfolgreich abgeschlossen werden, wenn es gelingt, die Arbeitsergebnisse aller einzelnen Programmierer*innen zu integrieren. Unsicherheiten über die Details der individuellen Arbeitsergebnisse stehen dem im Weg:

„There are no unique solutions for the coding problems engineers have at hand. Any given coding problem can have many solutions: the problem-solving code written by one engineer will not necessarily be the same as that written by another engineer facing the same problem, even though both sets of code would execute the desired operation. Thus different engineers might ‘work out the code’ in different ways. In any software development project, the code written by one engineer may not ‘fit’ that written by another.“ (Button und Sharrock 1998, S. 78)

Die Autoren zeigen mit ihren Studien zur Implementierungsphase, dass Organisationen den Umgang mit Unsicherheiten bei der Modellierung im Code beeinflussen, ohne dadurch die Unsicherheiten, die aus der Aufgabe selbst stammen, aufzuheben. Die Übersetzung von sozialen Phänomenen in Code und die organisatorischen Rahmenbedingungen der verketteten Modellierungsprozesse tragen beide auf je eigene Weise zur Komplexität von Software bei.

2.2.2.4 Organisatorisch eingebettete Aushandlungen in der Praxis des Testens

Während Spezifikation häufig, Projektmanagement, Entwurf und Implementierung zumindest gelegentlich Gegenstand soziologischer Untersuchungen sind, gibt es nur wenige Forschende, die sich mit den sozialen Prozessen während der Testphase auseinandersetzen. Einen Einblick in die Praxis des Softwaretests bieten immerhin John Rooksby, Mark Rouncefield und Ian Sommerville (2009), die sich in vier kurzen Feldstudien mit der Frage beschäftigen, wie die Praxis des Testens unter unterschiedlichen organisatorischen und technischen Bedingungen abläuft. Die Arbeit beinhaltet eher anekdotische Eindrücke vom Softwaretest in einem kleinen Softwarehaus, zwei Open-Source-Projekten, wovon eines unter Mitarbeit eines Unternehmens entwickelt wird, und einer Eigenentwicklung in einer großen Universität. Alle Beispiele gleichen sich darin, dass die Akteur*innen in der Praxis vom idealisierten Modell des Softwaretests abweichen. Diesem idealisierten Modell zu Folge sollten zu Beginn der Entwicklung Fehlerklassen definiert und festgelegt werden, wie viele Fehler aus jeder dieser Klassen am Ende des Projekts behoben sein müssen, damit die Software als erfolgreich fertiggestellt gelten kann. In keinem der beschriebenen Fälle berücksichtigen die Beteiligten eine solche Vorgabe oder folgen einem vorher fixierten Plan, mit dessen Hilfe alle Anforderungen überprüft werden. (a.a.O., S. 573). Stattdessen werden Ausmaß, Umfang und Art der Tests während der Testphase ebenso ausgehandelt wie die Frage, ob und unter welchen Bedingungen gefundene Fehler tatsächlich behoben werden sollen: „conversation is a key part of the work of testing, between developers, between board members, between users etc.“ (a.a.O. S. 576). Der Verlauf und das Ergebnis der Aushandlungen ist abhängig von den Ressourcen des Softwareprojekts und den Prioritäten und Einschätzungen der konkreten Teilnehmer*innen: „there is congruence between organizational structure, organizational priorities and the way tests are performed“ (Rooksby et al. 2009, S. 575). Nicht nur bedeutet das, dass Funktionen der Software, die von den Anforderungen abweichen, unbemerkt bleiben, weil sie im Test nicht geprüft werden, sondern auch, dass erkannte Abweichungen bestehen bleiben, weil sie während der Testphase als nicht (unmittelbar) signifikant eingeschätzt werden. Diese Einschätzung ist ein zentraler Aspekt aller untersuchten Beispiele. Nicht nur die Spezifikation, sondern auch der Test „involves reasoning and speculation about practices and situations of use“ (a.a.O., S. 576). Ohne Anspruch auf Verallgemeinerbarkeit zeigt die Arbeit von Rooksby et al. damit, dass auch beim Test Modellierungsprozesse stattfinden, die sowohl mit den übrigen Prozessen im Lebenszyklus der Software als auch mit deren (organisatorischer) Einbettung verknüpft sind.

2.2.2.5 Customizing von standardisierter Organisationssoftware

Im Rahmen ihrer organisationssoziologischen Dissertation zu SAP untersucht Hannah Mormann (2016) wie in Customizingprojekten generische Standardsoftware und spezifische Kund*innenorganisation aneinander angepasst werden. Sie analysiert dazu die Abhängigkeiten zwischen der Software, den Entscheidungen innerhalb der Organisationen, die das Customizingprojekt tragen, und den Interaktionen von Berater*innen und ausgewählten Mitarbeiter*innen der Kund*innenorganisation während des Projekts. Die Software charakterisiert sie dabei als Werkzeug zur „(Re-)Modellierung von Arbeitsabläufen“ (a.a.O., S. 131), das auf einem Organisationsmodell beruht, das frei von Unsicherheiten ist (a.a.O., S. 225). Aus dieser Annahme leiten die Akteur*innen die Überzeugung ab, dass die in der Software vorgefundenen Vorlagen für Arbeitsprozesse „vernünftig“ sind (a.a.O., S. 173). Berater*innen gelten daher sowohl als Expert*innen für die Software als auch als Expert*innen für den Gegenstandsbereich Es wird davon ausgegangen, dass die Kenntnis der Vorlagen und Erfahrungen aus anderen Customizingprojekten ebenso Grundlage einer solchen Expertise sein kann wie praktische Erfahrung mit den Arbeitsprozessen selbst (a.a.O., S. 171). Die Mitarbeiter*innen der Kund*innenorganisation, die am Customizing teilnehmen, sind oft Mitglieder höherer Hierarchieebenen, die wenig Bezug zu den konkreten Alltagsabläufen haben (Mormann 2010). Als solche wissen sie entweder nicht im Detail, wie die Arbeitsprozesse in ihrer Organisation aussehen, oder sind mehr daran interessiert, diese mit Einführung der Software zu verändern, als sie beim Customizing abzubilden (Mormann 2016). Die Einführung von standardisierter Organisationssoftware wird nämlich häufig als Gelegenheit genutzt, um lang etablierte Arbeitsprozesse, die als ineffizient gelten, entsprechend der Vorlagen aus der Software umzugestalten und damit vermeintlich zu optimieren. Begrenzte Projektlaufzeiten, die weitere technische Veränderungen der Software unmöglich machen (Mormann 2016) tragen zusätzlich dazu bei, dass die Berater*innen im Customizingprojekt vor allem versuchen, von den Kundenrepräsentant*innen zu erfahren, welche Kombination von Standardvorlagen aus der Software am ehesten ihren Vorstellungen entspricht (a.a.O., S. 182). An diese Kombination sollen dann die Arbeitsprozesse angepasst werden.

Neil Pollock und James Cornford stellen in ihrer Studie zum Customizing eines ERP-Systems heraus, dass beim Customizing Teile des Standardmodells gelegentlich auch übernommen werden, ohne dass irgendeine der Akteur*innen inhaltlich von ihnen überzeugt ist. In solchen Fällen bietet die Übernahme der Standardvorlagen den Projektmitgliedern eine Möglichkeit, das Projekt voranzubringen, obwohl dazu eigentlich notwendige Vorgaben aus verknüpften sozialen Prozessen (noch) nicht verfügbar sind:

„At a number of points in the process it becomes clear that there is more than one way, in current practice, in which a particular step in the process was being handled. If the issue cannot be resolved one way or another, the consultant leading the meeting identifies the issue as “a matter for policy”, a matter on which a definitive ruling must be given by the university centrally. […] [T]hese demands for policy were so copious that many of the requests simply remained on the database without senior management ever having the time to deal with them. […] As a result, most of the issues have to be resolved within the project team on more technical grounds, meaning the team had to deploy its own criteria while configuring the system. And, in many cases, this meant just accepting the default settings.“ (Pollock und Cornford 2004, S. 41–42)

Im zitierten Beispiel versucht der Beratende, Unsicherheiten, die im Customizingprozess sichtbar werden, an die Entscheidungsprozesse im oberen Management auszulagern. Die Unsicherheiten werden aber innerhalb dieser Prozesse nicht bearbeitet, da die Mitglieder der Universitätsleitung sich gar nicht mit den Anfragen aus dem Projektteam befassen. Sie bleiben damit unsicher und blockieren irgendwann die Modellierung im Customizingprozess. Da es den Akteur*innen aber weiterhin nicht gelingt, die Unsicherheiten durch Aushandlungen selbst zu reduzieren, nutzen sie das Standardmodell aus der Software. Die Software wird damit performativ, weil sie eine Möglichkeit anbietet, die Komplexität der sozialen Prozesse zu reduzieren, an denen die Akteur*innen selbst beteiligt sind. Statt sich zu einigen oder bei der Universitätsleitung vorstellig zu werden und eine Entscheidung zu verlangen, können die Mitarbeiter*innen des Customizingprojekts einfach übernehmen, was die Software bereits anbietet. Die Komplexität, die dem Standardmodell zugrunde liegt, ist für die Akteur*innen im Customizing nicht von Belang.

In der soziologischen Forschung zur Softwareentwicklung wird nur selten thematisiert, dass Softwareentwicklung durch die Organisationen beeinflusst wird, in denen sie stattfindet. Die hier vorgestellten Arbeiten wurden mit Blick auf dieses Thema ausgesucht; ihr Fokus auf Organisationen stellt eine Ausnahme im Forschungsstand dar. Anders sieht dies bei Studien aus, in denen die Forschenden sich mit den Phasen des Lebenszyklus beschäftigen, die nach der Fertigstellung der ersten Version der Software liegen. Hier werden in der Regel Organisationen fokussiert, die Frage nach der Performativität der Software bleibt hingegen meist unbeantwortet oder wird gar nicht erst gestellt. Einige dieser Studien sind jedoch entscheidend, um die in dieser Arbeit entwickelte soziologische Perspektive auf Software zu verstehen. Dieser zu Folge entsteht die Performativität von Software ja nicht allein im Softwareentwicklungsprozess, sondern ebenso in den sozialen Prozessen, in denen Akteur*innen – meist in irgendeiner Form beeinflusst von Organisationen – mit einer fertiggestellten Version der Software umgehen. Software wird dabei Teil der mikropolitischen Auseinandersetzungen im Nutzungskontext (Abschnitt 2.2.2.6) und hat Auswirkungen auf die Praktiken und Regeln, welche diesen Kontext strukturieren (Abschnitt 2.2.2.7).

2.2.2.6 Einführung und Nutzung von Software als Geflecht mikropolitischer Auseinandersetzungen

Mit der Einführung von Software im Rahmen von IT-Beratungsprojekten befasst sich die Arbeit von Michaela Wieandt-Ledebur (2014). In IT-Beratungsprojekten arbeiten Mitarbeiter*innen einer Beratungsorganisation mit Mitarbeiter*innen einer Kund*innenorganisation zusammen, meist um neue Software in der Kund*innenorganisation einzuführen. IT-Beratungsprojekte werden immer von der Kund*innenorganisation beauftragt. Wieandt-Ledebur betrachtet IT-Beratungsprojekte als besondere soziale Systeme, als Organisationen mit von vorneherein begrenzter Laufzeit,⁵³ die von zwei Organisationen ohne eine solche Laufzeitbegrenzung abhängen. Solche Projekte versteht sie als „Relaissysteme“ (a.a.O., S. 49) zwischen Beratungs- und Kund*innenorganisationen: Über die sozialen Prozesse innerhalb des Projekts werden soziale Prozesse innerhalb der beiden Organisationen, die das Projekt tragen, miteinander verknüpft. Auf Basis der strategischen Organisationsanalyse (Crozier und Friedberg 1979) entwickelt sie einen Forschungsrahmen, den sie einsetzt, um zu untersuchen, wie die Organisationsmitglieder versuchen, Kontrolle über die Regulierung eines internationalen IT-Beratungsprojekts zu gewinnen. Es wird nachgezeichnet, dass die Akteur*innen mit Hilfe dieser Kontrollversuche ihre Positionen in den Träger*innenorganisationen zu stärken, in denen sie beschäftigt sind. Die mikropolitische Betrachtung zeigt, dass die Dynamik der Aushandlungen innerhalb solcher Projekte nur vor dem Hintergrund der vielfältigen Aushandlungen verstanden werden kann, die sich in den Träger*innenorganisationen um Aufgaben, Rahmenbedingungen und Folgen des Projekts entwickeln. Bei Projekten zur Softwareeinführung entstehen besonders viele Verknüpfungen zu sozialen Prozessen in den Träger*innenorganisationen, die intensive Aushandlungen auf allen Seiten nach sich ziehen, weil die Projekte „die IT-Strukturen und damit Ungewissheitszonen und Machtbeziehungen in Organisationen tatsächlich und dauerhaft verändern“ (Wieandt-Ledebur 2014). Mitarbeiter*innen der Kund*innenorganisation versuchen daher, Kontrolle über das Projekt auszuüben, in dem über die zukünftigen Bedingungen ihres Handelns entschieden wird. Software wird in der Arbeit von Wieandt-Ledebur als Gegenstand der Auseinandersetzung und Mittel zur Kontrolle der sozialen Prozesse in Projekt und Organisation betrachtet. Nicht untersucht wird sie als performatives Element der Prozesse, das eigene Modelle der sozialen Prozesse mit sich bringt, deren Umgestaltung bei der Einführung der Software mit verhandelt wird.

Eine wichtige Vorlage für Wieandt-Ledeburs Theorierahmen ist die umfassende Arbeit zu den Bedingungen und Folgen von Informatisierung und Reorganisation im Betrieb von Günther Ortmann, Arnold Windeler, Albrecht Becker und Hans-Joachim Schulz (1990). In der Arbeit kommt ebenfalls die strategische Organisationsanalyse zum Einsatz; diese Herangehensweise wird jedoch nicht nur zur Analyse der empirischen Ergebnisse genutzt, sondern auch sozialtheoretisch reflektiert und weiterentwickelt. Die Autoren betrachten Einführung und Nutzung von Software gemeinsam. Sie zeigen anhand mehrerer detaillierter Fallstudien, wie stark Softwarenutzung zumindest in Organisationen durch bestehende Machtverhältnisse und Aushandlungen zwischen einflussreichen Akteur*innen beeinflusst wird. Das beginnt bereits lange vor der Einführung von Software damit, dass bestimmte Phänomene als zu lösende Probleme erst bestimmt und spezifisch ausformuliert werden müssen.

„‚Probleme‘ […] sind präformiert durch organisationale Standards und Normen, durch Identifizierungen mit partiellen Organisationszielen, durch eine organisationale Denk- und Sprechweise […] und sie sind gefiltert durch ein Raster mikropolitischer Interessen und Mittel, das die Chancen für Sachverhalte, zu anerkannten Problemen zu avancieren, ungleich verteilt.“ (Ortmann et al. 1990)

Die Problemdefinition ist nur eine von unzähligen Entscheidungen, mit denen innerhalb der Organisationen Unsicherheit reduziert wird, bevor die Nutzung von Software überhaupt beginnt (a.a.O., S. 377 ff.). Diese Entscheidungen folgen nicht einer im Nachhinein kolportierten ökonomischen oder technischen Rationalität (a.a.O., S. 408). Sie entstehen aus den von asymmetrischen Machtverhältnissen geprägten Aushandlungen zwischen Akteur*innen, deren Ziele, Perspektiven und Machtressourcen auch durch ihre Positionierung in den Organisationen bestimmt sind, denen sie angehören. Ortmann et al. verstehen Organisationen dabei als „Arenen mikropolitischer Aushandlungsprozesse und Kämpfe, in denen jeder ‚sein‘ Spiel spielt und das Ganze nur funktioniert, wenn die Spiele in Organisationen günstig strukturiert und aneinander gegliedert sind.“ (a.a.O., S. 8). Die formale Hierarchie ist in solchen Aushandlungen nur eine von mehreren Machtressourcen und auch den auf den ersten Blick unterlegenen Akteur*innen bieten sich im Laufe der Projekte der Softwareeinführung ausreichende Gelegenheiten, eigene Interessen zumindest zum Teil umzusetzen (a.a.O., S. 399 ff.). Die Akteur*innen machen Software zur Ressource, um ihre Vorstellungen von der Organisation durchzusetzen (z. B. a.a.O., S. 296–324) oder nutzen ihre (zugeschriebene) Expertise in Bezug auf Software, um unliebsame Veränderungen zu verhindern (a.a.O., S. 266–295).

Software spielt in den internen Aushandlungsprozessen, die Ortmann et al. betrachten, nicht nur als Mittel zur Durchsetzung bereits bestehender (Macht)-Interessen eine Rolle. Die Möglichkeit, Software selbst zu entwickeln statt ein fertiges Standardprodukt zu kaufen, wird durch die Rahmenbedingungen begrenzt, die die Organisation setzt (z. B. verfügbares Personal und Kostenrahmen). Die Entscheidung für Standardsoftware bedeutet, dass die Akteur*innen an ein gegebenes Angebot gebunden sind. Extern produzierte Software wiederum trägt Modelle von Arbeitsorganisation in sich, die im Rahmen von Aushandlungen in und zwischen anderen Organisationen entstanden sind (a.a.O., S. 409 ff.). Über die Software entsteht damit eine Verbindung von zwischen- und innerorganisatorischen Aushandlungsprozessen, denn die Software trägt dazu bei, dass die Ergebnisse von ersteren in letzteren aufgegriffen und damit wirksam werden können. Dieser Aspekt wird von Ortmann et al. als bedeutsames Forschungsgebiet angesprochen, aber nicht untersucht (a.a.O., S. 410). Diesen Vorschlag greife ich mit der vorliegenden Arbeit auf und integriere die Erkenntnisse von Ortmann et al. in den Forschungsrahmen, der in Kapitel 3 vorgestellt wird.

2.2.2.7 Verbindungen zwischen Entwicklung und Nutzung: Leitvorstellungen und Modi des Umgangs mit Software

Die Frage, welcher Zusammenhang zwischen den Modellen sozialer Phänomene, die bei der Softwareentwicklung entstehen, und der Art und Weise, wie Nutzer*innen mit Software umgehen, besteht, steht nur selten im Mittelpunkt soziologischer Forschung zu Software. Rammert et al. (1998) bezeichnen die verbindenden Elemente zwischen Entwicklung und Nutzung als Leitvorstellungen.⁵⁴ Diese entstehen aus den Erwartungen, die Entwickler*innen über die zukünftige Nutzung der Technik haben. Leitvorstellungen beinhalten Nutzer*innengruppen, Praktiken und Bedingungen der Techniknutzung und auch die Zwecke, die Nutzer*innen mit der Technik verfolgen. Nicht nur bei der Entwicklung, sondern auch in späteren Phasen des Lebenszyklus orientieren sich Akteur*innen an diesen Erwartungen. Leitvorstellungen beeinflussen dadurch, wie Software gestaltet und genutzt wird. Leitvorstellungen beeinflussen einerseits, welche Handlungsmöglichkeiten Software den Nutzer*innen bietet, also zum Beispiel welche Funktionen sie hat, wie die Benutzer*innenoberfläche aussieht und welche Daten eingegeben werden sollen. Sie prägen andererseits auch, wie diese Angebote angenommen werden, also zum Beispiel wie und wozu die Software genau eingesetzt wird und ob Nutzer*innen viele Auswahlmöglichkeiten als unnötig kompliziert verurteilen oder als Ausweis für erfreuliche Flexibilität schätzen. Leitvorstellungen, zum Beispiel über die zukünftige Anwendung und den dafür mindestens notwendigen Funktionsumfang, sind jedoch nicht einfach in der Software abgebildet. Sie hängen auch vom sozialen Kontext ab, in dem der Umgang mit der Software stattfindet. Daher transportiert Software nur einen Teil der Leitvorstellungen aus der Entwicklung in die Nutzung:

„Die Aneignung der Leitvorstellungen durch die Nutzer ist ein Übersetzungsprozeß für die im Artefakt verkörperten Sinngehalte. […] Der funktionierende technische Kern wird […] von den Entwicklern an die Nutzer weitergereicht. Ein Teil der semantischen Rahmung verschwindet dabei […]. Ein anderer Teil wird von den Nutzern nur bruchstückhaft angeeignet […]. Keineswegs sind die […] Leitvorstellungen also völlig uninteressant. Sie werden aber mehrmals gebrochen und zum Teil durch andere Vorstellungen ersetzt, wenn das System auf den Tisch der Nutzer kommt.“ (Rammert et al. 1998)

Rammert et al. interessieren sich vor allem für die Leitvorstellungen selbst und rekonstruieren weder, wie die „semantische Rahmung“ im Entwicklungsprozess entsteht, noch, welche sozialen Prozesse Anteil daran haben, dass sie bei der Nutzung „zum Teil durch andere Vorstellungen ersetzt“ werden. Das Konzept der Leitvorstellungen wird hier dennoch aufgeführt, weil es viele der Fragen miteinander verbindet, die in Abschnitt 2.1.2 vorgestellt wurden. Hinter dem Konzept steckt der zentrale Gedanke, der auch die vorliegende Arbeit trägt: Vorstellungen vom Umgang mit Software, die von den Rahmenbedingungen der Entwicklung beeinflusst sind, prägen die Nutzung, aber die Art und Weise, wie sie das tun, hängt von den Rahmenbedingungen ab, unter denen Nutzer*innen sich die Software aneignen.

Nicht nur angedeutet, sondern auch theoretisch fundiert und ausgearbeitet wird der gleiche Gedanke in dem Konzept der Dualität von Technik (Orlikowski 1992). Wanda Orlikowski versucht mit diesem Konzept, den Zusammenhang zwischen Softwareentwicklung und -nutzung aus einer soziologischen Perspektive zu beschreiben. Angelehnt an das strukturationstheoretische Grundmodell der Dualität von Struktur und Handeln, in dem soziale Strukturen als Medium und Resultat menschlicher Auseinandersetzung mit der Welt konzeptionalisiert werden (Giddens 2008 [1984]), lässt sich die Rolle von Software im Sozialen nur über den Umgang der Akteur*innen mit ihr verstehen:

„On its own, technology is of no import: it plays no meaningful role in human affairs. It is only through the appropriation of technology by humans (whether for productive or symbolic ends) that it plays a significant role and hence exerts influence. It is only through human action that technology qua technology can be understood.“ (Orlikowski 1992, S. 409)

Entwicklung und Nutzung von Software sind Orlikowski zu Folge gleichermaßen Formen des Umgangs mit Technik. Dieser Umgang ist immer eingebettet in einen sozialen Kontext, der Regeln zur Interpretation und Bewertung des Handelns und Ressourcen beinhaltet, die den Umgang mit Software erst möglich machen. Diese Regeln und Ressourcen bestimmen zwar nicht vollständig, wie Akteur*innen mit Software umgehen können, machen aber bestimmte Umgangsformen mehr und andere weniger wahrscheinlich. Software wird dabei als (auch) materielles Artefakt betrachtet, das aus bestimmten (gestaltenden) Umgangsformen entsteht und gleichzeitig Voraussetzung für alle Umgangsformen ist. Über die Software wirken Akteur*innen und soziale Kontexte, in denen frühere Umgangsformen entwickelt werden, auf Akteur*innen ein, die später eigene Umgangsformen entwickeln und damit ihre eigenen sozialen Kontexte verändern. Orlikowski unterscheidet dabei nicht prinzipiell zwischen Softwareentwicklung und –nutzung, sondern definiert stattdessen zwei Modi des Umgangs mit Software, die in allen Phasen des Lebenszyklus vorkommen können, und diskutiert die Auswirkungen dieses Umgangs auf den sozialen Kontext, in dem er stattfindet.

• (1) Im design mode betten Akteur*innen die Regeln und Ressourcen, die den Umgang mit der Technik ermöglichen und beschränken, in die Technik ein.

• (2) Im use mode wirken diese eingebetteten Regeln und Ressourcen dann gemeinsam mit denen, die aus dem sozialen Kontext stammen, auf die Akteur*innen ein, die mit der Software umgehen (a.a.O., S. 410).

• (3) Der soziale Kontext wiederum verändert sich in beiden Modi durch die Umgangsformen, die Akteur*innen in Auseinandersetzung mit der Software entwickeln.

Die Idee, dass Regeln und Ressourcen in Technik eingebaut werden und so zu Strukturen des sozialen Kontexts ihrer Nutzung werden, widerspricht der zentralen Grundfigur der Dualität von Struktur und Handeln in der Strukturationstheorie. Dieser Grundfigur zu Folge können die strukturellen Eigenschaften eines Sozialsystems, zu denen Regeln und Ressourcen zählen, nicht dauerhaft fixiert werden. Sie existieren nur im Handeln, wenn Akteur*innen in den Praktiken des Sozialsystems auf sie Bezug nehmen (Giddens 2008 [1984]). Die Figur der Dualität von Struktur und Handeln in der Strukturationstheorie bildet den Ausgangspunkt für das Modell der Dualität von Technik. Der Widerspruch zwischen dem Konzept und seiner sozialtheoretischen Grundlage wird in einer späteren Arbeit der Autorin aufgelöst (Orlikowski 2000). In dieser Arbeit werden die Regeln und Ressourcen in eigenen Strukturen der Techniknutzung (technologies-in-practice) statt in der Software verortet. Die Lösung des theoretischen Problems wird dabei jedoch mit einer Abwendung von zentralen Ideen des ursprünglichen Modells der Dualität von Technik erkauft: Im ursprünglichen Modell sind die Software, das Handeln der Akteur*innen und die verschiedenen sozialen Kontexte, in denen Software entwickelt, eingeführt oder genutzt wird, für die Analyse des Umgangs mit Software gleich bedeutsam. In dem Modell, in dem die Widersprüche zu sozialtheoretischen Grundannahmen aufgelöst sind, werden die Praktiken der Techniknutzung, also das Handeln der Akteur*innen, als das zentrale Element hervorgehoben, durch das sich der Umgang mit Software verstehen lässt. Durch die Konzentration auf Praktiken der Techniknutzung tritt die Bedeutung der Software und die der sozialen Kontexte, in denen Software entwickelt, eingeführt oder genutzt wird, in den Hintergrund. Für die soziologische Perspektive auf Software, die ich in dieser Arbeit entwickeln will, greife ich die Grundidee der Trias dreier gleich bedeutsamer Einflussfaktoren wieder auf. Wie sich der Umgang mit Software soziologisch als ein Zusammenspiel aus Software, sozialen Kontexten und Handeln von Akteur*innen verstehen lässt, wird in Abschnitt 2.3 theoretisch ausgeführt. Auch für den Forschungsrahmen, der in Kapitel 3 ausgearbeitet wird, bildet das Konzept der Dualität von Technik von Wanda Orlikowski eine wichtige Grundlage.

In den hier vorgestellten Arbeiten werden verschiedene der in 2.1.2 aufgeworfenen Fragen zum Softwarelebenszyklus untersucht. Die Autor*innen berücksichtigen dabei jedoch jeweils nur wenige der Einflüsse, die beim Umgang mit Software zwischen professioneller und organisationaler Einbettung der Akteur*innen, ihren Weltbildern, Machtressourcen und Interessen und den Handlungsmöglichkeiten der Akteur*innen bestehen. Vereinfacht gesagt erfasst jede der Arbeiten nur einen Ausschnitt der Komplexität der Software, die im Lebenszyklus entsteht. Die Rekursivität von Software wird in keinem der Ansätze explizit berücksichtigt. Sie wird in der Soziologie allgemein selten thematisiert. Eine Ausnahme stellen die wenigen Arbeiten dar, in denen Soziolog*innen sich gezielt mit der Weiterentwicklung und Wiederverwendung von Software auseinandersetzen. Solche Arbeiten werden im Folgenden vorgestellt.

2.2.3 Arbeiten zu Weiterentwicklung und Wiederverwendung

Bei der soziologischen Auseinandersetzung mit Software gehen Forschende in der Regel (explizit oder implizit) davon aus, dass Technik und soziale Prozesse einander in einem Verhältnis gegenüberstehen, das durch das Begriffspaar von Inskription und Deskription (Akrich 2000) beschrieben werden kann. Dieses Verhältnis lässt sich kurz wie folgt beschreiben: Aspekte sozialer Phänomene werden bei der Entwicklung in (wie auch immer spezifizierte) Eigenschaften der Technik überführt (Inskription). Bei der Nutzung werden aus diesen Eigenschaften Hinweise über das aktuelle soziale Phänomen extrahiert (Deskription), an denen sich die Akteur*innen in ihrem Handeln (in irgendeiner Form) orientieren. Nach der Inskription ist die Technik fertig, Veränderungen während der Nutzung sind nur interessant, wenn das Artefakt stabil bleibt, aber die Umgangsformen sich wandeln (Orlikowski 2000). Der bisher dargestellte Forschungsstand zur Komplexität von Software folgt diesem Modell: Die Komplexität von Software wird als Folge der Übersetzungen zwischen sozialen Phänomenen und codierten Arbeitsanweisungen für die Hardware behandelt (1. Dimension). Im Rahmen der Modellierungsprozesse, in denen diese Übersetzungen stattfinden, versuchen die beteiligten Akteur*innen, Unsicherheiten des Sozialen zu kontrollieren, indem sie die Eigenschaften der Modelle aushandeln. Im Modell ist nur sichtbar, wofür die Akteur*innen sich in den Aushandlungen entschieden haben, also zum Beispiel, dass das Modell einer Patient*in in einer Krankenhaussoftware die Eigenschaften Geschlecht, Alter und Symptome haben soll. Sichtbar wird weder, wogegen entschieden wurde, noch wer dies mit welchen Argumenten durchgesetzt hat. Am Beispiel: Das Modell der Patient*in zeigt nicht, dass es den Vorschlag gab, die Ernährungsgewohnheiten in der Software zu berücksichtigen, dass dieser aber nach intensiver Debatte durch ein Veto der Projektleiter*in abgelehnt wurde. Es zeigt auch nicht, dass diese Ablehnung damit begründet wurde, dass die zusätzliche Eigenschaft im Patient*innenmodell die Benutzer*innenoberfläche unnötig unübersichtlich machen würde. Indem die Akteur*innen solche Modell einfach nutzen, akzeptieren sie auch die Entscheidungen, die hinter den Modellen liegen, und geben damit Kontrolle über die Unsicherheiten ab, die in dem Modell reduziert sind. Sie verschieben damit implizit die Kontrolle, die sie auch selbst ausüben könnten, in frühere Prozesse. Sobald die Modelle jedoch in Frage gestellt werden, erscheinen die Unsicherheiten erneut. Am Beispiel: Entscheiden die Entwickler*innen des Diagnosemoduls der Krankenhaussoftware, dass Daten zu den Ernährungsgewohnheiten der Patient*innen unabdingbar sind, wenn das Modul seinen Zweck erfüllen soll, lehnen sie die Modellentscheidungen ihrer Vorgänger*innen ab und bringen die Unsicherheit wieder hervor, die in der Modellierung von Patient*innen steckt. Wenn es ihnen gelingt, im Projekt die gewünschte Änderung des Patient*innenmodells durchzusetzen, so verschieben sie die Kontrolle aus dem Prozess der Patient*innenmodellierung in den Prozess der Entwicklung des Diagnosemoduls. Bei der Softwareentwicklung werden so aufeinander aufbauende Modelle gestaltet, übernommen, geprüft und verändert. Insgesamt wird damit Kontrolle über die Unsicherheiten des Sozialen zwischen den einzelnen sozialen Prozessen hin- und hergeschoben (2. Dimension). Da Software nicht beliebig genutzt werden kann, haben die vielen Entscheidungen während der Softwareentwicklung Auswirkungen auf die Nutzung. Solange Nutzer*innen die Modelle, auf denen die Software beruht, nicht in Frage stellen, wird über die Modellentscheidungen somit auch Kontrolle über Unsicherheiten ausgeübt, die bei der Nutzung auftreten. Entwicklungsprozesse schaffen so die Grundlage für eine Performativität der Software, die sich in Nutzungsprozessen entfaltet.

Wie in Abschnitt 2.1.3 dargestellt sind jedoch auch die Entwicklungsprozesse von Software beeinflusst. Software wird nicht nur langfristig weiterentwickelt, sondern kann auch als Komponente in andere Software eingebaut werden. Die komplexen Zusammenhänge zwischen sozialem Phänomen und Code, die in dieser Arbeit als die erste und zweite Dimension der Komplexität von Software bezeichnet werden, gewinnt dabei eine neue Qualität. Über den Code bestehender Versionen oder wiederverwendeter Softwareelemente werden Rück- und Querverbindungen zwischen Entwicklungs- und Nutzungsprozessen in ganz unterschiedlichen Kontexten vermittelt. Um solche Rück- und Querverbindungen und die dadurch gesteigerte Komplexität von Software geht es in den Arbeiten, die ich im Folgenden zum Abschluss meines Literaturüberblicks vorstelle.

2.2.3.1 Strategische Komplexitätssteigerung bei Online-Plattformen

In der Soziologie erregen Online-Plattformen seit einigen Jahren besondere Aufmerksamkeit. Online-Plattformen sind ein idealtypisches Anwendungsgebiet für agile Softwareentwicklung, bei der die Anbieter*innen permanente Weiterentwicklung nutzen, um Informationen über das soziale Phänomen zu generieren, das durch Software gesteuert werden soll. Anbieter*innen von Online-Plattformen führen zum Beispiel sogenannte A/B-Tests durch. Bei diesen bieten sie ihren Besucher*innen zufällig eine von zwei Websiteversionen mit unterschiedlichen Layoutversionen an, prüfen, welche der Besucher*innengruppen mehr Umsatz generiert, und verändern dann die Plattform entsprechend der Testergebnisse. In der Wirtschaftssoziologie werden die Anbieter*innen von Online-Plattformen als Marktorganisator*innen betrachtet. Sie setzen statt formaler Organisationsregeln Software ein, um über die klassischen Organisationsgrenzen hinweg Verhaltenskontrolle auszuüben und Nutzer*innen so in Quasi-Mitglieder der Organisation zu verwandeln (Kirchner und Schüßler 2019). In einer Studie über die Entwicklung einer Fitness-Online-Plattform untersucht Tilo Grenz (2014) Wechselwirkungen, die bei der Softwareevolution zwischen Entwicklungsprozess und Nutzungsprozess entstehen. Dabei zeigt er, dass Anbieter*innen von Online-Plattformen strategisch Kontrolle über einige Aspekte des sozialen Phänomens aus den internen Modellierungsprozessen in die Nutzungsprozesse auslagern, um mit Hilfe der Software andere Aspekte, die für die Ziele des Unternehmens bedeutsamer sind, kontrollieren zu können.

Für die Arbeit untersucht Grenz die Entwicklung einer Fitness-Online-Plattform, die im Auftrag eines Unternehmens entwickelt wird, das eine Kette von Fitnessstudios betreibt. Die Plattform soll Kund*innen an die Studios binden, indem sie sie beim individualisierten Training unterstützt. Zu diesem Zweck eröffnet die Plattform den Kund*innen die Möglichkeit, aus verschiedenen aktuellen Fitnesstrends einen auszuwählen und ihren persönlichen Trainingsplan entsprechend des ausgewählten Trends zu organisieren (Grenz 2014). Statt wie im üblichen Geschäftsmodell von Fitnessstudios Informationen über Trends, Vorlieben und Trainingsfortschritte durch eigenes Personal im Rahmen von formal geregelten Organisationsprozessen zu erheben und an die Kund*innen weiterzugeben (a.a.O., S. 24), lässt die Organisation eine Online-Plattform entwickeln. Auf dieser können Trainingspläne, die von internen und externen Expert*innen und von Nutzer*innen selbst erstellt worden sind, eingesehen, diskutiert, geordnet und abgerufen werden (a.a.O., S. 25). Der Umgang mit der Plattform wird anhand von direktem Feedback von Nutzer*innen und mit Hilfe von Datenspuren analysiert. Für diese Analyse müssen die Mitglieder des Teams, das die Online-Plattform weiterentwickelt, die Datenspuren interpretieren. Ziel dieser Interpretationen ist es, Anhaltspunkte für neu zu entwickelnde Funktionen zu finden, die geeignet scheinen, die zukünftige Nutzung im Sinne der betrieblichen Interessen zu steuern (a.a.O., S. 39). Die Interpretation der Daten aus dem Nutzungsprozess und die Ableitung von Funktionen sind dabei ebenso Gegenstand mikropolitischer Auseinandersetzungen innerhalb der Organisation wie die Frage, welche Nutzer*innengruppen das Unternehmen mit der Online-Plattform eigentlich genau ansprechen will (a.a.O., S. 31). Durch die dauerhafte Einbindung der Nutzungsprozesse steigt mit der Zeit die Komplexität der Softwareevolution, auch, weil dadurch immer weitere externe Technologien (z. B. Tracking-Apps für Smartphones) an die Online-Plattform angebunden werden (a.a.O., S. 32), deren Funktionen immer neue Umgangsformen erzeugen. Die Möglichkeit, permanent Daten über den Nutzungsprozess in die Weiterentwicklung einzuspeisen, wird im Unternehmen „als permanenter Anpassungsdruck wahrgenommen“ (a.a.O., S. 42): Die Daten scheinen den Weg zu immer weiteren Verbesserungen der Plattform aufzuzeigen. Solche vermeintlichen Verbesserungen nicht umzusetzen und die Online-Plattform dauerhaft in einem festen Zustand zu belassen käme einer Verweigerung von Innovation gleich. Der Innovationsimperativ (oder zumindest der hohe Stellenwert von Innovationen) in unserer Gesellschaft (Hutter et al. 2011) ist für das Fitnessunternehmen schwer zu ignorieren.

Insgesamt zeigen sich Online-Plattformen in der Untersuchung von Grenz damit nicht als funktionales Äquivalent zu formalen Organisationsregeln, sondern als zentrales Element eines durch digitale Technik geprägten Fitnessangebots, das durch die Wechselwirkungen zwischen Entwicklungs- und Nutzungsprozessen permanent an Komplexität gewinnt. Durch die Weiterentwicklung wird diese Komplexitätssteigerung vorangetrieben. Sie bietet aber aus Sicht des Unternehmens, das die Online-Plattform anbietet, die besten Chancen, Kontrolle über soziale Phänomene wie die Trainingsvorlieben der Kund*innen auszuüben, die größtenteils unbekannt sind und sich (auch durch die Weiterentwicklung selbst) ständig verändern.

2.2.3.2 Kontrollierte Komplexitätssteigerung bei standardisierter Organisationssoftware

Im Fall der Online-Plattformen ist relativ offensichtlich, dass die Komplexität der Software durch die wiederholte Einbindung der Nutzungsprozesse in die Entwicklungsprozesse permanent steigt. Der gleiche Effekt kann auch bei traditionelleren Formen von Software beobachtet werden. Dass auch andere Software permanent weiterentwickelt wird und dadurch ständig an Komplexität gewinnt, wird der soziologischen Forschung selten beachtet. Eine Ausnahme stellen Studien dar, die an das Forschungsprogramm zur Biographie von Artefakten anschließen. Im Zentrum dieses Programms steht die Frage, wie Forschende die Einflüsse untersuchen können, die im Laufe der langfristigen Entwicklung und Weiterentwicklung auf eine Technik (wie Software) und den Umgang mit ihr einwirken. Diese Einflüsse stammen aus den unterschiedlichen sozialen Kontexten, in denen das Artefakt, dessen Biographie untersucht wird, im Laufe der Zeit entsteht und verändert wird. Grundlage des Ansatzes sind eine Reihe von Studien zur Entwicklung und Weiterentwicklung standardisierter Organisationssoftware, die vor allem von Neil Pollock und Robin Williams durchgeführt worden sind (Pollock und Williams 2009; Williams und Pollock 2012; Pollock et al. 2007; Pollock und Cornford 2004). Die Studien zeigen, wie sich ein Softwareprodukt über Jahrzehnte hinweg entwickelt und weltweit und über verschiedenste Branchen hinweg verbreitet. Einerseits orientiert sich das Unternehmen, das die Software herstellt, bei der Entwicklung (Meissner 1997) und Weiterentwicklung (Pollock et al. 2007) an den Anforderungen von den Repräsentant*innen konkreter Kund*innenorganisationen. Andererseits werden diese Anforderungen von Anfang an mit Blick auf die strategischen Interessen der Organisation ausgewählt, die für die Entwicklung der Software verantwortlich zeichnet, und so interpretiert, wie es diesen Interessen entspricht: Die Software soll an möglichst viele unterschiedliche Organisationen vermarktet werden; dafür müssen die Funktionen sowohl hochgradig generisch sein als auch sich an die im Detail hochgradig unterschiedlichen sozialen Phänomene anpassen lassen. Eine Funktion zum Erstellen von Rechnungen soll zum Beispiel in möglichst vielen Unternehmen genutzt werden können und die Rechnungen sollen gleichzeitig in jedem Unternehmen in einem Format erzeugt werden, das den spezifischen Vorgaben des Unternehmens möglichst genau entspricht. Dieser scheinbare Widerspruch wird durch die technische Struktur teilweise gelöst. In dieser Struktur werden bestimmte Eigenschaften der Software als generischer Kern festgehalten und durch Prozessvorlagen, sogenannte Templates, ergänzt, aus welchen Kund*innen lokal die Varianten auswählen können, die ihren spezifischen Anforderungen am ehesten entsprechen (Pollock et al. 2007).

Der generische Kern wird von Softwareunternehmen strategisch geschützt (Pollock und Williams 2009), zum Beispiel indem ihre Mitarbeiter*innen bei der Weiterentwicklung bereits möglichst früh im Modellierungsprozess darauf achten, dass die Modelle für neue Funktionen kompatibel mit den Modellen der bestehenden Software sind. Besondere Anstrengungen in dieser Hinsicht werden bei der Neuentwicklung von Branchenvarianten unternommen: Hier sind die Hersteller*innen darauf angewiesen, entweder Repräsentant*innen von Pilotorganisationen in die internen Entwicklungsprojekte einzubeziehen (Pollock et al. 2007) oder Modelle, die im Rahmen des Customizing in einzelnen Organisationen entstanden sind, in den generischen Kern zu übernehmen, um Prozessvorlagen in der Software als „best practices“ bewerben zu können (Locke und Lowe 2007; Wagner et al. 2006). Die Komplexität der Software steigert sich mit der Zeit, weil die Modelle, auf denen die hinzugefügten Elemente aufgebaut sind, von den konkreten sozialen und technischen Bedingungen in den Pilotorganisationen abhängen. Diese Bedingungen beeinflussen sowohl die Auswahl der zugelassenen Repräsentant*innen als auch deren Beiträge zur Modellierung des sozialen Phänomens.⁵⁵

Mitarbeiter*innen des Softwareunternehmens versuchen die Kontrolle über diese Komplexität in der eigenen Organisation zu halten. Dazu entscheiden sie im Modellierungsprozess mit Blick auf die von ihrem Unternehmen vorgegebenen Projektziele, wessen Anforderungen an neue Funktionen wie berücksichtigt werden oder welche in anderen Organisationen entstandenen Erweiterungen in den generischen Kern aufgenommen werden (Pollock et al. 2007). Gelingt es den Mitarbeiter*innen, hinter der Anforderung einer Repräsentant*in, die eine eigene Funktion für die an ihrer Universität übliche Form der Benotung einfordert, ein allgemeineres Problem zu entdecken, das von den Repräsentant*innen anderer Organisationen als solches bestätigt wird, wird die Anforderung aufgenommen. Scheint das Problem auf eine Organisation beschränkt, wird die Anforderung abgelehnt (a.a.O. 264–266).

Auf das, was bei der regulären Weiterentwicklung geschieht, die außerhalb der initialen Modellierung neuer Branchenvarianten stattfindet, passt die Idee einer primär am Nutzungsprozess orientierten Modellierung dann überhaupt nicht mehr: In dieser Phase lehnt das Softwareunternehmens die meisten Anfragen von einzelnen Kund*innenorganisationen ab und begründen die Ablehnung damit, dass die Anforderungen zu spezifisch seien. Während des Projekts, bei dem das Branchenmodul entwickelt wurde, bemühte sich eine Mitarbeiter*in des Softwareunternehmens darum, das generische Problem hinter der spezifischen Anforderung zu identifizieren. Bei der Weiterentwicklung müssen die Kund*innenorganisationen sich nun allein um diese Aufgabe kümmern, wenn sie wollen, dass ihre Anforderungen in der Software berücksichtigt werden. Das Softwareunternehmen organisiert Communities, in denen Repräsentant*innen der Kund*innenorganisationen sich austauschen und andere finden können, die ihren Wunsch nach einer bestimmten Anforderung unterstützen (a.a.O., S. 267). In den Communities identifizieren die Repräsentant*innen gemeinsam das allgemeine Problem hinter ihren spezifischen Anforderungen und übernehmen damit die Aufgabe, die vorher eine Mitarbeiter*in des Softwareunternehmens erfüllt hat: Sie formulieren ihre Wünsche so aus, dass sichtbar wird, dass deren Erfüllung den Zielen des Softwareunternehmens dient.

Bei der Betrachtung des Konzepts der Biographie von Artefakten zeigt sich, dass über die Weiterentwicklung mit der Zeit immer neue Prozesse zu dem Geflecht aus Prozessen hinzukommen, in welchem ausgehandelt wird, wie Software und der Umgang mit ihr genau aussehen sollen. In jeder dieser Aushandlungen versuchen die Akteur*innen, Unsicherheiten des Sozialen durch Entscheidungen zu reduzieren. In der eben vorgestellten Studie geschieht dies zum Beispiel, indem sie die spezifischen Prozesse zur Benotung von Studierenden, die an jeder Universität anders sind, auf zwei verschiedene generische Prozessvorlagen reduzieren, aus denen spätere Nutzer*innen dann eine auswählen müssen, wenn sie die Software nutzen wollen, um Noten zu speichern. Bei jedem dieser Reduktionsversuche entstehen jedoch auch immer neue Unsicherheiten, zum Beispiel durch die Auswahl der an der Aushandlung Beteiligten, die zukünftige Nutzer*innen repräsentieren sollen, ohne deren Anforderungen genau kennen zu können. Anders als bei Online-Plattformen versuchen Softwareunternehmen in diesen Fällen jedoch die Komplexität der Software durch gezielte Kontrolle auch des Codes zu steuern (Pollock et al. 2007). Robert Schmidt zeigt in seiner Arbeit zu den Ursachen der Software-Alterung (Schmidt 2012), dass die Kontrolle auch dadurch begrenzt ist, dass die Biographie der Software im Code präsent bleibt, wodurch die Software bei der Weiterentwicklung performativ wird:

„Because [the code, DA] acts not only as a passive, but also as a (re)active operative entity, the continuing modification of the software continually creates situations in which pieces of the code perform erstwhile tasks and organizational conditions in a modified context.“ (a.a.O., S. 206).

Die Praxis der Programmierung bringt es mit sich, dass der Zusammenhang zwischen den bei der Modellierung intendierten und den vom Code tatsächlich verursachten Funktionen mit der Zeit immer undurchschaubarer wird.

2.2.3.3 Auslagerung von Komplexität aus dem sozialen Phänomen in Standardisierungsprozesse

Die Kontrolle, die Hersteller*innen von Standardsoftware über die Modellierungsprozesse ausüben, kann als Versuch interpretiert werden, die Komplexität von Nutzungsprozessen im Voraus so zu begrenzen, dass die Funktionen ihrer Produkte auf Dauer als hilfreiche Unterstützung der Nutzung wahrgenommen werden. Standards der Datenverarbeitung setzen mit der Komplexitätsreduktion früher an. Sie sind das Ergebnis von Versuchen, für ein ganzes Bündel an sozialen Phänomenen festzuschreiben, welche Aspekte der Unsicherheit in den Modellierungsprozessen der Softwareentwicklung berücksichtigt werden sollen. Standards sind, einmal etabliert, schwer zu verändern und berühren per definitionem eine große Zahl an sozialen Phänomenen. Im Detail gibt es oft sehr unterschiedliche Ansichten darüber, wie unterschiedliche Aspekte dieser sozialen Phänomene zu interpretieren sind, welche der Aspekte für den Standard zentral und welche nebensächlich sind (Bowker und Star 2000). Zentrale Aspekte müssen bei der Standardisierung einheitlich definiert, nebensächliche können ignoriert werden. Anders gesagt: Wie bei der Softwareentwicklung sind die Akteur*innen auch bei der Standardisierung mit einem hohen Grad an Unsicherheit konfrontiert, der durch Standards reduziert werden soll. In den Aushandlungen, die in Standardisierungsprozessen stattfinden, wird darüber entschieden, wie die standardisierten Phänomene in den Prozessen interpretiert werden sollen, in denen die Standards zum Einsatz kommen. Die Aushandlungen stellen also den Versuch dar, Unsicherheiten der Anwendungsprozesse im Voraus zu kontrollieren. Wegen ihrer weitreichenden Auswirkungen – Standards reduzieren sehr viele Unsicherheiten auf einmal und werden gleichzeitig in sehr vielen Prozessen genutzt – sind Standardisierungsprozesse immer hochgradig politisch: „Whatever appears as universal or indeed standard, is the result of negotiations, organizational processes, and conflict“ (Bowker und Star 2000). Ole Hanseth und Eric Monteiro (1997) zeigen dies am Beispiel der Entstehung eines Standards zum elektronischen Austausch von Labordaten in Norwegen. In ihrer Fallstudie machen sie sichtbar, wie viele unterschiedliche Akteur*innengruppen versuchen, Einfluss auf einen Standardisierungsprozess zu nehmen, bei dem die Unsicherheiten eines sozialen Phänomens so reduziert werden sollen, dass sich primär auf Software gestützte Prozesse durchsetzen können. Während der Anstoß für den Standardisierungsprozess noch von den Hersteller*innen von Praxis- und Laborsoftware ausgeht, die in engem Kontakt mit den Nutzer*innen der Nachrichtenformate stehen (a.a.O., S. 192), versuchen große Unternehmen von Beginn an den Standard so zu beeinflussen, dass er möglichst weitgehend mit den Modellen übereinstimmt, die ihren eigenen Softwareprodukten zu Grunde liegen. Diese strategischen Interessen werden im Standardisierungsprozess nicht expliziert, sondern als Ausdruck „objektiver“ Interpretationen des sozialen Phänomens dargestellt:

„As there was a general consensus […] about the need for standards, the fight about what these standards should look like and how they should be developed started. This race was a seemingly neutral and technical discussion about which technology fitted the needs best. In reality, however, it was a race between different actors trying to manoeuvre themselves into key positions [...]“ (Hanseth und Monteiro 1997, S. 192).

Dabei wird schnell überlegt, an welche bereits existierenden internationalen Standards für medizinischen Datenaustausch der neue angeschlossen werden soll. Diese werden in Arbeitsgruppen internationaler Standardisierungsorganisationen wie der ISO entwickelt, in denen Repräsentant*innen von Unternehmen und Regierungen neue Standards ausarbeiten. Die einflussreichen Akteur*innen in diesen Arbeitsgruppen sind vor allem an der Erweiterung bestehender Standards interessiert, da ein neuer technischer Standard nicht nur aus Modellen für die Verarbeitung von Information besteht, sondern von Software umgesetzt und eingebunden werden muss, um wirksam zu werden (a.a.O., S. 196). Die Existenz dieser technischen Infrastruktur erzeugt nicht nur strategische Interessen bei den Hersteller*innen, den neuen Standard möglichst im Einklang mit ihren bestehenden Produkten zu formen, sondern auch hohe Eintrittsbarrieren für Akteur*innen, die sich nur mit dem ursprünglichen Handlungsproblem, nicht aber mit Standardisierung auskennen. „To be involved in the standardization work, one needs to know all the rules of the game […] in order to make lab standards, one also has to be familiar with standards in virtually all other sectors as well.“ (a.a.O., S. 196).

Über den Standard zum Austausch von Labordaten entscheiden am Ende Standardisierungsbürokrat*innen, die sich für die praktischen Probleme, die mit Hilfe des elektronischen Datenaustauschs gelöst werden sollen, weniger interessieren als für die Konsistenz des neuen Datenformats mit bestehenden Standards. Der Standard, der in der Fallstudie letztendlich ausgehandelt wird, ist kompliziert, löst viele der Probleme nicht, die Nutzer*innen in der Praxis haben und ist schwer in die vorhandenen Arbeitsabläufe einzubinden (a.a.O., S. 197). Dennoch können sich weder Nutzer*innen noch Softwarehersteller*innen dem Standard verweigern, ohne selbst eine Alternative zu konstruieren, die ihrerseits von einer großen Gruppe einflussreicher Akteur*innen unterstützt würde (a.a.O., S. 207).

Standards liegen nicht nur dem Code zu Grunde, sondern auch Programmiersprachen und –paradigmen, Vorgehensmodellen und den Programmen, die im Rahmen des Entwicklungsprozesses genutzt werden (Schulz-Schaeffer und Bottel 2018). Die hohe Standardisierung ist Voraussetzung und Folge der hohen internationalen Kooperation, die für die heutige Softwareentwicklung kennzeichnend ist (a.a.O.). Da Standards der Datenverarbeitung die Komplexität der Softwareentwicklung verringern sollen, werden die komplexen Prozesse, die zu ihrer Entstehung führen, bei ihrem Einsatz gezielt ausgeblendet.

2.2.3.4 Softwaresysteme als Infrastrukturen

Die Wiederverwendung von Softwarekomponenten ist die in der Softwareentwicklung bedeutendste Form, die Komplexität im Entwicklungsprozess zu reduzieren. Doch in der Soziologie ist Wiederverwendung bisher praktisch nicht untersucht worden. Bei der Wiederverwendung werden Teile der Komplexität des sozialen Phänomens aus dem Softwareentwicklungsprozess ausgelagert, indem sie, ähnlich wie bei der Standardisierung, in andere Prozesse verschoben werden. Diese Strategie hat Folgen auch für Endnutzer*innen, zum Beispiel weil unsichtbare Abhängigkeiten zwischen den Prozessen der Softwareentwicklung (und damit auch der späteren Nutzung dieser Software) entstehen, in denen wiederverwendete Software eingesetzt wird, und denen, in denen sie entwickelt wird. Solche Folgen werden teilweise in der Forschung zu digitalen Informationsinfrastrukturen betrachtet. Grundlage dieses Forschungsfelds ist die Arbeit von Bowker und Star zur Entstehung von Kategorien und deren Bedeutung als Informationsinfrastrukturen, die Gesellschaft strukturieren (Bowker und Star 2000). Infrastrukturen werden in dieser Forschung als relationales Konzept genutzt, um Artefakte und den Umgang mit ihnen gemeinsam zu untersuchen (Star und Ruhleder 1996). Als Informationsinfrastrukturen (IIs) werden dabei sowohl die technischen Systeme verstanden, die aus (im hier vorgestellten Sinn) komplexer Software bestehen, als auch die Umgangsformen, die sich mit diesen Systemen in verschiedenen Nutzungsprozessen entwickeln. Mit dem Begriff der Informationsinfrastruktur versuchen Forscher*innen, alle Aspekte zu berücksichtigen, die für die Komplexität des Gegenstands relevant sein könnten, ohne die Verhältnisse, in denen diese Aspekte zu einander stehen, über die Definition festzulegen:

„IIs are characterised by openness to number and types of users (no fixed notion of “user”), interconnections of numerous modules/systems (i.e. multiplicity of purposes, agendas, strategies), dynamically evolving portfolios of (an ecosystem of) systems and shaped by an installed base of existing systems and practices (thus restricting the scope of design, as traditionally conceived). IIs are also typically stretched across space and time: they are shaped and used across many different locales and endure over long periods (decades rather than years)“ (Monteiro et al. 2013, S. 576)

Eine solche übergreifende Definition ist für die Operationalisierung und den Vergleich verschiedener Forschungsergebnisse wenig hilfreich, was innerhalb des Forschungsfeldes auch kritisiert wird (Lee und Schmidt 2018). Dennoch sind in diesem Forschungsfeld in den letzten Jahren eine Vielzahl an empirischen Studien entstanden, die jeweils mit sehr unterschiedlichen Definitionen des Begriffs der Infrastruktur arbeiten (Pipek et al. 2017; Lee und Schmidt 2018; Monteiro et al. 2014). In all diesen Arbeiten wird aber betont, dass Software, Akteur*innen, welche egal in welcher Rolle mit ihr umgehen, und die sozialen Prozesse, in denen dieser Umgang stattfindet, sich gegenseitig beeinflussen und nur verstanden werden können, wenn die Wechselwirkungen zwischen ihnen berücksichtigt werden (Karasti et al. 2018, 270 f.).

Für die in der vorliegenden Arbeit entwickelte soziologische Perspektive auf Software ist die Forschung zu Informationsinfrastrukturen vor allem deswegen relevant, weil in ihr thematisiert wird, dass Modellierungsprozesse bei der Entwicklung einer Software auch von den Ergebnissen der Modellierungsprozesse anderer Software beeinflusst werden:

„Infrastructures are not designed from scratch – they are normally designed by modifying and extending what already exists. So the infrastructure as it currently is – the installed base – wield a strong influence on what it may become in the future.“ (Monteiro et al. 2013, S. 597)

Das komplexe Geflecht an sozialen Prozessen, in dem sich die Kontrolle des Umgangs mit Software verteilt, umfasst mit dieser Perspektive alle Prozesse, die jemals einen Beitrag zur Modellierung irgendeiner ihrer Komponenten geleistet haben.

2.2.4 Fazit: Fragmentierte Soziologie der Software

Durch die Aufarbeitung des Forschungsstands wurde gezeigt, dass viele der in Abschnitt 2.1 aufgeworfenen Fragen zur Soziologie der Software bereits in der soziologischen Forschungsarbeiten thematisiert worden sind. Dabei ist aber auch sichtbar geworden, dass kaum Forschung existiert, in der mehrere Dimensionen der Komplexität von Software gleichzeitig berücksichtigt werden. Die Komplexität von Software entsteht jedoch vor allem durch die Wechselwirkungen zwischen den drei vorgestellten Dimensionen: Um die Aufgabe, soziale Phänomene in durch Computer ausführbaren Code zu übersetzen, zu erfüllen, müssen so viele Unsicherheiten reduziert werden, dass Akteur*innen sich gezwungen sehen, diese Reduktionen auf verschiedene Modellierungsprozesse zu verteilen. In den einzelnen Prozessen und durch die Abhängigkeiten zwischen ihnen entstehen jedoch neue Unsicherheiten. Diese versuchen die Akteur*innen zu kontrollieren, indem sie bestehende Software wiederverwenden. Dadurch entstehen neue Abhängigkeiten, neue Akteur*innen, soziale Prozesse und Unsicherheiten kommen hinzu und so weiter. Die soziologischen Arbeiten, in denen solche Bezüge zwischen den Dimensionen angesprochen werden, eignen sich kaum als Vorlage für weitergehende Forschung zum Thema. Die Arbeiten von Kallinikos (2009) und Orlikowski (1992) bleiben in entscheidenden Punkten abstrakt, was es schwierig macht, mit neuen Arbeiten an ihre Konzepte anzuschließen. Bei Arbeiten wie der von Ortmann et al. (1990) geht es nur nebenbei um Software. Die Komplexität von Software wird zwar erwähnt, aber nicht in die primär organisationssoziologischen Konzepte integriert, die im Fokus der Studien stehen. Die techniksoziologischen Untersuchungen von Rammert et al. (1998) befassen sich im Gegensatz dazu beinahe ausschließlich mit Software. Sie sind aber so eng auf einen speziellen Gegenstand zugeschnitten, dass sie nicht auf andere Formen von Software verallgemeinert werden können. Insgesamt zeigt sich beim Blick auf den Forschungsstand, dass viele Erkenntnisse, die für eine Soziologie der Software notwendig sind, bereits vorliegen, aber nicht miteinander verbunden sind. Im folgenden Abschnitt schlage ich eine Möglichkeit vor, wie sich diese Elemente verbinden lassen. Dazu identifiziere ich zwei Perspektiven auf Software, welche sich in der soziologischen Forschung zu den verschiedenen Ebenen der Komplexität finden, und setze sie miteinander in Beziehung. Aus der einen Perspektive wird Software als Mittel betrachtet, über das Akteur*innen versuchen, Kontrolle auszuüben. Aus der anderen Perspektive wird Software als Resultat solcher Kontrollversuche betrachtet. Ich zeige, wie diese beiden Perspektiven verbunden werden können, und lege so die Grundlage für die Entwicklung eines Forschungsrahmens, der zur Untersuchung der Performativität von Software im Sozialen eingesetzt werden kann. Dieser Forschungsrahmen wird in Kapitel 3 entwickelt.

2.3 Unsicherheitsreduktion als Mittel und Resultat von Kontrollversuchen

Die Analyse der Komplexität von Software und der Art und Weise, wie Soziolog*innen sich mit dieser Komplexität auseinandersetzen, zeigt, dass Software in soziologischen Arbeiten in der Regel aus einer von zwei Perspektiven untersucht wird: Sie wird entweder als Mittel oder als Resultat von Versuchen betrachtet, Kontrolle über soziale Prozesse auszuüben. Diese Perspektiven stimmen in etwa mit den zwei Aspekten der Technik überein, welche in dem in der Einleitung von 2.2 vorgestellten Konzept der Dualität von Ressourcen und Routinen identifiziert werden. Beiden Perspektiven liegt zumindest implizit die Annahme zu Grunde, dass Entwicklungs- und Nutzungsprozesse grundsätzlich unterschiedlich sind: Es wird untersucht, wie aus Entwicklungsprozessen über Software Einfluss auf Nutzungsprozesse genommen wird, aber nicht, ob und wie das gleiche zwischen Entwicklungs- oder zwischen Nutzungsprozessen geschieht. Die Arbeiten zur Biographie von Artefakten stellen in dieser Hinsicht eine Ausnahme dar und werden in der soziologischen Forschung zu Software bisher selten aufgegriffen. Weder die Rekursivität des Softwarelebenszyklus noch die Performativität, die Software in allen Prozessen aufweist, in denen mit ihr umgegangen wird, werden in der Soziologie bisher hinreichend berücksichtigt.

Aus der ersten Perspektive wird Software als Mittel betrachtet, mit dem Kontrolle über soziale Prozesse ausgeübt werden soll. Dazu besteht sie aus Modellen, in denen die sozialen Phänomene, die für die zu kontrollierenden Prozesse als bedeutsam gelten, so abgebildet werden, dass sie von einem Computer verarbeitet werden können. Während bei sozialen Phänomenen oft nicht ganz klar ist, wo sie anfangen und wo sie enden, haben diese Modelle klare Grenzen; wo die Eigenschaften sozialer Phänomene interpretationsbedürftig sind, sind Modelleigenschaften eindeutig; im Sozialen können spontan ganz neue Handlungsweisen entstehen, aber die Möglichkeiten, Modelle zu transformieren, sind durch die Definitionen in Software festgeschrieben. Am Beispiel: Eine Patient*in mag unsicher sein, ob das Gefühl in ihrem Kopf nur ein Zeichen von Erschöpfung ist oder schon einen Schmerz darstellt, ob der Schmerz nur mehrmals aufgetreten ist oder ob er regelmäßig wiederkehrt und ob sie darauf reagieren möchte, indem sie Medikamente einnimmt, mehr Sport treibt oder in Zukunft auf Laktose (Gluten, Zucker oder rote Lebensmittel) verzichtet. In den Modellen, aus denen Software besteht, gibt es all diese Unsicherheiten nicht: Das Symptom Kopfschmerz ist vorhanden oder es ist nicht vorhanden. Es kann unterschiedliche Ausprägungen haben, wenn diese definiert worden sind. Ist die Häufigkeit des Auftretens als Eigenschaft von Symptomen im Modell vorgesehen, kann diese Information aufgenommen werden. Ist sie nicht vorgesehen, gibt es für die Software keinen Unterschied zwischen einmaligen und regelmäßigen Kopfschmerzen. Auch die möglichen Reaktionen auf dieses Symptom sind im Modell wohldefiniert. Ein Verzicht auf rote Lebensmittel gehört vermutlich nicht dazu. Modelle, die die Unsicherheiten sozialer Phänomene auf eine Reihe an eindeutigen Eigenschaften reduzieren, werden im Rahmen der Softwareentwicklung geschaffen, weil sie die Verarbeitung von Informationen über das Soziale durch Prozessoren ermöglichen sollen. Diese Modelle sind das Ergebnis von Aushandlungen, in denen die relevanten Elemente und Eigenschaften des sozialen Phänomens bestimmt werden und festgelegt wird, wie diese in Software umgesetzt werden sollen. In diesen Aushandlungen wird entschieden, wie Unsicherheiten des Sozialen reduziert werden sollen. Die Zwecke, die durch den Umgang mit der fertigen Software erreicht werden sollen, liefern die Kriterien, nach denen bei der Modellierung entschieden wird. Die Akteur*innen, die an diesen Entscheidungen beteiligt sind, bringen aber auch ihre eigenen Kriterien mit. Am Ende der Aushandlungen steht eine Software, die aus Modellen besteht, die das abbilden, was Nutzer*innen beim Umgang mit Software vorfinden. Übernehmen die Nutzer*innen die Vorgaben aus den Modellen, lösen sie Unsicherheiten, die im Nutzungsprozess bestehen, so auf, wie es bei der Modellierung entschieden wurde: Die Patient*in mit Kopfschmerzen bekommt Schmerzmittel und nicht die Empfehlung, keine roten Lebensmittel mehr zu essen. Über die Modelle wird kontrolliert, was Nutzer*innen in den sozialen Prozessen tun, in denen sie mit Software umgehen. Genauer gesagt: die Modelle stellen einen Kontrollversuch dar, denn die eben beschriebene Kontrolle hat Grenzen. Wenn Software als Mittel zur Kontrolle sozialer Prozesse durch Unsicherheitsreduktion betrachtet wird, so wird diese Kontrolle erstens dadurch begrenzt, dass Software auf Eingaben aus diesen Prozessen angewiesen ist. Diese Eingaben, aus denen die Daten entstehen, die für die Funktionen von Software notwendig sind, werden durch die Modelle zwar strukturiert, sind in ihnen aber niemals vollständig vorgegeben. Was Nutzer*innen eingeben, bleibt also unsicher. Sie wird zweitens dadurch begrenzt, dass die Modellierung sozialer Phänomene für den Computer so aufwändig ist, dass sie nur gelingt, weil jedes komplexe Modell aus einer Vielzahl an einfacheren Modellen besteht und keine Gruppe von Modellierer*innen wissen muss, wie die Modelle im Detail aussehen, die zwischen den von ihnen abgebildeten sozialen Phänomenen und der Maschinensprache liegen, in der diese Abbildungen vom Mikroprozessor bearbeitet werden, und welche Abhängigkeiten genau zwischen ihnen bestehen. Durch diese Komplexität, die bei der Modellierung für den Computer unvermeidlich ist, entzieht sich Software dem vollständigen Verständnis (und damit auch der Kontrolle) aller Beteiligten (Kallinikos 2009). Auch die Basis, auf der die Modellierung ruht, bleibt also unsicher.

Aus der zweiten Perspektive wird Software als Resultat von Kontrollversuchen betrachtet, die von sozialen Prozessen ausgehen und sich auf andere soziale Prozesse richten. Aus dieser Perspektive stehen soziale Prozesse als das Mittel, mit dem Unsicherheit reduziert wird, im Fokus. Prozesse der Softwareentwicklung und –einführung werden als aufeinander aufbauende Modellierungsprozesse betrachtet, deren Ziel die Produktion von Modellen sozialer Phänomene ist, die möglichst frei von Unsicherheit sind. Bei der Softwareentwicklung werden dabei primär Modelle produziert, die in Softwarecode überführt werden sollen. Bei der Softwareeinführung werden primär Modelle geschaffen, die die Form von formalen und informellen Regeln für den Umgang mit Software annehmen. Das Customizing bildet eine Mischform, denn dabei können beide Arten von Modellen entstehen (Mormann 2016; Pollock und Cornford 2004). Nachdem die Akteur*innen bei der Entwicklung und Einführung (und eventuell beim Customizing) eine Vielzahl an Entscheidungen über Modelle getroffen und damit Unsicherheiten kontrolliert haben, die beim Umgang mit Software auftreten können, sind bei der Nutzung scheinbar nur noch wenige Unsicherheiten übrig. Durch die Entscheidung, im Prozess auf Modelle zurückzugreifen, sind bestimmte Interpretations- und Handlungsspielräume der Akteur*innen von vorneherein begrenzt. Prinzipiell können Einzelheiten der in den Modellen vorgenommenen Reduktionen zwar jederzeit hinterfragt oder abgelehnt werden. Faktisch betrifft solche Kritik jedoch immer die Modelle als Ganzes und richtet sich damit auch an die Beteiligten der Prozesse, in denen sie entstanden sind und in denen über ihre Nutzung entschieden wurde. Statt sich nur mit den Einzelheiten der Nutzung auseinanderzusetzen, müssen Akteur*innen, die sich an diesen Einzelheiten stören, deutlich weitergehen und Kritik an Prozessen üben, an denen sie oft nicht beteiligt waren, deren Beteiligte ihnen möglicherweise nicht nahestehen, ihnen hierarchisch übergeordnet oder einfach unbekannt sind. Solche Kritik hat also potentiell deutlich weiter reichende Folgen, die für die Kritisierenden schwer bis gar nicht zu überblicken sind. Durch die Ablehnung von Modellen entstehen also neue Unsicherheiten, die es nicht gäbe, wenn von vorneherein auf den Einsatz von Modellen verzichtet worden wäre. Die Grenzen der möglichen Kontrolle liegen aus dieser Perspektive erstens in den Interpretations- und Handlungsspielräumen, die Akteur*innen trotz der Einflüsse haben, die verschiedene Modelle auf die Nutzung ausüben (und die eben auch dazu führen können, dass grundsätzliche Kritik geübt wird). Sie liegen zweitens darin, dass die sozialen Prozesse, in denen es eigentlich darum geht, Kontrolle auszuüben, sich gegenseitig beeinflussen und auch davon abhängig sind, was in den sozialen Prozessen geschieht, über die eigentlich Kontrolle ausgeübt werden soll. Zwischen unterschiedlichen Modellierungsprozesse bestehen Abhängigkeiten, weil die Modelle, die in ihnen produziert werden, aufeinander aufbauen und weil die Kontrolle, die durch Modellierung ausgeübt werden kann, immer nur vorläufig ist: Entscheidungen, mit denen in einem der Prozesse Unsicherheiten kontrolliert werden, können jederzeit durch Entscheidungen in einem der anderen Prozesse in Frage gestellt werden, mit Auswirkungen auf das Modell, welches bereits als fertig galt. Modellierungsprozesse sind darüber hinaus auch von anderen sozialen Prozessen abhängig, weil sie in soziale Systeme eingebettet sind, in denen über die Bedingungen entschieden wird, unter denen Modellierer*innen ihre Aufgabe erfüllen können. Diese Abhängigkeit führt dazu, dass in Modellierungsprozessen zwar Software entsteht und dass diese Software auch als Resultat von Kontrollversuchen betrachtet werden kann, die von sozialen Prozessen über andere soziale Prozesse ausgeübt werden. Aber: Wo der Ursprung dieser Kontrollversuche liegt, wann und in welchem sozialen Kontext also die Grundlagen für die Entscheidungen gelegt worden sind, mit denen in den Modellen der Software Unsicherheit reduziert wird, kann nicht eindeutig zugeordnet werden. Diese Abhängigkeiten zu anderen sozialen Prozessen werden in den Modellierungsprozessen zum Teil bewusst in Kauf genommen (Grenz 2014) oder strategisch genutzt, um Unsicherheiten in andere Prozesse auszulagern. Zum Teil bleiben sie aber auch unerkannt, weil diejenigen, die Modelle für die Software oder für den Umgang mit Software produzieren nicht hinterfragen, welche Unsicherheitsreduktionen zu den Modellen geführt haben, die sie in ihren eigenen Prozessen einsetzen (Weltz und Ortmann 1992; Ortmann et al. 2000; Wieandt-Ledebur 2014).

In den meisten der hier diskutierten Arbeiten wird prinzipiell von den Grundannahmen ausgegangen, die im Konzept der Dualität von Ressourcen und Routinen ausgearbeitet worden sind. Übertragen auf Software besagen sie, dass Software einerseits als Ressource eingesetzt wird, um etwas zu erreichen, was ohne ihren Einsatz nicht möglich wäre. Dies gelingt, weil sie verlässliche Ereigniszusammenhänge herstellt, die Nutzer*innen nicht verstehen müssen, an die sie aber ihr eigenes Handeln anschließen können. Andererseits kann Software diese Ereigniszusammenhänge nur verlässlich herstellen, wenn sie in Routinen eingebunden ist, die es möglich machen, dass sie auf die vorgesehene Art und Weise funktioniert. Software ist also im Sozialen nicht von sich aus wirksam, sondern nur als Teil von Nutzungsprozessen, welche ihre genaue Funktionsweise beeinflussen. Übertragen in die hier verwendete Begrifflichkeit bedeutet das, dass Software für Nutzer*innen nur zur Ressource werden kann, wenn sie die Unsicherheitsreduktionen, die in ihren Modellen stecken, zumindest zum Teil übernehmen. Es bedeutet auch, dass Nutzer*innen über ihren Umgang mit Software beeinflussen, welche Unsicherheiten entsprechend der Modelle kontrolliert werden und welche Modellentscheidungen und damit Kontrollversuche in Frage gestellt oder abgelehnt werden.

Eine umfassende Soziologie der Software sollte es Forscher*innen erlauben, Software gleichzeitig als Mittel und als Resultat von Kontrollversuchen zu betrachten. Dazu ist muss es möglich sein, Erkenntnisse aus Forschungsarbeiten zu verbinden, die Software nur aus einer der beiden hier vorgestellten Perspektiven betrachten. Keiner der in Abschnitt 2.2 vorgestellten Ansätze nimmt die Komplexität der Software in der Theorie ganz überzeugend auf oder eignet sich alleine dazu, diese in der Empirie systematisch zu untersuchen. Die wenigen Autor*innen, die es versuchen (speziell Orlikowski 1992 und Rammert et al. 1998) berücksichtigen vor allem die dritte Dimension der Komplexität, die sich der für die soziologische Untersuchung von Technik charakteristischen Unterscheidung zwischen Entwicklungs- und Nutzungsprozessen entzieht, nicht oder nur am Rande. Darüber hinaus schenken sie der Bedeutung konkreter Eigenschaften von Software, die ihrer Performativität zu Grunde liegen, zu wenig Aufmerksamkeit. Im folgenden Kapitel entwickle ich daher einen konzeptionellen Rahmen, der diese Lücke schließt. Im Mittelpunkt steht die Wechselbeziehung zwischen Unsicherheit reduzierenden Modellen, die bei der Entwicklung Software als Mittel zur Kontrolle sozialer Prozesse hergestellt werden, und den sozialen Prozessen, in denen Akteur*innen diese Modelle einsetzen, um Kontrolle auszuüben oder sich ihr zu entziehen (Abbildung 2.6). Die Grundannahmen der Dualität, über die die beiden hier vorgestellten Perspektiven zusammengeführt werden können, nehme ich auf, indem ich Software als Expert*innensystem betrachte. Über dieses Konzept lässt sich die Software gleichzeitig als Mittel zur Kontrolle sozialer Prozesse oder als Resultat von Kontrollversuchen aus sozialen Prozessen untersuchen. Wie dies gelingen kann und wie Expert*innensysteme überhaupt genau definiert sind, wird im nächsten Kapitel ausgeführt.

Abbildung 2.6

Die Rolle von Software im Sozialen als Verhältnis von Kontrollversuchen und Unsicherheitsreduktion