Wie Sie verhindern können, dass Ihre Produkte schon morgen veraltet sind
Wir leben in einer unglaublich schnelllebigen Zeit. Wie können wir da sicherstellen, dass das heiße Produkt von heute am nächsten Tag nicht schon völlig out ist? Beispiele gibt es dafür genug: Tablets und 3D-Fernseher sind schon wieder auf dem absteigenden Ast. Wer weiß, ob VR-Brillen und 3D-Drucker nicht morgen schon wieder out sind? Als Entwickler kann man sich – zumindest in Maßen – vor der technischen Entwicklung schützen. Neu ist der Lösungsansatz nicht; aber wie bei vielen anderen Konzepten, die eigentlich „selbstverständlich“ sind, lohnt es sich, wiederholt genau hinzuschauen. Gemeint ist hier konkret funktionales Denken.
Die Funktion steht bei der Entwicklung oft weit oben: Nicht ohne Grund liegt der Fokus oft auf den funktionalen Anforderungen, während die nicht-funktionalen Anforderungen wohl häufig vernachlässigt werden. Trotzdem geht der Fokus schnell zu den Systemen und Untersystemen über, oder direkt zu den Komponenten, die das System später realisieren sollen.
Dieses Vorgehen ist durchaus legitim, es hat sich ja in der Vergangenheit bewährt. Um ein System entwickeln zu können, muss es heruntergebrochen und in kleinere Teile zerlegt werden. Intuitiv macht es durchaus Sinn, dass dabei die Systemstruktur die führende Struktur ist. Das bedeutet aber auch, dass die Sicht auf die Hauptfunktionen des Systems „weiter unten“ verloren gehen kann.
So what?
Auch hier kann man sich wieder fragen: Was soll’s? Wir entwickeln ja schon seit Jahrzehnten erfolgreich umfangreiche Systeme. Dieser Aspekt wird genau dann besonders interessant, wenn sich die Technologien, die zur Realisierung der Funktionen eingesetzt werden, rasant ändern. und genau das Problem haben wir heute.
Funktionales Denken wird interessant, wenn sich die Technologien rasant ändern
Twittern
Es gibt viele Beispiele für Systeme mit konstanter Funktion, deren Technologie sich über die Zeit teilweise dramatisch geändert hat. Zu den klassischen Beispielen gehört die Bildaufnahme, die sich von Farbe und Pinsel (Auftragsmaler) über den klassischen Film und Polariod bis zur digitalen Fotografie entwickelt hat.
Die Beste Lösung für den Kunden
Idealerweise sollte man möglichst lösungsneutral an ein Problem herangehen. In der Praxis ist das natürlich selten der Fall: Bei einem Automobilhersteller ist nun mal gesetzt, dass es ein Auto wird. Die Entwickler würden sicher nicht auf die Idee kommen, einen Zug oder einen Hubschrauber zu bauen, auch wenn das für eine bestimmte Situation vielleicht doch die „bessere“ Lösung wäre (was „besser“ bedeutet, hängt übrigens oft von den nicht-funktionalen Anforderungen ab).
Nicht in die eigene Technologie verliebt sein
Aber um noch beim Auto zu bleiben: Warum musste Tessla auf der Bildfläche erscheinen, um das Elektroauto endlich salonfähig zu machen? Porsche wäre eigentlich in einer viel besseren Situation gewesen, eine Elektro-Sportauto zu entwickeln. Vielleicht stand doch nicht die Funktion im Vordergrund („sportliches fahren“), sondern die Technologie („Hochleistungs-Verbrennungsmotor“)?
Es gibt genug andere Beispiele: Nokia hätte eigentlich das Smartphone erfinden müssen, Microsoft das Cloudgeschäft. Diesen Beispielen ist gemein, dass die eigentliche Technologie über die Umsetzung der Kernfunktion für den Kunden gestellt wurde.
Aber wie?
Die Funktionalität wird heute bei der Produktentwicklung längst berücksichtigt. Was aber fehlt sind zwei Dinge: Erstens wird die Durchgängigkeit der Funktionen nicht immer berücksichtigt. Das bedeutet, dass bei der Entwicklung eines Untersystems nicht immer klar ist, zu welcher Hauptfunktion das Untersystem einen Beitrag leistet. Das kann dazu führen, dass die Untersysteme nicht optimal ihren Beitrag leisten, oder überflüssige Elemente enthalten.
Funktionales Denken im SE: Die Durchgängigkeit von Funktionen im System berücksichtigen, und hin und wieder den Aufbau des Systems in Frage stellen
Zweitens sollte regelmäßig der Aufbau des Systems in Frage gestellt werden. Das bedeutet nicht, dass man jedes Mal neu anfangen muss. Aber es lohnt sich darüber nachzudenken ob die Begründung „wir haben es schon immer so gemacht“ wirklich die beste ist.
Wer sich mit dem Thema mehr auseinandersetzen möchte, dem empfehle ich das Buch Model-Based System Architecture, welches unter anderem ein Kapitel zur FAS-Methode enthält (Functional Architectures for Systems).
