Immer mehr Unternehmen im Maschinen- und Anlagenbau versuchen sich daran, ihren Entwicklungsprozess „agil zu machen“. Erfolgsgeschichten, größtenteils aus der Software-Entwicklung, sind verlockend: erhöhte Flexibilität, Transparenz in der Entwicklung und vor allem die Fähigkeit schnell neue Produkterneuerungen zu entwickeln, zu testen und an den Markt zu bringen.
Die Herausforderungen, vor denen Unternehmen aktuell stehen erfordern ein Umdenken bei der Produktentwicklung: Technologische Innovationszyklen werden immer kürzer, während der wirtschaftliche und technische Wettbewerb intensiver wird. Gleichzeitig nimmt der Funktionsumfang in Produkten immer weiter zu. Hierbei fällt es vielen Unternehmen schwer, die Produktanforderungen schon zu Anfang der Entwicklung explizit zu definieren. Unternehmen müssen daher schneller entwickeln und gleichzeitig sehr lange im Entwicklungsprozess noch flexibel auf Änderungen von Anforderungen reagieren.
Die aus der Software-Entwicklung stammende Philosophie der Agilen Entwicklung verspricht Antworten auf diese Herausforderungen: Agilität ist „die Fähigkeit, schnell und kooperativ auf Veränderungen in unvorhersehbaren Umwelten (zumeist reaktiv) einzugehen, um Bedarfe effizient und effektiv zu befriedigen.“. Bei der Entwicklung von Softwareprodukten sind agile Entwicklungsmethoden schon weitestgehend Standard, die bekanntesten sind hier SCRUM, Kanban oder XP.
Die folgende Grafik zeigt beispielhaft das Framework der bekannten agilen Entwicklungsmethode SCRUM. Im Zentrum stehen iterative kurze Entwicklungszyklen von 1-4 Wochen, sogenannte Sprints (Quelle: https://www.scrum-academy.com/).
Bei dem Transfer solcher Entwicklungsmethoden für die Entwicklung komplexer physischer Produkte tun sich viele Unternehmen jedoch schwer.
Mehrere Faktoren machen den Transfer auf physische Produkte zu einer Herausforderung. So ist beispielsweise die schnelle iterative Entwicklung von Prototypen ein wichtiges Prinzip von Agile. Während bei der Softwareentwicklung neue Prototypen innerhalb von Sekunden oder Minuten kompiliert werden können benötigt die Herstellung von physischen Prototypen, je nach Produkt, eine deutlich längere Zeit. Insbesondere, wenn Zulieferketten für die Herstellung eines Prototyps eingebunden werden müssen, zieht sich die Herstellzeit deutlich in die Länge.
Eine weitere Herausforderung ist die Separierung von Teilumfängen für Prototypen. Damit nicht für die Weiterentwicklung einer Teilfunktion ein Prototyp einer gesamten komplexen Maschine erzeugt werden muss, muss es möglich sein Teilumfänge der Maschine über klar definierte Schnittstellen zu separieren.
Es hat sich weiterhin gezeigt, dass der Einsatz von agilen Entwicklungsmethoden besonders bei großen Entwicklungsprojekten mit global verteilten Entwicklungsabteilungen eine Herausforderung darstellt. Das ist z.B. bei der Entwicklung von komplexen mechatronischen Produkten wie Flugzeugen, Automobilen aber zunehmend auch im Maschinen- und Anlagenbau der Fall.
Neben diesen Herausforderungen, die dem Transfer der Methoden aus der Software- in die Hardware-Welt ohnehin schon inhärent sind, spielt auch die Produktarchitektur und die daraus folgende Produktstruktur eine große Rolle. Diese kann agile Entwicklung entweder unterstützen oder verhindern.
Wie eine Produktarchitektur die agile Entwicklung unterstützen kann, lässt sich an einem Beispiel zeigen. Auch hier müssen wir auf eine Erfolgsgeschichte aus der Softwareentwicklung zurückgreifen.
Ein Trend bei der Entwicklung von Software-Services sind die sogenannten Micro-Services, die von Unternehmen wie Amazon oder Netflix eingesetzt werden, um Ihre Online-Dienstleistungen bereitzustellen.
Es war lange üblich Softwaresysteme monolithisch zu entwickeln, so dass alle Anforderungen und Funktionalitäten von einem einzelnen großen System abgedeckt werden.
Micro-Services brechen mit dieser Tradition. Das Gesamtsystem wird in kleinere modulare Einheiten zerlegt. Diese kleineren Einheiten können unabhängig voneinander entwickelt, produziert und eingesetzt werden. Dies ist die Voraussetzung für Continuous Delivery - also die kontinuierliche Entwicklung und Verbesserung der einzelnen Micro-Services und damit des Gesamtsystems.
Die Grafik zeigt den Vergleich zwischen einem monolithischen System, dass alle Funktionalitäten abdeckt und einer Microservice-Architektur, bei der die Funktionalitäten in mehrere Micro-Services aufgeteilt sind (Quelle: https://dev.to/).
Damit dies gelingt müssen die einzelnen Einheiten den Prinzipien der Modularität folgen:
Ein Micro-Service sollte eine fachliche Einheit darstellen, so dass Änderungen bestimmter fachlicher Anforderungen jeweils nur einen Micro-Service betreffen (Prinzip der Funktionsbindung). Die Micro-Services müssen so gestaltet sein, dass diese möglichst unabhängig voneinander sind (Prinzip der Entkopplung). Nur so können die durch unterschiedliche Teams unabhängig voneinander entwickelt werden.
Die vereinheitlichten Schnittstellen zur Kommunikation zwischen den einzelnen Services werden durch eine entsprechende Infrastruktur bereitgestellt (Prinzip der Schnittstellenstandardisierung). Das Gesamtsystem ergibt sich dann durch die Kombination der verschiedenen Micro-Services (Prinzip der Kombinarbarkeit).
Leseempfehlung: Erfahren Sie mehr über die Definition von Modularität in unserem weiterführenden Artikel zu dem Thema.
Diese Zerlegung eines monolithischen Produktes in ein System von modularen Einheiten ist die Voraussetzung für die agile Entwicklung dieser Micro-Services. Die einzelnen Services sind so gestaltet, dass diese unabhängig voneinander entwickelt werden können. Die Größe eines einzelnen Service ist dabei begrenzt, so dass die Entwicklung von einem SCRUM Team von 3-9 Personen bewältigt werden kann.
So gelingt es, dass die Teams unabhängig voneinander agile Iterationen bei der Entwicklung vollziehen können. Das Produkt wird kontinuierlich durch die Neu- und Weiterentwicklung einzelner Micro-Services erneuert.
Dieser Zusammenhang zwischen Modularität und agilen Entwicklungsmethoden ist kein Zufall sondern kausal bedingt.
Schon 1967 sagte Mel Conway "Organisationen können nur Architekturen hervorbringen, die Ihren Kommunikationsbeziehungen entsprechen". Eine Aussage die heute in der Softwareentwicklung als Conway’s law bekannt ist.
Will also eine Organisation ihre Entwicklung in Form von kleinen agilen Teams organisieren, so muss die Architektur des zu entwickelnden Produktes dieses ermöglichen. Die Architektur muss den Prinzipien der Modularität folgen und Module und Entwicklungsteams müssen zueinander passen.
Modularität ist also eine wichtige Zutat für die agile Entwicklung. Um die ohnehin großen Herausforderungen bei der Umsetzung von agilen Prinzipien auf komplexe physische Produkte bewältigen zu können, kann die Modularisierung der Produktarchitektur als Wegbereiter genutzt werden.
Wollen Sie sich den Themen Agile Entwicklung und Modularität widmen? Lesen Sie hier, mit welchen Methoden Sie Ihre modulare Produktarchitektur als Basis eines modularen Baukastens definieren können und laden Sie sich den dazu passenden „step-by-step“ guide herunter.