Software-Kolumne Abgefahren: Das Zeitalter der Architekten

Im Jahr 1985 sprach Steve Jobs über seinen Versuch, Apple durch das Einstellen von Managern zu professionalisieren. Doch er scheiterte: „Wir sind losgegangen und haben eine ganze Reihe professioneller Manager eingestellt, und das hat überhaupt nicht funktioniert. Sie wussten zwar, wie man verwaltet, aber sie wussten überhaupt nicht, wie man etwas tut.“  

Nerds retten die Welt

Wenn man Ihnen anbieten würde, einen automobilen Software-Stack von Grund auf neu zu entwickeln, und sie könnten sich die besten Köpfe aussuchen. Sie müssten sich nur leider zwischen 50 oder 5000 Mitarbeitern entscheiden – worauf würde Ihre Wahl dabei fallen?

Keine Sorge – es geht in dieser Kolumne nicht um Manager-Bashing: Ich bin ja selber einer. Es geht aber um das richtige Verhältnis zwischen Wertschöpfung und dem Management derselben, zwischen Entwicklung und Organisation, zwischen Tun und Verwalten. Ohne Management wird das Produkt vielleicht zu teuer oder zu spät fertig, es wird vielleicht Normen verletzen oder sich schlecht verkaufen, die Entwicklung wird chaotisch verlaufen. Ohne Entwickler aber gibt es gar kein Produkt. Und daher sind der Kern eines Unternehmens nicht die Manager, sondern die Nerds.

Der Architekt geht nicht von Bord

Kundensegmente, Weltregionen, Fahrzeugplattformen, Compliance, digitale Ökosysteme: Das Produkt „Mobilität“ ist so komplex wie die heutige Welt. Das alles zu ordnen ist die Aufgabe des Architekten. „Architektur“ meint hier nicht nur die Topologie des Bordnetzes, sondern eine sachlogische Strukturierung, die die Business-Welt mit den Technologiebausteinen sinnvoll verbindet.

Das klingt sehr abstrakt – und ist es auch. Denn im ersten Schritt geht es um das warum. Was sollen wir überhaupt leisten? Welches Kundensegment soll erreicht werden, und wie wird da in fünf Jahren der Wettbewerb aussehen? Architekten haben die wesentliche Aufgabe, diese Anforderungen in Technologie zu übersetzen, das was und wie. Dazu gibt es allerlei Methoden des Systems Engineering, doch der Kern ist profunde Erfahrung und tiefes fachliches Verständnis von Software und Hardware. Typischerweise hat der Architekt in der frühen Definitionsphase des Projektes alle Hände voll zu tun – und übergibt dann gedanklich an die Serienentwicklung. Damit nimmt das Unheil seinen Lauf. Die sorgsam abgewägten Architekturentscheidungen zu Bausteinen, Schnittstellen und Kommunikationswegen im Produkt unterliegen nun dem freien Kräftespiel von Zeitdruck, Kostendruck und Entwicklungspannen. Die wichtigste Aufgabe des Architekten ist es, über die gesamte Lebensdauer des Produkts auf die Einhaltung der architektonischen Grundprinzipien zu achten. Das ist wie beim Hausbau nicht immer seine Lieblingsaufgabe.  

Führen heißt Dienen

Zurück zu Steve Jobs. Er fragte sich: „Wissen Sie, wer die besten Manager sind? Das sind die großartigen Einzelpersonen, die nie und nimmer Manager werden wollen, sich aber dazu entschließen, Manager zu werden, weil niemand sonst in der Lage sein wird, so gute Arbeit zu leisten wie sie.“

Aber gerade das geht häufig schief, der beste Experte, der dann eine Hierarchiestufe höher unglücklich ist? Vielleicht meinte Jobs eher das: In allen Hierarchiestufen brauchen wir ein tiefes fachliches Verständnis, und das ist heute Erfahrung im Software-Engineering. Und auf allen Ebenen gilt, dass das Management von Ressourcen, Menschen und Entscheidungen dem Produkt und Kunden dient.

So schließt sich der Kreis: Er beginnt und endet beim Kunden. „Customer centricity“ ist eine ganz und gar altmodische Tugend, die den Mehrwert für den Kunden in den täglichen Entscheidungen nach oben bringt. Der Architekt trägt Sorge dafür, dass dies nachhaltig für Kunden und Unternehmen geschieht.