Vor ein paar Wochen habe ich einen Artikel im Java Magazin veröffentlicht, der nur auf den ersten Blick die Frage diskutiert, was Architekten von Entwicklern unterscheidet. Tatsächlich geht es um Weiterentwicklung, und darum, dass Architekten Ihr Wissen und ihr Können tendenziell anders auf Stand halten bzw. vergrößern, als dies Spezialisten tun.
Der Artikel ist mittlerweile online verfügbar: Gretchenfrage 2.0: Was unterscheidet Softwarearchitekten von Entwicklern?, und ich habe bereits einige schöne Rückmeldungen erhalten von Entwicklern/Architekten, die sich nun im Anschluss ganz konkret fragen: Wie arbeite ich an meinem Architekten-T?
Da jeder andere Erfahrungen gemacht hat, und entsprechend ein anderes Standbein mitbringt, lassen sich hier keine allgemeinen Empfehlungen geben.
Zwei Fragen (in Anlehnung an Subsysteme nenne ich sie mal Subgretchenfragen), bzw. deren Beantwortung, sind meiner Meinung nach aber in jedem Fall interessant. Ich stelle Sie kurz vor, und versuche mich an einer Antwort.
Subgretchenfrage 1
Was ist die Basis bezüglich Softwarearchitektur, die jeder kennen und beherrschen sollte?
Diese Frage ist natürlich für jeden angehenden Architekten relevant. Aber auch für jeden Mentor, der angehende Architekten begleitet. Und für mich, der u.a. Seminare für Softwareentwickler hält. Und generell für praktizierende Architekten zum Abgleich.
Eine naheliegende Antwort stellen für mich die Zertifizierungsangebote dar. Ich sage damit nicht, dass Sie in jedem Fall eine Zertifizierung anstreben sollen. Man kann von Zertifizierungen halten, was man will, das ist hier nicht Thema. Die Objectives (Lernziele) der Zertifizierungen, vor allem von herstellerneutralen, bieten aber in jedem Fall einen großen Schatz an Erfahrungswissen. Wäre dumm, das zu ignorieren.
Beispiele
- The Open Group, Certified IT Architect
- International Software Architecture Qualification Board, Certified Professional for Software Architecture
Subgretchenfrage 2
Wie identifiziere ich die (Rand-)Themen, die ich mir als nächsten erschließen sollte?
Im Bild meines Gretchenfragen-Artikels geht es darum, den Querbalken im T dicker zu kriegen. Hier heißt es aufgepasst! Es wäre verlockend, sich hier ausschließlich mit den aktuellen Technologie-Hypes auseinanderzusetzen, und wichtige Dinge, die generell für Ihre Arbeit als Architekt wichtig sind, wegzublenden. Schauen Sie eher auf solche, die sind meist langlebiger. Das können z.B. auch Themen aus dem Projektmanagement sein. Oder Soft Skills.
Mein konkreter Ratschlag zum Identifizieren: Suchen Sie sich einen Mentor für Ihre Weiterentwicklung, der nicht exakt an den gleichen (vermutlich meist technischen) Themen dran ist als Sie. In großen Unternehmen ist das naturgemäß einfacher als in kleinen.
Und da ich Ihnen die Beschäftigung mit technologischen Trends natürlich nicht völlig verbieten möchte, noch ein Tipp in diese Richtung: Ich gleiche mich regelmäßig mit dem Trendradar von Thoughtworks ab, und identifiziere so Themen, die ich mir als nächstes erschließe.
Wie halten Sie es mit Ihrer Weiterentwicklung?
Nun bin ich natürlich siedend heiß an Ihren Antworten auf die beiden Subgretchenfragen interessiert! Halten Sie andere Quellen für wertvoller? Womit identifizieren Sie Themen, mit denen Sie sich als nächstes beschäftigen. Muss ich die Computerwoche abonnieren?
Hallo Stefan,
bin gerade auf deinen Artikel aufmerksam geworden, wirklich sehr gelungen. Hat Spass gemacht zu lesen.
Vielleicht ein paar Anregungen von mir: dein „T“ solle vielleicht eher in einem Serifen-Font geschrieben sein. Es gibt noch eine Basis für das T: Ein paar Grundfähigkeiten, vielleicht sogar Talente, die man nicht erlernen kann: Abstraktion. Die Kunst, die aus einem Entwickler einen Architekten macht, ist es, die Abstraktion des Problems zu erkennen. Mir geht es nicht um 17-stufige Vererbunghierarchieen, sonder eher wie der Arzt, der aus eine Menge von Symptomen die Krankheit abstahiert. Ich kenne viele exzellente Entwickler, die mit allen Frameworks gewaschen sind, aber die von mir angesprochene Fähigkeit ist sehr rar gesäht.
Und ein unstillbarer Hang nach Einfachheit gehört ebenfalls zum Fundament.
Mich würde interessieren, wie man diese beiden Grundfähigkeiten trainiert oder gar zertifizieren kann? Gehen nicht alle anderen Ansätze ins Leere, wenn diese beiden Elemente fehlen? Kippt dann das „T“ nicht einfach um?
Viele Grüße aus Karlsruhe
Guido
Hallo Stefan,
interessanter Ansatz. Allerdings ist mir das zu Entwickler-lastig angefaßt. Sicher will sich der Entwickler in Richtung Architekt entwickeln und nicht umgekehrt. Von daher ist diese Sichtweise erst mal nachvollziehbar. Aber ich denke, es wäre besser mal einen Schritt zur Seite zu treten und zu überlegen, was alles fehlt, damit aus dem, was ein Entwickler so erschafft, das wird, was der Kunde braucht.
Erst wenn ein Entwickler alle Facetten des Risiko-Managements wirklich erfaßt hat, kann er Architekt sein. Hierzu zählen alle nicht-funktionalen Anforderungen, Code-Qualitätsaspekte, Dokumentation, Wiederverwendbarkeit, Schnittstellen, Modularisierung, Layering, usw. Da kommt eine Menge mehr an Aspekten hinzu, die plötzlich zu berücksichtigen sind.
Ich würde deshalb zunächst einen Zwischenschritt einbauen und Design als nächste Entwicklungsstufe reinnehmen. Erst wenn der Entwickler wirklich mit Design etwas anfangen kann, erlernt er die Grundlagen für Architektur. Er sollte sich an Schnittstellen, Modularisierung, vielleicht sogar Wiederverwendung wagen. Ganz entscheidend für mich ist, da in der Vergangenheit bei vielen Entwicklern immer wieder beobachtet, er muß Evangelist für eine Codequalität sein, die es anderen erlaubt ohne zusätzlichen Aufwand bestehendes zu erweitern. Solange ich z.B. dabei über die Sinnhaftigkeit von JavaDocs diskutiere, besonders, wann diese zu verfassen sind, hat das ganze natürlich keinen Zweck.
Designfragen lassen sich sicher über die Literatur und eine Portion learning-by-doing im Projekt erarbeiten. Heutige Refactoring-Tools machen das Ausprobieren ja relativ komfortabel.
Wenn es um den fehlenden Rest bis zum Architekten geht, denke ich auch, daß ein Mentor notwendig wird. Das ist noch mal ein anderer Abstraktionslevel und man muß sich spätestens dann vom Code lösen können. Genau an dieser Stelle bin ich übrigens überhaupt nicht mehr der Meinung, daß ein Architekt auch entwickeln sollte. Die Sache ist zu zeitaufwendig, wenn man es richtig machen will, als daß man noch selbst Hand anlegen kann. Zudem sehe ich hier auch ganz klar eine Aufgabenteilung. Die Designer müssen sich um die Details kümmern, so daß die Entwickler ein Ergebnis produzieren können. Dafür müssen die Designer nicht auf den höheren Abstraktionsebenen unterwegs sein.
Zudem befaßt sich der Architekt ja mittlerweile auch zunehmend mit Anforderungsanalyse im Kundenkontakt, und übernimmt auch technische Projektleiterfunktionen. Das bedeutet für den Entwickler (Achtung Tellerrand) Social Skills zu entwickeln, die solche Tätigkeiten voraussetzen. Der meist so gern gemiedene Kundenkontakt wird dann zur Regel. Neben Präsentations- müssen zudem Coaching- und Konfliktmanagentfähigkeiten aufgebaut werden.
Das ist ein weiter Weg und hat aus der Sicht des Entwicklers nicht mehr viel mit Code zu tun. Die größte Herausforderung sehe ich gerade darin, sich vom lieb gewonnen Coden zu lösen, um den Level eines Architekten erreichen zu können. Für mich ist das ein Paradigmen-Shift, den es als erstes zu überwinden gilt.