IT-Systeme und Software-L\u00f6sungen werden komplexer, verteilter und st\u00e4rker miteinander vernetzt. Gesch\u00e4ftsprozesse greifen ineainander, Daten werden weitergegeben und \u00fcberall verarbeitet. <\/p>\n\n\n\n
Gleichzeitig f\u00fchrt die zunehmende Spezialisierung dazu, dass sich technische Rollen immer weiter voneinander entfernen: Netzwerk, Datenbanken, Cloud, Security, Betriebssysteme, Programmierung, DevOps, Containerisierung, CI\/CD, Monitoring und KI.<\/p>\n\n\n\n
Spezialisierung ist notwendig. Niemand kann heute noch die gesamte IT in gleicher fachlicher Kompetenz beherrschen.<\/p>\n\n\n\n
Das eigentliche Problem entsteht dort, wo Spezialisierung mit einem fehlenden Verst\u00e4ndnis f\u00fcr Zusammenh\u00e4nge verwechselt wird.<\/strong><\/p>\n\n\n\n Hier setzt das Konzept des T-Shaped Knowledge<\/strong> an.<\/p>\n\n\n\n Das \u201eT\u201c beschreibt eine Kombination aus fachlicher Spezialisierung und interdisziplin\u00e4rer Anschlussf\u00e4higkeit<\/strong>.<\/p>\n\n\n\n Der senkrechte Strich steht f\u00fcr ein Fachgebiet, in dem eine Person \u00fcber ausgepr\u00e4gte Kompetenz verf\u00fcgt. Das kann beispielsweise Software Engineering, Netzwerkarchitektur, Cloud Computing oder IT-Security sein.<\/p>\n\n\n\n Der waagerechte Strich steht f\u00fcr ein breiteres Verst\u00e4ndnis angrenzender Disziplinen.<\/p>\n\n\n\n Dabei geht es ausdr\u00fccklich nicht darum, jede technische Schicht selbst beherrschen zu m\u00fcssen.<\/p>\n\n\n\n Ein Software Engineer muss weder Netzwerkadministrator noch Datenbankadministrator, UX-Designer, Cloud Architect und Elektrotechniker sein. Er muss auch nicht jede Ebene des OSI-Modells bis zur physikalischen \u00dcbertragung einzelner Bits technisch analysieren k\u00f6nnen.<\/p>\n\n\n\n Entscheidend ist vielmehr die F\u00e4higkeit, technische Zusammenh\u00e4nge zu modellieren und Probleme \u00fcber die Grenzen der eigenen Spezialisierung hinweg einzuordnen.<\/strong><\/p>\n\n\n\n Eine Anwendung ist nicht erreichbar.<\/p>\n\n\n\n Die Ursache k\u00f6nnte in der Programmierung liegen. Sie k\u00f6nnte aber ebenso im DNS, Netzwerk, Routing, einer Firewall, einem Load Balancer, einem Zertifikat, einem Container, dem Betriebssystem, einer Datenbank oder einer externen Abh\u00e4ngigkeit liegen.<\/p>\n\n\n\n Die technische Herausforderung besteht deshalb zun\u00e4chst nicht darin, die richtige L\u00f6sung zu kennen.<\/p>\n\n\n\n Sie besteht darin, den Problemraum korrekt einzugrenzen.<\/strong><\/p>\n\n\n\n Ein Spezialist mit engem Zust\u00e4ndigkeitsverst\u00e4ndnis k\u00f6nnte sagen:<\/p>\n\n\n\n \u201eDas ist nicht mein Bereich.\u201c<\/p>\n<\/blockquote>\n\n\n\n Ein T-Shaped Engineer stellt dagegen zun\u00e4chst Hypothesen auf:<\/p>\n\n\n\n \u201eWelche Komponenten k\u00f6nnten diesen Fehler verursachen und wie kann ich die Ursache systematisch eingrenzen?\u201c<\/strong><\/p>\n<\/blockquote>\n\n\n\n Daf\u00fcr muss er nicht jede dieser Komponenten selbst administrieren k\u00f6nnen.<\/p>\n\n\n\n Er muss verstehen, welche Abh\u00e4ngigkeiten bestehen, welche Messgr\u00f6\u00dfen relevant sind und wann die Expertise eines anderen Spezialisten erforderlich ist.<\/strong><\/p>\n\n\n\n Genau hier liegt ein h\u00e4ufiges Missverst\u00e4ndnis.<\/p>\n\n\n\n T-Shaped Knowledge bedeutet nicht:<\/p>\n\n\n\n \u201eIch kann alles.\u201c<\/strong><\/p>\n\n\n\n Es bedeutet:<\/p>\n\n\n\n \u201eIch beherrsche ein Fachgebiet und verstehe ausreichend viele angrenzende Bereiche, um technische Systeme als Gesamtheit analysieren zu k\u00f6nnen.\u201c<\/strong><\/p>\n\n\n\n Ein Software Engineer sollte beispielsweise nachvollziehen k\u00f6nnen, dass zwischen einer Benutzeranfrage und einer Datenbankabfrage zahlreiche technische Komponenten liegen k\u00f6nnen:<\/p>\n\n\n\n Client \u2192 DNS \u2192 Netzwerk \u2192 Firewall \u2192 Load Balancer \u2192 Anwendung \u2192 Datenbank \u2192 externe Services<\/strong><\/p>\n\n\n\n Wenn eine Anfrage fehlschl\u00e4gt, muss er nicht jede dieser Komponenten selbst implementieren oder administrieren.<\/p>\n\n\n\n Er sollte jedoch in der Lage sein, die m\u00f6glichen Fehlerdom\u00e4nen zu unterscheiden und durch geeignete Tests und Messungen schrittweise einzugrenzen, wo die Ursache liegt.<\/p>\n\n\n\n This is Systemdenken in der IT<\/strong>.<\/p>\n\n\n\n Damit verschiebt sich auch die Definition eines guten IT-Spezialisten.<\/p>\n\n\n\n Es reicht nicht aus, m\u00f6glichst viel Wissen innerhalb einer einzelnen Technologie anzusammeln.<\/p>\n\n\n\n Entscheidend ist die F\u00e4higkeit, dieses Wissen in einem komplexen System anzuwenden.<\/p>\n\n\n\n Dazu geh\u00f6ren beispielsweise:<\/p>\n\n\n\n Das ist ein wesentlicher Unterschied zwischen Technologiewissen und Engineering-Kompetenz<\/strong>.<\/p>\n\n\n\n KI kann heute Programmierung erzeugen, Konfigurationen analysieren, Logs interpretieren und technische L\u00f6sungsvorschl\u00e4ge entwickeln.<\/p>\n\n\n\n Dadurch wird reines Auswendigwissen teilweise weniger wertvoll.<\/p>\n\n\n\n Gleichzeitig steigt die Bedeutung der F\u00e4higkeit, Ergebnisse fachlich zu validieren.<\/strong><\/p>\n\n\n\n Wenn ein KI-System eine \u00c4nderung an der Programmierung vorschl\u00e4gt, muss jemand beurteilen k\u00f6nnen, ob das Problem tats\u00e4chlich in der Programmierung liegt.<\/p>\n\n\n\n Wenn eine Konfiguration ver\u00e4ndert werden soll, muss jemand verstehen, welche Auswirkungen das auf Netzwerk, Security, Betrieb und abh\u00e4ngige Systeme haben kann.<\/p>\n\n\n\n KI kann damit die technische Arbeit beschleunigen.<\/p>\n\n\n\nWas bedeutet T-Shaped Knowledge?<\/h2>\n\n\n\n
\n\n\n\nIT-Probleme sind selten disziplinrein<\/h2>\n\n\n\n
\n
\n
\n\n\n\nT-Shaped bedeutet Systemverst\u00e4ndnis<\/h2>\n\n\n\n
Von der Fachkompetenz zur Probleml\u00f6sungskompetenz<\/h2>\n\n\n\n
\n
\n\n\n\nAuch KI ver\u00e4ndert daran wenig<\/h2>\n\n\n\n