Transaktionskosten in der Softwareentwicklung – Teil 3
Transaktionskosten in der Softwareentwicklung – Teil 3
Trotz vieler beteiligter Softwareentwicklerinnen und -entwickler scheint die Umsetzung fachlicher Anforderungen oft sehr lange zu dauern. Der entscheidende Faktor für dieses Phänomen ist eine falsche Arbeitsteilung, die die Komplexität erhöht und Fortschritt verlangsamt. Erst eine vertikale Organisationsstruktur, die Teams fachlich statt technisch ausrichtet, schafft die Grundlage für effiziente Softwareentwicklung.
Die Aufgaben von Architekt:innen sind vor allem mit technischen Fragestellungen verbunden. Die nicht-funktionalen Themen (erlaubte Toolbox, Sicherheit, Verfügbarkeit, Leistung usw.) sind aber lediglich Hygienethemen. Sie liegen jenseits der funktionalen Anforderungen und sind mit technischer Ausbildung und bekannten Prozessen lösbar.
Es gibt aber eine Herausforderung, die sehr große Auswirkungen auf die Effizienz der Softwareentwicklung mit vielen Personen hat: die Wahl der Arbeitsteilung bzw. die Organisationsstruktur. CT/I/DOs und IT-Architekt:innen müssen deshalb der Arbeitsteilung besondere Aufmerksamkeit schenken.
In Teil 1 dieser Serie habe ich die Bedeutung der Transaktionskosten erläutert: Der Großteil der Arbeitszeit der Softwareentwickelnden entfällt auf andere Tätigkeiten als das Schreiben von Code. Komplexität ist der zentrale Treiber für diese Transaktionskosten:
Komplexität der zu beherrschenden Fachlichkeit
Komplexität der benötigten Koordination für die gewählte Arbeitsteilung
IT-Architektur muss diese Komplexität für Teams minimieren, damit deren Aufgaben beherrschbar bleiben und die Transaktionskosten nicht ausufern.
Die gesamte moderne Gesellschaft wurde durch Arbeitsteilung leistungsfähiger (und effizienter). Sie ermöglicht es Menschen, hochkomplexe Tätigkeiten zu bewältigen, z. B. die Entwicklung und den Bau von Autos. Arbeitsteilung bedeutet die Bildung von Untereinheiten, die nur einen Ausschnitt einer Gesamtaufgabe verstehen und bewältigen müssen, also eine Reduktion der Komplexität. Bekannte Beispiele in Unternehmen sind Untereinheiten wie Einkauf, Produktion, Forschung und Entwicklung, Verkauf, Logistik, Buchhaltung, Controlling usw.
Der Preis, den Arbeitsteilung einfordert, ist die Koordination mit anderen Untereinheiten („Schnittstellen“). Die einzelnen Tätigkeiten müssen am Ende eine funktionierende Gesamtheit ergeben, um z. B. ein fertiges Auto an Kunden zu verkaufen.
Der besondere Wert weniger und einfacher Schnittstellen zwischen Abteilungen drückt sich darin aus, dass wenig abteilungsübergreifendes Verständnis und Können aufgebaut werden muss. Wenn es dagegen viele und komplexe Schnittstellen zu anderen Abteilungen gibt, führt das zu größerer fachlicher und koordinativer Komplexität, weil zu viel Fachlichkeit der anderen Abteilungen verarbeitet und zu viel Arbeit koordiniert werden muss. Aus der Perspektive der Effizienz ist eine optimale Schnittstellengestaltung in Organisationen dadurch gekennzeichnet, dass Anzahl und Komplexität der Schnittstellen zwischen den verschiedenen Untereinheiten auf ein Minimum reduziert werden.
Mit zunehmender Komplexität in den Untereinheiten entsteht der Bedarf nach weiteren Zellteilungen, um die Komplexität für die Menschen beherrschbar zu halten. Im Einkauf beispielsweise könnte sich eine eigene Abteilung um den Einkauf von Software(-leistungen) kümmern, während eine andere den Einkauf verschiedener Stahlsorten übernimmt.
Ich bevorzuge gegenüber dem Begriff „digitaler Zwilling“ den Begriff „digitaler Spiegel“, um die IT-Organisation zu adressieren. Er drückt besser aus, dass die IT-Struktur einer Organisation strukturell genau das spiegeln muss, was die „analoge“ Organisation bzw. die Menschen darin tun und automatisieren möchten. Ein Zwilling kann sich nach der Geburt anders entwickeln als sein Pendant. Ein digitaler Spiegel muss strukturell exakt die Struktur seiner analogen Organisation wiedergeben.
IT ist die (Teil-)Automatisierung dessen, was die Menschen vorher in Abteilungen getan haben. Der vielzitierte Melvin Edward Conway hat schon in den 60er-Jahren bemerkt, dass IT-Organisationen ihre Softwaresysteme entsprechend ihrer inneren Organisationsstruktur aufbauen.
Wie im Folgenden verständlich wird, hat die Reduktion der Komplexität in der IT einen vergleichbaren Wert wie in der „analogen“ Welt der Tätigkeiten in den Abteilungen. Je mehr Fachlichkeit automatisiert wird, desto komplexer wird Software und desto eher überfordert sie fachlich die Softwareentwicklerinnen und -entwickler. Diese arbeiten an der Grenze zwischen der Fachsprache des Fachgebiets, für das sie entwickeln, und der technischen Sprache, in der dieses Fachgebiet automatisiert wird. Sehr komplexe Systeme überfordern die Softwareentwickelnden also nicht technisch, sondern fachlich.
Wie in der analogen Organisationswelt gibt es darum auch in der IT dringenden Bedarf nach Reduktion fachlicher und koordinativer Komplexität durch geeignete Arbeitsteilung. Heutige IT-Landschaften großer Unternehmen sollten besser nicht mehr aus einer monolithischen Software bestehen, in der die gesamte analoge Organisationswelt digital gespiegelt wird. Bei zunehmender Automatisierung wächst die fachliche Komplexität solcher Software und treibt die Transaktionskosten der Entwicklung immer weiter in die Höhe (siehe Teil 1), weil die Softwareentwickelnden von der fachlichen Komplexität überfordert werden. Stattdessen wird in heutigen IT-Landschaften versucht, die automatisierte Fachlichkeit durch Arbeitsteilung wieder handhabbar zu machen. Unter dem sehr unscharfen Begriff „Microservice“ wird diese Arbeitsteilung technisch adressiert.
Meine zentrale These ist, dass die Auswirkungen schlechter Arbeitsteilung in der IT stark unterschätzt werden. Insbesondere bedeutet Arbeitsteilung, die zu einem Bedarf an Koordination mit anderen Teams führt, indirekt auch eine fachlich höhere Komplexität – die es ja eigentlich zu reduzieren gilt. Je mehr Koordinationsbedarf es zwischen Teams gibt, desto mehr müssen die einen die Fachlichkeit der anderen verstehen, um die scheinbar notwendigen Schnittstellen gemeinsam entwickeln und unterhalten zu können.
Reduktion des Koordinationsbedarfs ist darum der wichtigste Faktor in der IT-Architektur größerer Organisationen, da sie wachsende fachliche Komplexität beherrschbar hält. Genau wie schlechte...