Was ist der Unterschied zwischen Architektur und Design?

9 Kommentare

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 … 😉

Autor

Uwe Friedrichsen

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Februar 18, 2010 von Thomas Falkenberg

    Falls noch mehr Definitionen benötigt werden :-)

    http://www.sei.cmu.edu/architecture/start/community.cfm

    Ansonsten sehe ich es wie Gernot Starke
    „Architektur und Design beschäftigen sich mit dem Entwurf von Systemen. Ich vertrete die Auffassung, dass die Grenze zwischen Software-Architektur und Software-Design fließend ist.
    Damit rücken die Begriffe Design und Architektur sehr eng zusammen. Design oder Entwurf bezeichnen den Prozess der Erstellung der Architektur. Die Entwurfsphase konstruiert oder erschafft in diesem Sinne die Architektur.
    Manchmal gehört der Entwurf einer konkreten Klassenstruktur zur Aufgabe von Architekten, in anderen Fällen werden zusätzliche Designer diese Aufgabe lösen. Gehen Sie mit den Begriffen pragmatisch um und suchen Sie nicht nach einer „formalen“ Definition.“
    Das ist aus „Effektive Software-Architekturen“, wo er Architektur auch weniger definiert, als sie sehr umfänglich zu beschreiben. Stichworte sind hier auch die Struktur (Strukturen, Zerlegung, Schnittstellen, Beziehungen), Übergang von der Analyse zur Realisierung und verschiedene Sichten (Kontextsicht, Laufzeitsicht, Bausteinsicht, Verteilungssicht) und viele weitere.
    Was Du als „Einklang“ beschreibst, würde ich als Voraussetzung für jede Art von (guter) Architektur beschreiben, aber den Prozess dorthin(zumindest im ersten Wurf) eher der Analyse zuordnen. Der Architekt reagiert auf die Ergebnisse der Analyse mit Einschränkungen aus seiner Sicht und fördert so den Prozess des Alignments.
    Die besondere Herausforderung bei großen Projekten ist jedoch, dass er dabei in der Regel zu Beginn ziemlich im Dunkeln tappt, aber trotzdem Entscheidungen treffen muss. Daher ist der Prozess ähnlich iterativ wie bei der Umsetzung der Architektur in Code. Viele Anforderungen, insbesondere die nicht-funktionalen, sind in frühen Phase noch unscharf oder gar nicht definiert.
    Ich finde die Idee der domänen-artigen Trennung von Einklang und Struktur gut, allerdings darf nicht der Eindruck entstehen, dies könnte auch zeitlich getrennt geschehen (also sequenziell). Die beiden Bereich sind direkt miteinander verzahnt und beeinflussen sich ständig wechselseitig.

  • … ja, die gefürchtete Seite beim SEI, die jeden angehendenden Architekten in einem Zustand vollständiger Verwirrung zurücklässt … :-)

    Deine Anmerkungen ergänzen meinen Post um einige Aspekte, die ich darin ausgelassen haben. Daher auch noch einmal vielen Dank dafür! Gernot und ich hatten uns auch schon einmal über Architektur ausgetauscht und haben festgestellt, dass wir in sehr vielen Dingen auf einer Linie sind. Daher ich auch kein Problem mit dem fließenden Übergang und der unklaren Abgrenzung, die er propagiert. Ebenso sehe ich es genauso wie Du (und auch Gernot), dass Architektur keine einmalige „Upfront“-Tätigkeit sein kann, sondern evolutionär entstehen muss und von vielen Feedback-Zyklen begleitet ist.

    Mein eigentlicher Kernpunkt lag noch an einer anderen Stelle: Viele sehr entwicklernahe „Architekten“ reduzieren Architektur nur auf den Strukturierungsaspekt und – schlimmer noch – nur auf die nichtfunktionalen Anforderungen. So können sie – mal bösartig gesprochen – bequem in der ihnen vertrauten Domäne der Software-Entwicklung bleiben und drücken sich darum, über den Tellerrand schauen zu müssen.

    Wenn ich aber wartbare und änderbare Software entwickeln will, dann muss ich als Architekt mein gewohntes Wohnzimmer der Software-Entwicklung verlassen und dahin gehen, wo die Anforderungen und Änderungsanforderungen herkommen, muss verstehen, wie die Leute da ticken, warum die so ticken, was deren Probleme sind und was sie treibt. Nur dann bin ich in der Lage, ein System zu entwerfen, das die geeigneten Strukturen bietet, um mit den aktuellen und zukünftigen Anforderungen im Sinne von Wartbarkeit und Änderbarkeit umzugehen. Und – da sollten wir uns nichts vormachen – das ist eigentlich die einzige Existenzberechtigung für uns Architekten. Nur dadurch können wir wirklich „Business Value“ mit unserer Arbeit erzeugen. Leisten wir das nicht, braucht man uns nicht.

    Ich nehme auch explizit die funktionalen Anforderungen mit in die Liste der von einem Architekten zu betrachtenden Dinge auf. Aus meiner Sicht ist es vereinfacht so: Während die nicht-funktionalen Anforderungen die Struktur und Beschaffenheit der Bausteine steuern, die wir entwerfen, steuern die funktionalen Anforderungen die Inhalte, wie viele Bausteine wir brauchen, was in welchen Baustein hineinkommt und wie sie miteinander interagieren. Da erfahrungsgemäß über 90% aller Änderungsanforderungen funktionaler Natur sind, würde ich als Architekt 90% meiner Existenzberechtigung (siehe oben) in Frage stellen, wenn ich sie nicht entsprechend massiv in meine Arbeit einbeziehen würde.

    Entsprechend hatten die meisten Systeme, die ich mit Problemen in Änderbarkeit, Performanz, Stabilität, etc. gesehen hatte, keine signifikanten Probleme in der technischen Architektur (zumindest nichts Dramatisches), sondern sie waren fachlich einfach „lausig“.

    Um die Kurve zu der von Dir genannten Analyse zu bekommen: Ja, d’accord, wir Architekten nutzen die Ergebnisse aus der Analyse – mit zwei Einschränkungen aus meiner Erfahrung:

    Zum einen ist es in der Tat so, dass einem Business Analysts und Requirement Engineers einen guten Teil der Sammlung und Konsolidierung der Anforderungen abnehmen können. Nur beschränken sie sich aus meiner Erfahrung rein auf die einzelnen Anforderungsdomänen, ohne die verschiedenen Anforderungen untereinander auszubalancieren (die Widersprüche werden einfach in getrennten Kapiteln hingeschrieben, ohne sie aufzulösen –> „Problem anderer Leute“) und insbesondere ohne zu prüfen, ob die geschriebenen Anforderungen überhaupt sinnvoll in der Form umsetzbar sind, da ihnen wiederum der Bezug zur Lösungsdomäne fehlt. Den (oftmals sehr anstrengenden und schwierigen) Teil muss dann der Architekt immer noch leisten, um ein gutes Ergebnis im Sinne aller Stakeholder erzeugen zu können.

    Und zum zweiten sind leider nicht überall Analysten in den Projekten. Da werden die unkonsolidierten und massiv lückenhaften Anforderungen von einem Fachbereich „über den Zaun geworfen“ (Betrieb, Security, etc. sind erst gar nicht gefragt worden) und dann steht man als Architekt mit dem „Trümmerhaufen“ da. In dem Fall bleibt einem gar nichts anderes übrig, als die Analyse mitzumachen, um ein gutes Ergebnis liefern zu können.

    Boah, wieder viel zuviel Text … hätte ich einen eigenen Blog-Post draus machen können … 😉 … aber ich fand Deinen Kommentar einfach zu gut und wollte Dir darauf auch vernünftig antworten. In Summe liegen wir da m.E. ziemlich weit auf einer Linie und die Feinheiten sind wahrscheinlich ein Stück weit in den konkreten Projekten begründet, die wir jeweils gesehen haben.

    Wenn ich Architektur und Design wirklich abgrenzen müsste, dann vielleicht in der Form: Als Designer kannst Du Dir noch den Luxus erlauben, Dein „Wohnzimmer“ nicht zu verlassen, wenn Du nicht willst. Als Architekt musst Du da raus, ob Du willst oder nicht. Sonst bist Du kein Architekt. (Gernot hatte das sehr schön mit seiner IT-Weltkarte dargestellt, die er mal vor zwei oder drei Jahren zur Vorstellung seiner Person verwendet hat.)

  • Februar 19, 2010 von Thomas Falkenberg

    Da bleibt mir eigentlich nichts mehr hinzuzufügen, sehr gut beschrieben! Wir sind auf einer Linie und ich hoffe, möglichst viele Entscheider und (potentielle) Architekten lesen das hier.
    Der Architekt muss genau dahin gehen „wo’s weh tut“ und benötigt daher sehr viel mehr als technische Skills – Beharrlichkeit, Geduld, Einfühlungsvermögen, Überzeugungskraft, Neugier, Humor :-), fachliches Verständnis der Domäne(n), mindestens Grundkenntnisse in allen Bereichen der Stakeholder usw. usw. So etwas in einer Person zu finden ist wahrscheinlich selten – wie wär’s mit Pair Architecting (oh, gibt’s laut google schon, zu spät) 😉 Aber die Anzahl der Architekten und die Arbeitsteilung in größeren Projekten ist sicherlich wieder ein eigenes Thema, das auch Bücher füllen könnte.

  • Februar 24, 2010 von Niklas Schlimm

    Hallo Kollegen!
    Ich wollte mich mal einmischen :-)
    Für mich ist die „Architektur“ eines Systems der Bauplan eines Software-Systems sowie die zugehörigen Konstruktionsregeln für diesen Bauplan (Meta-Modell). Der Bauplan wird dabei auf mehreren Modellebenen erstellt (Achtung: Begriff „Modell“ nicht zu eng nehmen, gerne auch Bleistift und Papier :-)).

    Auf der Analyse-Ebene geht es nur darum die bestehende Fachdomäne zu „erkunden“. Es wird nur beschrieben, was fachlich in der Zieldomäne, die durch DV unterstützt werden soll, so getrieben wird. Hier geht es um Personen, Rollen, Geschäftsprozesse etc. Auf dieser Ebene wird allerhöchstens die Entscheidung auf betriebswirtschaftlicher Ebene getroffen welche Aufgaben voll-automatisiert, teil-automatisiert oder manuell durchgeführt werden soll. Ich habe bisher diesen technologiefreien Teil immer als Facharchitektur bezeichnet.

    Auf der Entwurfs-Ebene geht es darum eine Lösung zu „erfinden“. Es wird beschrieben/diskutitiert, wie die Software aussieht, die die einzelnen fachlichen Aufgaben bewätligen soll. Diese Tätigkeit verstehe ich als das klassische Design. Design ist also nach meinem Verständnis eher ein Teil von Architektur. Der Teil, der sich damit befasst die Lösung zu beschreiben. Jetzt kann sich jemand hinstellen und sagen ich „designe“ die Fachdomäne bzw. die Facharchitektur. Wenn aber die Fachdomäne gestaltet wird, dann befinden wir uns nicht im Design, sondern im Bereich Aufbau- und Ablauforganisation … Design ist für mich ein Begriff, der für uns Techies reserviert ist :-)

    Die beiden Ebenen Analyse und Design kann man nicht immer scharf trennen. Aber man sollte sich mit so einer Aussage nicht wegstehlen und alles durcheinander werfen. Wir sollten den Anspruch haben fachliche Themen nicht zu stark mit software-technischen Themen zu mischen. „Teile und hersche“: Auf der komplexen Fachebene sind so viele Probleme/Themen zu erfassen, dass sich eine Trennung von Lösungsaspekten oft lohnt. Im Grunde genommen muss ein Entwickler von einem Fachexperten erklärt bekommen wie er arbeitet. Der Entwickler sucht dann instinktiv nach der richtigen Software-technischen Unterstützung für die Arbeit des Fachexperten. Die Lösung liegt m.E. also im Konsens zweier Personen die vertrauensvoll miteinander umgehen und reden. Der eine kennt das Geschäft, der andere weiß aus Erfahrung wie man ein gutes Softwareprogramm schreibt, dass das Geschäft erleichtert … ich glaube ich hab meinen Punkt klar gemacht!? :-)

    Es gibt noch eine weitere Modellebene, nämlich die Infrastruktur-Ebene, auf der von verteilten Rechnerknoten, Netzwerken und Betriebssystemen die Rede ist. Die Ebene gehört für mich aber klar in den technischen Teil und ist in unserem Diskurs am besten vom Rest der Welt zu trennen.

    Fazit: Mein Weltbild ist, dass Architektur auf allen Ebenen Analyse, Design und Infratsruktur statt findet. Design ist eine Teildisziplin (also eine Tätigkeit) im Rahmen der Architekturerstellung. Dabei begrenze ich den Begriff Design bewußt auf eine Tätigkeit, die ein Techie (Technischer Architekt/Entwickler) durchführt.

    Freue mich auf Feedback! Vielleicht liege ich hier ja total daneben.

    @Uwe: Noch ein Wort gegen Uncle Bob und ich lass Dich verhaften :-)

  • Hallo Niklas,

    okay, okay, ich sag ja gar nichts mehr gegen Uncle Bob … :-)

    Zu Deinem Kommentar: Ich denke, er macht zunächst einmal sehr schön sichtbar, dass es fürchterlich schwer bis unmöglich ist, Architektur und Design sauber voneinander zu trennen, nicht zuletzt auch deshalb, weil das Wort „Design“ im Englischen auch ganz allgemein „Entwurf“ bedeutet, was irgendwie auch wieder die Architektur umfasst. So habe ich auch schon öfter von „designing an architecure“ gelesen … wenn man nur lange genug darüber nachdenkt, bekommt man irgendwie spontane Kopfschmerzen … 😉

    Und auch einen zweiten Punkt, der mir wichtig ist, hast Du schön herausgearbeitet: Architektur hat sehr viel mit Kommunikation zu tun, man kann eine gute Architektur nicht alleine im stillen Kämmerlein entwerfen, man muss dafür viel kommunizieren, diskutieren und moderieren … natürlich kann man sich auch mal ins stille Kämmerlein zurückziehen, um den ganzen Input zu verarbeiten, aber das ist so ziemlich der geringste Teil der Gesamtaufgabe.

    Und was Du auch geschrieben hast: Man muss sich aus der Software-Entwicklungs-Domäne herausbewegen, um eine gute Architektur zu erstellen; man muss verstehen, wirklich verstehen, was „die anderen da draußen“ wollen und brauchen, um den Job gut machen zu können.

    Wenn Du eine Architektur entwirfst, dann gehst Du mittlerweile „instinktiv“ dahin, wo die Antworten auf Deine Fragen sind, nämlich zu den verschiedenen Stakeholdern, zu den Fachbereichen, zu den Anwendern, zu den Betrieblern, zu den Projektleitern, zu den Managern, usw. … und Du siehst zu, dass Du mit ihnen in ihrer Sprachen über ihre Probleme, ihre Treiber und ihre daraus resultierenden Anforderungen sprichst, zumindest – um die Aufgabe des Architekten jetzt nicht künstlich weiter zu vergrößern – in dem Umfang, in dem das notwendig ist, damit die Lösung zur Aufgabenstellung passt, d.h. dass die Anforderungen der verschiedenen Stakeholder in Summe möglichst gut erfüllt werden. Und wenn da Widersprüche sind, dann siehst Du halt zu, diese soweit wie möglich aufzulösen, bevor Du die Lösung an der Stelle fest machst.

    Du machst das „instinktiv“, Du merkst es gar nicht mehr, es ist für Dich selbstverständlich, dass Du das im Rahmen der von Dir beschriebenen Tätigkeiten machst, so selbstverständlich, dass Du es vielleicht gar nicht mehr erwähnenswert findest. Meine Erfahrung ist aber, dass viele sogenannte oder auch selbsternannte „Architekten“ genau das nicht tun, dass sie sich viel lieber tagelang damit auseinandersetzen, ob man nun EJB3 oder Spring einsetzen sollte, anstatt einmal für zwei Stunden zum Fachbereich zu gehen und zu klären, was die Anwendung denn an der im Fachkonzept schwammig beschriebenen Stelle wirklich tun soll. Das ist jetzt etwas pointiert dargestellt, aber Du weißt, was ich meine … 😉

    Ich denke einfach, es gibt viel zu viel Literatur zu Architektur, die sich nur auf den reinen Strukturierungsaspekt fokussiert und darüber komplett ausblendet, was dafür logisch (nicht zeitlich) vorher stattfinden muss, nämlich all die Arbeit, die notwendig ist, um zu klären und zu verstehen, was man da überhaupt entwerfen soll. Diese in der Literatur vielfach vernachlässigte Seite der Architektur wollte ich einfach mal etwas stärker beleuchten.

    Im Summe bin ich davon überzeugt, dass es keine Art gibt, wie man Achitektur genau machen „muss“ und auch keine Art, wie man IT-Lösungen realisieren „muss“, sondern dass es dafür – wie so oft – verschiedene Möglichkeiten gibt. Wichtig ist dabei aber, dass für eine gute Lösung die Domänengrenzen aktiv überschritten werden müssen, dass sich irgendwer aus der Software-Entwicklungs-Domäne (da wo die Lösung erstellt wird) aktiv in die anderen Domänen (da wo die Anforderungen herkommen) begeben muss und die Verbindung dazwischen herstellen muss. Aus meiner Erfahrung ist das der Architekt … zumindest habe ich noch keine andere Rolle in Projekten gefunden, der man das auf die Fahne schreiben könnte.

    Gruß, Uwe

    PS: Ich finde den Diskurs sehr interessant und stelle dabei fest, dass wir uns bislang noch viel zu selten zu solchen Themen ausgetauscht haben. Vielleicht sollten wir uns bei Gelegenheit mal zu einem guten Kaffee treffen (z.B. im Düsseldorfer Süden … 😉 ) und die Unterhaltung da fortführen … fände ich spannend.

  • Juni 16, 2010 von ingo

    Grady Booch hat mal eine gute Definition gegeben, die mein Verständnis von Architektur gut zusammenfasst. Hier mal aus dem Gedächtnis zitiert:

    „(All architecture is design and code but not all design and code is architecture). Architecture are the things that are expensive to change.“

    Als ein Mensch, der sich auch im Hardware/Mechanical Design von Systemen bewegen muss, war mir der Begriff der Architektur in der Softwareentwicklung, so wie ihn z.B. das SEI definiert, stets suspekt, weil er keine klare Abgrenzung zum Begriff des Designs ermöglicht.In der Hardware-Entwicklung bzw. dem Maschinenbau gibt es den Begriff der Architektur so ja nicht. Dort ist alles Entwurf (Design) bis zum Bau des Prototypen. Aus dieser Sicht, ist alles in der Softwareentwicklung Design bis zum „Anwerfen“ des Compilers.

    Booch’s Definition zieht die Grenze zwischen Architektur und Design auf einer hohen Ebene, gibt uns aber die Möglichkeit bzw. die Aufgabe zu entscheiden, welche Dinge zu einem späteren Zeitpunkt schwer zu ändern sind. Das ist eben von Projekt zu Projekt verschieden und nicht zuletzt auch eine Frage der Kosten.

    Das die Arbeit eines Architekten mehr umfasst – die sogenannten „weichen“ aber in der Regel alles andere als weichen Themen – wurde ja schon oben geschrieben.

  • Hallo Ingo,

    danke für die Ergänzung! Ich bin auch immer stärker davon überzeugt, dass es absolut müßig (und auch nicht zielführend) ist zu versuchen, eine klare Trennung zwischen Architektur und Design herzustellen. Das endet eh nur in einer philosophischen Debatte … :-)

    Wichtig ist mir der Punkt, dass Architektur, wenn ich es richtig machen will, mehr ist als „Malen nach Zahlen“ im UML-Tool der Wahl und das Beschreiben von kleineren oder größeren Programmstrukturen. Sicher, das gehört auch irgendwie dazu, aber wirklich wichtig ist das, was ich oben mit „Alignment“ beschrieben hatte … und das wird sehr häufig (unabsichtlich? mangels besseren Wissens?) übersehen.

    Manchmal bin ich mir ehrlich gesagt auch nicht mehr sicher, ob das wirklich noch zu Architektur gehört oder nicht. Klar ist nur, dass man das ganz, ganz dringend braucht, wenn man ein erfolgreiches Projekt haben will.

    Bzgl. Deines Schlusses aus dem Vergleich mit dem Hardware-Design, dass alles bis zum Anwerfen des Compilers in der Software-Entwicklung Design ist: Yep, exakt! Genauso ist es heute! Die Codierungsphase der früheren Tage, als Codierer Pseudocode in Assembler, COBOL, PL/1 oder welche Sprache auch immer „codierten“, gehört der Vergangenheit an. Das Design ist heute fertig, wenn die letzte Zeile Sourcecode geschrieben ist.

    Gruß aus Solingen, Uwe

  • eine interessante sichtweise. vor allem nicht der übliche tenor, wie ich finde.

  • sehr interessante artikel, ich danke ihnen für information.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *