Suche
Be pragmatic, not dogmatic!

Modernes Tooling versus etablierte Best Practices

Joachim Arrasz

Dogmatismus als auch Pragmatismus werden oft als Ausrede für verschiedene Unarten innerhalb der Softwareentwicklung genutzt. In dieser Kolumne wollen wir verschiedene Beispiele für beides vorstellen und hoffentlich spannend diskutieren.

Im letzten Teil der Kolumne ging es um Kompetenzen und deren Grenzen im Betrieb einer Software. Wir hatten diskutiert, inwiefern dogmatisches Handeln Strukturen und Methoden beim Betrieb hilfreich oder eben auch unsinnig sein können. Hierzu gab es auch wieder eine Umfrage (Dogmatiker oder Pragmatiker: Wie viele Tests braucht der Mensch?) mit einem, aus meiner Sicht, ein wenig überraschendem Ergebnis. Klar wurde jedoch, dass es hier auf keinen Fall nur eine Meinung geben kann, sondern man sich diese jedesmal auf’s Neue von Projekt zu Projekt bilden muss. Dogmatisches Handeln kann Prozesse beschützen, pragmatisches Handeln kann diese beschleunigen…

Noch ein wichtiger Punkt der unbedingt angemerkt werden muss: Alles, was ich hier schreibe, ist meine persönliche Meinung und spiegelt auch nur diese wider 🙂 Diskussionen sind herzlich willkommen! Falls sich der eine oder andere Kollege angesprochen fühlt – natürlich ist alles frei erfunden und Ähnlichkeiten sind rein zufällig… 🙂

Hier werden nur Systeme betrieben, welche nach Masterarchitektur-Plan entwickelt wurden!

Steigen wir also in den fünften Teil der Kolumne ein. Jeder Softwareentwickler hat sicherlich schon das eine oder andere Mal Begriffe wie „Blueprint Architecture“, „Masterarchitekturplan“ oder dergleichen gehört. Die allermeisten meiner Kollegen zucken bei diesen Begriffen unweigerlich erschreckt zusammen. Nur warum ist das so? Architekturvorgaben, und letztlich sind solche Dokumente exakt dieses, haben das Ziel, zu vereinheitlichen. Es geht darum, Dinge, die immer wiederkehren, zu identifizieren, zu strukturieren und zu regulieren. Dies sind also alles Qualitäten, die derzeit innerhalb eines anderen spannenden Themas, des Continuous Deployments, hoch gelobt werden und zwingende Grundvorraussetzung dafür sind. Warum also werden Dokumente, welche diese Qualitäten unterstützen, für so problematisch angesehen? Kommen wir zu einem Beispiel…

Während der Konzeptionsphase eines Entwicklungsprojekts wurden mittels Rapid Application Tools sehr schnell Erfolge erzielt und technische Durchstiche bewiesen. Anhand dieser konnte die Konzeptionsphase deutlich verkürzt werden, ohne die zugrundeliegende Konzeptionstechnik allzu sehr zu beeinflussen. Nach dem Durchstich mittels Prototyp beriet sich das Team, wie man denn aus dem Prototyp möglichst großen Nutzen ziehen könnte. Da Spring Roo genutzt wurde, dachte man natürlich schnell darüber nach, einfach mit einer leichtgewichtigen Spring-Anwendung weiter zu machen. Dies hätte auch weitere Vorteile gehabt, da das zu entwickelnde System viele andere Systeme auf verschiedensten Protokollen mit anzubinden hatte.

Um hier nicht in eine falsche Richtung zu galoppieren, sicherten wir uns ab, wie genau der Betrieb denn vonstatten gehen sollte und was uns vom Betrieb her an Technik erlaubt würde. Die Aussage war : „Schickt uns doch einfach ein WAR-File“, ach und: „Wir können alles betreiben was auf Java5 aufsetzt, in Ausnahmen bereits Java6“. Damit konnten wir aufgrund des gewählten Stacks sehr gut leben.

Eine Woche später starteten wir dann mit der Entwicklung des Systems. Wir unterhielten uns aufgrund einiger Schnittstellen mit dem stellvertretenden Architekten, der uns lapidar mitteilte, dass es natürlich verboten sei, jedwede Library, die von SpringSource komme, zu verwenden. Natürlich gab es einige Verwirrung, bis klar wurde, dass innerhalb der Firma einige „Masterarchitekturentwürfe“ einzuhalten waren. Nun, kurz gesagt wurde uns dringend empfohlen, diesen Masterarchitekturplan unbedingt einzuhalten, da es sonst total unklar sei, ob das System betrieben werden könne! Natürlich war das Team in der Lage, das System mittels des empfohlenen Stacks ebenfalls umzusetzen, allerdings mit der Einschränkung, dass wir nichts weiterverwenden konnten und dass beim erneuten Anfang auf der grünen Wiese, wie das meist so ist, einiges ein wenig anders gemacht werden musste (Spring MVC Views sehen eben nicht aus wie JSF Views, solange man nicht einige Zeit in CSS Magie investiert). Zudem zog sich die Entwicklung dadurch deutlich länger hin.

[ header = Seite 2: Meine Meinung zu dieser Kontroverse ]

Meine Meinung zu dieser Kontroverse:

Entwickler auf aus ihrer Sicht langweilige, nicht mehr zeitgemäße Werkzeuge und Architekturen einzuschränken, ist demotivierend und wird auf Dauer nicht zum gewünschten Tempo führen. Architekten und DevOps mit dauernd neuen Werkzeugen und dementsprechend oft mit neuen Anforderungen zu überhäufen, führt bei diesen aufgrund des hohen Aufwands, der dadurch erzeugt wird (Neues ist nicht automatisiert!), dauerhaft zu Demotivation und Reizbarkeit 🙂

Wie bringen wir also diese beiden Welten zusammen? Es funktioniert, wie immer, nur über Kommunikation. Die Architekten dieser Welt sollten nicht versuchen, alles bis in das kleinste Detail vorzugeben. Sie sollten bedenken, wie sehr sie sich selbst in ihrer Arbeit eingeschränkt sehen würden, wenn sie nur Bestimmtes nutzen dürften. Die Entwickler wiederum müssen anerkennen, dass sie Freiheitsgrade nur bis zu einem bestimmten Punkt, nämlich die Einbindung des Systems in die Systemlandschaft und Infrastruktur, ausreizen sollten. Aussagen wie „Mit RESTful Services kann ich mich doch in jede Landschaft integrieren“ sind nicht hilfreich!

Meiner Meinung nach kann dieses Dilemma recht einfach gelöst werden. Architekten kümmern sich mehr um die Systemintegration sowie um grundlegende Dinge wie Lastanforderungen und dergleichen. Die Entwickler bekommen dadurch klare Grenzen und Vorgaben, wie Systeme eingebunden werden müssen, und vor allem mit welchen Tools. Sie haben dann aber innerhalb ihres Systems recht freie Hand wie diese Integration implementiert wird und sind somit deutlich motivierter bei ihrer eigentlichen Arbeit.

Wie immer innerhalb dieser Kolumne wäre ich sehr froh, wenn sich daraus eine interessante und spannende Diskussion ergeben würde. Ich bin der Meinung, dass dringend mit Vorurteilen aufgeräumt werden muss, die Architekten aus ihren Elfenbeintürmen herauskommen und den Entwicklern zuhören sollten. Umgekehrt müssen die Entwickler endlich beginnen, zu kommunizieren, und ihre Chance nutzen, die Blueprints mit zu beeinflussen.

Geschrieben von
Joachim Arrasz
Joachim Arrasz
Joachim Arrasz ist als Software- und Systemarchitekt in Karlsruhe bei der synyx GmbH & Co. KG als Leiter der CodeClinic tätig. Darüber hinaus twittert (@arrasz) und bloggt er gerne (http://blog.synyx.de/)
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.