In dem Beitrag “The Dawn of the In-House Software” des Portals Logistics Tech Outlook spricht CIO Kevin Glynn von DSC Logistics über Vorzüge der Software-Entwicklung durch eigene Teams. Durch die immer weiter steigende Zugänglichkeit der Werkzeuge und die stetige Verbesserung der Prozesse sowie durch agile Methoden und einfach verfügbare Cloud-Lösungen ist es so einfach wie noch nie die Entwicklung unternehmenskritischer Software im Haus durchzuführen.
Inhouse-Development als Gegenpol zu Softwarepaketen
Ein Vorteil der internen Entwicklung ist die Möglichkeit einzelne Features auszurollen, anstelle von umfangreichen Versions-Updates. So können Unternehmen laut Kevin Glynn zwei kritische Szenarien vermeiden:
- Die meisten Unternehmen passen Suite-Lösungen an ihre individuellen Bedürfnisse an, um Arbeitsprozesse zu optimieren. Bei häufigen Versionsaktualisierungen müssen diese Anpassungen immer wieder durchlaufen werden, was Zeit und Ressourcen kostet.
- Die durch die Aktualisierung entstehenden Anpassungskosten machen das Update finanziell so unattraktiv, dass lieber eine alte Version weiterverwendet wird, was zu Sicherheitslücken und Kompatibilitätsproblemen führen kann.
Ein weiteres Risiko von Paketlösungen ist, dass die eigentlichen Entwickler keinen direkten Bezug zu den Geschäftsmodellen haben, für die sie Lösungen anbieten. Zusätzlich muss das Produkt ein breites Spektrum an Anwendungsfällen abdecken. Ein Problem, das allen Anwendern einer Office-Lösung bekannt sein dürfte: Nur ein Bruchteil der Features findet tatsächlich Anwendung, der Rest des Pakets erschwert in den meisten Fällen nur die Nutzung.
DevOps und Cloud-Lösungen als Grundlage für Inhouse-Entwicklung
Die eingangs erwähnte einfache Verfügbarkeit von Cloud-Lösungen minimiert das Risiko die eigene Entwicklung nicht skalieren zu können. Projekte zur Implementierung einer Suite-Lösung dagegen sind komplexere und damit potentiell fehleranfälligere sowie kostenintensivere Unterfangen. Langfristig kann durch das DevOps-Modell der Risikofaktor Support intern abgebildet werden, was Reaktionszeiten verbessert und die Qualität des Produkts erhöht, da Anwender, Umsetzer und Qualitätssicherung zu jedem Zeitpunkt handlungsfähig sind, so Glynn.
“DevOps is agile IT (operations) delivery, required to match the cadence of agile IT development. DevOps is a philosophy, not a method, or framework, or body of knowledge, or *shudder* vendor’s tool. DevOps is the philosophy of unifying Development and Operations at the culture, practice, and tool levels, to achieve accelerated and more frequent deployment of changes to Production. – Rob England: The IT Skeptic
Das deckt sich mit den gängigen Anforderungen an Software in der Intralogistik:
- Verfügbarkeit, Stabilität und Sicherheit
- Hohe Performance an allen Arbeitsplätzen
- Daten in Echtzeit, maximale Unterstütung der Mechatronik
- Hohe Parallelität in den Lager-Prozessen
- Hohes Anpassungs- und Erweiterungspotential
- Einfache, gleichbleibende Wartungsprozesse
- Skalierbarkeit der Infrastruktur und des Durchsatzes
Dieses Qualitätsziel kann durch unsere Manufaktur-Philosophie hervorragend unterstützt werden. Denn eine potentielle Schwachstelle der Entwicklung im Haus ist, dass der Blick auf den Markt unter Umständen verloren gehen kann, der sich vor allem in der Logistik rasend schnell wandelt. Die Gefahr, dass einen das Schicksal Nokias ereilt und man den Wandel nicht rechtzeitig erkennt, ist also nicht von der Hand zu weisen.
Die Software-Manufaktur
Das Ziel unseres Ansatzes ist es nicht ein bestehendes Produkt so abzufeilen, dass es die Anforderungen erfüllt, sondern die passende Lösung für ein konkretes Problem zu schaffen.
Software follows function
Die Manufaktur verbindet die Vorteile des Inhouse-Developments mit denen eines Dienstleisters: Die Entwicklungszyklen bleiben kürzer und featurebasiert. Gleichzeitig entfällt die Notwendigkeit eine Suite-Lösung auf die individuellen Bedürfnisse anzupassen. Der zentrale Vorteil des Manufaktur-Ansatzes ist jedoch der marktbasierte Einsatz jeglicher produzierter Software, die eine Inhouse-Lösung in diesem Umfang nie erreichen kann. Aus den Anforderungen unterschiedlicher Unternehmen und Geschäftsmodelle lassen sich wiederkehrende Muster ableiten, die durch die Kombination von erprobten Modulen mit individuellen Anpassungen besser aufgegriffen und gelöst werden können, als es aus der Perspektive des Einzelunternehmens möglich wäre. Denn das Manufaktur-Modell setzt auf individuelle Lösungen, die sich aus standardisierten Prozessen ableiten, im Gegensatz zu Paketlösungen, die durch ihre breite Szenariomodellierung anfällig für Grauzonen mit wenig Mehrwert sind.
Was das Manufaktur-Modell bietet:
- Standards im Kern, flexible Anpassung an Prozesse
- Stabile, offene Architektur
- Best-Practice-Konzepte aus dem gesamten Markt
- Schnelle und kleinteilige Aktualisierungszyklen
- Hohe Performanz durch engere Szenarien
- Hardware und Plattformunabhängigkeit
Was die Grundlagen für die Software-Manufaktur sind
Eine zwingende Voraussetzung des Modells ist eine hohe Expertise im Themenfeld der Intralogistik, eine genaue Kenntnis der aktuellen Lösungen am Markt sowie der Projektmanagement- und Software-Entwicklungsttechniken. Nur wenn die Manufaktur und der Auftraggeber die gleiche Sprache in der Methodik sprechen, kann der Zyklus aus Analyse, Beratung und Umsetzung in einen kontinuierlichen Wertschöpfungprozess überführt werden, der dem Plan-Do-Check-Act-Modell folgt.
Clean Architecture als Grundlage der Software-Manufaktur
Die erste Einsicht für komplexe Software-Projekte muss sein, dass die Weiterentwicklung nie abgeschlossen ist. Um hier zu verhindern, dass die Software-Lösungen den Prozess beeinflusst und damit nach und nach immer mehr Ballast in die unternehmerischen Abläufe bringt. Daher sollten die Geschäftsregeln (eng. Business rules) den eigentlichen Kern und damit den Wert einer Anwendung definieren.
Mit den Geschäftsregeln im Kern der Architektur werden Systeme erzeugt, die folgende Bedinungen erfüllen:
- Unabhängigkeit von Frameworks. Die Architektur hängt nicht von einer feature-überladenen Software-Bibliothek ab. Das ermöglicht es, Frameworks als Werkzeuge zu verwenden, anstatt die Geschäftsregeln in ein existierendes System-Korsett zu pressen
- Testfähigkeit. Die Geschäftsregeln können durch die Entkopplung vom System jederzeit ohne Nutzerinterface, Datenbank, Server oder andere externe Elemente getestet werden
- Unabhängigkeit von Nutzerinterfaces. Die Geschäftsregeln haben Bestand, auch wenn sich das Interface ändert: Sie können über eine Kommandozeile genauso abgebildet werden wie über eine grafische Nutzeroberfläche
- Unabhängigkeit von Datenbanken. Die Art der Speicherung und Verwaltung der Regeln ist nicht auf eine bestimmte Architektur angewiesen
- Unabhängigkeit von äußeren Einflüssen. Die Geschäftsregeln verfügen über keine Verbindung zur Außenwelt.
Über diesen Kern legen sich weitere Lagen, die diese Geschäftsregeln weiter nach außen transportieren.
Die inneren Kreise sind dabei Richtlinien, die äußeren sind Mechanismen. Das besondere daran ist, dass Abhängigkeiten im Quellcode nur von einem äußeren Kreis in den nächsten inneren Kreis verweisen dürfen, so können die äußeren Schichten leicht angepasst und ausgetauscht werden, während der Kernprozess intakt bleibt.
Context-Aware Frontend Architecture zur Sicherung der Zukunftsfähigkeit
Durch die ständige Weiterentwicklung und Transformation digitaler Infrastruktur verkürzen sich die Zyklen in denen Software angepasst werden muss. Daraus ergibt sich die Anforderung bereits von Anfang an Front- und Backend strikt zu trennen und alle Komponenten als eigenständige Module zu begreifen, die eigenen Release-Zyklen folgen können. Ähnlich wie in dem vorherigen Modell, werden hier Funktionsebenen definiert.
- Die Service-Ebene ist dabei das klassische Backend, in dem die Geschäftsprozesse zur Verfügung gestellt werden
- Die Lieferebene aggregiert die Geschäftsprozesse zur Darstellung und Bearbeitung im Frontend und erfüllt die Anforderungen hinsichtlich der Zwischenspeicherung
- Die Client-Ebene enthält alle möglichen Clients in denen der Applikationsteil dargestellt wird
Damit ist das Manufaktur-Modell besonders für komplexe Projekte über eine längere Laufzeit in beweglichen Märkten geeignet und entwickelt dort gegenüber Suite-Lösungen auch seine größten Stärken, da alle Module und Prozesse eine größtmögliche Flexibilität und Unabhängigkeit erlangen, indem Verkettungen vermieden und Geschäftsregeln als zentrales Element eingesetzt werden.