Modularität

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Modularität (auch Baustein- oder Baukastenprinzip) ist die Aufteilung eines Ganzen in Teile, die als Module, Komponenten, Bauelemente oder Bausteine bezeichnet werden. Bei geeigneter Form und Funktion können sie zusammengefügt werden oder über entsprechende Schnittstellen interagieren.

Bei einem modularisierten Aufbau werden Gesamtsysteme aus standardisierten Einzelbauteilen entlang definierter Stellen (bei Programmen Schnittstellen) zusammengesetzt. Die gegenteilige Bauweise nennt man einen integralen Aufbau, oder auch monolithisch (griechisch monólithos, „der Einstein“). Dies kann sich sowohl auf reale Objekte, als auch auf immaterielles, wie beispielsweise eine Ausbildung beziehen.

Als Anwendungsparadigmen für Modularität lassen sich u.a. unterscheiden Modularität in der Entwicklung (z. B. in Anlagenbau, Softwarearchitektur oder Unternehmensorganisation), Modularität in der Produktion bzw. beim Bau (Mass Customization, z. B. in Automobilbau, Computer-Fertigung und Architektur) sowie Modularität im Gebrauch (“Plug and Play”).[1]

Wissenschaftlicher Hintergrund[Bearbeiten | Quelltext bearbeiten]

Einige Forscher geben eine Definition von der Architektur von allgemeinen Systemen[2][3], während andere sich dabei auf die Architektur von Produkten beziehen[4]. Den verschiedenen Definitionen liegt dennoch der gleiche Gedanke zugrunde, dass Architektur den strukturellen Aufbau eines Systems beschreibt und somit als ein Entwurf anzusehen ist, welcher die Bestandteile eines Systems, deren jeweilige Funktionen und die Schnittstellen zwischen diesen definiert[5]:

  • Crawley et al. (2004) identifizieren die Architektur als Schlüsselelement für die Planung, den Betrieb und das Verhalten komplexer Systeme. Dabei ist die Architektur eine abstrakte Beschreibung eines Systems, seiner Elemente und der Beziehungen zwischen diesen. Die Architektur ist in der Lage die Funktionen und Eigenschaften von Systemen zu beeinflussen.[2]
  • Sanchez und Mahoney (1996) beschreiben die Architektur eines komplexen Systems, ob nun ein Produkt oder aber eine organisationale Struktur, als ein Konstrukt aus mehreren miteinander interagierenden Teilen, welche zu einem gewissen Grad voneinander abhängig sind. In einer weiteren Definition der Architektur von Produkten erklären Sanchez und Mahoney, dass eine Komponente innerhalb einer Produktdesigns eine Funktion innerhalb eines Systems, von miteinander interagierenden Komponenten, ausübt und deren gemeinsame Funktionen das Produkt abbildet. Die Beziehungen zwischen den Komponenten und der sie verbindenden Schnittstellen bildet die Produktarchitektur.[3]
  • Architektur ist das Muster, nach welchem Funktionen physikalischen Objekten zugeordnet werden und wie diese miteinander interagieren. Auf dieser Definition basierend erklärt Ulrich (1995) die Architektur eines Produktes weiter als Anordnung funktionaler Elemente, die Zuordnung dieser zu physikalischen Komponenten sowie die Festlegung der Schnittstellen zwischen diesen. Dabei bezeichnet Ulrich funktionale Elemente als einzelne Funktionen, welche durch das Produkt erfüllt werden. Die Anordnung dieser stellt damit eine funktionale Struktur dar. Ein physikalisches Produkt besteht dabei aus einer oder mehrerer Komponenten, welche die funktionalen Elemente des Produktes ausüben. Hierbei können eine oder mehrere dieser Komponenten auch einem oder mehreren funktionalen Elementen zugeordnet werden und diese ausüben. Die gegenseitig aufeinander einwirkenden Komponenten sind dabei mit Schnittstellen verbunden, welche die Interaktionen zwischen ihnen koordinieren.[4]

Ist ein funktionales Element genau einer Komponente des Systems zugeordnet, spricht man von einer eher modularen Struktur. Wird ein funktionales Element von mehreren Komponenten ausgeübt, spricht man von einer eher integralen Struktur. Aus diesem Grund können sich Systeme, welche die gleichen Aufgaben erfüllen, in ihrer Architektur grundlegend unterscheiden.[3][4][6]

Die Zustände komplett modularer oder integraler Produkte sind keine klar bestimmten Zustände und stellen in der Realität eher nicht aufzufindende Fälle dar. Dennoch lassen sich Systemenarchitekturen vom Grad der beiden Zustände differenzieren, befinden sich auf einer, in ihren Grenzen, nicht klar festgelegten Skala zwischen diesen beiden Extremfällen und können sich jeweils einem Zustand annähern oder aber auch davon entfernen. So sagt man Systemen, welche man in ihre Komponenten zerteilen, umgestalten und wieder zusammenfügenkann, ohne das sie dabei einen Verlust von Funktionalität erleiden, einen hohen Grad an Modularität zu.[7][8][9][10][11]

Die kleinste vornehmbare Änderungen an einem System ist eine Änderungen einer der Komponenten. Die Systemarchitektur bestimmt dabei, welche funktionalen Elemente durch eine Änderung beeinflusst werden und welche weiteren Komponenten davon betroffen sind. Darum steht die Art der Architektur eines Systems in direktem Zusammenhang mit dem Grad seiner Komplexität und der Möglichkeit Veränderungen in diesem durchzuführen.[4]

George Stigler beobachtete, dass viele Industrien durch ihre kleine Größe mit einer vertikal integrierten Struktur begannen und im Laufe ihres Wachstums die Anzahl an spezialisierten Unternehmen zunahm.[12] Diese Beobachtung, dass es bei wissensintensiven Prozessen zu einen industrieübergreifenden Wandel zu immer höher spezialisierten Unternehmen und damit auch einer Zunahme an verteilter oder auch unternehmensübergreifender Entwicklungen neuer komplexer Systeme kommt, wurde später von weiteren Forschern bestätigt.[13]

So wurde dieser Wandel in der Festplatten-[14], Computer-[15][16][14], Mikroprozessor-[17][14], High Fidelity-[16], Fahrrad-[18] und Automobilindustrie[19] nachgewiesen. Die effiziente Umsetzung dieses Trends wird erst durch modulare Produktarchitekturen ermöglicht.

Funktionsprinzipien[Bearbeiten | Quelltext bearbeiten]

Skizze eines kleinen Nachbarschaftsnetzwerks mit drei voneinander relativ unabhängigen Komponenten (oder Modulen). Die wenigen Verbindungen der Module untereinander repräsentieren ihre Schnittstellen.

Das Konzept der Modularität wurde in der Forschung mit unterschiedlichen zugrundeliegenden Definitionen behandelt. Diesen Definitionen unterliegt generell das Verständnis, dass Modularität den Zustand eines Systems beschreibt in welchem die Abhängigkeiten zwischen den einzelnen Komponenten niedrig gehalten und ihre Interaktionen miteinander über standardisierte Schnittstellen koordiniert werden. Einzelne bis alle Komponenten des Systems sind dabei durch andere Komponenten austauschbar ohne die Funktionsfähigkeit des Gesamten zu gefährden.[20][4][16][21]

Als Folge eines solchen Systemzustandes können die einzelnen Module weitgehend unabhängig voneinander operieren oder bei einem Produkt voneinander entwickelt und hergestellt werden.[22][3][23][24]

Einzelne Komponenten lassen sich unterschiedlich zu einem Ganzen kombinieren, wenn sie wie Spielbausteine ausgeführt sind – das beschreibt das sprachliche Bild, das Gegenteil wäre einem Puzzle vergleichbar, bei dem jede Komponente nur genau einen möglichen Platz hat, und das System nur als ein ganzer Block (monolithisch) funktioniert.

Ein großer Vorteil ist, dass man alte Module leicht gegen neue Module austauschen oder neue Module zum Ganzen hinzufügen kann. Dafür brauchen Module klare Schnittstellen – möglichst genormt, um Probleme der Kompatibilität (des „Zusammenpassens“) gering zu halten.

Änderungen innerhalb von Modulen sollten sich nicht auf andere Module auswirken. Dieses Prinzip nennt man lokale Stetigkeit bei Änderungen. Um Änderungen möglichst problemlos durchführen zu können, sollte die Anzahl der Schnittstellen möglichst klein sein. Treten Fehler in Modulen auf, dürfen diese Fehler andere Module nicht in Mitleidenschaft ziehen ("lokaler Schutz bei Ausnahmefehlern"). Diese Prinzipien betreffen beispielsweise die Modularität von Softwareprojekten, sind jedoch auch auf andere Bereiche anwendbar. Hierdurch ist es auch möglich, die statistische Lebensdauer von Modulen untereinander zu entkoppeln und z. B. Innovationen gezielt und störungsfrei in bestehende Systeme einzubringen.

Module setzen das Black-Box-Modell um. Informationen sind nur über explizite Schnittstellen zugänglich.

Vorteile und Nutzen[Bearbeiten | Quelltext bearbeiten]

Durch die Modularität von komplexen Systemen lässt sich deren Verständlichkeit für den Menschen erhöhen. Für den Hersteller bzw. das Unternehmen, für den Service wie auch für den Konsumenten bzw. Kunden kann ein Baukastenprinzip Vorteile bringen, besonders wenn unterschiedliche Unternehmen am Markt als Anbieter von weitgehend standardisierten Einzelkomponenten bzw. Geschäftsprozessen miteinander konkurrieren. Mögliche Vorteile sind:

  • niedrigere Entwicklungs- bzw. Geschäftsprozesskosten: Modularisierung reduziert Koordinations- und Kommunikationskosten und ermöglicht Outsourcing und Benchmarking.
  • Flexibilität in der Produkt- bzw. Organisationsentwicklung: schnellere Produktzyklen und höhere Anpassungsfähigkeit, wenn verschiedene kompatible Module zur Verfügung stehen, die angebracht, entfernt, gewechselt oder anders gruppiert werden können, um das System an neue Bedingungen anzupassen. Ein monolithisches System hingegen kann solche Anpassungen nur in Form einer Strukturumwandlung bewerkstelligen, wenn die Parametrisierung seiner Funktionen nicht eine passende Einstellung erlaubt.
  • Flexibilität im Angebot: größere Produktvarietät
  • billigere Herstellung durch baugleiche Serien und einfachere Montageprozesse
  • Wartung: kostengünstige Reparatur durch Austausch der fehlerhaften Komponente

Grenzen und Risiken der Modularisierung[Bearbeiten | Quelltext bearbeiten]

Verarbeitungsgeschwindigkeit und Anpassungsfähigkeit: Modularisierung hat dort ihre Grenzen, wo ein System sehr spezifischen Anforderungen gerecht werden muss, insbesondere im Hinblick auf Verarbeitungsgeschwindigkeit (Performance) oder problemspezifische Anpassungsfähigkeit. Ursache sind in der Regel die hohen Kosten

  • für eine Änderung bzw. Erweiterung der Schnittstellen zwischen den Modulen, wenn sich durch den Austausch eines Moduls allein keine weitere Verbesserung mehr erzielen lässt;
  • für eine Anpassung des Gesamtsystems (sofern überhaupt möglich) an kundenindividuelle bzw. problemspezifische Anforderungen.

In der Informationstechnik beispielsweise gibt es Unternehmen, die sich darauf spezialisiert haben, kunden-individuelle Software-Lösungen (Individualsoftware) zu entwickeln. Solche Komponenten werden von ihren Kunden (trotz ggf. höherer Kosten) ergänzend oder alternativ zu Standardsoftware eingesetzt, wenn diese den Anforderungen nicht genügt.

Hemmende Wirkung richtungsweisender Innovationen: Wie Fleming und Sorenson, welche Daten des US-amerikanischen Patentamts aus einem Zeitraum von 200 Jahren auswerteten, feststellen, kann der Trend zu hochgradiger Modularität die Innovationsfähigkeit eines Systems negativ beeinflussen. Während einerseits ein modulares Design die Produktentwicklung vorhersagbar machen kann und die Innovationsraten der einzelnen Module beschleunigt, kann andererseits ein Punkt erreicht werden, wo Modularisierung die Chancen für einen richtungsweisenden modulübergreifenden Durchbruch in der Produktentwicklung untergräbt. Gemäß der Untersuchung ihres Modells übt das Abhängigkeitsverhältnis zwischen den Modulen den größten Einfluss auf die Wahrscheinlichkeit modulübergreifender und somit potenziell richtungsweisender Innovationen aus. Ihr Modell ergibt das gute Innovationen in Situationen hoher Abhängigkeiten zwischen den Modulen signifikantere Auswirkungen haben können als die besten Innovationen in Situationen niedriger Abhängigkeiten. Um den Nutzen von Innovationen zu optimieren empfehlen sie daher eine Balance, zwischen dem Grad der Abhängigkeiten und Unabhängigkeiten innerhalb eines Systems, zu finden.[25]

Imitierbarkeit: Gerade die Vorhersagbarkeit, die für einen modularen Ansatz typisch ist, kann dazu führen, dass ein konkurrierendes Unternehmen ähnliche Produkte entwickelt.[26]

Kooperationsfähigkeit und strategische Steuerung: Unter den organisatorischen Einheiten, die für je einzelne Module in der Produktentwicklung bzw. einzelne Prozesse im Unternehmen zuständig sind, kann es zu einem verringerten Austausch von (implizitem) Wissen und zu einer reduzierten Kooperationsfähigkeit kommen. Dadurch kann der Blick auf die Performanz des gesamten Systems verstellt werden.[1]

Anwendungsbeispiele[Bearbeiten | Quelltext bearbeiten]

Literatur[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. a b Margit Osterloh: Das Management von Strukturen und Prozessen. IOU – Institut für Organisation und Unternehmenstheorien, Universität Zürich, 2. Mai 2006
  2. a b Edward Crawley, Olivier de Weck, Steven Eppinger, Christopher Magee, Joel Moses, Warren Seering, Joel Schindall, David Wallace, Daniel Whitney: THE INFLUENCE OF ARCHITECTURE IN ENGINEERING SYSTEMS. Monograph of the MIT ESD Architecture Committee. In: Engineering Systems Symposium Proceedings. März 2004, abgerufen am 29. April 2016 (PDF, englisch).
  3. a b c d Ron Sanchez, Joseph T. Mahoney: Modularity, flexibility, and knowledge management in product and organization design. In: Strategic Management Journal. Band 17, Nr. 2, 1996, S. 63–76, doi:10.1002/smj.4250171107.
  4. a b c d e Karl Ulrich: The role of product architecture in the manufacturing firm. In: Research Policy. Band 24, Nr. 3, 1995, S. 419–440, doi:10.1016/0048-7333(94)00775-3.
  5. C. Y. Baldwin, K. B. Clark: Managing in an Age of Modularity. In: Harvard Business Review. Band 75, Nr. 5, 1997, S. 84–93.
  6. Alan MacCormack, John Rusnak, Carliss Y. Baldwin: Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code. In: Management Science. Band 52, Nr. 7, 2006, S. 1015–1030, doi:10.1287/mnsc.1060.0552.
  7. Carliss Y. Baldwin, Kim B. Clark: The Architecture of Participation: Does Code Architecture Mitigate Free Riding in the Open Source Development Model? In: Management Science. Band 52, Nr. 7, 2006, S. 1116–1127, doi:10.1287/mnsc.1060.0546.
  8. Anna Cabigiosu, Arnaldo Camuffo: Beyond the “Mirroring” Hypothesis: Product Modularity and Interorganizational Relations in the Air Conditioning Industry. In: Organization Science. Band 23, Nr. 3, 2012, S. 686–703, doi:10.1287/orsc.1110.0655.
  9. Sendil K. Ethiraj, Daniel Levinthal: Modularity and Innovation in Complex Systems. In: Management Science. Band 50, Nr. 2, 2004, S. 159–173, doi:10.1287/mnsc.1030.0145.
  10. Manuel E. Sosa, Steven D. Eppinger, Craig M. Rowles: The Misalignment of Product Architecture and Organizational Structure in Complex Product Development. In: Management Science. Band 50, Nr. 12, 2004, S. 1674–1689, doi:10.1287/mnsc.1040.0289.
  11. Glenn Hoetker: Do Modular Products Lead to Modular Organizations? In: Strategic Management Journal. Band 27, Nr. 6, 2006, S. 501–518, doi:10.1002/smj.528.
  12. George J. Stigler: The Division of Labor is Limited by the Extent of the Market. In: Journal of Political Economy. Band 59, Nr. 3, 1951, S. 185–193.
  13. Sebastian K. Fixson, Jin-Kyu Park: The power of integrality: Linkages between product architecture, innovation, and industry structure. In: Research Policy. Band 37, Nr. 8, 2008, S. 1296–1316, doi:10.1016/j.respol.2008.04.026.
  14. a b c Clayton M. Christensen, Matt Verlinden, George Westerman: Disruption, disintegration and the dissipation of differentiability. In: Industrial and Corporate Change. Band 11, Nr. 5, 2002, S. 955–993, doi:10.1093/icc/11.5.955.
  15. Ron Adner, Daniel Levinthal: Demand Heterogeneity and Technology Evolution: Implications for Product and Process Innovation. In: Management Science. Band 47, Nr. 5, 2001, S. 611–628, doi:10.1287/mnsc.47.5.611.10482.
  16. a b c Richard N. Langlois, Paul L. Robertson: Networks and innovation in a modular system: Lessons from the microcomputer and stereo component industries. In: Research Policy. Band 21, Nr. 4, 1992, S. 297–313, doi:10.1016/0048-7333(92)90030-8.
  17. Allan Afuah: Dynamic Boundaries of the Firm: Are Firms Better off Being Vertically Integrated in the Face of a Technological Change? In: The Academy of Management Journal. Band 44, Nr. 6, 2001, S. 1211–1228, doi:10.2307/3069397.
  18. Peter Galvin, Andre Morkel: The effect of product modularity on industry structure: The case of the world bicycle industry. In: Industry and Innovation. Band 8, Nr. 1, 2001, S. 31–47, doi:10.1080/13662710120034392.
  19. Nicholas Argyres, Lyda Bigelow: Innovation, Modularity, and Vertical Deintegration: Evidence from the Early U.S. Auto Industry. In: Organization Science. Band 21, Nr. 4, 2010, S. 842–853, doi:10.1287/orsc.1090.0493.
  20. Melissa A. Schilling: Toward a General Modular Systems Theory and Its Application to Interfirm Product Modularity. In: The Academy of Management Review. Band 25, Nr. 2, 2000, S. 312–334, doi:10.5465/AMR.2000.3312918.
  21. Herbert A. Simon: The Architecture of Complexity. In: Proceedings of the American Philosophical Society. Band 106, Nr. 6, 1962, S. 467–482.
  22. Richard N. Langlois: Modularity in technology and organization. In: Journal of Economic Behavior & Organization. Band 49, Nr. 1, 2002, S. 19–37, doi:10.1016/S0167-2681(02)00056-2.
  23. Christian Terwiesch, Christoph H. Loch, Arnoud De Meyer: Exchanging Preliminary Information in Concurrent Engineering: Alternative Coordination Strategies. In: Organization Science. Band 13, Nr. 4, 2002, S. 402–419, doi:10.1287/orsc.13.4.402.2948.
  24. Fabrizio Salvador, Cipriano Forza, Manus Rungtusanatham: Modularity, product variety, production volume, and component sourcing: theorizing beyond generic prescriptions. In: Journal of Operations Management. Band 20, Nr. 5, 2002, S. 549–575, doi:10.1016/S0272-6963(02)00027-X.
  25. Lee Fleming, Olav Sorenson: Technology as a complex adaptive system: evidence from patent data. In: Research Policy. Band 30, Nr. 7, 2001, S. 1019–1039, doi:10.1016/S0048-7333(00)00135-9.
  26. Fleming, L., Sorenson, O.: The dangers of modularity. Harvard Business Review, 79(8), 2001, S. 20-21
  27. Modularis