Is there a difference between architecture and design?

Meanwhile, there is a debate for a long time whether architecture and design are the same thing or not. The advocates of the “both are the same” thesis say that architecture is basically the first stage of design, while the opponents of this thesis claim that architecture and design are completely different tasks that just share some more or less fuzzy line of contact. So, who the heck is right?

I think it is really hard to find out who is right or wrong … actually I think it is sort of impossible. Even within our small company we are not able to get a common agreement about what exactly architecture is and what design is. And if it is not possible to get to an agreement within a few people (even if some of them are strong characters … :-) ), how should we come to an agreement within the whole IT community? It is probably impossible.

Thus, I will not try to find a precise answer for that question. Instead I will try to approach the topic from a different angle. First, why is it so hard to answer the question? I think a big part of the problem is that there is no satisfying definition for both terms available, neither for architecture nor for design. So, whenever you talk with another person about architecture or design you can almost be sure that he or she will talk about something different than you do.

I mean there are *lots* of definitions available but most of them are so specific that they do not capture the topic sufficiently or they are so vague that they do not help at all. Just for instance, Robert Martin (who said and wrote a lot of very smart things, btw) once stated “Architecture is about the important stuff. Whatever that is.”. Now, this means everything and nothing. Does it mean that design is about the unimpotant stuff? Probably not. And, if coffee is really important for the developers (which it usually is), does it mean, that architecture is about coffee? Probably not. As you can see this definition does not really help.

I will not go into detail for other definitions because I think it will not lead anywhere. It won’t be possible to find a definition for architecture and design that everybody will agree upon *and* that will help us to figure out the difference between architecture and design. Especially I think it won’t be possible to find a clear separating line between architecture and design, where the one thing ends and the other thing starts. Everybody draws his line somewhere else and many people probably rather have some kind of fuzzy cloud in mind instead of a sharp line. “Somewhere within that cloud architecture stops and design starts” they will say.

Okay, but there must be something that might help us. At least there should be something …

Maybe it does help to step away from that question for a moment. From my experience I figured out that there are two basic tasks that make up that whole architecture and design thing (without trying to find the separating line). The whole thing is about transforming all the requirements that are around into a result. (Btw: If you would ask where the coding is in there, I think I would leave it up to you to find the separating line between design and coding; I think it is a similar question … 😉 )

The first part of that transformation task is to understand all the requirements (not just the business and user requirements, but also the requirements of the mangement, the project management, the development team, operations, system planning, the security department, the testers, and so on), really understand them, to balance them (there are always conflicting and inconsistent requirements across the different domains and stakeholders to deal with) and to find an appropriate solution idea for all those balanced requirements. I usually call this part of the work “alignment”.

The second part of the transformation into a working solution consists of turning the solution idea into an appropriate structure that supports maintainability and changeability, and refine the structure over and over again until you are down at the code level without losing the properties described before. I usually call this part of the work “structuring”.

Now, is it important to distinguish those two tasks? I think, yes! The reason for this is that I figured out that those two tasks require very different skills. While alignment has much to do with communication and conflict management skills, structuring requires more formal strengths. Also alignment requires kind of a broad knowledge about all the different requirement domains while structuring requires more of a deep knowledge about the solution domain. As a consequence, you will find quite few persons who are capable (or willing) of doing both tasks with the same strength, and if you neglect one of the two tasks you will most likely get an unsatisfying result.

Okay, getting back to the initial question. Will alignment and structuring help us to find a separating line. I think, sort of …

From my perspective, alignment is definitely part of any good architecture while structuring is definitely part of any good design. You cannot be a good architect without doing a lot of alignment and you also cannot be a good designer without doing a lot of structuring. How much of structuring is required in architecture and how much of alignment is required in design, I think that is mostly a matter of taste and there won’t be a definite answer to this.

So, I also cannot provide you with “the” answer to the initial question. But I know, if somebody talks about architecture without talking about alignment he does something wrong and if somebody talks about design without talking about structuring he also does something wrong. And that is the most important thing from my point of view …

PS: My apologies to Robert Martin for picking on his definition of architecture. As I wrote before he said and wrote a lot of really smart things, even though I do not agree with all of them. So, if you have the opportunity to read some of his stuff or listen to a presentation of him, just do it! Now, that should be enough of indemnification … 😉

  • Facebook
  • Delicious
  • Digg
  • StumbleUpon
  • Reddit
  • Blogger
  • LinkedIn
Uwe Friedrichsen

9 Responses to Is there a difference between architecture and design?

  1. Thomas Falkenberg says:

    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.

  2. … 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.)

  3. Thomas Falkenberg says:

    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.

  4. Niklas Schlimm says:

    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 :-)

  5. 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.

  6. ingo says:

    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.

  7. 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

  8. Stephan Kahn says:

    eine interessante sichtweise. vor allem nicht der ĂŒbliche tenor, wie ich finde.

  9. Junger Beer says:

    sehr interessante artikel, ich danke ihnen fĂŒr information.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>