Softwarearchitektur

Bisher habe ich Gunter Dueck nur von seiner regelmäßigen Kolumne im Informatikspektrum gekannt. In dieser Woche auf der OOP habe ich ihn zum ersten ‚mal live erlebt und man kann wirklich nur von einem Erlebnis reden. Sein Thema waren Infrastrukturen (The Smarter Planet) mit der für mich wesentlichen Aussage, daß Infrastruktur nicht um der Technik willen gebaut werden sollte. Er brachte ein schönes Beispiel, das ich nur sinngemäß zitieren kann:

Vor ca. 10 Jahren hat er sich mit den ersten digitalen Kameras beschäftigt. Diese waren schwer, hatten eine schlechte Auflösung und es war schwer, die Kamera mit einem Computer zu verbinden. Das war aber die einzige Möglichkeit, sich die Bilder anzusehen. Seine Frau hielt digitale Kameras daher auch für komplett überflüssig. Eines Tages kam seine Frau aus der Filiale einer Drogeriekette nach Hause und berichtete, daß man dort neuerdings digitale Bilder direkt von einer Diskette oder CD auf Papier drucken könne und sie nun auch gerne eine digitale Kamera hätte.

Zu diesem Zeitpunkt, der sicherlich 6 Jahre später kam, war also für den Kunden die richtige Infrastruktur verfügbar, um die Technik für sich nutzbringend einzusetzen. Es wird generell so sein, daß der Entwicklungsstand der Technik der tatsächlichen Nutzbarkeit durch den Anwender einige Innovationszyklen voraus ist. Was ist aber die Nachricht, die man daraus ablesen soll:

• soll man nur noch an Technik arbeiten, die der Kunde dann direkt einsetzen kann?
• nimmt man in Kauf, daß die Entwicklung der Nutzung voraus ist und daher der „Return of Invest“ auf sich warten läßt?

Ich habe nach dem Vortrag natürlich sofort über die Entwicklung von OpenScape, das Produkt an dem ich arbeite, nachdenken müssen und mir kamen etliche Fragen in den Kopf. Sollen wir nur das umsetzen, was Kunden explizit als Anforderung formuliert haben? Können solchermaßen formulierte Anforderungen noch innovativ sein oder orientieren wir uns dann nur noch an dem was der Wettbewerb schon kann? Ist das Finden der Balance zwischen den Anforderungen der Kunden und der technologischen Innovation eine Aufgabe des Architekten?

Fangen wir mit der letzten Frage an, denn sie ist nur rhetorischer Natur. Von einem Softwarearchitekten werden mehr Fähigkeiten erwartet, als nur ein guter Entwickler zu sein. Dieses Thema hat Frank Buschmann auf der OOP in seinem Vortrag Was ein Software-Architekt wissen sollte ausgiebig ausgeleuchtet.

Wer außer dem Architekten kann denn beurteilen, ob eine Technologie notwendigerweise eingesetzt werden sollte oder vielmehr eine „Spielerei“ ist, deren Einsatz für den Business Case nicht relevant ist. Die Schwierigkeit ist wie immer, die richtige Balance zu finden. Ob die Anforderung vom Produktmanagement, dem Endkunden, einem Servicetechniker oder einem der Entwickler definiert wurde, die wichtigste Grundlage die Anforderung umzusetzen ist der Kundennutzen. Andere Einflußfaktoren bei der Entscheidungsfindung sind

• Einsparmöglichkeiten
• das Ablösen von benutzten technischen Komponenten
• Innovationen

Bei der Beurteilung dieser Faktoren ist nicht nur das Produktmanagement sondern auch der Architekt gefragt: die Einführung einer neuen Installationsroutine ist nur dann sinnvoll, wenn der Servicetechniker die Installation oder ein Update in kürzerer Zeit durchführen oder mit weniger Fehlern durchführen kann. In diesem Fall kann man den Nutzen für die Firma wieder in Geld bemessen. Der Architekt hat die Verantwortung auszuschließen, daß hier eine Baustelle geöffnet wird, nur weil es ein neues Tool zur Programmierung eines Installers oder einen weiteren Packaging Mechanismus für Linux Distributionen gibt.

Der Architekt muß sich mit den aktuellen und relevanten Technologien auskennen und jederzeit überprüfen, ob die von ihm mitentwickelte Lösung nicht inzwischen durch eine Standardimplementation, ein OpenSource Projekt oder eine zugekaufte 3rd Party Komponente abgelöst werden kann. Das kostet Überwindung und und bedeutet notwendigerweise, daß der Architekt die notwendigen Soft-Skills benötigt, sein Team zu überzeugen, daß die eigene Implementation nicht mehr dem Stand der Kunst entspricht oder einfach nur deshalb abgelöst werden sollte, weil sich die Wartungskosten verringern.

Handelt es sich um ein besonders innovatives Thema, fällt es dem Architekten besonders schwer, den Kundennutzen zu bemessen. Wie soll er über etwas urteilen,was es so noch nicht gegeben hat? Der Bewegungssensor im iPhone, der vornehmlich ersteinmal dafür da ist automatisch den Bildschirm zu drehen, wenn man das Telefon in eine andere Position bringt, hat ein enormes Potential für neue Formen der Interaktion. Zuerst preschen natürlich die Spieleentwickler vor und nutzen einfach das gesamte Telefon zur Steuerung. Soll man dieses Konzept auf andere Anwendungsprogramme übertragen und ein Schütteln des Telefons nutzen, in einem Client den Serverzustand zu aktualisieren (Reload)? Ist das eine Spielerei, die ein verantwortungsvoller Architekt unterbinden sollte, oder ist es nur so möglich, alteingefahrene Wege zu verlassen und dem Kunden neue Erfahrungen zu vermitteln?

Orientiert sich die Entwicklung neuer Produkte nur an existierenden Anforderungen, werden anhand von Checklisten nur die Features der Konkurrenz nachgebaut. Ist die Produktentwicklung nur technologiegetrieben, besteht die Gefahr, daß man zwar der „First Mover“ ist, sich das Produkt aber nicht verkaufen lässt. Deshalb ist es unabdingbar den Architekten in die Verantwortung zu nehmen, eine Balance zwichen Business Prioritäten, architekturellen Risiken und technologischen Innovationen zu finden.