Kommentare für Softwarearchitektur http://www.softwarearchitektur.de Was ich schon immer über Softwarearchitektur schreiben wollte. Wed, 08 Jul 2009 13:26:59 +0200 http://wordpress.org/?v=2.9.2 hourly 1 Kommentar zu Architekten mauern keine Wände und Softwarearchitekten programmieren nicht von alexander http://www.softwarearchitektur.de/?p=80&cpage=1#comment-960 alexander Wed, 08 Jul 2009 13:26:59 +0000 http://www.softwarearchitektur.de/?p=80#comment-960 Das Gegenstück zum Softwarearchitekten, der sich mal lieber nicht die "Finger an Code schmutzig" machen will, ist für mich eher der Architekt, der sich weigert, die Baustelle zu betreten und Bauaufsicht/-leitung lieber per Bauplan und Telefon erledigt. Ein Zufallsfund beim Googlen zeigt mir, dass dies wohl auch in der Baubranche ein real existierendes Problem ist: "Falls Sie einen Architekt haben dem die harte Baustellenarbeit nicht liegen sollte, oder wenn Sie eine zusätzliche Kontrollfunktion installieren möchten, dann übernehmen wir gerne die Örtliche Bauaufsicht. Wir haben den Vorteil, dass unsere Mitarbeiter über langjährige Baustellenerfahrung verfügen und dadurch für diese Aufgabe bestens geeignet sind." Dennoch denke ich, dass im Baugewerbe Aufsicht und Leitung ernsthafter verfolgt werden, denn im Gegensatz zu unserer Branche, wo ein unbefriedigendes (zu langsam, fehlerhaft, unbedienbar, etc.) Softwareerzeugnis oft als naturgegeben hingenommen wird und selten zu persönlichen Konsequenzen führt, kann ein Fehler bei der Bauaufsicht für den Architekten schnell zu einem teuren Haftungsproblem werden. Interessanterweise wird im Artikel das Thema Test - zum dem es in der Baustellenwelt meiner Ansicht nach keine direkte Entsprechung gibt - etwas stiefmütterlich behandelt. Ich denke, dass ein Softwarearchitekt nicht nur mit den Entwicklern, sondern auch mit dem Testteam eng zusammenarbeiten muß. So müssen zum Beispiel repräsentative Performancetests realisiert werden, um die Tragfähigkeit der Architektur zu validieren. Integrationstest, Lasttests und Feldversuche werden dem Architekten wertvolle Daten und Feedback über das Gesamtsystem liefern. Zudem kann es nicht schaden, wenn ein Softwarearchitekt ein Auge auf die im Test entstehene Software hat - auch die Tests werden sich über die Zeit fortentwickeln und müsen daher wartbar sein. Zuletzt noch eine Vermutung meinerseits: kann es sein, dass die Kaste der nicht-programmierenden Softwararchitekten mit auch das Produkt einer Firmenkultur ist, in der es eine strenge Wertigkeitshierarchie zwischen Tätigkeiten gibt? Frei dem Motto "Designen ist besser als Programmieren und das ist allemal besser als Testen"? Das Gegenstück zum Softwarearchitekten, der sich mal lieber nicht die “Finger an Code schmutzig” machen will, ist für mich eher der Architekt, der sich weigert, die Baustelle zu betreten und Bauaufsicht/-leitung lieber per Bauplan und Telefon erledigt.

Ein Zufallsfund beim Googlen zeigt mir, dass dies wohl auch in der Baubranche ein real existierendes Problem ist: “Falls Sie einen Architekt haben dem die harte Baustellenarbeit nicht liegen sollte, oder wenn Sie eine zusätzliche Kontrollfunktion installieren möchten, dann übernehmen wir gerne die Örtliche Bauaufsicht. Wir haben den Vorteil, dass unsere Mitarbeiter über langjährige Baustellenerfahrung verfügen und dadurch für diese Aufgabe bestens geeignet sind.”

Dennoch denke ich, dass im Baugewerbe Aufsicht und Leitung ernsthafter verfolgt werden, denn im Gegensatz zu unserer Branche, wo ein unbefriedigendes (zu langsam, fehlerhaft, unbedienbar, etc.) Softwareerzeugnis oft als naturgegeben hingenommen wird und selten zu persönlichen Konsequenzen führt, kann ein Fehler bei der Bauaufsicht für den Architekten schnell zu einem teuren Haftungsproblem werden.

Interessanterweise wird im Artikel das Thema Test – zum dem es in der Baustellenwelt meiner Ansicht nach keine direkte Entsprechung gibt – etwas stiefmütterlich behandelt. Ich denke, dass ein Softwarearchitekt nicht nur mit den Entwicklern, sondern auch mit dem Testteam eng zusammenarbeiten muß. So müssen zum Beispiel repräsentative Performancetests realisiert werden, um die Tragfähigkeit der Architektur zu validieren. Integrationstest, Lasttests und Feldversuche werden dem Architekten wertvolle Daten und Feedback über das Gesamtsystem liefern. Zudem kann es nicht schaden, wenn ein Softwarearchitekt ein Auge auf die im Test entstehene Software hat – auch die Tests werden sich über die Zeit fortentwickeln und müsen daher wartbar sein.

Zuletzt noch eine Vermutung meinerseits: kann es sein, dass die Kaste der nicht-programmierenden Softwararchitekten mit auch das Produkt einer Firmenkultur ist, in der es eine strenge Wertigkeitshierarchie zwischen Tätigkeiten gibt? Frei dem Motto “Designen ist besser als Programmieren und das ist allemal besser als Testen”?

]]> Kommentar zu REST: ein Architekturstil und kein weiteres Protokoll von Wolfgang Strunk http://www.softwarearchitektur.de/?p=126&cpage=1#comment-959 Wolfgang Strunk Mon, 06 Jul 2009 09:54:20 +0000 http://www.softwarearchitektur.de/?p=126#comment-959 Hallo Robert,herzlichen Dank für deine Kommentare. Ich möchte dir gerne zwei Antworten geben. 1. jede Resource hat eine ID Der Ansatz jedem Ding eine ID zu geben eignet sich natürlich nicht für alles. Ich bin aber nicht bei dir, daß daß die Suchanfrage, um Ressourcen zu finden eigentlich eine Funktion referenzieren muß. Nehmen wir als Beispiel die Domäne der Unternehmenskommunikation. Ich möchte an einer Telefonkonferenz teilnehmen und muß ersteinmal die Konferenz ID finden, bevor ich der Konferenz beitreten kann. Hierbei kann die Einstiegs URI die Adresse des Konferenzservers sein, der mir als Seite alle laufenden Konferenzen, die jede wiederum eine eigene URI haben, auflistet. Caching kann ich hierfür natürlich nicht anwenden, da sich die Menge dynamisch ändert. 2. Statuslose Kommunikation Um hier Misverständnisse zu vermeiden: ich sage nicht, daß die Applikation selbst keinen Zustand haben sollte. Wichtig ist nur, diesen Zustand nicht über Session-Data in den Klienten zu verlagern. Mir ist auch klar, daß nicht alles zustandslos abgebildet werden kann. Um aber wieder auf das Beispiel des Kommunikationsservers zurückzukommen, denke ich, daß man die wichtigsten UseCases wie "Click-To-Call" oder "Konferenz beitreten" durchaus statuslos realisieren kann. Die Klienten-Seite muß dann die Server Antworten entsprechend auswerten und sich einen Satus selsbt speichern oder vor jedem weiteren Call beim Server erneut abfragen. Hallo Robert,herzlichen Dank für deine Kommentare. Ich möchte dir gerne zwei Antworten geben.
1. jede Resource hat eine ID
Der Ansatz jedem Ding eine ID zu geben eignet sich natürlich nicht für alles. Ich bin aber nicht bei dir, daß daß die Suchanfrage, um Ressourcen zu finden eigentlich eine Funktion referenzieren muß. Nehmen wir als Beispiel die Domäne der Unternehmenskommunikation. Ich möchte an einer Telefonkonferenz teilnehmen und muß ersteinmal die Konferenz ID finden, bevor ich der Konferenz beitreten kann. Hierbei kann die Einstiegs URI die Adresse des Konferenzservers sein, der mir als Seite alle laufenden Konferenzen, die jede wiederum eine eigene URI haben, auflistet. Caching kann ich hierfür natürlich nicht anwenden, da sich die Menge dynamisch ändert.
2. Statuslose Kommunikation
Um hier Misverständnisse zu vermeiden: ich sage nicht, daß die Applikation selbst keinen Zustand haben sollte. Wichtig ist nur, diesen Zustand nicht über Session-Data in den Klienten zu verlagern. Mir ist auch klar, daß nicht alles zustandslos abgebildet werden kann. Um aber wieder auf das Beispiel des Kommunikationsservers zurückzukommen, denke ich, daß man die wichtigsten UseCases wie “Click-To-Call” oder “Konferenz beitreten” durchaus statuslos realisieren kann. Die Klienten-Seite muß dann die Server Antworten entsprechend auswerten und sich einen Satus selsbt speichern oder vor jedem weiteren Call beim Server erneut abfragen.

]]> Kommentar zu REST: ein Architekturstil und kein weiteres Protokoll von Robert Schmelzer http://www.softwarearchitektur.de/?p=126&cpage=1#comment-957 Robert Schmelzer Fri, 03 Jul 2009 13:42:55 +0000 http://www.softwarearchitektur.de/?p=126#comment-957 Ich halte REST (neben dem prinzipellen Unterschied in der architekturellen Denkweise) schon für einen Pendelausschlag ins andere extrem ist. Den wie REST derzeit eingesetzt wird, sind es Schnittstellen ohne definierten bzw. ohne dokumentierten Format. Das heisst die Komplexität der Schnittstellenvereinbarung verlagert sich wiederum ins zwischenmenschliche bzw. erfordert es zusätzliche Dokumentation. Für einen Einsatz im B2B Beriech würde ich wenn dann auf jeden Fall strukturierte Nachrichten wie XML (mit Schema Definitionen) und Versionierung der Nachrichten einführen. Um auch die volle Eleganz mit REST auszuspielen, finde ich, dass man auch relativ lange abwärtskompatibel sowohl aus Client als auch auf Server Seite sein muss. Dann hat die etwas lockerer Handhabung der Payload auch praktische Vorteile. Des weiteren klingt der Ansatz zwar sehr sauber, in der Praxis merkt man aber doch, dass die Welt komplexer ist. Ein Beispiel: 1. Jedes “Ding” bzw. jede Ressource hat eine ID: Welche ID hat eine Suchabfrage um Resourcen zu finden? Das ist dann die URL eigentlich ein Name für ein Funktion, die über Parameter konfiguriert wird. Du kannst mit der URL dann auch die klassischen Chaching verfahren nicht anwenden, da Suchfunktionen ja in Ihrer Definition jedesmal andere Ergebnisse liefern. 5. Statuslose Komunikaiton Ist halt auch mehr Gerücht als Wahrheit. Nicht umsonst steckt man in Webanwendungen soviel Know-How in das Session Handling. Also zustandslose Kommunikaiton ist schon möglich - das ändert halt nichts an der Tatsache dass Applikationen nicht zustandslos funktionieren und man auch in einer REST Architketur Antworten dafür haben muss. Ich halte REST (neben dem prinzipellen Unterschied in der architekturellen Denkweise) schon für einen Pendelausschlag ins andere extrem ist. Den wie REST derzeit eingesetzt wird, sind es Schnittstellen ohne definierten bzw. ohne dokumentierten Format. Das heisst die Komplexität der Schnittstellenvereinbarung verlagert sich wiederum ins zwischenmenschliche bzw. erfordert es zusätzliche Dokumentation. Für einen Einsatz im B2B Beriech würde ich wenn dann auf jeden Fall strukturierte Nachrichten wie XML (mit Schema Definitionen) und Versionierung der Nachrichten einführen. Um auch die volle Eleganz mit REST auszuspielen, finde ich, dass man auch relativ lange abwärtskompatibel sowohl aus Client als auch auf Server Seite sein muss. Dann hat die etwas lockerer Handhabung der Payload auch praktische Vorteile.

Des weiteren klingt der Ansatz zwar sehr sauber, in der Praxis merkt man aber doch, dass die Welt komplexer ist.
Ein Beispiel:
1. Jedes “Ding” bzw. jede Ressource hat eine ID:
Welche ID hat eine Suchabfrage um Resourcen zu finden? Das ist dann die URL eigentlich ein Name für ein Funktion, die über Parameter konfiguriert wird. Du kannst mit der URL dann auch die klassischen Chaching verfahren nicht anwenden, da Suchfunktionen ja in Ihrer Definition jedesmal andere Ergebnisse liefern.

5. Statuslose Komunikaiton
Ist halt auch mehr Gerücht als Wahrheit. Nicht umsonst steckt man in Webanwendungen soviel Know-How in das Session Handling. Also zustandslose Kommunikaiton ist schon möglich – das ändert halt nichts an der Tatsache dass Applikationen nicht zustandslos funktionieren und man auch in einer REST Architketur Antworten dafür haben muss.

]]> Kommentar zu In eigener Sache von Marko http://www.softwarearchitektur.de/?p=16&cpage=1#comment-3 Marko Wed, 17 Dec 2008 18:43:19 +0000 http://www.softwarearchitektur.de/?p=16#comment-3 Moin Wolfgang! Die meisten Blogs lese ich per Feedreader. Ich weiß nicht, wie/ob WordPress so Artikeln in den Feed setzt, die man in die Vergangenheit datiert. Und ich weiß auch nicht, wie die Feedreader (in meinem Fall: Google Reader) damit umgehen. Ich fände es aber schade, falls mir dadurch diese Artikel entgehen. Deswegen meine Bitte: Beobachte mal, ob auch so zurückdatierte Artikel noch in den Feed kommen. Sonst kannst Du ja gelegentlich mal Ankündigungs-Artikel machen, welche alten Artikel Du so in letzter Zeit eingestellt hast. Mit Gruß aus Mainz, marko Moin Wolfgang!

Die meisten Blogs lese ich per Feedreader. Ich weiß nicht, wie/ob WordPress so Artikeln in den Feed setzt, die man in die Vergangenheit datiert. Und ich weiß auch nicht, wie die Feedreader (in meinem Fall: Google Reader) damit umgehen. Ich fände es aber schade, falls mir dadurch diese Artikel entgehen.

Deswegen meine Bitte: Beobachte mal, ob auch so zurückdatierte Artikel noch in den Feed kommen. Sonst kannst Du ja gelegentlich mal Ankündigungs-Artikel machen, welche alten Artikel Du so in letzter Zeit eingestellt hast.

Mit Gruß aus Mainz, marko

]]>