Wie technologische Faktoren Ambidextrie in Software-Projekten beeinflussen

Unsere Studie zielt darauf ab, die Auswirkungen technologischer Faktoren auf Ambidextrie in Software-Projekten besser zu verstehen. Auch wenn der Großteil der Informationssystemsforschung Ambidextrie auf Organisationsebene betrachtet (Werder und Heckmann 2019), ist eine Untersuchung auf Projektebene aus zwei Gründen relevant. Erstens variieren technologische Faktoren (z. B. Softwareentwicklungstechnologien, Nutzung von Standardsoftware) auf Projektebene. Untersuchungen auf Organisationsebene können damit Varianz in technologischen Faktoren nur begrenzt erfassen. Zweitens kann argumentiert werden, dass Ambidextrie in Software-Projekten wesentlich zur Ambidextrie einer Organisation beiträgt. Denn die Applikationslandschaft einer Organisation ist zu einem bedeutenden Teil das Ergebnis ihrer Software-Projekte (Soh und Markus 1995), so dass Organisationen, deren Software-Projekte sowohl vorhersagbar als auch anpassungsfähig sind, auch vorhersagbarer und anpassungsfähiger darin sind, wie sie ihre Geschäftsprozesse und Produkte mit IT unterstützen.

Unsere Studie untersucht, wie Ambidextrie in Software-Projekten von drei technologische Faktoren abhängt, die in modernen Organisationen und der Praxisliteratur oft als gute Praxis genannt werden: (1) Kontinuierliche Integration (Humble und Farley 2010; Kim et al. 2016), (2) Technologie- und Geschäftsprozessstandardisierung (Ross et al. 2006; Weill und Ross 2004) gemessen in Form von Wissensspezifität (Dibbern et al. 2008) und (3) Microservice-Architektur (Ross et al. 2019; Taibi et al. 2017). Abb. 1 zeigt unser Forschungsmodell.

Full size image

Kontinuierliche Integration (Continuous Integration, CI) bezeichnet einen Prozess, bei dem Entwickler systematisch und mehrfach täglich Code-Beiträge integrieren und auf einem Testserver deployen (Tripp et al. 2016). CI setzt auf Automatisierung von Deployment und Test-Prozessen. Diese Automatisierung fördert Qualität und Regeltreue, was Exploitation unterstützt (Beal 2022; Kim et al. 2016). CI ermöglicht es zudem, Fehler und Integrationsprobleme früh zu erkennen und zu beheben, was zu Verlässlichkeit und damit Exploitation beiträgt (Krancher 2020; Tripp et al. 2016). Gleichzeitig ermöglicht CI das schnelle Erproben inkrementeller Änderungen, was Experimente und Innovationen unterstützen und somit Exploration fördern kann (Knapp et al. 2016; Ries 2014). Daraus leiten wir die folgende Hypothese ab:

H1: Eine höhere Nutzung von kontinuierlicher Integration ist mit einer höheren Ambidextrie verbunden.

Organisationen nutzen häufig standardisierte Prozesse und Rahmenwerke (wie Lean, Six Sigma, ITIL, SAFe, Cobit 5), um die Zusammenarbeit intern und mit externen Partnern zu erleichtern (Bharadwaj et al. 2013; Lee et al. 2010). Zudem nutzen Organisationen oft Standardsoftware, was Entwicklungsprozesse beschleunigt und das Finden von externen Partnern mit Kompetenzen in den vorhandenen Technologien erleichtert (Dibbern et al. 2008). Standardisierte Prozesse und Systeme können auch die Auditierbarkeit, Sicherheit und Stabilität erhöhen und damit zur Exploitation beitragen (Weill und Ross 2004). Gleichzeitig kann argumentiert werden, dass standardisierte Prozesse und Systeme schnelle Innovationen, das rasche Erfüllen von Qualitätskontrollen und das Einbinden von Services von externen Partnern ermöglichen. So empfiehlt beispielsweise die CISR-Gruppe des MIT standardisierte externe Plattformen, um Co-Kreation mit externen Partnern zu unterstützen (Ross et al. 2019). Wir untersuchen diese positive Wirkungen von Standardisierung mittels des Konstrukts der Wissensspezifität aus der Outsourcing-Forschung (Dibbern et al. 2008). Wissensspezifität bezeichnet – als Gegenstück zu Standardisierung – das Ausmaß, in dem ein Projekt Wissen zu Applikationen und Prozessen benötigt, das spezifisch für eine Organisation ist. Somit ist zu erwarten, dass Projekte mit hoher Wissensspezifität (z. B. Projekte mit Individualsoftware oder hochgradig angepasster Standardsoftware und einzigartigen Geschäftsprozessen) kaum von den oben genannten Vorteilen der Standardisierung profitieren. Unsere Hypothese lautet daher:

H2: Niedrigere Wissensspezifität geht mit höherer Ambidextrie einher.

Wir testeten unsere Hypothesen durch eine Mehrinformanten-Umfrage unter Sponsoren und Entwicklern aus 95 Software-Projekten in Dänemark und der Schweiz. Eine Mehrinformanten-Umfrage reduziert Methodenverzerrung (Common-Method Bias), weil Daten zu unabhängigen und abhängigen Variablen aus unterschiedlichen Quellen stammen (Podsakoff et al. 2003). Wir kontaktierten potenzielle Organisationen in der Schweiz und Dänemark und fragten nach Software-Projekten, die in den vergangenen 12 Monaten abgeschlossen wurden. Interessierte Organisationen baten wir um die Kontaktdaten von Sponsor und Entwickler ihrer Projekte. Diese Teilnehmenden erhielten dann auf ihre Rolle zugeschnittene Online-Fragebögen. Wir erhielten Antworten von 133 Sponsoren und 115 Entwicklern. Für unsere finale Stichprobe von 95 Projekten erhielten wir die Antworten beider Rollen.

Tab. 1 zeigt unser Messinstrument. Wir nutzten existierende Skalen wo möglich. Wir fokussierten auf Exploitation und Exploration als Komponenten von Ambidextrie (Gibson und Birkinshaw 2004; Werder und Heckmann 2019). Im Einklang mit Tiwana (2010) umfasste Exploitation die Dimensionen Effektivität (das Ausmaß, in dem die Produkte eines Projekts Anforderungen erfüllen), Zeiteffizienz und Budgeteffizienz. Wissensspezifität war ebenfalls ein multidimensionales Konstrukt mit den Dimensionen Domänenwissensspezifität und Applikationswissensspezifität.

Die Fragebögen wurden für die Schweizer Umfrage auf Deutsch und Französisch sowie für die dänische Umfrage auf Dänisch und Englisch formuliert. Die Validierung erfolgte durch einen Pretest, einen Pilotdurchlauf und eine Faktorenanalyse der finalen Daten (DeVellis 2012; MacKenzie und Podsakoff 2011). Die Validität und Reliabilität unseres Instruments wurde belegt durch (1) Faktorladungen von mindestens 0,6 (siehe Tab. 2), (2) deutlich niedrigere Kreuzladungen (höchster Wert: 0,32), (3) Cronbachs Alpha-Werte über 0,7 (siehe Tab. 1) und (4) Konstruktkorrelationen unterhalb der Quadratwurzeln der Average Variance Extracted (AVE) (Fornell und Larcker 1981).

Wir testeten unsere Hypothesen mittels einer Regressionsanalyse. Wie in bisheriger Forschung zu Ambidextrie berechneten wir Ambidextrie als Produktterm aus Exploitation und Exploration (Gibson und Birkinshaw 2004; Tiwana 2010). Wir führten eine hierarchische Regression durch, bei der wir in Schritt (a) nur Kontrollvariablen und in Schritt (b) Kontrollvariablen und die unabhängigen Variablen des Forschungsmodells mitführten. Die Kontrollvariablen waren binäre Variablen für das Land Schweiz, Outsourcing und Wartung sowie metrische Variablen für Projektgröße (gemessen auf einer Fünf-Punkte-Skala) und Vertrauen, da Vertrauen als ein etablierter Prädiktor der kontextuellen Ambidextrie gilt (Gibson und Birkinshaw 2004). Drei fehlende Werte für CI und zwei fehlende Werte für Wissensspezifität wurden mit dem Mittelwert ersetzt.

Unsere Ergebnisse haben die Erwartung einer positiven Beziehung zwischen kontinuierlicher Integration (CI) und Ambidextrie bestätigt (β = 0,23, p < 0,01). Die Kultur und Arbeitsweise der modernen Softwareentwicklung (agil, DevOps) basiert auch auf den Mechanismen und der Automatisierung von CI (Beal 2022; Humble und Farley 2010; Kim et al. 2016; Ross et al. 2019). DevOps wurde entwickelt, um Vorhersagbarkeit und Stabilität (und somit Exploitation) sowie Anpassungsfähigkeit und Neuentwicklung (und somit Exploration) in Einklang zu bringen (Kim et al. 2013). Unsere Studie belegt, dass CI bei dieser Zielerreichung tatsächlich helfen kann.

Unsere Umfrage bestätigt die Hypothese, dass geringe Wissensspezifität mit höherer Ambidextrie einhergeht (β = −0,24, p < 0,01). Die Auswirkungen von spezifischem Wissen (nichtstandardisierte Prozesse und Systeme) wurden im Bereich des Offshoring und Outsourcing untersucht und als Teilursache für unerwartete Kosten identifiziert (Dibbern et al. 2008). Unsere Ergebnisse erweitern dieses Verständnis. Hochgradig unternehmensspezifische Prozesse und Applikationen in einem Software-Projekt, sei es ausgelagert oder nicht, gehen mit niedrigerer Ambidextrie einher, möglicherweise aufgrund zusätzlicher Kosten oder Zeitaufwände, etwa durch längere Wissensübertragungszeiten für neue Mitarbeiter, Nacharbeit wegen Missverständnissen und maßgeschneiderte Prozess- und Systemdokumentation. Ergänzend zur etablierten Ansicht, die Standardisierung mit Zentralisierung, Kapitalrendite und Projekteffizienz in Verbindung bringt (Lee et al. 2010; Weill und Ross 2004), zeigen unsere Ergebnis, dass Standardisierung auch Exploration unterstützen kann. Standardisierung ist möglicherweise vorteilhaft für Exploration, da sie Organisationen ermöglicht, schnell von Fortschritten in Standardtechnologien zu profitieren (z. B. Software-as-a-Service-Lösungen mit häufigen Releases) und weil Standardisierung die flexible Neukombination modularer Komponenten erleichtert.

Hypothese H3 sagte eine positive Beziehung zwischen Microservice-Architektur und Ambidextrie voraus, doch die Ergebnisse waren nicht signifikant (β = 0,07, p = 0,40). Ein möglicher Grund hierfür könnten Schwierigkeiten bei der Umsetzung des Microservice-Konzepts sein. Eine Studie zeigt, dass das Design von Applikationen im Einklang mit Prinzipien der Microservice-Architektur anspruchsvoll ist und dass Verletzungen dieser Prinzipien (z. B. Verletzung von Modularität) sowohl zu Qualitätsproblemen (d. h. Probleme mit Exploitation) als auch zu eingeschränkter Modifizierbarkeit (d. h. Probleme mit Exploration) führen können (Zhong et al. 2022). Eine andere Studie zeigt, dass eine besondere Schwierigkeit darin besteht, Domänenkonzepte in angemessene Microservice-Strukturen zu übersetzen, was sich in zu grobgranularen oder zu feingranularen Services niederschlagen kann (Zhong et al. 2024). Im Einklang mit diesen Ideen zeigen unsere Daten neben den in diesem Artikel berichteten Korrelationen auch signifikante positive Zusammenhänge zwischen Microservice-Architektur mit Aufgabeninterdependenz (r = 0,31, p = 0,002, gemessen durch drei Items) und mit Koordinationsproblemen (r = 0,21, p = 0,04, gemessen durch drei Items), was ebenfalls darauf hindeutet, dass der Versuch, autonome, unabhängig einsetzbare Dienste zu entwerfen, in der Praxis nicht immer gelingt. Es erscheint plausibel, dass Microservices, die zu feingranular oder nicht ausreichend modular gestaltet sind, zu Koordinationsproblemen und kognitiver Überlastung von Architekten und Entwicklern (Krancher und Dibbern 2012) führen können.

Diese Studie liefert drei wesentliche Beiträge zum Stand der Forschung. Erstens belegt unsere Studie einen Zusammenhang zwischen technologischen Faktoren und Ambidextrie auf Projektebene. Dies ist ein bedeutender Beitrag zur Ambidextrie-Literatur, die Ambidextrie bislang auf räumliche und zeitliche Trennungsstrategien (strukturelle und temporale Ambidextrie) (Smith und Tushman 2005), auf Individuen, die situativ Exploitation oder Exploration wählen (kontextuelle Ambidextrie) (Gibson und Birkinshaw 2004) oder auf Management-Strukturen, die formale und informale Elemente vereinen (Gregory und Keil 2014; Ramesh et al. 2012; Tiwana 2010), zurückführt. Unsere Studie zeigt dagegen, dass technologische Faktoren, insbesondere die Nutzung von CI und von Standardtechnologien und -prozessen, ebenfalls einen Beitrag zu Ambidextrie leisten können, der nicht durch existierende Ambidextrie-Konzepte abdeckt ist.

Zweitens bestätigt und erweitert unsere Studie Forschung zu CI und zu Standardisierung. Der signifikante Effekt von CI auf Ambidextrie ist im Einklang mit der Idee, dass häufiges, automatisiertes Deployment frühe Fehlerfindung (Krancher 2020; Tripp et al. 2016) und stabile, verlässliche Lieferprozesse ermöglicht (Beal 2022; Kim et al. 2016), während es gleichzeitig das schnelle Experimentieren mit alternativen Designs und neuer Funktionalität fördert (Krancher et al. 2018b). Die negative Korrelation zwischen Wissensspezifität und Ambidextrie zeigt, dass Standardisierung mit höherer Ambidextrie einhergehen kann. Dies ergänzt Perspektiven, die Standardisierung einseitig als Faktor für Exploitation sehen (Lee et al. 2010; Weill und Ross 2004). Möglicherweise hängt dieser Wandel mit technologischen Veränderungen hin zu mehr Automatisierung und komponentenbasierter Infrastruktur zusammen, wodurch Standardkomponenten einfacher und schneller kombiniert und somit für Innovationszwecke genutzt werden können.

Drittens setzen unsere Ergebnisse zu Microservice-Architektur zumindest ein Fragezeichen hinter Perspektiven, die lose gekoppelten Komponenten als Beitrag zu Ambidextrie sehen (Kim et al. 2016; Ross et al. 2006, 2019). Unsere Ergebnisse bekräftigen damit Arbeiten, die auf Schwierigkeiten bei der Umsetzung von Microservice-Architekturen hinweisen (Zhong et al. 2022, 2024).

Die Kernimplikation aus unserem Artikel für die Praxis ist, dass Organisationen die disziplinierte Nutzung von kontinuierlicher Integration (CI) und von Standardtechnologien forcieren sollten, um sowohl Effizienz und Anpassungsfähigkeit in Software-Projekten zu fördern.

Unsere Studie ist nicht ohne Limitationen. Erstens basiert unsere Studie auf Korrelationen und ermöglicht daher nur in begrenztem Maß starke kausale Schlussfolgerungen. (Quasi‑)Experimentelle Methoden und Fallstudien könnten zusätzliche wertvolle Einblicke in kausale Zusammenhänge liefern. Zweitens beschränkt sich unsere Untersuchung auf die Analyseebene von Software-Projekten. Künftige Forschung könnte untersuchen, wie sich Ambidextrie in Software-Projekten auf Ambidextrie der IT-Organisation und der gesamten Organisation auswirkt (Werder und Heckmann 2019). Drittens kamen die Befragten aus der Schweiz und Dänemark und damit aus Kulturen mit niedrigem Kontext, hohem Vertrauen und relativ flachen Hierarchien (Meyer 2014), was kontextuelle Ambidextrie möglicherweise begünstigt und damit die Ergebnisse beeinflusst hat. Es ist möglich, dass Studien in anderen Kulturräumen andere Ergebnisse zutage fördern würden. Viertens beleuchtet unsere Studie nur die Assoziation einzelner Faktoren mit Ambidextrie, nicht deren Kombination. Ein tieferes Verständnis des Zusammenspiels dieser Faktoren könnte für Praktiker wertvoll sein. Fünftens verdient die Beziehung zwischen standardisierten Prozessen und Ambidextrie sowie die Rolle von Continuous Delivery weitere Forschung. Continuous Delivery, als Weiterentwicklung von CI hin zu häufigen automatisierten Releases in Produktionsumgebungen, könnte ebenfalls Ambidextrie fördern und wird stark von IT-Governance und Entscheidungsstrukturen beeinflusst, was zukünftige Untersuchungen inspirieren könnte.