Freitag, 5. Oktober 2012

Java Architekten im Elfenbeinturm und Maulwurfshügel

Was sieht man von dort oben?
CC-BY-SA - peperoni -
Java Architekten nennen sich viele, doch werden sie auch wirklich ihrer Rolle gerecht? Die einen fühlen sich zuständig für die Definition der High-Level-Architektur sämtlicher Software, die in ihrem Unternehmen entwickelt wird. Sie nennen sich selbst "Enterprise Architekt", andere nennen sie "Theoretiker" und behaupten sie säßen im Elfenbeinturm. Andere wiederum definieren die detaillierte Architektur einzelner Applikationen, deren Schichten, Komponenten, interne und externe Schnittstellen sowie zu verwendende Frameworks. Sie nennen sich selbst "Systemarchitekt" oder "Applikationsarchitekt", andere nennen sie "kurzsichtig" und "technologiegeil" und behaupten, sie sehen die Aufgaben vor lauter Tools nicht.

Architekten laufen Gefahr abzuheben (die Architektur ausschließlich aus der 10.000 Meter = applikationsübergreifenden Perspektive zu betrachten) oder unterzutauchen (die Architektur ausschließlich aus der Maulwurfs = Framework Perspektive betrachten).

Nein liebe Enterprise Architekten, SOAMDACloud-Computing sind keine Architekturkonzepte die einfach so und überall funktionieren, und liebe Applikationsarchitekten, Spring, OSGi, JSF ... sind keine Architekturkonzepte und bringen in der Praxis oft mehr Nachteile als Vorteile. Dogfooding und ein bisschen mehr Reflexion über den tatsächlichen Nutzen ihrer Architekturentscheidungen würde vielen Architekten gut bekommen.

Kaum ein Java Architekt kümmert sich jedoch um die Einhaltung der Architektur. In keinem einzigen der vielen Java Projekte, die ich im Rahmen meiner Beratertätigkeit kennengelernt habe hat die tatsächlich umgesetzte Architektur mit der definierten übereingestimmt. Mehrere 100 Architekturverletzungen (d.h. statische Abhängigkeiten die laut Architektur nicht vorhanden sein sollten) sind keine Seltenheit.

Architektur ist mehr als nur Pläne zeichnen und hoffen dass sie auch korrekt umgesetzt werden. Auch beim Bau muss man ständig nachmessen, ansonsten wird jeder Turm schief. Erklärungen, Architekturskizzen, Dokumente, Videos, ... das alles ist wichtig, damit die Softwarearchitektur verstanden wird - Prüfungen mit JDepend, Macker oder Sonargraph sind aber notwendig um die Einhaltung der Architektur zu garantieren. Wäre in kürzester Zeit (wenige Tage) umzusetzen, wird es aber meist nicht. Die Architektur im Nachhinein zu korrigieren ist dann meist so teuer (mehrere Personenmonate bzw. Jahre), dass darauf meist verzichtet wird.

Was aber sind denn nun die Aufgaben von Java Architekten? Hier eine möglichst vollständige Auflistung aller Aufgaben, die von Java Architekten verlangt werden - die Kernaufgaben muss jeder Architekt beherrschen und federführend vorantreiben. Die weiteren Aufgaben sollten ebenso beherrscht werden, können aber auch durch andere Rollen im Projekt abgedeckt werden:

Kernaufgaben und Entscheidungskompetenz
Weitere Aufgaben
  • Applikationsarchitektur (z.B. Client-Server, Schichtentrennungen, ...)
  • Server- und Clienttechnologien (JBoss, Tomcat, 
  • Interne und externe Schnittstellentechnologien (SOAP, API-Calls, XML, RMI, ...)
  • Frameworks und Libraries (Spring, Hibernate, GWT, Apache Commons, ...)
  • Tools (Eclipse, Jenkins, Sonar, ...)
  • Marktbeobachtung von potentiellen und eingesetzten Frameworks, Libraries und Tools
  • Architekturdokumentation (Word, Wiki, Videos, ...)
  • Architekturprüfungen, und -bewertungen
  • Architekturverbesserungen und Architekturrefactorings
  • Technische Analyse (z.B. Schnittstellenbeschreibungen)
  • Kosten- und Aufwandschätzungen
  • Verantwortung für technische Tasks
  • Training der Entwickler (Designprinzipien und -patterns, Best Practices)
  • Entwicklung von Architektur-Spikes und -Prototypen
  • Technische Qualitätssicherung (Code Reviews, Quality Gates)
  • Coding Guidelines und Prüfung deren Einhaltung
  • Definition und Prüfung technischer Entwicklungsprozesse (z.B. Branching)
  • Umsetzung und Sicherstellung von Continuous Integration und/oder Continuous Delivery
  • Sicherstellung von Unit-Testing bzw. TestDrivenDevelopment
Ein mMn sehr guter Artikel über die Aufgaben von Softwarearchitekten ist "Role of the Software Architect" von Dana Bredemeyer und Ruth Malan.
n

2 Kommentare:

  1. Hallo Sebastian,

    ich interessiere mich auch schon seit einiger Zeit für das Thema "Architecktur Einhaltung".

    Es ist wirklich verwunderlich, wie wenig Menschen es gibt, die diesem Aspekt der Softwareentwicklung Ihre Beachtung schenken. Ich vermute, es gibt einfach nicht so viele, die Ihre Architektur formal beschreiben und anschließend die Umsetzung begleiten.

    In unseren Projekten setzen wir Dependometer (http://source.valtech.com/display/dpm/Dependometer) ein um die Einhaltung der statischen Architektur-Regeln zu prüfen. Auf Design Ebene sorgt CODERU (http://coderu.org/) für klare Strukturen und "Component Oriented Design".

    Viele Grüße,
    Alexander

    AntwortenLöschen
  2. Derartige Tools gibt es viele - doch wie du sagst werden die viel zu wenig auch eingesetzt. Wie bei Chernobyl werden alle Systeme, die vor Fehlern warnen abgedreht, um das Projekt nicht zu gefährden...

    AntwortenLöschen

web analytics