Modularität

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Modulbauweise)
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 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 im Design (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]

Funktionsprinzipien[Bearbeiten]

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

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]

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]

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.

Innovationshemmende Wirkung: Wie Fleming und Sorenson, die - über 200 Jahre hinweg - die Daten des US-amerikanischen Patentamts auswerteten, feststellen, kann der Trend zu hochgradiger Modularität die Innovationsfähigkeit eines Systems infragestellen. Während einerseits ein solches Design die Produktentwicklung möglichst vorhersagbar machen kann, kann andererseits ein Punkt erreicht werden, wo Modularisierung die Chancen für einen Durchbruch in der Produktentwicklung untergräbt.[2]

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

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]

Literatur[Bearbeiten]

Einzelnachweise[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 Fleming, L., Sorenson, O.: The dangers of modularity. Harvard Business Review, 79(8), 2001, S. 20-21
  3. Modularis