Wie lassen sich gewachsene Testsoftware-Strukturen beherrschbar machen?
Viele gewachsene Testsoftware-Lösungen beginnen mit einer vernünftigen Entscheidung. Für die konkrete Aufgabe gibt es am Markt nichts, was wirklich passt. Also entsteht eine eigene Lösung – zugeschnitten auf die vorhandenen Messgeräte, Produkte und Abläufe.
Dabei entstehen keineswegs zwangsläufig einfache oder technisch unsaubere Lösungen. Viele Unternehmen investieren erheblichen Aufwand in gemeinsame Bibliotheken, abstrahierte Schnittstellen und Standards. Teilbereiche können über Jahre sehr gut strukturiert und für unterschiedliche Projekte wiederverwendbar sein.
Die Schwierigkeit zeigt sich häufig erst in der Gesamtheit.
Eine interne Testsoftware entsteht unter anderen Bedingungen als ein Standardprodukt. Sie muss zunächst die Anforderungen des eigenen Unternehmens erfüllen. Mit jedem neuen Produkt, Gerät oder Prozess kommt etwas hinzu. Auch wenn einzelne Bereiche sauber abstrahiert sind, wurde die Gesamtarchitektur selten von Anfang an darauf ausgelegt, eine große Bandbreite zukünftiger und noch unbekannter Anwendungsfälle aufzunehmen.
Das kann viele Jahre gut funktionieren. Irgendwann verändert sich jedoch etwas: Neue Anforderungen lassen sich nicht mehr selbstverständlich ergänzen. Änderungen greifen an immer mehr Stellen ein, Auswirkungen werden schwerer vorhersehbar und der Entwicklungsaufwand steigt.
Die Software ist an eine Grenze gelangt, die während ihres Wachstums kaum sichtbar war.
Gute Einzelarchitekturen ergeben noch kein grenzenlos erweiterbares Ganzes
Auch eine sorgfältig entwickelte Eigenlösung kann gemeinsame Geräteabstraktionen, Datenbankschichten, Ablaufmodelle oder wiederverwendbare Komponenten besitzen. Viele dieser Ansätze unterscheiden sich technisch gar nicht grundlegend von denen eines Standardprodukts.
Der Unterschied liegt häufig in der ganzheitlichen Betrachtung.
Eine interne Lösung entwickelt sich entlang realer Anforderungen. Eine neue Funktion wird benötigt und möglichst sinnvoll in die vorhandene Architektur integriert. Später folgt die nächste. Mit der Zeit wächst damit auch der Bereich, in dem Komponenten voneinander abhängen.
Das ist kein ungewöhnlicher Fehler der Testsoftwareentwicklung. Jeder Entwickler, der über Jahre an einer größeren Software gearbeitet hat, kennt diesen Effekt.
Irgendwann lässt sich eine neue Anforderung nicht mehr isoliert betrachten. Vor der Umsetzung muss geklärt werden, welche bestehenden Funktionen betroffen sind, welche Seiteneffekte entstehen können und ob bisherige Annahmen weiterhin gelten. Selbst mit hoher Expertise lässt sich der Aufwand dann nicht immer zuverlässig vorhersagen.
Mit zunehmender Vernetzung wächst deshalb auch das Änderungsrisiko.
Wenn Anforderungen schneller wachsen als die Software
Hinzu kommt eine organisatorische Besonderheit vieler Testabteilungen.
An den Testsystemen arbeiten Ingenieure, die neue Produkte einführen, Prüfabläufe entwickeln und Produktionsprobleme lösen. Aus dieser Arbeit entstehen laufend neue Anforderungen an die gemeinsame Software.
Damit diese Anforderungen zu allgemeinen Funktionen werden, braucht es jedoch Softwareentwicklung im Hintergrund.
Auf der einen Seite stehen dann zahlreiche Testsysteme, Projekte und Anwendungsfälle. Auf der anderen Seite kümmert sich häufig nur eine kleine Zahl von Entwicklern um die gemeinsame Softwarebasis – teilweise zusätzlich zu anderen Aufgaben.
Solange die Anforderungen überschaubar bleiben, funktioniert dieses Verhältnis. Mit wachsender Nutzung steigt jedoch nicht nur die Zahl neuer Wünsche. Auch bestehende Funktionen müssen gepflegt, Abhängigkeiten berücksichtigt und unterschiedliche Projektstände unterstützt werden.
Die Entwicklung beginnt den Anforderungen hinterherzulaufen.
Damit entsteht ein zusätzlicher Druck: Es bleibt weniger Zeit für grundlegende Architekturarbeit, während gleichzeitig immer mehr Funktionen in diese Architektur aufgenommen werden müssen. Kurzfristig notwendige Lösungen gewinnen zwangsläufig an Bedeutung.
Die eigene Situation wirkt einzigartig
Wer über viele Jahre eine solche Software entwickelt hat, kennt vor allem die Besonderheiten der eigenen Umgebung. Bestimmte Messgeräte müssen auf eine bestimmte Weise angesprochen werden. Produkte besitzen eigene Varianten. Daten müssen in vorhandene Systeme gelangen und die Produktion folgt ihren spezifischen Abläufen.
Aus dieser Perspektive erscheint auch die Software zwangsläufig hochindividuell.
Mit der Erfahrung aus unterschiedlichen Testumgebungen ergibt sich ein anderes Bild. Die technischen Details unterscheiden sich teilweise erheblich. Die grundlegenden Aufgaben wiederholen sich dagegen erstaunlich zuverlässig.
Testabläufe müssen entwickelt und ausgeführt, Instrumente angebunden, Varianten verwaltet und Ergebnisse gespeichert werden. Hinzu kommen Benutzer und Rechte, Diagnose, Datenanalyse, Versionsverwaltung oder die Kommunikation mit Produktionssystemen.
Die Besonderheiten liegen überwiegend in der konkreten Ausprägung dieser Aufgaben.
Diese Erkenntnis verändert den Blick auf die gewachsene Software. Viele ihrer Herausforderungen sind keine einmaligen Sonderfälle. Andere Unternehmen beschäftigen sich mit denselben grundsätzlichen Fragen – mit anderen Geräten, Daten und Prozessen.
Individualität braucht einen definierten Platz
Genau hier setzt eine anpassbare Testplattform an.
Ein produktspezifischer Prüfablauf darf individuell sein. Messungen, Grenzwerte, Geräte und Prozessschnittstellen können sich erheblich unterscheiden. Die gemeinsame Infrastruktur schafft dafür definierte Mechanismen.
Ein neues Messgerät wird über eine Instrumentenschnittstelle eingebunden. Produktvarianten nutzen eine vorhandene Variantenverwaltung. Kundenspezifische Daten werden über definierte Schnittstellen in die Dateninfrastruktur integriert. Erweiterungspunkte erlauben individuelle Funktionen, ohne dafür die gemeinsame Basis verändern zu müssen.
Die entscheidende Architekturleistung besteht darin, diese Grenzen über das Gesamtsystem hinweg zu ziehen.
Genau dafür hat ein Standardprodukt einen strukturellen Vorteil: Seine Entwicklung ist von Beginn an damit konfrontiert, dass der nächste Anwendungsfall unbekannt ist. Was bei einem Kunden fest vorgegeben ist, kann beim nächsten völlig anders aussehen. Allgemeine Funktionen müssen deshalb stärker von ihrer konkreten Verwendung getrennt werden.
Auch eine Plattform kann dabei nicht jede zukünftige Anforderung vorhersehen. Ihre Architektur ist jedoch darauf ausgerichtet, unterschiedliche Ausprägungen aufzunehmen.
Warum eine Standardplattform trotzdem flexibler sein kann
Gerade für Unternehmen mit einer weit entwickelten Eigenlösung wirkt das zunächst widersprüchlich.
Die eigene Software wurde über Jahre exakt für die vorhandenen Anforderungen entwickelt. Hoch spezialisierte Entwickler haben Abstraktionen geschaffen und immer wieder neue Funktionen integriert. Trotzdem wird die Weiterentwicklung zunehmend schwierig. Wie soll eine Standardsoftware mit denselben Besonderheiten besser zurechtkommen?
Der Unterschied liegt weniger in einzelnen Funktionen als in der Systematik dahinter.
Eine Plattform bündelt Erfahrungen aus vielen Anwendungsszenarien in einer gemeinsamen Architektur. Wiederkehrende Aufgaben werden abstrahiert, Verantwortlichkeiten voneinander getrennt und individuelle Anforderungen über vorgesehene Erweiterungspunkte eingebunden.
Dadurch muss eine Kundenanforderung nicht bereits als fertige Funktion vorhanden sein. Entscheidend ist, ob die Plattform einen geeigneten Platz bietet, um sie abzubilden.
Genau das unterscheidet eine anpassbare Plattform von einer Software, die lediglich einen festen Standardprozess vorgibt.
Wenn Weiterentwickeln zum strukturellen Umbau wird
Ist die Grenze einer Eigenentwicklung erreicht, beginnt häufig eine schwierige Phase. In der vorhandenen Software steckt viel Wissen, und große Teile funktionieren weiterhin zuverlässig.
Entsprechend naheliegend ist es, die vorhandene Architektur noch einmal zu erweitern.
Eine zusätzliche Abstraktionsschicht, eine neue Bibliothek oder die Überarbeitung einzelner Komponenten können weiteren Spielraum schaffen. Irgendwann betrifft eine notwendige Änderung jedoch so viele Bereiche, dass daraus faktisch ein Architekturprojekt wird.
Eine solche Neuordnung ist anspruchsvoll. Gleichzeitig müssen laufende Projekte betreut, neue Anforderungen umgesetzt und bestehende Systeme unterstützt werden. Gerade bei wenigen verfügbaren Softwareentwicklern konkurriert die grundlegende Modernisierung damit unmittelbar mit dem Tagesgeschäft.
So kann eine Situation entstehen, in der technisch durchaus bekannt ist, was grundsätzlich verbessert werden müsste, die dafür notwendige Neuordnung aber kaum noch aus eigener Kraft durchführbar erscheint.
Der Ausgangspunkt macht den wirtschaftlichen Unterschied
Auch die wirtschaftliche Betrachtung beginnt bei einer Plattform an einem anderen Punkt.
Eine bestehende Plattform bringt die allgemeine Infrastruktur bereits mit. Ablaufsteuerung, Geräteintegration, Datenhaltung, Benutzerverwaltung, Diagnose oder andere grundlegende Funktionen müssen nicht erst im Rahmen der eigenen Projekte entwickelt und dauerhaft gepflegt werden.
Aufwand entsteht weiterhin. Bestehende Testprojekte müssen migriert, Schnittstellen angebunden und kundenspezifische Anforderungen umgesetzt werden.
Die Entwicklungsarbeit kann sich dabei wesentlich stärker auf die tatsächlichen Besonderheiten des eigenen Testprozesses konzentrieren.
Dieser Unterschied wird besonders relevant, wenn die Alternative in einer grundlegenden Weiterentwicklung der eigenen Softwarebasis besteht. Dann werden nicht nur die Kosten der nächsten Funktion miteinander verglichen. Auf der einen Seite steht die fortgesetzte Entwicklung und Pflege einer eigenen Plattform. Auf der anderen Seite steht eine bereits vorhandene Plattform, die für die konkrete Umgebung angepasst wird.
Und auch die Zeitachse unterscheidet sich: Die grundlegenden Funktionen einer bestehenden Plattform sind zu Beginn bereits verfügbar. Die kundenspezifische Anpassung baut darauf auf.
Gewachsene Strukturen müssen nicht verschwinden
Ein Plattformwechsel bedeutet trotzdem selten, die bisherige Arbeit vollständig aufzugeben.
In der bestehenden Lösung steckt wertvolles Wissen über Prüfabläufe, Produkte, Geräte und Prozesse. Dieses Wissen bleibt auch bei einer Migration erhalten. Es bekommt lediglich eine andere technische Grundlage.
Neue Projekte können bereits auf dieser Grundlage entstehen. Bestehende Testprogramme lassen sich schrittweise überführen. Auch vorhandene Komponenten können weiterverwendet werden, wenn ihre technische Trennung dies sinnvoll erlaubt.
Der erste Schritt besteht deshalb häufig darin, die gewachsene Software aus etwas Abstand zu betrachten: Welche Teile bilden tatsächlich Besonderheiten des eigenen Testprozesses ab? Welche Aufgaben sind inzwischen zu einer selbst entwickelten allgemeinen Testplattform geworden? Wo entstehen die größten Abhängigkeiten? Und wie viel Entwicklungsleistung wird mittlerweile allein dafür benötigt, diese Grundlage weiterzutragen?
Eine über Jahre gewachsene Eigenentwicklung ist kein Beleg dafür, dass grundsätzlich falsch entwickelt wurde. Häufig zeigt sie vielmehr, wie weit eine ursprünglich passende Architektur getragen hat.
Irgendwann können Umfang, Zahl der Anwendungsfälle und Anforderungen jedoch größer werden als der Rahmen, für den diese Architektur entstanden ist. Beherrschbarkeit entsteht dann wieder durch klare Verantwortlichkeiten, definierte Erweiterungspunkte und eine Softwarebasis, deren Weiterentwicklung nicht allein von den Anforderungen des nächsten Projekts bestimmt wird.