Suche
Allgemeinwissen versus Expertenwissen

Wie viel Technologiewissen braucht ein Softwarearchitekt?

Coman Hamilton

© Shutterstock/IvanNikulin

Ist ein guter Softwarearchitekt wie ein Oktopus, der seine Tentakel in den Code anderer Leute steckt? Wie kann ein Architekt als Autorität für alle in einem System genutzten Technologien fungieren? Wir diskutieren die uralte Problemlage „breit gefächertes versus fokussiertes Wissen“ mit drei Veteranen der Softwarearchitektur.

Jeder Programmierer kommt in seiner Karriere an den Punkt, an dem er sich entscheiden muss, in welchem Bereich er sich spezialisieren will – bzw. ob er es überhaupt tun möchte. Doch beim Fällen von Softwarearchitektur-Entscheidungen erweist sich das Konzept des Expertenwissens als verzwicktes Konzept.

Wir befragten drei erfahrene Softwarearchitekten dazu, wie sie die Balance zwischen allgemeinem IT-Wissen und Expertenwissen finden.

„Stelle dich selbst in Frage“

Gernot Starke, Softwarearchitekt: Dieses Problem ist auch in anderen Disziplinen bekannt. Hochintelligente Leute haben sich mit dem Umstand beschäftigt, dass wir einerseits über allgemeine Kenntnisse über ein möglichst breites Themenspektrum, andererseits auch über spezielles Fachwissen verfügen müssen. Das Ergebnis dieser Bemühungen ist das sogenannte „T-Modell“: Auf der einen Seite verfügt man über breites, grundlegendes Wissen über mehrere Wissensgebiete (z. B. Soft Skills, Moderation, Präsentation, Kommunikation, Dokumentation, Systemanalyse, Tests, Projektmanagement usw.). Von all diesen Bereichen muss man zumindest eine gewisse Vorstellung haben. Auf der anderen Seite haben wir die „vertikalen Spalten“, spezialisierte Wissensgebiete, eventuell mehr als eines. Es ist also eigentlich kein T, sondern ähnelt eher einem M, E oder einem anderen Buchstaben mit vielen Strichen [lacht].

Niemand kann ein Experte in allen Dimensionen sein – in dem Fall hätten wir ein perfektes Rechteck vor uns. Und an das glaube ich nicht. In manchen Bereichen, wie etwa bei medizinischen Systemen, braucht man Fachwissen über sicherheitskritische Systeme, also darüber, wie man Systeme wirklich zuverlässig macht. Für extrem schnelle Datenmanipulation muss man in diesem Fall allerdings kein Experte sein, weil das Szenario es einfach nicht erfordert. Hat man einen Webshop, der eine Stunde pro Tag nicht verfügbar ist, ist das im Grunde nicht so schlimm. Bei einem medizinischen System hingegen schon – stellen Sie sich vor, das System fällt aus, während der Chirurg einen Patienten operiert. Es handelt sich also höchst individuelle Auswahl von Themen, in denen man sich spezialisieren muss.

Lesen Sie auch: Warum Programmierer an ihren Software-Systemen riechen müssen

Als Architekt muss ich über ein gewisses Fundament verfügen, zumindest im Hinblick auf die kommunikativen Fähigkeiten und die Fähigkeit, darüber zu reflektieren, was noch fehlt. Wenn man davon ausgeht, genug zu wissen, stellt man sich selbst nicht mehr in Frage. Doch wenn man als Architekt ein System von Grund auf aufbaut, weiß man nicht über alle Technologien Bescheid, man kennt die Leute nicht. Deshalb muss man darüber reflektieren, in welchen Bereichen man sich noch Wissen aneignen muss.

„Bewege dich“

Carola Lilienthal, Softwarearchitektin: Meine Methode besteht darin, niemals im selben Team zu bleiben. Vielmehr bewege ich mich von Team zu Team. Ich kann natürlich nicht alles wissen, nicht jede dunkle Ecke ausleuchten. Das ist unmöglich. Deshalb geht es mir um Vertrauen. Ich vertraue den Leuten, die in meinen Teams arbeiten. Wenn ein Problem auftaucht, von dem ich wissen muss, geben sie mir Bescheid. Uns allen muss klar sein, dass die Systeme einfach zu groß sind, um alles wissen zu können. Aber es ist von Vorteil, wenn man sich als Architekt von Team zu Team bewegt, denn dabei nimmt man immer Wissen mit sich. Somit kann man die anderen Teams mit Dingen konfrontieren, von denen sie bislang nichts wussten oder an die sie nicht gedacht hätten. Diese Art der „Störung“ ist eine gute Idee.

Das hängt natürlich alles von der Größe des Teams ab. Ich glaube, es ist nur natürlich, dass Menschen gewisse Teile eines Systems besonders lieben. Dabei kann es sich beispielsweise um eine bestimmte Technologie handeln, der sie besonders zugetan sind. Also neigen sie dazu, vor allem in diesem einen Bereich zu arbeiten und werden somit zu Experten, was wiederum dazu führt, dass alle anderen entsprechende Arbeit an diese Person weiterreichen. Ich denke, das ist eine sehr natürliche Sache, die allen Programmierern passiert.

Diesem Problem können wir mit unserem Programmiererteam begegnen. Wir betreiben Paarprogrammierung, es arbeiten also zwei Programmierer als Team zusammen. Auf diesem Weg verbreitet sich Wissen über das System bei allen Programmierern. Deshalb mache ich mir auch keine Sorgen um Experten; da sie immer jemanden um sich haben, verbreitet sich das Wissen im Team. Allerdings ist es meiner Ansicht nach unmöglich, Situationen zu verhindern, in denen gerade die zwei Leute, die sich am besten mit der Datenbank auskennen, beide im Urlaub sind. Dieses Problem werden wir immer haben.

„Ich versuche, so viele Technologien wie möglich zu ignorieren“

Rainer Stropek, Softwarearchitekt: Ich weiß nicht, ob es eine allgemeingültige Lösung gibt, aber ich kann Ihnen verraten, wie meine eigene Lösung aussieht.

Wann immer mir eine neue Technologie begegnet, versuche ich mich an einer Art Triage: Ich frage mich selbst, ob die Technologe wirklich relevant ist. Ich spiele etwas mit ihr herum. Vielleicht lese ich den ein oder anderen Artikel darüber. Und manchmal komme ich dann zu dem Schluss, dass ich dieses bestimmte Stück Technologie komplett ignorieren kann. Und ich versuche, so viele Technologien wie möglich zu ignorieren, weil es einfach so viele gibt.

Dann wiederum gibt es Dinge, von denen ich glaube, dass sie mittel- oder langfristig interessant sein könnten. In diesen Fällen suche ich nach einem … nennen wir es einmal „Spielplatz-Projekt“. Entweder ich manövriere mich absichtlich in eine Situation – z. B. eine Session auf einem User-Group-Treffen – die mich dazu zwingt, mehr über das Thema zu lernen. Oder ich schreibe einen einführenden Artikel – vielleicht suchen auch andere Leute nach grundlegenden Informationen, die ihnen bei der Einschätzung der Technologie helfen können.

Lesen Sie auch: Was uns die Pariser Geschichte über Netzwerk-basierte Architekturen lehren kann

Und wenn sich nach einer Phase des Herumprobierens herausstellt, dass die Technologie wirklich relevant für mich ist, tja, dann verbringe ich mehr Zeit mit ihr. Ich lese, ich führe Erkundungsprojekte durch; solche Dinge. Auf diese Art versuche ich, wie Sie es bezeichneten, die Breite (all die verschiedenen Technologien da draußen) und Tiefe (der Technologien, die ich als relevant für mich bzw. mein Geschäftsleben als wichtig erachte) auszubalancieren.

Ich kann auch noch konkreter werden. Java zum Beispiel ist etwas, dass ich bereits seit Jahren komplett ignoriere. Nicht, weil es nicht interessant ist, sondern weil ich entschieden habe, dass es für mich nicht notwendig ist. Ich kenne mich mit TypeScript, JavaScript, Node.js und .NET aus – und mit diesen Technologien kann ich alles erreichen, was ich möchte. Ich benötige keine weitere.

Aufmacherbild: conspiracy theory von Shutterstock / Urheberrecht: IvanNikulin

Verwandte Themen:

Geschrieben von
Coman Hamilton
Coman Hamilton
Coman was editor of JAXenter.com at S&S Media Group. He has a master's degree in cultural studies and has written and edited content for numerous websites and magazines, as well as several ad agencies.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: