Software Engineering Blog » Architektur http://www.swe-blog.net/blog Menschen. Prozesse. Technik. Wed, 28 Jul 2010 00:42:09 +0000 http://wordpress.org/?v=2.9 en hourly 1 MapReduce & Apache Hadoop-Vortrag auf Slideshare http://www.swe-blog.net/blog/archives/168 http://www.swe-blog.net/blog/archives/168#comments Fri, 22 Jan 2010 15:45:46 +0000 Oliver Fischer http://www.swe-blog.net/blog/?p=168 Wie gestern versproche, habe ich meinen Vortrag zu MapReduce und Apache Hadoop auf Slideshare online gestellt.

View more documents from oliver.b.fischer.
]]> http://www.swe-blog.net/blog/archives/168/feed 0 Ward Cunnigham über technische Schulden http://www.swe-blog.net/blog/archives/94 http://www.swe-blog.net/blog/archives/94#comments Sun, 03 May 2009 17:43:02 +0000 Oliver Fischer http://www.swe-blog.net/blog/?p=94 Vor einiger Zeit habe ich ein Phänomen beschrieben, welches ich Event-Driven-Software-Development nenne und dessen Kern von Martin Fowler als Technische Schulden beschrieben wird.

In Fowlers Blog habe ich jetzt einen Verweis auf ein Video von Ward Cunnigham gefunden, in welchem er den Begriff Technische Schulden erläutert und in 4 Minuten und 44 Sekunden auf den Punkt bringt.

]]> http://www.swe-blog.net/blog/archives/94/feed 0 Vortrag zu Architekturkommunikation http://www.swe-blog.net/blog/archives/82 http://www.swe-blog.net/blog/archives/82#comments Wed, 11 Mar 2009 21:04:00 +0000 Oliver Fischer http://www.swe-blog.net/blog/?p=82 Gernot Starke hat in seinem Blog einen Hinweis auf seinen auf der WJAX
gehaltenen Vortrag zum Thema Architekturkommunikation hingewiesen, der als Video online zur Verfügung steht.

Starke widmet sich in seinem Vortrag dem Zusammenhang von Architektur und Kommunikation und weiß das überzeugend zu vermitteln.

Nach seiner Ansicht ist eine der wesentlichen Aufgaben eines Architekten die Kommunikation mit allen am Projekt beteiligten Stakeholdern. Richtig dachte ich nur während des ganzen Videos. Gute Architekturen zu entwerfenist das eine, sie zum Leben zu erwecken und zu halten etwas anderes. Dafür
müssen alle miteingebunden werden, die davon betroffen seien könnten. Und leider muß es muß auch immer wieder wiederholt werden.

Hier ein paar nebenbei notierte Aussagen von Starke:

  • Architektur beschäftigt sich mit Strukturen und Konzepten.
  • Implizite Annahmen treten immer da auf, wo etwas nicht
    dokumentiert ist, wo es notwendig gewesen war. (Alt bekannt!)
  • Implizite Annahmen schaffen Mißverständnispotential. (Ich nenne
    das einfach mal heterogene Projektentwicklung. Klingt doch
    netter.)
  • Architektur ist nicht das Kodieren von selbigen, da Code
    allein ab einer gewissen Größe keine Basis für Verständnis
    ist.
  • Verständnis (von Architekturen) muß erst geschaffen werden und
    kann erst danach gefördert werden.
  • Dokumentation muß minimalistisch sein, womit gemeint ist, daß
    nur die relevanten oder stabilen Punkte dokumentiert werden sollten,
    die für das Verständnis der Anwendung notwendig sind.
  • Dokumentation muß wartbar sein.

Starke schafft es diese Punkte überzeugend zu vermitteln.

Fazit: Anschauen!

]]> http://www.swe-blog.net/blog/archives/82/feed 0 Ping-Pong spielen http://www.swe-blog.net/blog/archives/37 http://www.swe-blog.net/blog/archives/37#comments Tue, 25 Nov 2008 20:28:50 +0000 Oliver Fischer http://www.sw-blog.net/blog/?p=37 Schnittstellen zwischen Systemen, sind heute as A und O vieler Systeme. Gerade für Geschäftsanwendungen ist der Datenaustausch mit anderen Systemen ein zentraler Leistungsaspekt. Doch wie kann sichergestellt werden, daß alle Systeme erreichbar sind? Bei direkt gekoppelten Schnittstellen mit einem synchronen Aufruf kein Problem. Doch was kann tun, wenn die beteiligten Systeme nur indirekt und asynchron kommunizieren können? ping zeigt und hier den Weg auf.

In vielen Fällen tauschen Systeme nicht direkt aus, sondern über Drittsysteme wie E-Mail oder FTP. Diese Systeme fungieren dann als Relay und leiten die Nachricht an den eigentlichen Empfänger oder an ein weiteres Relay-System weiter. Das Problem ist, daß der Sender ab der Übergabe an ein Relay-System nichts mehr über den Zustellstatus der Nachricht weiß. Fire and forget. Daher ist es bewährt und erprobt ein Acknowledge für empfangene Nachrichten zu schicken. So kann der Sender feststellen, ob seine Nachricht empfangen wurde.

Was ist aber, wenn einfach nur festgestellt werden soll, ob einen Nachricht empfangen werden kann, also ob der Transportweg funktioniert? In Geschäftsanwendungen ist der Nachrichtenaustausch meist an Fachprozesse gebunden. Daher ist es nicht sinnvoll einfach zum Test eine Nachricht zu verschicken, soll auf der Empfangsseite keine Aktion ausgelöst werden. Doch wie kann der Transportweg anders getestet werden?

ping ist ein kleines Programm aus Unix-Urzeiten, mit dem die Erreichbarkeit von Rechnern in Netzwerken überprüfen läßt. Dafür verschickt es eine ICMP-Echo-Nachricht an einen Rechner und erwartet eine Antwort von diesem System, auch Pong genannt. Erhält ping keine Antwort, ist davon auszugehen, daß der Rechner nicht erreichbar ist.

Das gleiche Prinzip kann für Fachanwendungen genutzt werden. Hierzu muß lediglich eine eigene Ping-Nachricht für die Systemschnittstellen definiert werden, wobei folgende Anforderungen zu erfüllen sind:

  • Ihre Übermittlung muß vom Zielsystem quittiert werden.
  • Sie muß den gleichen Transport-Mechanismus durchlaufen wie die eigentlichen Nachrichten.
  • Sie darf keinen fachlichen Prozess auf der Empfängerseite auslösen.

So definiert, steht ein universelles Werkzeug bereit, um den Nachrichtenaustausch leicht und zuverlässig testen zu können.

]]> http://www.swe-blog.net/blog/archives/37/feed 0