„Second System Effect“ Die nächste RM Tool Generation

Der Essay „The Second System Effect“ (SSE) ist aus „The Mythical Man-Month“, dass bekannte Software Engineering Management Buch erschien erstmalig 1975. Neben dem viel zitierten „No Silver Bullet“  Artikel, der Teil des Buches von Frederick P. Brooks ist, gehört SSE wohl zu den weniger bekannten Essays. Das ist kein Wunder, denn die Entwicklungsprojekte und Software Produkt Beispiele die Brooks nennt sind in der Regel nur Spezialisten bekannt und werden wohl selten benutzt. Es gibt aber einen bedeutungsvollen Kern, der sich auch auf die Situation übertragen lässt, die heutige Anwender von RM Tools vor Augen haben, wenn es um die Ablöse dieser ersten Generation von Datenbank basierten Werkzeugen geht.  

…the total creative effort involves three distinct phases: architecture, implementation and realization. It turns out that these can in fact be begun in parallel and proceed simultaneously…

Brooks hat eine Lanze für das moderne Software-Engineering gebrochen und den Archetypen des Software-Architekten zu formen geholfen. In SSE startet die Betrachtung mit einer verteilten Verantwortung in den Feldern der Anforderungen, der Architektur und der Implementierung (Builder). Übertragen wir die Aussagen, die über den Architekten gemacht werden, auf Werkzeuganbieter, dann stellt Brooks eigentlich die Frage, was den ausufernden Erfindungsreichtum eines Toolherstellers Grenzen setzten kann? In SSE ist die Antwort darauf auf eine interaktive Kommunikation zwischen Architekt und Builder beschränkt.

…remember that the builder hast the inventive and creative responsibility for the implementation; so the architect suggests, not dictates…  

Nun sollte man an dieser Stelle bedenken, das Brooks in einem Kontext arbeitet in dem Schuster Schuhe für Schuster gestalten und herstellen. Wir müssen die Felder also noch auseinander ziehen und die Ratschläge Brooks auch für die Interaktion zwischen Anwendern und Toolhersteller einordnen. Bei den weiteren Beispielen die in SSE folgen wurden diese Ratschläge wohl nicht beachtet. Vielmehr führen diese Erkenntnisse Brooks zu der Aussage:

…This second is the most dangerous system one can ever design…  

Die Gefahr des over-design wird von Brooks an erste Stelle gesetzt. Wenn man z.B. das Design von Typdefinitionen in RM Tools betrachtet gibt es bei den Zweit-Generationen sowohl ausufernde Möglichkeiten als auch seltsame Einschränkungen. Die administrative und die nutzende Seite nimmt das nur als vom Nutzen befreite Erschwernis wahr. Da dazu noch mit dem ersten Generationen Werkzeug oft eine einfachere Lösung bekannt ist, sind Anwender an dieser Stelle eher überzeugungsresistent.

…The second-system effect has another manifestation somewhat different from pure functional embellishment. That is a tendency to refine techniques whose very existence has been made obsolete by changes in basic system assumption…

Brooks scheint hier eine Menge Beispiele aus seiner OS/360 (IBM Mainframe) Zeit parat zu haben. Wo es Brooks um optimierte Speicher und Laufzeitnutzung geht könnten wir einen Blick auf den technologischen Unterbau von RM Tools werfen. Bei den ersten Generationen Tools die z.B  mit 4GL und OODB Technologien realisiert wurden, hat sich oft die IT Anforderungswelt so geändert das die Betriebsseite einen gewissen Eifer entwickelte, Anwender in konformere RM Werkzeuge zu drängen. An dieser Stelle werden oft Security Erwägungen, Backup oder Datenbankkompatibilitäten genannt. Neue Lösungen haben neue IT kompatible Technologie-Stacks, eine quasi Standard RDBMS und offene auf Web Technologie basierte Komponenten mit eingebauten Sicherheitsstandards gebracht.  Diese Lösungen gehen einfach viel leichter durch die Checklisten der Security Officers. Der SSE Essay geht nicht explizit auf die Beweggründe für eine neue Software Generation ein. Thematisiert werden jedoch die Personen, also Architekten und Builder, die ja so ziemlich alle in Ihrer Karriere einem Second System Effekt ausgesetzt sind. Nach Parnas wissen wir jedoch das es Effekte gibt die eine Organisation zu drastischen Mitteln wie Abstell- und Downramp-Projekten greifen lässt. Es bleiben nur leider die Anwender auf der Strecke. Eine Mischung aus Versuchen es besser zu machen, falsch verstandenen Anforderungen aus dem Feld und Fehlleitung durch gut gemeinte Experten Ratschläge, gewürzt mit einer gehörigen Portion Selbstüberschätzung, führt zu Einführungsversuchen von Monster RM Tools die in manchen Fällen sogar bei der Bewältigung von Standardaufgaben der ersten Generation unterliegen.

…How does the architect avoid the second-system effect?…

Welche Ratschläge gibt uns Brooks um den Effekt abzumildern? Man sollte sich der besonderen Gefahren dieses Systems bewusst sein und zusätzliche Selbstdisziplin anwenden. Das hilft z.B. um funktionale Verzierungen zu vermeiden. Genauso sollte die Extrapolation von Funktionen vermieden werden, die durch Änderungen von Annahmen oder Zweck obsolet geworden sind. Für unseren besonderen Fall “RM Tools”, müssen wir die Brooksche Betrachtung noch etwas erweitern. Um in einem First System RM Anwenderfeld erfolgreich ein Second System RM mit den weiter oben beschriebenen Randbedingung einzubringen, kann der Erfolg nicht über den berühmten „geht weg wie geschnitten Brot“ Effekt erreicht werden. Ein schönes Beispiel, wo Innovation an der Verhaftung am Althergebrachten und der puren Gewohnheit der Vielen ihr Ende findet, haben wir täglich vor Augen: Schreibtastatur. Auch „Friss oder stirb“ Ansätze verbieten sich von selbst und haben im R&D sowieso keine Chance. So werden neu RM Werkzeuge, die hohe Freiheitsgrade bei der flexiblen und kontinuierlichen Gestaltung von Anforderungs-Informationsmodellen durch Nutzer einschränken, Schiffbruch erleiden, wenn keine adequate Alternative zur Verfügung steht.

Was bleibt? Ein schwieriger Weg ist baldigst zu beschreiten. Dieser kann sich eigentlich nur von einer Strategie der höchsten erreichbaren Einbeziehbarkeit ableiten lassen. Dabei geht nicht weit genug den Kern einer Toolauswahl und Implementierung anzugehen und diese noch mit einem Farbtupfer mehr Anwendereinbezug anzureichern. Das Transformationsteam muss nicht nur intime Kenntnisse über das neue Werkzeug erlangen, es muss eins werden mit der Anwenderschaft die es umzustimmen gilt. E-Auto Entwickler die mit Verbrennungsmotoren zur Arbeit fahren können gar nicht konkurrenzfähig entwickeln. Da auch eine reine Toolschulung alleine zu wenig Hilfestellung ist, unterstützt HOOD  mit einem RE Tool Training Workshop der anhand der methodischen Felder Stakeholder Anforderungen  und System Anforderungen den jeweiligen Tool Einsatz aufzeigt. Derzeit unterstützen wir hier Jama, DNG, Codebeamer und Polarion. Der Methodische Schwerpunkt des Trainings ist anpassbar und kann sich auf die Anforderungsgeber-Seite oder Anforderungsnehmer-Seite konzentrieren.

    Nehmen Sie mit uns Kontakt auf.