Architektur für Bauwerke und Software – vergleichbar, aber anders

Vergangenen Freitag war ich am Institut für Technologie in der Architektur der ETH Zürich auf Einladung von Dr. Schoch zu Besuch. Wir trafen uns im neuesten Gebäude des Instituts, das Arch_Tech_Lab, eine futuristische Studie von sechs Professoren im 1:1 Prototyp. Anders als erwartet, haben wir dann weniger über BIM (Building Information Modelling) als über verschiedene neue Techniken und Technologien in der Architekturwelt gesprochen.

Als Softwarearchitekt nutze ich die Gelegenheit immer gerne, die eigenen Praktiken mit denen der “richtigen” Architekten zu vergleichen. So beschreibe ich hier in einem ersten Blog zum Thema Bauwesen die  vielleicht nicht ganz offensichtlichen Unterschiede zwischen diesen Welten. Natürlich ist das nur ein Gedankenspiel, aber vielleicht haben Sie daran ja so viel Freude beim Lesen wie ich beim Schreiben.

Unterschiede im Supply Chain Management

Bauwerke benötigen Baumasse, sogar sehr viel Baumasse. Leichtbau ist im Trend, und das neue Arch_Tech_Lab wurde mit sehr wenig Baumasse konstruiert (240 kg/m3), trotzdem müssen im Rahmen der Baulogistik etliche Tonnen an Material bewegt werden, und zwar in alle möglichen Richtungen. Baumasse benötigt Auswahl, Einkauf, Lieferanten, Lieferung, Transport und Lagerung, es entstehen also substanzielle Kosten. An einem Bau sind zudem viele verschiedene Firmen beteiligt, so dass ein Bauträger vor einer komplexen und riskanten logistischen Aufgabe steht, die ganzheitlich gelöst werden sollte.

Bei der Konstruktion eines Software Systems sieht die Sache eigentlich einfacher aus, denn Software besteht nur aus einem einzigen, erneuerbaren Rohstoff: unseren Gedanken. Neben einem Team, benötigt Software aber auch eine Laufzeitumgebung, um die man sich kümmern muss. Die Auswahl der richtigen Betriebspartner für ein System erscheint mir ebenso wichtig wie das Management der Lieferanten im Bauwesen. Zudem arbeitet der Softwarearchitekt mit Ideen statt Steinen, und die Psychologie des Teams ist ein wichtiger Erfolgsfaktor, viel mehr als man annehmen möchte. Wir Silberrücken kümmern uns deshalb mit viel Fingerspitzengefühl um dieses Thema und verstehen es als ein wichtiges Standbein unserer Beratungsleistung.

Bei Software ist die Lösungsarchitektur darüber hinaus  technisch kommutativ, das heisst die verwendeten Technologien sind austauschbar ohne das Ergebnis funktional zu beeinflussen. Solange eine Programmiersprache turingmächtig ist, ist es egal welche ich auswähle, denn ich kann jede Funktion mit jeder dieser Sprachen herstellen. Es dauert dann einfach länger, je nachdem wie gut die Entwickler die Sprache beherrschen, welche Werkzeugunterstützung es gibt, und wie gross das Angebot an Software Bibliotheken ist.

Iterationen kontra Wasserfall

Nobody is perfect, diese einfache Weisheit übersetzt sich in der Softwareentwicklung in die Notwendigkeit, unsere Entwürfe und Prototypen sukzessive und iterativ zu verbessern. Dabei werfen wir dann auch mal eine fehlerfreie Software wieder weg, wenn sie nicht im geschäftlichen Kontext funktioniert. Die meisten Softwaresysteme sind sozio-technische Feedbacksysteme, d.h. sie generieren nur Wert, wenn sie die Bedürfnisse ihrer Benutzer erfüllen. Diese Systeme verändern die Arbeit ihrer Nutzer, aber gleichzeitig bewirken diese auch Veränderungen an der Software, wenn sie diese an ihre Arbeit anpassen lassen. Die Formbarkeit von Softwaresystemen ist also ein entscheidendes Kriterium.

Bei einem Bauwerk ist diese Herangehensweise so nicht möglich. Ist das Tragwerk erst konstruiert, so kann es eigentlich aufgrund der hohen Kosten nicht mehr verändern. Im Bauwesen sind also 100% Lösungen gefragt, und deswegen sind hier die Planungsphasen ziemlich lang. Dies führt zu einer völlig verschiedenen Arbeitskultur, oder anders gesagt: im direkten Vergleich prallen hier Welten aufeinander.

Umso faszinierter war ich vom Produktionsprozess des Holzdaches des Arch_Tec_Labs. Hier wurde ein iteratives Verfahren zwischen den beteiligten Parteien erarbeitet, an dessen Ende die korrekte Programmierung eines Nagelroboters für die Dachlatten stand (in Python). Ein Beispiel für eine CAD Software, die auf Holzkonstruktionen spezialisiert ist, ist Cadworks.

Gehe nicht über Los

Der dritte wesentliche Unterschied hat nichts mit Monopoly zu tun, sondern mit der Judikative. Die rechtlichen Aspekte spielen im Bauwesen eine viel grössere Rolle als beim Entwurf von Software. Der Architekt eines Gebäudes kann belangt werden, wenn er Fehler bei der Arbeit macht. Dies ist bei Software jenseits des Missbrauchs von Daten anders. Ein Architekt, der einen schlechten Entwurf liefert, beispielsweise weil dieser nicht zu den Geschäftsanforderungen passt, kann nicht vor Gericht in die Verantwortung genommen werden.

Das finde ich persönlich schade, denn bei einigen Entwürfen, die ich in den letzten Jahren gesehen habe, sollte das Team eigentlich kein zweites System mehr bauen dürfen. Fairerweise muss man aber sagen, dass die Ausbildung zum Softwarearchitekten heute verbesserungswürdig ist, und man es gar nicht besser wissen kann. Beispielsweise ist es wichtig, die nicht-funktionalen Bedürfnisse exakt abzuklären bzw. zu verhandeln. Ich treffe kaum auf Projekte, wo dies konsequent geschieht, bzw. der Architekt seine Verantwortung begreift und spürbar macht. In vielen Teams wird immer noch der beste Programmierer zum Architekten gewählt, wenngleich die Qualität der Programmierung geringeren Einfluss auf die Qualität des Systems hat wie der Entwurf des Softwarearchitekten.

Fehlende Ausbildung für Software-Architekten

Der wichtigste Unterschied ist mir erst nach meinem Besuch an der ETH aufgefallen: es gibt gar keine Ausbildung zum Softwarearchitekten. Und deswegen haben auch viele Teams keinen Architekten an Bord, denn sie finden einfach keinen. Wird doch ein Anwärter gefunden, fällt es einem Auftraggeber schwer zu beurteilen, ob ein Kandidat hält was er verspricht. Denn da es ausser der meiner Meinung nach fragwürdigen ISAQB Zertifizierung aus Deutschland im DACH Raum keine Zertifizierungen gibt, kann auch niemand sein Wissen nachweisen.

Die BFH in Bern und die HWZ in Zürich bieten zumindest ein CAS für Softwarearchitektur an, aber ich bin unsicher, ob man in 40 Tagen (davon 10 in Eigenorganisation) zu einem guten Architekten werden kann, aber es ist sicher ein guter Anfang. Während also im Bauwesen der Architekt gut ausgebildet in sein Arbeitsleben starten darf, kann man den Beruf des Softwarearchitekten an keiner Schweizer Hochschule als Bachelor oder Master studieren.

Und man muss dazu sagen, dass wir in einer Zeit leben, in der Kompositionen von Informationssystemen das Lebensblut von Firmen darstellen, bzw. Firmen zur Gänze aus solchen Informationssystemen bestehen, beispielsweise autoscout24.ch. Da es nunmal keine akademische Ausbildung zum Architekten gibt, gibt es eben auch viel zu wenig Leute, die diese wichtige Rolle ausfüllen können. Dies stellt einen Nachteil für den Standort Schweiz dar.

Fazit

Das Bauwesen ist eine uralte Domäne, und die heutige Industrie hat sich über Jahrhunderte formiert und gebildet. Software hingegen gibt es nicht annähernd so lange. Kein Wunder, dass das Bauwesen bei vielen Themen weiter und gefestigter ist. Als Softwarearchitekt kann ich hier viel lernen. Vielen Dank an Herrn Dr. Schoch für die Gelegenheit zur Diskussion, es war mir eine grosse Freude. Kommende Woche schreibe ich dann über die aktuellen Trends im Bereich VR/AR/MR, und die hier zum Einsatz kommenden Technologien.

Kommentar verfassen