Modularität

Modularisierung ist eine Weiterleitung auf diesen Artikel. Das Prinzip in der Programmierung ist unter modulare Programmierung beschrieben.

Modularität (auch Baustein- oder Baukastenprinzip) ist die Aufteilung eines Ganzen in Teile, die als Module, Komponenten, Bauelemente, Baugruppen 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 Systeme aus Bauteilen 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 (Mass Customization, z. B. in Automobilbau, Computer-Fertigung und Architektur) sowie Modularität im Gebrauch (“Plug and Play”).

Wissenschaftlicher Hintergrund

Einige Forscher geben eine Definition von der Architektur von allgemeinen Systemen, während andere sich dabei auf die Architektur von Produkten beziehen. 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:

• Crawley u. a. (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.

• 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.

• 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.

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.

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 dass sie dabei einen Verlust von Funktionalität erleiden, einen hohen Grad an Modularität zu.

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.

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. Diese Beobachtung, dass es bei wissensintensiven Prozessen zu einem industrieübergreifenden Wandel zu immer höher spezialisierten Unternehmen und damit auch einer Zunahme an verteilten oder auch unternehmensübergreifenden Entwicklungen neuer komplexer Systeme kommt, wurde später von weiteren Forschern bestätigt.

So wurde dieser Wandel in der Festplatten-, Computer- Mikroprozessor- High-Fidelity-, Fahrrad- und Automobilindustrie nachgewiesen. Die effiziente Umsetzung dieses Trends wird erst durch modulare Produktarchitekturen ermöglicht.

Funktionsprinzipien

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.

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

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.

Herausforderungen

Immer mehr Unternehmen strukturieren ihre Produkte in Baukästen, um individuell konfigurierbare Endprodukte erzeugen zu können, ohne auf baureihenübergreifende Skaleneffekte verzichten zu müssen. Aufgrund entscheidender Unterschiede zwischen Baukastensystem und der klassischen Produktenentwicklung stehen Unternehmen bei der Baukastengestaltung vor der Herausforderung erhöhter Entwicklungsaufwände, da sich Module nicht mehr auf einzelne Produkte und deren Produktionsprozesse beziehen, sondern eine ungleich höhere Produktvielfalt ermöglichen. Die Unterschiedlichen Kundenanforderungen müssen durch standardisierte Bausteine und individuelle Anpasselemente flexibel über den Baukasten realisierbar sein. Organisatorisch stehen Unternehmen vor der Herausforderung, den übergreifenden Einsatz von Baugruppen und Modulen innerhalb des Baukastens mit der notwendigen Akzeptanz und Verständnis bei den Mitarbeitern zu etablieren.

Anforderungen der Baukastengestaltung

Das Schaffen von Akzeptanz und Verständnis für die branchenübergreifende Anwendbarkeit und alle an der Wertschöpfung beteiligten Bereiche des Baukastenentwicklungsprozesses ist von großer Bedeutung. Der Fokus liegt nicht alleine auf dem Produkt, sondern auch auf der Produktion, der Montage, dem Markt und weiteren Feldern der Wertschöpfungskette, die in den Entwicklungsprozess eingebunden werden sollen, sodass alle Beteiligten zu jedem Zeitpunkt den Überblick über den Entwicklungsstand behalten und sich einbringen können.

Vorteile und Nutzen

Unimog 405 mit Heckenschere von MULAG als modulares Anbaugerät. Durch verschiedene kompatible Module die zur Verfügung stehen und angebracht, entfernt, gewechselt oder anders gruppiert werden können, lässt sich das Fahrzeug-System an verschiedene Bedingungen anpassen

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

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, dass 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.

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

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 Performance des gesamten Systems verstellt werden.

Anwendungsbeispiele

• Normteile (genormte technische Bauteile als funktionelle Einzelteile) und standardisierte Baugruppen (Montagegruppen) in Maschinenbau und anderen Gebieten der Technik, über die etwa Baukastenstücklisten (nach DIN 6789) geführt werden. Bedeutende Einsatzgebiete sind u. a.:
  • Raumstationen
  • Plattformstrategie im Fahrzeugbau
  • in Computern, in denen austauschbare Bauteile über standardisierte Schnittstellen kommunizieren (z. B. Steckkarten oder Speichermodule). Der IBM-PC und seine Nachfolger verdanken ihre Verbreitung auch und gerade diesem Effekt.
  • Modularer Maschinenbau, insbesondere technische Großanlagen wie Kraftwerke und Verkehrsanlagen, aber auch kleinere Maschinen wie ein modularer Seilzug
  • Elektrische und elektronische Bauelemente: Bestückung von Platinen
  • Das 19-Zoll-Aufbausystem (Rack) der Elektronik
  • Lego, Fischertechnik oder Rasti
• In Architektur und Bauwesen
  • In Serie vorgefertigte Bauteile
  • Gebäude aus modularen Raumelementen (zum Beispiel Containergebäude oder Modulbauten)
  • Gebäudekomplexe, insbesondere Hochhäuser, aus modularen Gebäudeteilen (Gebäudeflügeln), zum Beispiel das Crystal Palace (London, 1851)
  • Möbelbausysteme wie USM Haller
• Komponentenbasierte Entwicklung von Software, Gruppen von Befehlen als funktionsorientierte Komponenten in Computerprogrammen, die eine bestimmte Funktion erfüllt und über eine definierte Schnittstelle aufgerufen wird:
  • Softwaremodule für wiederkehrende Aufgaben
  • Kernel-Module, Betriebssystemkomponenten, die nur bei Bedarf aktiviert werden, im Gegensatz zum Kernel
• Geschäftsprozessmodellierung bzw. Business Process Reengineering zur Optimierung der Abläufe in einem Unternehmen
• gestufte Studiengänge im Hochschulwesen
• Content-Management bzw. Wissensmodellierung mit Hilfe eines Wikis modularisiert das zu dokumentierende Wissen äußerst feingranular. Die Schnittstellen sind die Links zwischen den einzelnen Wissenseinheiten (also Wiki-Seiten).
• beim Militär, welche sich zu einem modularen Aufbau hin wandelt, siehe Transformation (Militärwissenschaft)
• bei Modularen Synthesizern zur Klangsynthese
• Produktions- und Kompositionstechnik für Popmusik entwickelt von Brian Wilson, bekannt geworden durch Good Vibrations und Smile
• Modularer Modelleisenbahnbau bei großen Modelleisenbahnanlagen
• bedarfsgerechte Dosierung der waschaktiven Substanzen durch ein Waschmittel-Baukastensystem, das es beispielsweise erlaubt, den benötigten Wasserenthärter - je nach Wasserhärte vor Ort - getrennt zuzusetzen und somit, diesen unabhängig zu dosieren
• Modularis ist ein System, das eine Physical-Computing-Plattform als Baukasten bereitstellt

Siehe auch

• Integrationsmodell: Baukasten & Modularität

Literatur

• Margit Osterloh: Das Management von Strukturen und Prozessen. IOU – Institut für Organisation und Unternehmenstheorien, Universität Zürich, 2. Mai 2006 (PDF auf uzh.ch).
• K. B. Clark, C. Y. Baldwin: Design Rules. Band 1: The Power of Modularity. MIT Press, Cambridge, Massachusetts 2000, ISBN 0-262-02466-7 (englisch).
• Ron Sanchez im Interview: Modularity: upgrading to the next generation design architecture. In: Connected Magazine Dossiers. 12. Mai 2000 (englisch; Professor für Strategie und Technologie Management am IMD - International Institute for Management Development, Lausanne).
• Stefano Brusoni, Andrea Prencipe: Unpacking the black box of modularity: Technologies, products and organizations. In: Industrial and Corporate Change. Band 10. 2001, S. 179–205 (englisch; PDF: 1,3 MB auf rollins.edu).
• Günther Schuh: Produktkomplexität managen: Strategien - Methoden - Tools. Hanser, München, August 2017, ISBN 978-3-446-45225-1.
• Günther Schuh: Leitfaden zur Baukastengestaltung. VDMA, Frankfurt/M. 2015, ISBN 978-3-8163-0674-0.

Weblinks

Wiktionary: Modularität – Bedeutungserklärungen, Wortherkunft, Synonyme, Übersetzungen

Einzelnachweise

1. Margit Osterloh: (Memento des Originals vom 4. März 2016 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.uzh.ch. IOU – Institut für Organisation und Unternehmenstheorien, Universität Zürich, 2. Mai 2006.
2. 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. (PDF) Monograph of the MIT ESD Architecture Committee. In: Engineering Systems Symposium Proceedings. März 2004, abgerufen am 29. April 2016 (englisch). 
3. 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. 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. 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. 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. L. Fleming, O. Sorenson: The dangers of modularity. In: Harvard Business Review. 79(8), 2001, S. 20–21.
27. Modularis.