Zu Beginn dieser Arbeit habe ich die Frage gestellt, wie der Umgang mit digitaler Technik unsere Gesellschaften verändert. Ich habe konstatiert, dass die Soziologie sich mehr mit dem Verhältnis zwischen dem „Digitalen“ und dem Sozialen befassen muss, wenn sie Neues zur Beantwortung dieser Frage beitragen will. Ich habe mir vorgenommen, einen Beitrag zu dieser Aufgabe zu leisten, indem ich eine soziologische Perspektive skizziere, aus der heraus verständlich wird, wie Software in das Verhältnis von sozialem Handeln und sozialer Ordnung eingebettet ist. Macht und Kontrolle sollten dabei besonders berücksichtigt werden. Diese Perspektive sollte als Grundlage für eine Vorgehensweise dienen, mit der Soziolog*innen den Umgang mit Software soziologisch untersuchen können. Dabei sollte die instrumentelle Sichtweise auf Software, die Akteur*innen bei diesem Umgang oft einnehmen, in der konstruktivistischen Sichtweise auf das Soziale, die häufig von Soziolog*innen vertreten wird und die auch ich vertrete, ausreichend Berücksichtigung finden. Als Begründung für das ganze Unterfangen habe ich mich auf C.W. Mills berufen, der es als Aufgabe von Soziolog*innen gesehen hat, mit ihrer Forschung deutlich zu machen, wie die Schwierigkeiten der Individuen („private troubles“) und die Probleme der Allgemeinheit („public issues“) zusammenhängen (Mills 2000 [1959], S. 8), und den Individuen dadurch ihre Handlungsmöglichkeiten beim Umgang mit diesen Schwierigkeiten und Problemen aufzuzeigen (a.a.O., S. 20). Am Ende der Arbeit steht die Analyse einiger Spiele, in denen eine kleine Gruppe von Mitgliedern eines einzigen Krankenhauses eine spezifisch konfigurierte Software nutzt, um ihre Arbeit zu erledigen und um die Bedingungen zu beeinflussen, unter denen in diesem Krankenhaus zusammengearbeitet wird.

Dass die Erkenntnisse über einen kleinen Ausschnitt der Gesellschaft nicht ausreichen, um die große Frage nach der Veränderung der Gesellschaft zu beantworten, ist offensichtlich; welche Rückschlüsse von der Beobachtung dieses kleinen Ausschnitts auf das generelle Verhältnis von Software und Gesellschaft gezogen werden können, will ich in diesem abschließenden Kapitel herausarbeiten, indem ich die Grundlinien der Arbeit rekapituliere. Mit diesem Rückblick zeige ich, wie die von mir skizzierte Soziologie der Software Schwierigkeiten von Individuen (wie die durch Software beeinflussten Arbeitsbedingungen in der Sanusklinik) und Probleme der Allgemeinheit (wie den Wandel der Gesellschaft durch Digitalisierung) zueinander in Beziehung setzt und wie Soziolog*innen, die den Umgang mit Software aus dieser Perspektive untersuchen, dadurch in die Lage versetzt werden, in ihren Ergebnissen Handlungsmöglichkeiten aufzuzeigen, mit denen Schwierigkeiten und Probleme angegangen werden könnten. Dadurch soll auch deutlich werden, welchen Beitrag Fallstudien wie die, die im vorangegangenen Kapitel vorgestellt worden ist, zu dem großen Unterfangen leisten, an das ich mit meiner Arbeit anknüpfen will: die Entwicklung einer Soziologie der Software, die Neues zur Beantwortung der Frage beiträgt, wie digitale Technik die Gesellschaft verändert.

FormalPara Zur Rolle von Software im Sozialen

Die Rolle digitaler Technik für die Gesellschaft wird in soziologischen Diskursen mit Hilfe unterschiedlicher theoretischer Begriffe verhandelt, deren Beziehung zueinander ungeklärt ist. In dieser Arbeit steht Software im Mittelpunkt. Software bringt Daten und Algorithmen zusammen, setzt sie mit Hardware in Verbindung und steuert so die Funktionen von Computern, Informationssystemen und digitalen Infrastrukturen. Gesellschaftlich wird digitale Technik relevant, weil deren Funktionen beeinflussen, wie Menschen miteinander interagieren. In technik- und organisationssoziologischer Forschung wird gezeigt, dass die Funktionen, die Software auslöst, von sozialen Ordnungsmustern abhängen, die das Geschehen während der Entwicklung der Software strukturieren, und davon, wie die an der Entwicklung Beteiligten mit diesen Mustern sozialer Ordnung konkret umgehen. Aus dieser Forschung geht auch hervor, dass die Funktionen, die bei der Softwareentwicklung definiert worden sind, den Umgang mit Software und die sozialen Ordnungsmuster der Nutzung beeinflussen, ohne sie zu determinieren. Welche Prozesse als Entwicklungs- und welche als Nutzungsprozesse gelten sollen, lässt sich bei Software jedoch schwerer als bei anderen Formen der Technik bestimmen. Die Software Studies zeigen, dass beim Umgang mit Software eine Situation entsteht, in der lokale soziale Ordnungsmuster und die Folgen lokaler Interaktionen auf neue Weise beeinflussen, was anderswo und zu anderen Zeitpunkten getan werden kann und wie sich die Bedingungen dieses Tuns verändern.

Welche sozialen Ordnungsmuster und Formen sozialen Handelns durch Software miteinander in Beziehung gesetzt werden, lässt sich nicht allgemein bestimmen. Die Beziehungen, die durch den Umgang mit Software entstehen, hängen von den spezifischen Bedingungen ab, die bei Entwicklung, Einführung und Nutzung herrschen. Die Rolle von Software im Sozialen entsteht und verändert sich durch die jeweiligen sozialen Kontexte, die sie im Rahmen ihres Lebenszyklus durchläuft. Wer die soziale Dimension der Funktionen von Software verstehen will, muss daher in der Biographie der Software nach den Aushandlungen suchen, in denen sie ihre Ursprünge hat.

Wie soziale Ordnungsmuster und Formen sozialen Handelns über Software miteinander in Beziehung stehen, lässt sich hingegen allgemein bestimmen. Software ist Technik, die gezielt geschaffen wird, um Zwecke zu erfüllen. Insofern ist sie immer ein Instrument, mit dem Kontrolle über soziale Prozesse ausgeübt werden soll. Sie ist an Hardware gebunden, um wirksam werden zu können. Insofern ist sie immer den Bedingungen unterworfen, die Hardware setzt. Diese Bedingungen sind im Abstrakten einfache Grundprinzipien mit im Konkreten komplexen Folgen. Die abstrakten Grundprinzipien sind: Freiheit von Unsicherheit, Diskretheit und Determinismus. Die konkreten Folgen sind: Kontextabhängigkeit der Funktionen, undurchschaubare Zerlegungen der Modelle des Sozialen und rekursive Abhängigkeiten durch Wiederverwendung.

Über Software wird die Funktionslogik der Hardware mit den Funktionswünschen vermittelt, die die Gesellschaft an digitale Technik richtet, und mit den Funktionsbedingungen, die sie für den Umgang mit digitaler Technik einrichtet. Die Vermittlung geschieht über Modelle, die so miteinander verknüpft werden, dass aus den sozialen Phänomenen voller Unsicherheit, die die Vorlagen für die Modellierung liefern, die unsicherheitsfreien mathematischen Formalismen entstehen, die Hardware verarbeiten kann. Dazu sind wiederholte Modellierungsprozesse erforderlich, in denen Unsicherheit immer weiter reduziert wird. Jeder dieser Prozesse ist sozial. Entscheidungen darüber, welche Aspekte der Unsicherheit für das Modell wie reduziert werden sollen, sind in jedem dieser Prozesse nicht nur Ergebnis von, sondern auch Mittel für Kontrollversuche. Wie diese Modellierungsprozesse verlaufen hängt davon ab, in welchem Verhältnis soziale Ordnung und soziales Handeln in diesen Prozessen stehen, ebenso wie von anderen Modellen, die bei der Modellierung als Grundlage genutzt werden und in denen Entscheidungen aus vorangegangenen Prozessen abgelagert sind. Solche fertigen Modelle werden performativ, wenn sie als Grundlage für die Erstellung neuer Modelle genutzt werden: Sie beeinflussen das, was sie beschreiben, so, dass es der Beschreibung ähnlicher wird. Darin gleichen Modellierungsprozesse jenen anderen Prozessen, in denen Software „nur“ genutzt wird: Auch solche Nutzungsprozesse werden durch den Umgang mit Software in einzelnen Aspekten den Modellen ähnlicher, in denen dieser Umgang beschrieben ist.

In welchen Aspekten und in welchem Ausmaß die Prozesse, bei denen mit Software umgegangen wird, sich an ihre in der Software modellierten Vorlagen anpassen, lässt sich weder bei der Softwareentwicklung festlegen noch an der Software ablesen. Es hängt davon ab, wie Akteur*innen Modelle, auf denen die Software beruht, durch soziales Handeln in die sozialen Ordnungsmuster integrieren, durch die der Kontext der Nutzung strukturiert wird. Software wird im Sozialen durch performative Modelle relevant, in deren Unsicherheitsreduktionen sich die verschiedenen Kontrollversuche aus dem Lebenszyklus abgelagert haben.

FormalPara Zur soziologischen Untersuchung von Software

Aus dieser Antwort auf den ersten Teil der Forschungsfrage folgen drei Punkte, die bei der soziologischen Untersuchung von Software beachtet werden müssen:

  1. (1)

    Entwicklung und Nutzung von Software sind soziale und sozial geordnete Prozesse, die prinzipiell zusammengedacht werden müssen, weil sie sich immer gegenseitig beeinflussen: (Vorgestellte und tatsächliche) Nutzung dient der Entwicklung als Vorlage für Modelle, Entwicklung schafft in den Modellen Bedingungen für die Nutzung.

  2. (2)

    Software soll Soziales immer auf irgendeine Weise kontrollieren und diese Kontrollversuche sind niemals notwendigerweise erfolgreich: Das Ziel, Kontrolle über den Umgang mit Software auszuüben, ist Anlass für all die Modellierungen, die Software hervorbringen. Der Gegenstand, auf den sich diese Kontrollversuche richten (also die bei der Entwicklung vorgestellten Nutzungsprozesse) und die Kontexte, in denen sie beim Umgang mit Software sozial bedeutsam werden (also die tatsächlichen Nutzungsprozesse), können sich aber grundlegend unterscheiden. Selbst wenn Software in genau dem Kontext eingesetzt wird, für den sie entwickelt worden ist, bleibt der Umgang mit Software sozial und damit (aus der in dieser Arbeit eingenommenen konstruktivistischen Perspektive) mit Unsicherheiten behaftet.

  3. (3)

    Mit der Entscheidung, eine bestimmte Software zum Gegenstand einer soziologischen Untersuchung zu machen, ist noch nicht festgelegt, welche Modelle und welche Umgangsformen erforscht werden müssen, um die Rolle der Software im Sozialen zu verstehen. Auch die Frage, welche Prozesse als Ursprung der Performativität und welche als performativ beeinflusste betrachtet werden müssen, kann nicht allein durch die Wahl der Software entschieden werden. Diese Entscheidungen lassen sich nur im Hinblick auf konkrete Forschungsinteressen treffen: Jeder Software liegen eine Vielzahl an Modellen zu Grunde, zwischen denen komplexe Abhängigkeiten bestehen. Jedes dieser Modelle ist das Ergebnis von Aushandlungen in miteinander verketteten Prozessen, in denen entschieden wird, wie Unsicherheit durch das Modell reduziert werden soll. Jede dieser Aushandlungen ist von den Bedingungen in den sozialen Systemen beeinflusst, in denen sie stattfindet. Jeder dieser Faktoren kann bedeutsam werden, wenn Akteur*innen in sozialen Systemen mit Software umgehen und dabei einzelne Modelle performativ werden. Insgesamt gibt es zu viele mögliche Antworten auf die Frage, was eine Software ausmacht und welche Folgen der Umgang mit ihr hat, als dass Forscher*innen sie in einzelnen empirischen Studien erschöpfend beantworten könnten.

Auf Basis dieser Grundsätze sind bei der soziologischen Untersuchung von Software unterschiedliche Vorgehensweisen denkbar. Ich habe mich für eine entschieden, die mit dem Konzept der Dualität von Technik von Wanda Orlikowski (1992) vereinbar ist und an bestehende technik- und organisationssoziologische Untersuchungen zu Software anschließt. In der Vorgehensweise, die ich in der vorliegenden Arbeit vorschlage, wird Software als Expert*innensystem im Sinne von Anthony Giddens (2010 [1995]) betrachtet, das auf Modellen basiert, die ebenfalls Expert*innensysteme sind. Diese Modelle sind das Ergebnis von Aushandlungen in sozialen Systemen, in denen die Praktiken und strukturellen Eigenschaften dieser Systeme zum Ausdruck kommen. Für die empirische Arbeit bedeutet die Entscheidung, Software und Modelle als Expert*innensysteme zu beobachten, folgendes: Wenn Akteur*innen mit Software und ihren Modellen umgehen, setzen sie – vielleicht nicht bewusst, aber faktisch – Vertrauen in die sozialen Systeme, aus denen die Expert*innensysteme stammen. Damit geben sie den Kontrollversuchen, die in den Modellen, die beim Umgang mit Software performativ werden, zum Ausdruck kommen, insofern nach, als sie die Unsicherheitsreduktionen akzeptieren, die diese Modelle anbieten. Performative Modelle in Software lassen sich jedoch nicht direkt beobachten, denn die Akteur*innen gehen mit einzelnen Elementen der Software um. Informationen über die sozialen Systeme, die an der Entwicklung der Software beteiligt waren, können genutzt werden, um zu rekonstruieren, welche Modelle die Elemente der Software, die sich bei der Beobachtung als bedeutsam für das Forschungsinteresse erweisen, miteinander verbinden, und welche Kontrollversuche in diesen Modellen zum Ausdruck kommen. Der Umgang mit Software wird als kollektives Handeln in strukturierten und von Machtungleichgewichten geprägten strategischen Spielen betrachtet und mit der strategischen Organisationsanalyse nach Michel Crozier und Erhardt Friedberg (1979) untersucht. Solche Spiele sind kollektive Handlungszusammenhänge, in denen Akteur*innen ein gemeinsames Handlungsproblem bearbeiten, wobei sie mehrfache, divergierende und flexible individuelle Ziele verfolgen. Die Kontrollversuche, die in den Modellen der Software zum Ausdruck kommen, sind insofern nur Teil eines ohnedies von Kontrollversuchen geprägten sozialen Kontextes, mit dem Akteur*innen strategisch umzugehen wissen. Für die empirische Arbeit bedeutet diese Entscheidung für die strategische Organisationsanalyse, dass der beobachtete Umgang mit Software als Ergebnis individueller, von den Ordnungen der Handlungsfelder geprägter Strategien betrachtet wird, in denen Akteur*innen versuchen, ihre Handlungsspielräume zu bewahren oder auszudehnen. Inwieweit sie darin erfolgreich sind, hängt von ihrer Machtposition im Feld und somit davon ab, wie gut es ihnen gelingt, für die Spiele relevante Ungewissheiten zu kontrollieren. Dabei haben sie nicht nur die Möglichkeit, sich den Kontrollversuchen, die in den Modellen der Software zum Ausdruck kommen, vollständig zu unterwerfen oder zu verweigern. Sie können sich vor allem auch partiell so auf sie einlassen, so dass die Software ihnen als Ressource zum Erreichen ihrer Ziele und zur Verbesserung ihrer Position im Handlungsfeld dient.

FormalPara Zur Fallstudie

Die Fallstudie, mit der die Arbeit abschließt, dient auf der einen Seite dazu, die vorgeschlagene Herangehensweise zu verdeutlichen und zu zeigen, wie eine von den Grundsätzen der skizzierten Soziologie der Software geleitete Forschung aussehen und welche Ergebnisse sie produzieren kann. Auf der anderen Seite stellt sie, gemäß dem in der Einleitung formulierten Anspruch an Soziologie, die Verbindung in den Mittelpunkt, die zwischen den Schwierigkeiten der Individuen und den Problemen der Allgemeinheit besteht, und zeigt, welche Rolle Software bei dieser Verbindung spielt: Die Veränderungen im deutschen Gesundheitswesen, vor allem der Wechsel von bedarfswirtschaftlicher zu fallbasierter Vergütung der Krankenbehandlung, und die Verbreitung standardisierter Organisationssoftware, die den Verantwortlichen im Krankenhaus die buchhalterische Perspektive auf Organisationen als primäre Steuerungsperspektive anbietet, beeinflusst konkret den Arbeitsalltag von Einzelnen im Krankenhaus. Im untersuchten Fall setzt die Klinikleitung sich mit ihren Versuchen, mit Hilfe der Software Kontrolle über den OP-Bereich auszuüben, teilweise durch. Teilweise scheitert sie aber auch, und zwar vor allem an etablierten Strukturen des Krankenhauses, die durch die Logik der medizinischen Profession beeinflusst sind, und den mehr oder weniger problematischen Folgen der Strategien, in denen Akteur*innen die Software einsetzen, um Ziele zu erreichen, deren Bedeutung für die Nutzer*innen bei der Entwicklung der relevanten Modelle offensichtlich nicht hinreichend berücksichtigt worden ist.

Die in der Fallstudie untersuchte Software ist auch über das Anwendungsfeld Gesundheitswesen hinaus von gesellschaftlicher Relevanz: Standardisierte Organisationssoftware ist eine der Voraussetzungen für die Selbstverständlichkeiten des Lebens in unseren reifen Industriegesellschaften. Verteilte Produktion und komplexe Logistik wären ohne sie nicht vorstellbar. Im Alltag begegnen uns die Auswirkungen dieser Phänomene überall: Im Supermarkt, wo wir täglich frisches Obst aus allen Ecken der Welt vorfinden, im Berufsalltag, wo Produktivitätsanalysen in Konzernzentralen dazu führen, dass der eigene Arbeitsablauf komplett umgestaltet wird, oder bei der Urlaubsplanung, wo die Informationen der Fluglinien über die zum Reisezeitpunkt noch verfügbaren Plätze darüber entscheiden, was es uns kostet, unseren Urlaubsort zu erreichen. Auch der Trend, organisiertes Handeln aller Art nach Kennzahlen zu bewerten und zu steuern, der von Michel Power in „The Audit Society“ (Power 2002) als charakteristisch für unsere Gesellschaften dargestellt wurde, wäre ohne die technischen Voraussetzungen zur massenhaften Sammlung und Analyse von Daten über die Arbeitsprozesse in Organisationen unmöglich.

Die Fallstudie in dieser Arbeit baut auf dem umfangreichen soziologischen Forschungsstand zu SAP auf. Die Standardsoftware ist vermutlich die soziologisch am besten untersuchte Software überhaupt; es gibt eine Vielzahl empirischer Studien, die Entstehung, Weiterentwicklung, Einführung und Nutzung in verschiedensten Organisationen aus unterschiedlichen Perspektiven erforschen. Die in der Einleitung kritisierte Trennlinie zwischen Entwicklungs- und Nutzungsforschung durchzieht jedoch auch diesen Bereich. Zu der gesellschaftlich relevanten Frage, inwieweit die (gut erforschten) Prozesse bei der Entwicklung und Weiterentwicklung, die in wenigen, stark ungleich strukturierten Kontexten stattfinden, sich auf die (gut erforschten) Prozesse des Umgangs mit SAP in den unterschiedlichen, oft völlig anders strukturierten Kontexten auswirken, in denen SAP zum Einsatz kommt, ist bisher wenig bekannt. Mit der Fallstudie demonstriere ich insofern keine beliebige Anwendungsmöglichkeit für die Soziologie der Software, sondern eine, die relevant und dank der vielen Vorarbeiten unmittelbar umsetzbar ist.

FormalPara Zu den Grenzen dieser Arbeit

Die Fallstudie dient in der vorliegenden Arbeit vor allem, um zu zeigen, wie sich die in der Theorie entwickelte soziologische Perspektive auf den Umgang mit Software für empirische Forschung operationalisieren und anwenden lässt. Methodische Überlegungen sind bei der Durchführung der Studie oft pragmatischen Erwägungen untergeordnet worden. Nicht alle Akteur*innen, die ich befragen wollte, um die im Forschungsprozess vorläufig gebildeten Hypothesen zu prüfen, waren bereit, Interviews zu geben; nicht alle Dokumente, die für eine fundierte Analyse der Software wünschenswert gewesen wären, waren für mich verfügbar. Der fehlende Zugang zu Softwareentwickler*innen und die Tatsache, dass das Thema „persönliche Machtkalküle in der Krankenbehandlung“ unter Chirurg*innen als problematisch wahrgenommen und von den meisten nur indirekt angesprochen wird, haben die Datenerhebung erschwert. Bei der Auswertung ist mehr auf die methodologische Grundhaltung geachtet worden, auf der die Grounded Theory basiert, als auf die strenge Befolgung eines der verschiedenen Codierverfahren, die von verschiedenen Anhänger*innen der Grounded Theory entwickelt worden sind. In der Studie werden daher nur die Konturen der Spiele in der Sanusklinik dargestellt. Details über den Umgang mit der Software, die Machtverteilung in den Abteilungen und die Strategien der Akteur*innen fehlen überall dort, wo auf Basis der verfügbaren Daten keine belastbaren Aussagen über diese Details getroffen werden konnten. Mit der für eine Soziologie der Software zweifellos bedeutsame Frage, mit welchen Methoden Soziolog*innen allgemein Erkenntnisse über Modelle in Software gewinnen können, wird in dieser Arbeit nur am Rande behandelt. Für den Gegenstand, den ich in meiner Fallstudie untersuche, sind ausführliche Vorarbeiten vorhanden, die ich so gut wie möglich mit Hilfe der Daten ergänzt habe, die ich selbst erheben konnte.

Die Tatsache, dass die Fallstudie stark auf solchen Vorarbeiten zur untersuchten Software aufbaut, zeigt auch, wo die Grenzen der hier vorgeschlagenen Vorgehensweise liegen: Auch wenn sie sich auf allgemeine Prinzipien des Zusammenhangs zwischen Software und Sozialem stützt, liefert sie keine Vorlage, wie Forschende einfach zu allgemeinen Aussagen darüber kommen können, welche Rolle eine beliebige Software für den Umgang mit ihr in einem beliebigen sozialen Kontext spielt. An der Skizze einer Soziologie der Software, die ich in dieser Arbeit entwickelt habe, zeigt sich, mit welcher Komplexität Forschende konfrontiert sind, wenn sie nicht nur beobachten wollen, welche Rolle Software im Sozialen spielt, sondern auch verstehen wollen, wie es dazu kommt, dass Software diese Rolle spielt, und wer wann welche Handlungsspielräume hat, um diese Rolle mitzugestalten.

Ich habe für die Rekonstruktion dieser Komplexität viele Forschungsstränge zusammengeführt, in denen Wissenschaftler*innen sich intensiv mit der Grundfrage der vorliegenden Arbeit auseinandersetzen. Einige habe ich allerdings bewusst ausgelassen. Aus der Soziologie ist dies vor allem die Arbeitssoziologie, die hier keine Erwähnung findet, und die Kultur- und Mediensoziologie, aus der nur punktuell Forschungsergebnisse aufgegriffen werden, z. B. Grenz (2014) Arbeit zu digitalen Plattformen. Der Grund dafür ist, dass die Komplexität, die ich im Zentrum der soziologischen Auseinandersetzung mit Software sehe, in beiden Bereichen eine noch geringere Rolle spielt, als in denen, die hier aufgenommen sind: In den Studien der Arbeitssoziologie steht praktisch ausschließlich die Nutzung digitaler Technik im Mittelpunkt. Fragen nach der Gestaltung dieser Technik, die die gefürchtete Digitalisierung der Arbeit vorantreibt, werden von den meisten Arbeitssoziolog*innen ignoriert. In der Kultur- und Mediensoziologie hingegen konzentrieren sich die Forscher*innen so stark darauf, herauszufinden, was Algorithmen, Daten oder Netzwerke allgemein für Konsequenzen für das Soziale haben, dass die Frage, wie diese Konsequenzen konkret von Menschen unter sozialen Bedingungen hervorgebracht werden, meistens untergeht.

Die größeren Lücken, die ich bei der Aufarbeitung des Forschungsstands für die vorliegende Arbeit gelassen habe, liegen außerhalb meiner eigenen Disziplin: Die Rolle von Software im Sozialen wird auch in der Informatik verhandelt. Auch wenn das Verhältnis von sozialem Handeln und sozialer Ordnung für Informatiker*innen nicht generell als relevanter Forschungsgegenstand betrachtet wird, ähneln sich viele der Probleme, die durch eine soziologische Perspektive auf den Umgang mit Software verstanden werden können, und viele der Probleme, auf die Softwareentwickler*innen im Alltag und in der Forschung Lösungen suchen und finden. Ich habe für die vorliegende Arbeit vor allem auf Literatur der Informatik zurückgegriffen, die in der Ausbildung von Informatiker*innen eingesetzt wird. Im Ergebnis spiegelt meine Darstellung der Perspektive von Informatiker*innen auf die Softwareentwicklung vor allem wider, was in der Praxis der Softwareentwicklung geschieht. Inwieweit Forscher*innen in der Informatik sich der potentiell weitreichenden gesellschaftlichen Folgen der technischen Komplexität von Software bewusst sind, bleibt im Dunkeln. Der Eindruck, der bleibt, wenn man sich einen groben Überblick über die Themen der Forschung in Software Engineering, Systems Engineering und Wirtschaftsinformatik verschafft, ist der eines unbearbeiteten Feldes. Informatiker*innen nehmen den Soziolog*innen die Aufgabe nicht ab, zu erklären, welcher Zusammenhang zwischen den gesellschaftlichen Bedingungen und der Arbeit von Informatiker*innen besteht.

FormalPara Zum Nutzen der Arbeit für weitergehende Forschung

Soziolog*innen, die sich ernsthaft mit Software auseinandersetzen wollen, müssen der Informatik mehr Aufmerksamkeit widmen. Mit der vorliegenden Arbeit will ich Leser*innen auch davon überzeugen, dass Soziolog*innen fundiertere Antworten auf Fragen geben können, in denen Software eine Rolle spielt, wenn sie zumindest in groben Zügen verstanden haben, was die Technik auszeichnet, die sie betrachten. Eine Soziologie der Software kann mehr zu einem Verständnis der Rolle von Software im Sozialen beitragen als bisher, wenn Soziolog*innen in der Lage sind zu identifizieren, welche Elemente der Software für ihr Funktionieren bedeutsamer und welche weniger bedeutsam sind und wenn sie eine Vorstellung von den Bedingungen haben, unter denen diese Elemente entstanden und zusammengefügt worden sind. In dieser Arbeit stelle ich Grundprinzipien der Funktion und des Lebenszyklus von Software dar, um darauf hinzuweisen, dass diese Grundprinzipien für die Soziologie bedeutsam sind und dafür zu werben, dass es sinnvoll ist, die Komplexität von Software in soziologischer Forschung stärker als bisher zu berücksichtigen. Moderne Softwareentwicklung ist ein in der Soziologie kaum beachtetes Untersuchungsfeld. Dass Forschung über aktuelle Software sich fast ausschließlich auf Erkenntnisse zur Softwareentwicklung stützen muss, die durch Studien in den 1990er Jahren gewonnen worden sind, ist angesichts der Ausmaße, in denen sich die Praxis der Softwareentwicklung seit diesem Zeitpunkt verändert hat, mindestens problematisch. Ich hoffe, dass die vorliegende Arbeit dazu beiträgt, dass Soziolog*innen den Fokus ihrer Forschung wieder stärker auf Prozesse und Prinzipien der Softwareentwicklung richten. Ausgehend von den Darstellungen dieser Arbeit lassen sich zwei Gründe benennen, warum diese Ausweitung des Fokus für eine soziologischen Digitalisierungsforschung relevant ist.

Erstens ist Softwareentwicklung an sich ein relevanter Untersuchungsgegenstand, in dem arbeits-, organisations- und techniksoziologische Fragestellungen auf spezielle und bisher nur ansatzweise verstandene Weise zusammenspielen. Welche Auswirkungen hat die immer stärkere Verwendung von standardisierten „Softwarebausteinen“ auf die Handlungsspielräume bei der Softwareentwicklung? Inwieweit kommen in den Nutzungsdaten, die z. B. für die Weiterentwicklung digitaler Plattformen herangezogen werden, tatsächliche Anforderungen von Nutzenden zum Ausdruck? Inwieweit sind diese Nutzungsdaten Artefakte der Programmierung, technischer Trends oder vergangener und vergessener Vorgaben von Manager*innen, Geldgeber*innen oder Regulator*innen? Forschungsprojekte, in denen solche Fragen untersucht werden, lassen nicht nur soziologische Erkenntnisse erwarten, sondern könnten auch für Informatiker*innen relevant sein und diese in ihrer Praxis informieren.

Zweitens werden sich Fragen nach den Auswirkungen, die der Umgang mit konkreten, weit verbreiteten Arten von Software haben kann, nur beantworten lassen, wenn die Bedingungen, unter denen diese konkreten Artefakte entstehen und weiterentwickelt werden, besser bekannt sind. SAP ist nicht die einzige Software, die für einen großen gesellschaftlichen Bereich relevant ist. Mehr Aufmerksamkeit verdienen vor allem Standards, Protokolle und Designmodelle, die vielen Einzelanwendungen zugrunde liegen, aber für die Nutzenden nicht sichtbar sind. Studien, in denen Forschende sich mit den sozialen Bedingungen und den Beziehungen zwischen den Akteur*innen befassen, welche bei der Entwicklung solch weit verbreiteter Softwarebausteine bedeutsam werden, gibt es bisher kaum. Solche Studien können die Grundlage für andere Arbeiten bilden, in denen sich Soziolog*innen mit der Rolle konkreter Anwendungen befassen, die aus solchen Bausteinen aufgebaut sind.

In der Soziologie fehlt es nicht an Studien zum Umgang mit Software oder am allgemeinen Austausch über die Ergebnisse; was fehlt, ist eine Grundlage dafür, dass Forschende mit unterschiedlichen Forschungsfragen zur Rolle von Software im Sozialen über Einzelstudien hinweg kooperieren, ihre Ergebnisse systematisch aufeinander beziehen und reflektieren, wo ihre jeweiligen blinden Flecken liegen. Mit einer Soziologie der Software können nicht alle blinden Flecken soziologischer Forschung erhellt werden, denn die Tatsache, dass für jede Untersuchung ein Fokus gewählt werden muss, macht blinde Flecken unvermeidlich. Aber eine Soziologie der Software kann es für Forscher*innen einfacher machen zu erkennen, wo die spezifischen blinden Flecken in einzelnen Forschungsarbeiten liegen, durch welche anderen Arbeiten diese Forschungslücken gefüllt werden können und was zu tun ist, wenn ganz bestimmte Fragen beantwortet werden sollen.

In der Softwareentwicklung wird von „technischen Schulden“ gesprochen, die angehäuft werden, wenn darauf verzichtet wird, komplexe Probleme unmittelbar zu beheben, um schneller und mit weniger unmittelbarem Aufwand zu vorerst funktionsfähigen Lösungen für aktuelle Aufgaben zu kommen (Tom et al. 2013). Der Jurist und Internetforscher Jonathan L. Zittrain beschreibt den aktuellen gesellschaftlichen Umgang mit einer bestimmten Form von Software, der künstlichen Intelligenz, als das Anhäufen von „intellektuellen Schulden“ („intellectual debt“): Obwohl wir wissen, dass die Prinzipien, nach denen sogenannte „intelligente“ Systeme operieren, nicht bekannt sind, werden Entscheidungen dennoch an solche Systeme ausgelagert, weil diese Systeme schneller und auf den ersten Blick zuverlässiger entscheiden als Menschen (Zittrain 2019). Eine Soziologie der Software muss Mechanismen wie die, die Zittrain für den Umgang mit künstlicher Intelligenz beschreibt, in den Blick nehmen und die Debatte auf die gesellschaftlichen Bedingungen und Folgen der Komplexität von Software lenken. Soziolog*innen, die die Aufgabe, die Mills ausformuliert hat, ernst nehmen, dürfen nicht selbst der Versuchung erliegen, heute weitreichende Aussagen zur Rolle digitaler Technik für die Gesellschaft zu treffen, denen die Grundlage fehlt, weil Forscher*innen die fundierte Auseinandersetzung mit der Technik auf morgen verschieben. Ich hoffe, dass meine Arbeit dazu beiträgt, dass Soziolog*innen erkennen, dass sie mit schwach fundierten Aussagen eigene „Schulden“ anhäufen, die fällig werden, wenn sich die geringe Verlässlichkeit solcher Aussagen zeigt.