ja
Filtern
Dokumenttyp
- Masterarbeit (21)
Sprache
- Deutsch (21)
Volltext vorhanden
- ja (21)
Gehört zur Bibliographie
- ja (21)
Schlagworte
- Software Engineering (2)
- Agile Softwareentwicklung (1)
- Agilität <Management> (1)
- Ausschreibung (1)
- Führung (1)
- Industrie 4.0 (1)
- Internet der Dinge (1)
- Migration <Informatik> (1)
- Mikroservice (1)
- Software (1)
Institut
- Software Engineering Leadership (21) (entfernen)
Immer mehr Unternehmen setzen ihre Systeme mit Microservices um, da sie ihre Anwendungen schnell, agil und unabhängig in Produktion bringen möchten. So komplex dieser Architekturansatz ist, so vielfältig sind die Informationen, die für diesen Ansatz benötigt werden. Die vorliegende Arbeit beschäftigt sich daher damit, welche Aspekte für eine Microservice-Architektur von Relevanz sind und als Modell sichtbar gemacht werden sollten. Hierbei führt die Arbeit zunächst die allgemeinen Grundlagen der Softwarearchitektur und Modellierung ein. Anschließend werden auf Basis einer Literaturrecherche die relevanten Informationen einer Microservice-Architektur hervorgehoben. Die Kernelemente dabei sind die Makro- und Mikroarchitektur, die fachliche Aufteilung mit Domain-driven Design sowie die infrastrukturellen Herausforderungen. Aufgrund der sich ständig dynamisch ändernden Servicelandschaft, ist es in einer Microservice-Architektur außerdem erforderlich, sich mithilfe von automatisierter Datensammlung einen Überblick zu verschaffen. Anhand einer empirischen Studie konnte herausgefunden werden, dass die Unternehmen bereits diese relevanten Daten überwiegend über das Monitoring, Service Discovery oder Logging sammeln. Auch konnte herausgefunden werden, dass es Tendenzen bei den Aufgaben gibt, welche in der Praxis zur Makroarchitektur zugeordnet wurden. Im weiteren Verlauf der Arbeit wurde untersucht, inwieweit sich eine Microservice-Architektur mit klassischer Architekturbeschreibung wie arc42 beschreiben lässt. Aufgrund der allgemeinen Ausrichtung des Templates wurde prototypisch ein Modell entwickelt, welches die für eine Microservice-Architektur relevanten Entscheidungsfragen bereitstellt und somit bei den konkreten Entscheidungen unterstützt. Schließlich wurde das Modell mithilfe von qualitativen Interviews evaluiert. Hierbei wurde als Ergänzung ein Experte herangezogen, um mögliche Verbesserungen aus einer weiteren Perspektive miteinbringen zu können. Die Ergebnisse zeigten, dass das Modell zwar eine gute Basis darstellt, um einen Überblick zu den wichtigsten Entscheidungsfragen zu erhalten, aber dennoch weitere zielgruppenspezifische Informationen und detailliertere Ausführungen grundlegender Konzepte benötigt werden.
Die vorliegende Arbeit beschäftigt sich mit der Thematik, wie schnelle Ergebnisse mit Enterprise Architecture Management (EAM) und mit agilen Vorgehensweisen erzielt werden können, um prozessuale und technische Änderungen in der Organisation nachzuvollziehen. Zunächst wurde untersucht, welche Prinzipien und Werkzeuge aus den agilen Methoden und EAM vorhanden sind und wie daraus die Forschungsfragen zu beantworten sind. Aus diesen Werkzeugen wurde eine methodische Vorgehensweise entwickelt, mit der geprüft werden kann, wie Änderungen mit EAM nachvollzogen und daraus Anforderungen für das EAM fokussiert und priorisiert aufgenommen werden. Ergebnisse sollen so beschleunigt ermittelt werden. Im praktischen Teil wurde die methodische Vorgehensweise am Beispiel der Unternehmensgruppe ABLE Group angewendet. Mit Hilfe der Business-Scenario-Methode (TOGAF) wurden Qualitätsszenarien erstellt, welche als Startpunkt für ein iterativinkrementelles Vorgehen für die Nachvollziehbarkeit von Änderungen dienen. Die Qualitätsszenarien bildeten einen gedanklichen Rahmen für eine fokussierte Implementierung und mit EAM-Backlogs konnten diese Qualitätsszenarien priorisiert umgesetzt werden.
Als Schatten-IT werden IT-Systeme bezeichnet, die nicht in das IT-Management eines Unternehmens eingebunden sind. Schatten-IT-Systeme können durch Ausfall oder durch Sicherheitslücken bestandsgefährdende Risiken für Unternehmen darstellen. Schatten-IT kann aber auch ein Innovationsmotor sein. Wenn Schatten-IT-Systeme erkannt werden, kann es erforderlich und nützlich sein, diese in das IT-Management des Unternehmens aufzunehmen. Die vorliegende Arbeit untersucht die Eignung und Übertragbarkeit der aus der agilen Software-Entwicklung stammenden Werte und Prinzipien bei der Einbindung von Schatten-Individualsoftware in das IT-Management von Unternehmen. Am Beispiel von Schatten-Individualsoftware wird untersucht, wie die bisherige Rolle des IT-Managements durch Schatten-IT in Frage gestellt wird und wie die einzelnen Disziplinen des IT-Managements durch Schatten-IT betroffen sind. Es werden die Eigenschaften von Schatten-Individualsoftware erarbeitet und es wird untersucht, welche agilen Werte und Prinzipien sich auf das IT-Management übertragen lassen, um Schatten-Individualsoftware in das IT-Management von Unternehmen einzubinden. Aus den identifizierten agilen Werten und Prinzipien wird ein Handlungsansatz entwickelt, um Schatten-Individualsoftware in das IT-Management von Unternehmen zu integrieren. Dieser Ansatz wird durch Experten-Interviews initial evaluiert.
Durch die fortschreitende Globalisierung gewinnt eine standortverteilte Produktentwicklung im Bereich der Embedded-Software zunehmend an Bedeutung. Standortverteilte Teams stehen jedoch aufgrund vorherrschender Distanz vor zusätzlichen Herausforderungen. Die Kommunikation erfolgt primär über elektronische Medien. Dies kann eine Kooperation und eine effektive Zusammenarbeit in standortverteilten Teams erschweren. Bei international verteilten Teamstrukturen arbeiten Personen aus verschiedenen Kulturkreisen in verschiedenen Zeitzonen miteinander. Elemente, wie eine effektive Wissensverteilung, oder die Regelung bzw. Erkennung von Konflikten können sich in standortverteilten Teams als schwierig erweisen. Das Ziel dieser Arbeit ist die Untersuchung der Einflussfaktoren auf eine erfolgreiche Teamentwicklung von standortverteilten Teams im Bereich der Embedded-Software-Entwicklung. Dabei soll untersucht werden, durch welche Maßnahmen eine Kollaboration, über verschiedene Standorte hinweg, verbessert werden kann. Die Eigenschaften und Herausforderungen der Entwicklung von Embedded-Software werden aufgezeigt und die Bedeutung der Teamentwicklung für standortverteilte Teams wird diskutiert. Im ersten Teil dieser Arbeit werden die theoretischen Grundlagen zur Teamentwicklung von standortverteilten Teams abgebildet. Unter Berücksichtigung aktueller Forschungsergebnisse werden die potentiellen Einflussfaktoren diskutiert und ihre Wechselwirkung zueinander beschrieben. Eine signifikante Fragestellung dieser Arbeit ist die Untersuchung der Rolle und Aufgabe der Teamleitung hinsichtlich der Teamentwicklung. Weitere zentrale Themen sind die Bedeutung der Kommunikation und des Vertrauens in standortverteilten Teams sowie das Verhältnis zwischen Konfliktmanagement und Teamentwicklung. Weiterhin werden die Teamentwicklungsprozesse theoretisch aufgearbeitet, die Teamrollen und Teamzusammensetzungen diskutiert und Motivationstheorien zu der Thematik der standortverteilten Teams dargestellt. Der zweite Teil dieser Arbeit besteht aus einer empirischen Untersuchung, welche mithilfe von Methoden aus der qualitativen Sozialforschung durchgeführt wurde. Bestandteil der Untersuchung sind durchgeführte Experteninterviews sowie eine erstellte Onlineumfrage. Das Ergebnis der Untersuchung ist ein Modell zur Entwicklung von standortverteilten Teams, mit daraus abgeleiteten Hypothesen und konkreten Handlungsempfehlungen für die praktische Arbeit.
Die Wettbewerbsfähigkeit von Organisationen hängt mittlerweile maßgeblich von ihrer Fähigkeit ab, wie schnell sie sich den geänderten Rahmenbedingungen ihrer Umwelt anpassen kann. Dieses Phänomen betrifft vor allem die IT-Branche, die aufgrund von immer stärker schwankenden Rahmenbedingungen bereits vor Jahren die Vorteile agiler Vorgehensmodelle für sich entdeckt haben. Agile Vorgehensmodelle zeichnen im Gegensatz zu ihren klassischen Vorgängern einen leichtgewichtigen Prozessrahmen, der es nicht nur erlaubt, sich schnell an neue und geänderte Anforderungen anzupassen, sondern auch eine kontinuierliche Verbesserung der Prozesse anstrebt. Wenig überraschend ist es daher, dass immer mehr Unternehmen versuchen, ihre Entwicklungsprozesse nach agilen Prinzipien zu gestalten und klassischen Projektmanagement-Methoden den Rücken kehren. Um die Vorteile von Agilität jedoch vollständig nutzen zu können, ist es nicht ausreichend, wenn allein die Produktentwicklungsprozesse neu definiert werden. Agilität fordert ein Umdenken auf allen Organisationsebenen und hat dadurch einen immensen Einfluss auf das Verständnis von Mitarbeiterführung. Da das Prinzip des Agile Leaderships noch weitestgehend unerforscht ist, existieren derzeit wenig Handlungsempfehlungen für die Praxis, inwieweit eine agile Organisation mit verschiedenen Führungsebenen und -hierarchien vereinbar ist. Daher soll mithilfe dieser Arbeit geklärt werden, wie Agilität die Mitarbeiterführung beeinflusst und wie sich das Aufgabenfeld von Führungskräften verändert. Dazu wird auf Basis theoretischer Vorüberlegungen eine praktische Untersuchung vorgestellt, welche am Ende zu einem allgemeinen Leadershipmodell zusammengefasst wird.
In Software-Entwicklungsprojekten ist, wie auch in anderen Projekten, die Qualität der Planung ein wesentlicher Faktor für den Projekterfolg. Um eine zuverlässige Termin- und Kostenplanung zu erstellen, ist es notwendig, den Aufwand für die Projektumsetzung mit hinreichender Genauigkeit zu kennen. Daher ist es wichtig, Faktoren zu identifizieren, welche die Genauigkeit der Schätzung in Software-Entwicklungsprojekten positiv beeinflussen. In der Software-Entwicklung wird zwischen traditionellen (schwergewichtigen) und agilen (leichtgewichtigen) Vorgehensmodellen unterschieden. Wichtige Vorgehensmodelle werden in ihren Grundzügen beschrieben. Bei den traditionellen Vorgehensmodellen sind dies das Wasserfallmodell, der Unified Process und das Spiral-Modell. Bei den agilen Vorgehensmodellen, auf die sich die Betrachtungen im weiteren Verlauf dieser Arbeit konzentrieren, ist Scrum das am häufigsten eingesetzte, Extreme Programming XP (oder ein abgeleitetes Vorgehensmodell) das am zweithäufigsten angewendete. Eigenschaften der Vorgehensmodelle und Unterschiede in den Zugängen zu einigen Aspekten des Vorgehens im Projekt werden beschrieben. Neben dem Vorgehen im Projektablauf sind auch die Methoden für das Erstellen von Schätzungen unterschiedlich. Diese Methoden werden für traditionelle und agile Projekte betrachtet. In agilen Projekten wird häufig eine Trennung der Schätzung der Größe eines Entwicklungsprojekts und dem Aufwand vorgenommen. Verbreitete Methoden für dieses Vorgehen ist das Schätzen mit Story Points oder Idealen Tagen. Beide Methoden haben aber auch Nachteile, weshalb eine Alternative, das Schätzen mit tatsächlicher Zeit, betrachtet wird. Sodann werden Einflussfaktoren auf die Genauigkeit von Schätzungen – sowohl positive als auch negative – beschrieben. Im zweiten Teil der Arbeit erfolgt eine Prüfung der Einflussfaktoren auf Schätzungen in einem mittleren IT-Unternehmen daraufhin, ob diese eine signifikante Auswirkung auf die Qualität der Schätzung haben. Diese Prüfung erfolgt durch Interviews mit sechs Experten, einer Befragung aller Mitarbeiter in der Software-Entwicklung mittels Fragebogen und durch das Auswerten von historischen Daten. Diese Daten sind wesentliche Projekt-Kenngrößen wie Gesamtumfang in Stunden, Anzahl der im Projekt tätigen Mitarbeiter, sowie eine Gegenüberstellung des geschätzten Aufwands pro Backlog-Item und tatsächlichem Aufwand.
Diese theoriegeleitete Fallstudie geht der Frage nach, inwieweit sich das Requirements Engineering (RE) in einem Software-Entwicklungsprozess mit den Konzepten des Domain-Driven Designs (DDD) vereinbaren lässt. Die per Interview und teilnehmender Beobachtung erhobenen Daten wurden gemäß der qualitativen Inhaltsanalyse nach Gläser und Laudel ausgewertet. Der theoretische Rahmen gibt einen Überblick über die wichtigsten Konzepte des Domain-Driven Designs sowie über das Requirements Engineering, mit Fokus auf der Requirements-Analyse, skizziert Möglichkeiten der Integration des RE in das DDD und stellt Scrum als Vorgehensweise vor. Die Interviews zeigen, dass dem Projektteam sowohl die Ziele als auch die Produktvision unklar sind und dies zu Verunsicherung und Orientierungslosigkeit im Team führt. Das Requirements Engineering in der Rolle als Mittelsmann zwischen Fachbereich und Entwicklungsteam wird als problematisch eingestuft, da das Domänen-Wissen auf RE-Seite oft nicht ausreicht und der Abstimmungsaufwand durch Dreiecksdiskussionen steigt. Dies erschwert die Formulierung und Nutzung einer Ubiquitous Language und die Modellierung des Domänenmodells. Ist der Domänenexperte gleichzeitig in der Rolle des Product Owners tätig, entsteht zudem ein Rollen- und Interessenkonflikt, der eine DDD-Herangehensweise erschwert. Ergebnis der Arbeit ist, dass das Requirements Engineering als Vermittler sich nicht mit DDD vereinbaren lässt, aber unterstützende Funktionen einnehmen kann. Als Handlungsempfehlung kann daraus abgeleitet werden, Situationen zu vermeiden, in denen das Requirements Engineering im Widerspruch zum Domain-Driven Design steht, und Probleme im Entwicklungsprozess mit DDD zu beheben. Methoden und Techniken dafür werden vorgestellt. Die Arbeit ist für Personen interessant, die Aufgaben des Requirements Engineerings in DDD-basierten Entwicklungsprojekten wahrnehmen, also beispielsweise Projektleiter, Product Owner, Requirements Engineers oder Business Analysten.
Die vorliegende Masterarbeit beschäftigt sich mit Lasttests auf Systemebene. Die betrachtete Art von Softwaresystemen ist davon gekennzeichnet, dass diese innerhalb einer vernetzten Umgebung betrieben werden. Das bedeutet, dass diese mit verschiedenen anderen Systemen kommunizieren müssen und von Ereignissen eben dieser abhängig sind. Vorbereitend wird die betrachtete Problemstellung genauer klassifiziert. Dies soll helfen, dass der Leser die Ergebnisse der Arbeit auf eigene Problemstellungen übertragen kann. Weiterhin wird dadurch für die vorliegende Arbeit ein klarer Fokus geschaffen. Nachdem Methoden ermittelt werden, welche in modernen IT-Projekten bei der Testdurchführung eingesetzt werden, beschäftigt sich die vorliegende Arbeit mit den Voraussetzungen für die Testfallbeschreibung und -umgebung. Diese bilden das Ergebnis der vorliegenden Arbeit in Form einer Auflistung zu beachtender Punkte bei Lasttests auf Systemebene bei der betrachteten Art von Softwaresystemen. Hierbei werden jeweils sechs Voraussetzungen anhand aktueller Literatur ermittelt. Um die Anwendbarkeit für laufende und künftige Softwareprojekte gewährleisten zu können, werden die identifizierten Voraussetzungen im Rahmen eines IT-Migrationsprojekts angewendet. Bei dem hier zu testenden Softwaresystem handelt es sich um ein System auf Lagerveraltungs- und Materialflusssteuerungsebene innerhalb eines Intralogistiksystems. Es ist gekennzeichnet durch eine hohe Zahl an verbundenen Systemen zur Prozesssteuerung und einer hohen Materialflussleistung. Abschließend wird ein Fazit aus dem Praxisprojekt gezogen. Die Ergebnisse der vorliegenden Masterarbeit sind für Führungskräfte und insbesondere Testverantwortliche in der Softwareentwicklung gedacht. Beispielsweise Projektleiter, die vor der Herausforderung des Tests eines Softwaresystems in einer vergleichbaren vernetzten Umgebung stehen.
Untersuchung der Kompatibilität von agilen Prozessen und den vorherrschenden Unternehmenskulturen
(2017)
Die vorliegende Arbeit beschäftigt sich mit der Kompatibilität von Unternehmenskulturen und agilen Vorgehensweisen. Das Ziel und die zentrale Fragestellung lautet, welche Unternehmenskulturen mit den
agilen Methoden und dessen Varianten kompatibel sind. Um diese Frage beantworten zu können wird zunächst in die Themen Agilität, agile Methoden und Unternehmenskultur eingeführt. Die Themen werden definiert, Hintergründe dargestellt und Ansätze vorgestellt, die als Grundlage für die weitere Betrachtung dienen. Auf Basis dieser theoretischen Betrachtungen wird eine Herangehensweise ermittelt, die es erlaubt Unternehmenskulturen einzusortieren und mit agilen Methoden zu vergleichen.Dies geschieht auf 2 Ebenen. Auf Ebene der Gemeinsamkeiten der agilen Methoden und auf der Ebene ihrer unterschiedlichen Betonungen der agilen Werte und Prinzipien. Für beide Ebenen werden Soll-Profile der Unternehmenskulturen entwickelt, die eine optimale Abbildung einmal für agile Methoden insgesamt und auf der anderen Seite für die Methoden Scrum, Kanban und Extreme Programming im Speziellen darstellen. Im Zuge der weiteren Masterarbeit werden diese Soll-Profile in der Praxis auf ihre Tauglichkeit hin überprüft, inwieweit mit Ihrer Hilfe eine Aussage über den zu erwartenden Erfolg bei der Einführung verschiedener agiler Methoden möglich ist. Im Zuge dieser Betrachtungen ist zunächst festzuhalten, dass unzählige Ansätze und Modelle zur Erfassung und Typologisierung von Unternehmenskulturen existieren. Der Einfluss der
Unternehmenskultur auf den Erfolg einer Unternehmung ist jedoch unbestritten. Dennoch galt es zuerst einen Überblick über die verschiedenen Modelle zu schaffen um im Anschluss eine für die agilen
Methoden geeignete Typologisierung von Unternehmenskulturen zu ermitteln. Hierzu wurden die ermittelten Typologien sowie ihre jeweiligen Kriterien der Unterscheidung mit den Werten und Prinzipien
des Agilen Manifests, als die Grundlage der Gemeinsamkeiten von agilen Methoden, verglichen. Die Auswertung ergab zum einen, dass keine der betrachteten Typologien sich als vollständig ungeeignet erweist wenigstens mit einem Kriterium das Agile Manifest zu bewerten. In der Summe der Überdeckungen und unter Beachtung weiterer positiver Aspekte, wie der Anzahl der Bewertungsdimensionen und die Vielzahl der Werteaussagen zur Bewertung der Ausprägungen, erwies sich das „Organizational Culture Profile (OCP)“ entwickelt von Charles A. O'Reilly, Jennifer Chatman und David F. Caldwell als am besten geeignet die Kompatibilität von Unternehmenskulturen und agilen
Vorgehensweisen zu betrachten. Nach genauerer Untersuchung der OCP wurden die Bewertungskriterien von O’Reilly, Chatman und Caldwell beibehalten, die Bewertungsmethode Q-Sort jedoch durch die Likert Skala der neueren OCP-Versionen ausgetauscht. Die Likert Skala ist für diese Betrachtung ausreichend und in der praktischen Handhabung deutlich einfacher. Der Einfachheit halber wurde dieser Methodenkombination innerhalb dieser Arbeit der Name „OCPx“ gegeben. Auf Basis des OCPx wurde durch Vergleich mit den Werten und Prinzipien des Agilen Manifests eine Kulturausprägung definiert, die dem Agilen Manifest am nächsten kommt.
Diese Ausprägungen sind wie folgt: Die innovativen, detailgenauen und respektvollen Bereiche der Unternehmenskultur sind Neutral bis
Hoch ausgeprägt, die stabile und aggressive Dimension der Unternehmenskultur hingegen erfährt eine niedrige Betonung. Besonders hoch ist die Ausprägung bei den ergebnisorientierten und teamorientierten Teilen der Unternehmenskultur. Unter Berücksichtigung der unterschiedlichen Betonung der agilen Werte innerhalb der verschiedenen agilen Methoden wurde für die meistverwendeten Methoden Scrum, Kanban und Extreme Programming (XP) die Gewichtung der Unternehmenskulturdimensionen untersucht und angepasst. Im Ergebnis zeigt dies eine Betonung der innovativen und detailgenauen Unternehmenskultur bei Scrum und der stabilen Unternehmenskultur bei XP. Kanban hingegen schwächt die stabile Kultur ab, betont aber die innovative und auch stark die respektvolle Seite der Unternehmenskultur. Die so entwickelten Soll-Profile von Unternehmenskulturen, wurden anschließend hinsichtlich deren Eignung in der Praxis anhand folgender Hypothesen überprüft.
- Je mehr Unternehmenskulturen dem Soll-Profil des OCPx entsprechen, desto erfolgreicher sind sie beim Einsatz agiler Methoden
- Je mehr Unternehmenskulturen dem Soll-Profil des OCPx entsprechen und die Kulturen Stabile und Detailgenaue betonen, desto erfolgreicher sind sie beim Einsatz von Scrum
- Je mehr Unternehmenskulturen dem Soll-Profil des OCPx entsprechen und die Kulturen Innovative und Respektvolle betonen, sowie Stabile Kulturen abschwächen, desto erfolgreicher
sind sie beim Einsatz von Kanban
- Je mehr Unternehmenskulturen dem Soll-Profil des OCPx entsprechen und die Stabile Kultur betonen, desto erfolgreicher sind sie beim Einsatz von XP
Dabei konnte im Rahmen einer Umfrage auf Basis eines standardisierten Fragebogens die erste Hypothese für agile Methoden bestätigt werden und somit die Fragestellung der Arbeit für allgemeine agile Methoden beantwortet werden. Die Differenzierung der Unternehmenskulturen nach einzelnen agilen Methoden war in der Praxis nicht möglich, die Hypothesen konnten nicht bestätigt werden. Anzumerken ist auch, dass der Versuch den Zusammenhang zwischen Unternehmenskultur und erfolgreichen agilen Methoden über Literaturrecherche anhand Praxisbeispielen zu verifizieren nicht erfolgreich war. Grund hierfür ist das Fehlen von einschlägiger Literatur zu konkreten Unternehmenskulturen.
Unternehmen müssen heute schnell am Markt agieren und auf die Bedürfnisse und Anforderungen der Kunden eingehen, um wettbewerbsfähig zu bleiben. Um diesen Anforderungen als Unternehmen gerecht werden zu können, bedarf es innovativen Informationssystemen mit flexiblen Softwarearchitekturen. Die Unternehmenskultur kann in Unternehmen eine starke Position einnehmen, wenn Veränderungen in der Unternehmensstrategie vorgenommen werden. Die Veränderung oder Einführung einer neuen Softwarearchitektur eines Informationssystems stellt hierbei eine solche Veränderung in der Strategie dar. Diese Arbeit beantwortet die Frage, wie sich die Kultur in einem Unternehmen und Softwarearchitektur gegenseitig beeinflussen. Hierzu werden zunächst die theoretischen Grundlagen zu Unternehmenskultur und Softwarearchitektur dargelegt. Anschließend wird der mögliche Einfluss der Unternehmenskultur auf die Softwarearchitektur mittels fünf Dimensionen der Unternehmenskultur beschrieben und dadurch deduktiv 59 Hypothesen zur Wirkungsbeziehung generiert. Das Ergebnis der Arbeit ist, dass Unternehmenskultur durch die gemeinsam geteilten Werte das Verhalten des Softwarearchitekten im Architekturzyklus und somit schließlich auch die entworfene Softwarearchitektur beeinflusst. Ebenso stellt die Unternehmenskultur ausgehend von verschiedenen Dimensionen Qualitätsanforderungen an die Softwarearchitektur. Der mögliche Einfluss der Softwarearchitektur auf die Unternehmenskultur wird in der Arbeit am Beispiel des Microservice-Architekturstils beschrieben. Die Einführung oder Veränderung einer Softwarearchitektur führt zu einer Veränderung der Unternehmenskultur, in dem sie gegenwärtige grundlegende Annahmen und Werte in Frage stellt. Ebenso kann eine neue oder veränderte Softwarearchitektur sich auf die Rahmenbedingungen in der Ablauf- und Aufbauorganisation des Unternehmens auswirken. So wird gezeigt, dass das Modularisierungskonzept des Microservice-Architekturstils verschiedene Dimensionen der Unternehmenskultur positiv begünstigen kann.