Mittlerweile tobt seit längerem eine hitzige Debatte über die Frage, ob Architektur und Design die gleiche Sache sind oder nicht. Die Vertreter der „Beides ist das Gleiche“-Fraktion sagen, dass Architektur eigentlich einfach nur die erste Phase des Designs ist, während die Gegner dieser These darauf beharren, dass Architektur und Design zwei vollständig verschiedene Aufgaben sind, die nur eine mehr oder minder unscharfe gemeinsame Berührungslinie teilen. Tja, wer von den beiden hat denn nun recht?
Ich bin der Meinung, dass es sehr schwer ist herauszufinden, wer recht oder unrecht hat … tatsächlich glaube ich, dass das weitestgehend unmöglich ist. Sogar in unserer kleinen Firma finden wir keinen gemeinsamen Konsens darüber, was genau Architektur und was Design ist. Und wenn es schon nicht möglich ist, einen Konsens unter so wenigen Leuten zu erzeugen (selbst wenn einige davon recht starke Persönlichkeiten sind … 🙂 ), wie soll es dann möglich sein, einen Konsens in der gesamten IT Community zu erzeugen? Das ist höchstwahrscheinlich unmöglich.
Deshalb versuche ich erst gar nicht, eine präzise Antwort auf die Frage zu finden. Stattdessen werde ich versuchen, das Thema von einem anderen Standpunkt aus zu betrachten. Zunächst: Warum ist es so schwer, die Frage zu beantworten? Ich denke, ein großer Teil des Problems liegt darin, dass es keine zufriedenstellende Definition für die beiden Ausdrücke gibt, weder für Architektur noch für Design. Wann immer sie mit einer anderen Person über Architektur oder Design reden, können Sie sich deshalb schon nahezu sicher sein, dass die andere Person über etwas anderes spricht als Sie.
Es gibt *jede Menge* Definitionen, aber die meisten davon sind meines Erachtens entweder so spezifisch, dass sie das Thema nicht wirklich erfassen oder sie sind so vage, dass sie einem überhaupt nicht weiter helfen. Nur ein Beispiel: Robert Martin (der nebenbei gesagt eine Menge sehr schlauer Dinge gesagt und geschrieben hat) hat einmal gesagt „Bei Architektur geht es um die wichtigen Dinge; was auch immer das ist.“. Nun, das sagt alles und nichts. Bedeutet das, dass es bei Design um die unwichtigen Dinge geht? Wahrscheinlich nicht. Und, wenn Kaffee für die Entwickler ein sehr wichtiges Thema ist (was es fast immer ist), bedeutet das, dass es bei Architektur um Kaffee geht? Wahrscheinlich nicht. Wie Sie sehen können, bringt uns diese Definition nicht weiter.
Ich verzichte darauf, andere Definitionen näher zu betrachten, weil ich denke, dass das nirgendwohin führt. Es wird nicht möglich sein, eine Definition für Architektur und Design zu finden, der alle zustimmen *und* die uns hilft, den Unterschied zwischen Architektur und Design herauszufinden. Insbesondere glaube ich, dass es nicht möglich sein wird, eine klare Trennlinie zwischen Architektur und Design zu finden, wo das eine endet und das andere beginnt. Jeder zieht die Linie an einer anderen Stelle und viele Leute haben wahrscheinlich eher eine Art unscharfer Wolke als eine klare Linie in ihrem Kopf. „Irgendwo innerhalb dieser Wolke endet Architektur und beginnt Design“ werden sie sagen.
So weit, so gut. Aber es muss doch etwas geben, das uns weiterhilft. Oder zumindest sollte es etwas geben …
Vielleicht hilft es, die Frage für einen Moment beiseite zu schieben. Im Laufe der Zeit habe ich herausgefunden, dass es zwei grundsätzliche Aufgaben gibt, aus denen diese ganze „Architektur-und-Design-Sache“ besteht (ohne zu versuchen, eine Trennlinie zu finden). Insgesamt geht es bei der Sache darum, alle existierenden Anforderungen in eine Lösung zu transformieren. (Und sollte jemand fragen, wo dabei die Codierung geblieben ist, möchte ich es demjenigen überlassen, die Trennlinie zwischen Design und Codierung zu finden; ich denke, dass ist eine ähnliche Fragestellung … 😉 ).
Im ersten Teil dieser Transformation geht es darum, die ganzen Anforderungen zu verstehen (nicht nur die Anforderungen der Fachbereiche und Anwender, sondern auch die Anforderungen des Managements, der Projektleitung, des Entwicklungs-Teams, des Betriebs, der Systemplanung, der Sicherheitsabteilung, der Tester, und so weiter), die Anforderungen wirklich zu verstehen, sie auszubalancieren (es gibt immer widersprüchliche und inkonsistente Anforderungen über die verschiedenen Domänen und Stakeholder hinweg, mit denen man umgehen muss) und eine geeignete Lösungsidee für all diese ausbalancierten Anforderungen zu finden. Ich pflege diesen Teil der Arbeit „Alignment“ oder auch „Einklang“ zu nennen.
Der zweite Teil der Transformation in eine funktionierende Lösung besteht daraus, die Lösungsidee in eine geeignete Struktur zu bringen, die Wartbarkeit und Änderbarkeit unterstützt und diese Struktur weiter und weiter bis herunter auf Code-Ebene zu verfeinern, ohne die zuvor beschriebenen Eigenschaften zu verlieren. Diesen Teil der Arbeit pflege ich „Strukturierung“ oder einfach nur „Struktur“ zu nennen.
Nun, ist es wichtig, diese beiden Aufgaben zu unterscheiden? Ich denke, ja! Der Grund dafür ist, dass ich bemerkt habe, dass diese beiden Aufgaben sehr unterschiedliche Skills erfordern. Während Einklang viel mit Kommunikations- und Konflikt-Management-Skills zu tun hat, erfordert Struktur eher formale Stärken. Einklang erfordert auch ein recht breites Wissen über all die verschiedenen Anforderungsdomänen, während Struktur ein eher tiefes Wissen in der Lösungsdomäne erfordert. Als eine Konsequenz daraus findet man nur relativ wenige Personen, die beide Aufgaben mit der gleichen Stärke wahrnehmen können (oder wollen), und wenn man eine der beiden Aufgaben vernachlässigt, erhält man höchstwahrscheinlich kein befriedigendes Ergebnis.
Okay, kommen wir zurück zu initialen Fragestellung. Helfen uns Einklang und Struktur, eine Trennlinie zu finden. Nun, ich denke, in gewisser Weise …
Aus meiner Sicht ist Einklang auf jeden Fall Teil einer guten Architektur und Struktur ist auf jeden Fall Teil eines guten Designs. Man kann kein guter Architekt sein, ohne viel an Einklang zu arbeiten und man kann kein guter Designer sein, ohne viel an Struktur zu arbeiten. Wie viel Struktur zusätzlich in Architektur benötigt wird und wie viel Einklang in Design – ich denke, das ist gewissermaßen eine Geschmacksfrage und darauf wird es keine endgültige Antwort geben.
Zusammenfassend kann ich auch nicht „die“ Antwort auf die initiale Fragestellung bieten. Aber ich weiß, wenn jemand über Architektur redet, ohne über Einklang zu reden, macht er etwas falsch und wenn jemand über Design redet, ohne über Struktur zu reden, macht er auch etwas falsch. Und das ist das Wichtigste aus meiner Sicht …
PS: Ein dickes „Sorry“ an Robert Martin, weil ich ausgerechnet auf seiner Architektur-Definition herumgehackt habe. Wie ich bereits zuvor geschrieben habe, hat er eine Menge sehr schlauer Dinge gesagt und geschrieben, auch wenn ich nicht allen davon zustimme. Wenn Sie also die Gelegenheit haben sollten, etwas von ihm zu lesen oder einen Vortrag von ihm zu hören, dann tun Sie es! So, das sollte genug der Wiedergutmachung sein … 😉
War dieser Beitrag hilfreich?
Weitere Beiträge
von Uwe Friedrichsen
16.10.2018 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Uwe Friedrichsen
CTO
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.