Was ist eine Referenzarchitektur? Wie wird sie bewertet?

Liebe Leser!

Man hört oft von Referenzarchitekturen und deren Vorteile. Was ist nun eine Referenzarchitektur?

Laut wikipedia ist eine Referenzarchitektur ein Modellmuster – also ein idealtypisches Modell – für eine Klasse  zu modellierender Architekturen. Typischerweise wird eine Klasse von Softwarearchitekturen mit einem bestimmten Anwendungsbereich mittels einer Referenzarchitektur beschrieben. Neben fachlichen gibt es aber auch technische Referenzarchitekturen.

Produkte aus konkreten, aus einer Referenzarchitektur abgeleiteten Architekturen, können auch Teil einer „Produktfamilie“ sein. In diesem Fall kann die Referenzarchitektur die der Produktfamilie gemeinsamen Aspekte beschreiben.

Hauptvorteile bei der Verwendung von Referenzarchitekturen ist die Zeitersparnis durch die erzielte Wiederverwendung – hierbei reicht das Spektrum der Wiederverwendung von den architektonischen Blaupausen bis hin zu konkreten Software Komponenten, da diese ja alle der Referenzarchitektur inhärenten Anforderungen erfüllen. Ein System, welches einer Referenzarchitektur folgt, muss also nicht „von Null weg“ auf dem Reißbrett geplant werden, sondern fußt auf – im besten Fall – vielfach bewährten Konzepten, Entscheidungen und Lösungsmustern. Damit ist die Verwendung von Referenzarchitekturen auch angewandtes Wissensmanagement, da sich viele evolutorisch gewonnene Erfahrungen in einer Referenzarchitektur manifestieren.

Nachteile der Verwendung einer Referenzarchitektur sind der Aufwand der Erstellung und Pflege (technologische und konzeptuelle Neuerungen im Technologie- und Anwendungsbereich der Referenzarchitektur müssen ja nachgezogen werden), die Vererbung von Fehlern der Referenzarchitektur in konkrete, von dieser Referenz abgeleiteten, Architekturen und die Einschränkung des kreativen Freiraumes der Beteiligten, da viele Rahmenbedingungen und Entscheidungen bereits vorweg genommen sind [vgl. auch http://www.imn.htwk-leipzig.de/~weicker/pmwiki/pmwiki.php/Main/Referenzarchitektur]. Ein weiteres Problem ist das „Konsistent-Halten“ von konkreten abgeleiteten Architekturen und Referenzarchitektur – ohne Konsistenz entwickeln sich beide Architekturen unabhängig voneinander weiter und Fortschritte in der Referenzarchitektur müssen – möglicherweise manuell – in jede einzelne instanziierte Architektur eingearbeitet werden.

Für Produktfamilien ist es wichtig, die Gemeinsamkeiten der Produkte zu beschreiben und den Spielraum für erlaubte Abweichungen festzulegen. Dabei ist eine Referenzarchitektur umso wertvoller, je größer der gemeinsame Kern ist und je formeller die erlaubten Abweichungen – die Generik – beschrieben und validiert werden können.

Euer

JWR@coopXarch.

Architektur in der Cloud

Liebe Leser,

ich war vor kurzem auf einem abendlichen Microsoft Architect Forum Event in Wien. Die Themen lauteten „Windows Azure Update“ und „Der Architekt im Zeitalter von Cloud Computing“. Zu Beginn wurden einige neue – durchaus sehr interessant wirkende – Features von Windows Azure vorgestellt. Darüber hinaus fand eine sehr spannende Podiumsdiskussion von ehemaligen und aktuellen Microsoft Architekt-Evangelisten statt. Im Rahmen der Diskussion wurden einige sehr spannende Ansichten kundgetan, welche mich durchaus zum Nachdenken angeregt haben. Im Folgenden möchte ich einige Quintessenzen wiedergeben, welche ich aufgenommen bzw. für mich gebildet habe.

Kostenbetrachtung
Im Gegensatz zu Architekturen der vergangenen Jahre ist gerade in Verbindung mit Cloud Computing ein KPI (Key Performance Indicator) besonders wichtig geworden. Dabei handelt es sich um den sogenannten TCO (Total Cost of Ownership). Dieser Wert beschreibt im konkreten Kontext die Kosten, welche gesamtheitlich betrachtet in Verbindung mit einer vorliegenden Architektur entstehen. Bei herkömmlichen Lösungen lässt sich dieser sehr schwer fassen bzw. beziffern. Durch Cloud Computing und der damit einhergehenden pay-per-use Philosophie entsteht eine Kostentransparenz, welche die Kosten wieder in einen zentralen Blickwinkel rückt und uns Architekten dadurch zur Konzeption einer kosteneffizienten Gesamtlösung zwingt. Schöne Architektur über alles und um jeden Preis ist damit passé.

Business Value
Der oberste Wert, an dem sich ein Architekt orentieren sollte, ist der Business Value, der hinter einer umzusetzenden Lösung steckt. Architekten sind heutzutage mehr denn je dazu angehalten, dass das Systemdesign und die Systemarchitektur nach den Grundsätzen des BCM (Business Capability Management) ausgerichtet und dem konkreten Geschäftszweck und –wert angepasst sind. Die IT als Selbstzweck war seit jeher eine schlechte Idee. Im Hinblick auf Business Value und Kostentransparenz muss die IT an das vorliegende Geschäft angepasst werden und sollte darüber hinaus sogar in vielen Fällen als Business Enabler dienen. Dies bedeutet natürlich auch, dass nicht immer die perfekte Lösung gefragt ist, sondern vielmehr die auf das jeweilige Geschäft (und die damit verbundenen Anforderungen) am besten passende. Die Rolle des Architekten in diesen Zeiten beinhaltet deshalb noch stärker denn je die Aufgabe der Brückenbildung zwischen Fachbereich(en) und IT um gerade die Kundenbedürfnisse genau zu erfassen und danach zu handeln. 

Systemgrenzen / Systemdesign
Die Architektur von zukünftigen nachhaltigen Cloud-Lösungen kann mehrere grundsätzliche Ausprägungen annehmen. Die aktuell am erfolgversprechendste und auch mit der geringsten Einstiegshürde für Kunden verbundene ist vermutlich jene einer Hybrid-Cloud. Dabei werden Teile der Services bzw. Daten in der Cloud und andere on-premise gehostet. Die beiden Ufer werden durch die Cloudanbieter-Infrastruktur wie beispielsweise den Windows Azure AppFabric ServiceBus miteinander verbunden. Daraus resultiert natürlich eine essenzielle und entscheidende Herausforderung für den Architekten: er muss eine intelligente Serviceisolierung und die dazugehörigen Servicegranularitäten festlegen. Diese Aufgabe ist unter anderem stark von den jeweils vorherrschenden Governance- und Compliencebestimmungen eines Unternehmens oder gar eines Landes abhängig.

Versionierung
Ein nicht zu vernachlässigendes Thema in Bezug auf Serviceorientierung – und nichts anderes ist eine cloudbasierte Lösung in der Regel – ist Serviceversionierung. Überlegungen hierzu existieren bereits seit längerem und besonders durch das Aufkommen von SOA (Service Oriented Architecture) wurden diese vakant. Ein möglicher Ansatz, welcher mir ganz gut gefällt, ist die Lösung der Versionierungsproblematik auf organisatorischer Ebene. Hierbei werden für alle Servicebetreiber und Servicekonsumenten geltende Policies in Bezug auf Lebensdauer und Servicegenerationen festgelegt. Der Einsatz von Servicefassaden für alle in Betrieb befindlichen Generationen ist ebenfalls verpflichtend. Solche Policies findet man nicht nur unternehmensintern, sondern auch bei großen Anbietern von unternehmensübergreifenden oder öffentlichen Services, wie diese zum Beispiel von Amazon angeboten werden.

Stateless Behaviour
Ein weiteres Faktum bei der Erstellung einer Architektur unter der Verwendung von Cloud-Technologie ist, dass Services in der Cloud stateless sein müssen! Mit Hilfe von Queues und persistenten Storagemöglichkeiten (wie SQL Azure, Table Storage oder Blob Storage) können Services natürlich (laufend) Informationen über deren State ablegen, welche dann im Falle eines Serviceausfalles bzw. Neustart des Services (auf irgendeiner virtuellen Instanz) wieder ausgelesen werden können. Diese Logik ist jedoch ebenfalls von Anfang an vorzusehen und aktuell auch selbst zu implementieren. 

Fazit
Im Hinblick auf oben genannte Punkte und natürlich darüber hinaus bin ich mir sicher, dass Architekten aktuell und in unmittelbar bevorstehender Zukunft vor neuen spannenden Herausforderungen gestellt sind. So wie sich die IT in einem ständigen Wandel befindet, so trifft dies auch auf die Handlungsweisen und Aufgaben eines Architekten zu. Wir befinden uns in einer spannenden Zeit und es ist an uns, diese mitzugestalten.

Euer
JL@coopXarch

JWR@coopXarch spricht auf den Software Quality Days 2011

Liebe Leser!

Ich spreche in meinem Vortrag im Rahmen der Konferenz "Software Quality Days 2011" über die Schaffung eines Ökosystems für agile, nachhaltig-effektive Software-Entwicklung.

Ein Ökosystem für agil-effektive Software-Entwicklung

Die erste B2B-Automobil-Auktion auf www.papa.at wurde am 3. März 2009 nach nur vier Monaten Entwicklungszeit des Online Portals erfolgreich durchgeführt. Dieser Beitrag stellt das Projekt vor, das auf agiles Vorgehen (Scrum), innovative Methoden und Technologien (Kontinuierliches Integrieren, Automatisiertes Testen, Spring Framework, GWT) und die vom Vortragenden entwickelte Plattform für agile Projektzusammenarbeit "Openspace" gesetzt hat und erfolgreich liefern konnte. Der Vortragende gibt als Projektleiter, Scrum Master und Backend-Architekt des Projekts Einblicke in die Erfolgsgeheimnisse und "Lessons Learned" und zeichnet ein Bild eines "Ökosystems“ für agile, nachhaltig-effektive Software-Entwicklung.

Mittwoch, 19. Jänner 2011 von 15:15 bis 16:00 Uhr (Die Gesamt-Veranstaltung "Software Quality Days 2011" findet vom 18. bis 20.01.2011 statt - siehe Konferenzprogramm).

Austria Trend Hotel Savoyen Vienna, A-1030 Wien, Rennweg 16

Ich freue mich natürlich über Euren Besuch auf den Software Quality Days 2011! DI Johannes Bergsmann ist ein Ziviltechniker Kollege - er und sein Software Quality Lab veranstalten die Software Quality Days.

Euer

JWR@coopXarch.

Software Architektur im Großen - wie überzeuge ich nur die Mannschaft?

Liebe Leser!

Zur Zeit darf ich eine große Organisation bei Ihren Bemühungen um eine unternehmensweite Architekturinitiative unterstützen. Hier wird versucht, eine Enterprise Architektur aus der gegebenen Landschaft zu extrahieren und zu kartographieren. Neben der Ist-Darstellung gibt es auch bereits eine Soll-Darstellung. Gleichzeitig wird die Software Architektur der bestehenden Applikationen (und das sind nicht 2 oder 3 oder 30, sondern viel mehr) rekonstruiert ("Architektur-Rekonstruktion" - mein Part) und mit dem Gesamtbild in Einklang gebracht - alles in allem also eine vorbildliche Initiative.

In der Diskussion entstand dann die interessante Frage, wie wohl die Unterstützung der Mannschaft dafür gewonnen werden kann, da bei der Einbeziehung von Mitarbeitern auf Produktebene vornehme Zurückhaltung bis leichter Widerstand ("na wenn wir das jetzt auch noch tun sollen, verschieben sich aber A, B und C...") zu spüren war.

Jetzt ist es zweifelsfrei so, dass man alles verkaufen muss, auch Architektur (vgl.etwa [Peter Hruschka]), jedoch möchte ich doch meine Meinung zu diesem Punkt in den folgenden Bullets anführen:

• Architekturmanagement ist keine Schönheitsdisziplin als Antithese zu "Wir sind auch bisher ohne Architektur ausgekommen" (Architektur-Agnostik)
• Stadtplanung ohne Architektur führt zum selben Ergebnis wie Softwareentwicklung ohne Architektur: zu beliebiger, heterogener, emergenter und teilweise stark suboptimaler Anordnung von Bauelementen mit Problemen in der Pflege und Weiterentwicklung bzw. Skalierung.
• Skalierung ohne Architektur ist jedenfalls ein Abenteuer, wie man an vielen Ghettos rund um Großstädte sehen kann - oder eben auch in stark gewachsenen Softwareapplikationen bzw. Applikationslandschaften. Jedoch muss man auch sehen, dass das Gegenteil von vollständiger Abwesenheit, also z.B. künstliche Städte vom Reißbrett, noch keinen Ästheten vom Hocker gehauen hat...
• Wer also glaubt, man könne ganz ohne Architektur-Fokus auskommen, sollte sich nicht wundern, wenn die Organisation bald ohne ihn auszukommen versucht...
• Der CIO ist für das "Herunterbrechen der Architektur-Ziele auf die Mitarbeiterebene" verantwortlich als Analogon zu "Umsatzziele werden ja auch auf den einzelnen Verkäufer herunter gebrochen"
• Jedem ist ungefähr klar, wie Umsatzziele aufgeteilt werden, um sie schlussendlich hoffentlich zu erreichen. Bei Architekturzielen fragt man sich jedoch, wie die Mannschaft davon zu überzeugen wäre.
• Ich meine, wir haben es hier mit einem Analogon zu tun und muss es auch so behandeln. Ein Kompetenzcenter Architektur unterstützt den CIO (oder auch CTO) bei der Definition und Kommunikation der Maßnahmen, auf die Reise in die Linie schicken muss diese Maßnahmen aber der CIO - das ist sein Job!
• Die Wertschöpfung aus Architekturmaßnahmen muss und darf nicht nur langfristig erkennbar sein als Gegenpol zu "Wer macht die schönere Kosten/Nutzen Aufstellung"
• Die Gefahr ist nicht, dass Investitionen in Architektur möglicherweise nicht ganz die erhofften Erwartungen treffen, sondern, dass Budget investiert wird und nach 2-3 Jahren gar nichts dabei heraus schaut. Das passiert, wenn etwa das Budget für die Quersubventionierung von anderen Schmerzbereichen verwendet wird, oder nur tote Dokumentation ohne Chance auf Wartung erstellt wird.
• Man kann auch kurzfristige Benefits ins Rennen schicken, dafür eignet sich z.B. der Ist/Soll Vergleich sehr gut, da er den Ausgangspunkt und das Ziel visuell darstellt. Für viele Mitarbeiter offenbart sich hier erstmals das Gesamtbild der Applikationslandschaft und schafft die Basis für die Motivation, den Status Quo zu verändern.
• Eine Kultur der Architektur als Gegenbewegung zu "Ich muss mich immer für Architekturmaßnahmen rechtfertigen!"
• Meiner Meinung nach ist die Migration in eine Kultur des Architekturverständnisses dann erreicht, wenn nicht der, der sich Zeit für Architektur nimmt, eine Ausrede suchen muss ("ja hast du denn nichts Besseres zu tun?"), sondern der, der Architekturmaßnahmen unterlässt. Für eine Unterlassung gibt es auch immer Gründe, wie das allseits bekannte "Es muss aber unbedingt nächsten Ersten ausgeliefert werden!". Realität schafft Fakten. Punkt. Dann muss man es auf das "Schulden in der Zukunft" Konto laden und später behandeln. Nur vergessen sollte man es nicht.

Zusammenschau:

Im klassischen Umfeld:

Es bedarf meines Erachtens sowohl des Verständnisses als auch des sanften Drucks - oder positiv formuliert - der Motivation, um Bemühungen zu fokussieren und das Vorhaben auf die Reise zu schicken. Wer an Architektur als Freifach oder Kür glaubt, ist meines Erachtens blauäugig und wird auf Dauer zur Gefahr für den nachhaltigen Erfolg.

Und im agilen Umfeld?

Hier kommt der Druck aus dem Team selbst, sofern es die Wichtigkeit verstanden hat und die Relation zum geschaffenen Wert hergestellt ist. Agile Vorgehensweisen sind Wertmaximierer, und wenn ein Wert zu erkennen ist, müssen die Aktionen diesen auch berücksichtigen - ihn also "schöpfen".

Ich hoffe, das Thema ist für Euch genauso spannend wie für mich!

Euer

JWR@coopXarch.

Automatisierte Validierung der Software Architektur mit dem Tool "SonarJ"

Liebe Leser!

Zur Modellierung und Validierung von Softwarearchitektur verwenden wir das Tool "SonarJ". Im Anschluss lest ihr eine Mail an mein Team aus dem "42" Projekt, das auf Architekturverletzungen und damit verbundene, von mir bereits teilweise durchgeführte Refactorings verweist und aufzeigt, welche zusätzlichen Schritte zu setzen sind, um die bestehenden Architekturverletzungen zu beheben. Sehr schön sieht man wieder einmal, dass das schönste Architekturmodell ohne automatische Validierung nicht eingehalten werden kann und sich im Prozess der Entwicklung sub-optimale Designentscheidungen und daraus folgende Implementierungen nicht "up-front" vermeiden lassen. Aber lest selbst...

---- mail snippet ----

Hallo 42-Team!

Nachdem ich gerade mit SonarJ für ein anderes Projekt arbeite, hab ich auch gleich die 42-Software einem Architektur-Review unterzogen und ein paar unschöne Abhängigkeiten entfernt:

Das ist die definierte Architektur (horizontale Box = Layer; vertikale Box = Domain-Bereich) mit den in grün eingezeichneten erlaubten Abhängigkeitsbeziehungen – links von oben nach unten, rechts von unten nach oben (eine Abhängigkeit vom Backend auf den Layer „view“ ist z.B. verboten):

Ein frappantes Ergebnis des SonarJ Durchlaufs war eine Abhängigkeit vom Backend auf den Layer „view“ - das ist natürlich immer strengstens verboten, ist aber 3x im Code vorgekommen! Ich habe das klarerweise sofort behoben.

Nachdem es nun keine Abhängigkeiten auf den layer „view“ mehr gibt, könnte man das Projekt gänzlich ohne den View Layer "at.*****.client" im Klassenpfad kompilieren und die Backend Tests fahren – wer will, kann’s ja ausprobieren.

Folgende Architekturverletzungen gibt es noch (in rot auf der rechten Seite der Layer eingezeichnet):

Die Layer „model“ und „service“ greifen auf „remoting“ zu, was natürlich auch zu vermeiden wäre – der Grund sind die DTOs (i.e. die „*Info“ Klassen), die wir in den 3(!) Layern "remoting", "service" und "model" definiert haben:

AuctionServiceImpl.java befüllt ein AuctionInfo und das referenziert auf VehicleInfo(s).

Die Verstreuung der *Info Klassen sollte man natürlich auch in den Griff bekommen, allerdings gibt es im Backend sehr viele weitere zyklische Abhängigkeiten, sodass nach Beseitigung der Abhängigkeiten nur die Layer „remote" und "controller“ unabhängig würden, das Backend mit "data-access", "model" und "service" bliebe aber nur monolithisch verwendbar.

Hier nochmal alle nicht erlaubten Abhängigkeiten:

Diese Architekturverletzungen müssen noch systematisch durch Refactoring behoben werden. 

mfg

Hannes.

---- mail snippet ----

Euer

JWR@coopxarch.

Logging in dot.net

Einführung

Aktuell bin ich als Entwicklungsleiter in einem C# Umfeld eingesetzt. Bei einer Client/ServerApplikation galt es, UseCases zu monitoren und die Laufzeit zu messen. Dabei interessiert besonders

• Anzahl und Dauer der Netzwerkrequests vom Client zum Server
• Art, Anzahl und Dauer der abgesetzten SQL-Statements am Server
• Dauer des Netzwerkresponses vom Server zum Client

und natürlich das selektive Einschalten von Logging für zu überwachende Teilbereiche, wie ich es von Java (sprich von log4j [1]) gewohnt bin.

Der Client loggte bereits mittels der Logging-Implementierung von dot.net, nämlich Systems.Diagnostic.TraceSource. Der Server hatte kein explizites Logging, intern wurden jedoch einige Bibliotheken verwendet, die auf unterschiedliche Arten loggen. Verwendet wurden

• als Job Scheduler Quartz.net, verwendet Common.Logging [3]
• als ORM NHibernate, verwendet log4net [2], die dot.net Variante von log4j [1]
• zur Netzwerkkommunikation WCF, verwendet die Systems.Diagnostic.TraceSource

Die Aufgabenstellung lautet daher:

• Einführen von Logging auf Client und Serverseite
• Harmonisierung der bestehenden Frameworks
• Zusammenfassung der Logs von Client und Server, um die gewünschten Fakten zu ermitteln

Common.Logging

Common.Logging ist kein eigenes Logging Framework, sondern eine Abstraktion (eine "Bridge") von unterschiedlichen Frameworks. Common.Logging erlaubt die konfigurierbare Wahl des Logging-Frameworks, welches die Ausgabe schlussendlich wahrnimmt. Geschaffen wurde die Bibliothek nach dem Vorbild von Commons.Logging (man beachte das "s"), welches dieselbe Aufgabe in der Java-Welt wahrnimmt.

Eine Bibliothek sollte mich durch ihre Verwendung nicht  nötigen, andere Frameworks einzusetzen, die gänzlich andere Aspekte  abdecken, in diesem Falle Logging. Daher sollten Bibliotheken immer Common.Logging benutzen. D.h. an dieser Stelle ist Kritik an NHibernate angebracht, dass log4net verwendet wird. Ein entsprechender Issue, der die Umstellung auf Common.Logging fordert, existiert bereits in Jira, bitte fleissig voten [4].

Der eigene Code hingegen kann sehr wohl direkt ein spezifisches Logging-Framework verwenden, allerdings wird damit ein späterer, möglicher Wechsel auf ein alternatives Logging-Framework unnötig erschwert. Daher macht es Sinn, dass auch innerhalb des eigenen Codes Common.Logging verwendet wird.

Common.Logging bringt zusätzlich noch Adaptoren mit, die die Logausgabe von Logging-Frameworks "einfangen" und nach Common.Logging überführen. Somit kann man sehr leicht die Logging-Ausgaben unterschiedlicher Frameworks "harmonisieren".

Im Folgenden schauen wir uns an, wie wir die oben genannten Anforderungen über log4net und TraceSource abwickeln können.

Variante 1: Loggen über log4net

Die beteiligten Komponenten werden wie folgt verdrahtet:

Sowohl Client als auch Server verwenden Common.Logging, damit muss der rote Teil der Grafik konfiguriert werden. An dieser Stelle soll nicht angeführt werden, wie Common.Logging oder Log4Net zu konfigurieren ist. Dazu sei auf die entsprechenden Homepages verwiesen. Anmerken möchte ich jedoch, dass die Konfiguration von Log4Net sowohl in einem eigenen config-File als auch in der app.config passieren kann. Am Server ist auf jeden Fall das eigene config-File anzustreben, da Log4Net dieses überwachen kann, bei einer Änderung die Datei neu einliest und man damit die Konfiguration zur Laufzeit ändern kann. So kann im Bedarfsfall eine Komponente näher untersucht werden, ohne dass der Server restartet werden muss.

Anbei die Teile der app.config, die notwendig sind, um TraceSource nach Common.Logging über zu führen:

<!-- ************ System.Diagnostics Konfiguration ************ -->
<system.diagnostics>

  <!-- Listener für Weiterleitung der Ausgaben von Trace und TraceSource nach Common.Logging registrieren -->
  <!-- Der Wert für initializeData gibt an, welche Levels von Trace und TraceSource weiter gegeben werden, -->
  <!-- siehe System.Diagnostics.TraceEventType -->
  <sharedListeners>
    <add name="Diagnostics"
         type="Common.Logging.Simple.CommonLoggingTraceListener, Common.Logging"
         initializeData="DefaultTraceEventType=Information; LoggerNameFormat={listenerName}.{sourceName}">
    </add>
  </sharedListeners>

  <!-- Bestehende Behandlung von Trace (mit clear) deaktivieren und Listener für Weiterleitung der Ausgaben -->
  <!-- von Trace in Common.Logging aktivieren. Damit wird Trace ausschließlich in Common.Logging überführt. -->
  <trace>
    <listeners>
      <clear />
      <add name="Diagnostics" />
    </listeners>
  </trace>

  <!-- Bestehende Behandlung von TraceSource (mit clear) deaktivieren und Listener für Weiterleitung der Ausgaben -->
  <!-- von TraceSource in Common.Logging aktivieren. Damit wird TraceSource ausschließlich in Common.Logging überführt. -->
  <!-- Eine Eigenheit von TraceSource ist, dass alle Sources (= Logger in der Log4Net-Sprache) -->
  <!-- einzeln zu Listenern (= Appendern in der Log4Net-Sprache) zugewiesen werden müssen.-->
  <sources>
    <source name="System.ServiceModel" switchValue="All" propagateActivity="true">
      <listeners>
        <clear />
        <add name="Diagnostics" />
      </listeners>
    </source>
  </sources>
</system.diagnostics>

Der erste Block definiert einen Listener (=Appender in der Log4x-Sprache), der das Logging von TraceSource entgegen nimmt und nach Common.Logging überführt. Der zweite Block sorgt dafür, dass System.Trace-Aufrufe nach Common.Logging umgeleitet werden. Hier ist zu beachten, dass ein Default-Listener registriert ist (Log-Window in Visual Studio), welcher mit clear entfernt werden kann. Der dritte Block definiert, dass genau eine Source (= Logger in der Log4x-Sprache), nämlich "System.ServiceModel" mit dem oben definierten Listener verdrahtet wird. Diese Source nimmt die Protokollierung der WCF-Kommunikation vor. Alternativ kann Beginn und Ende der Kommunikation über Aspekte geloggt werden, was zu weniger und sinnvolleren Logging-Outputs führt.

Die Harmonisierung der unterschiedlichen Log-Quellen funktionierte auf diese Art und Weise, wie sieht's nun mit dem Zusammenführen der Outputs von Client und Server aus? Dies kann sehr einfach mit einem Tool wie NetLogClient [5] erfolgen, welches sowohl vom Client als auch vom Server den Output von definierten Loggern über UDP entgegen nimmt und diese zeitlich geordnet visualisiert (NetLogClient ist der C#-Counterpart zu chainsaw).

Variante 2: Loggen über TraceSource

Die beteiligten Komponenten werden wie folgt verdrahtet:

Client als auch Server verwenden System.Diagnostic.TraceSource, der rote Teil der Grafik muss konfiguriert werden. Auch hier schauen wir uns nur die relevanten Teile an.

Zuerst muss Log4Net nach TraceSource übergeführt werden, in der Konfiguration von Log4Net ist folgendes vorzusehen.

<!-- A1 is a TraceAppender and uses PatternLayout -->
<!-- Siehe http://logging.apache.org/log4net/release/sdk/log4net.Layout.PatternLayout.html -->
<!-- # %date Zeitpunkt in ISO8601DateFormat {ISO8601} oder absolut=ohne Date-Info {ABSOLUTE} -->
<!-- # %thread Thread name -->
<!-- # %level   Used to output the level of the logging event. -->
<!-- # %logger  Used to output the logger of the logging event. -->
<!-- # %ndc  NDC (nested diagnostic context) associated with the thread that generated the logging event -->
<!-- # %message message -->
<!-- # %newline platform dependent line separator character or characters -->
<appender name="A1" type="log4net.Appender.TraceAppender">
  <layout type="log4net.Layout.PatternLayout">
    <conversionPattern value="%date{ABSOLUTE} [%thread] %-5level %logger %ndc - %message%newline"/>
  </layout>
</appender>

Zweitens ist Common.Logging zu konfigurieren:

<!-- ************ Common.Logging Konfiguration ************ -->
<common>
  <logging>
    <!-- Common.Logging nach Diagnostic.Trace überführen. -->
    <factoryAdapter type="Common.Logging.Simple.TraceLoggerFactoryAdapter, Common.Logging">
      <arg key="level" value="DEBUG"/>
      <arg key="showLogName" value="true"/>
      <arg key="showDataTime" value="true"/>
      <arg key="dateTimeFormat" value="yyyy/MM/dd HH:mm:ss:fff"/>
    </factoryAdapter>
  </logging>
</common>

Diese Lösung hat den Nachteil, dass drei unterschiedliche Layouts vorhanden sind, die an jeweils unterschiedlichen stellen anzupassen sind, um über die gesamte Architektur einheitliche Layouts zu erhalten. Die Harmonisierung ist damit abgehandelt, die Zusammenführung funktioniert über den Microsoft Service Trace Viewer. Für diesen sind sowohl auf der Client- als auch auf der Serverseite XML-Logs zu erstellen, die dann importiert werden müssen. Zusammengehörige Requests werden in beiden Varianten durch dieselbe Activity-ID identifiziert.

Bewertung

Wenn man sich die Konfiguration der beiden Varianten ansieht (und mit Reflector ein bisschen in TraceSource rumschnüffelt), dann merkt man, dass Log4Net und TraceSource unterschiedliche Konzepte verfolgen.

Bei der Implementierung von Log4Net wurde das Observer- und das Mediator-Pattern verwendet. Jeder Logger kennt nur seinen Mediator, was zu leichtgewichtigen Logger-Objekten führt. Deshalb wird beim Einsatz von Log4Net auch fast immer das logger-per-class pattern [6] angewandt.

TraceSource verwendet zwar auch das Observer-, nicht aber das Mediator-Pattern. Deshalb muss für jede Source angegeben werden, welcher Listener den Output erhält. Auch werden Log-Levels nicht vererbt. Dies ist ein Grund, warum Log4Net-Jünger jammern, wenn sie mit TraceSource in Berührung kommen. Tatsächlich steht dahinter ein ganz anderes Konzept: die Logger - Entschuldigung, die Sources sind schwergewichtig, daher wird ein source-per-componente pattern angewandt (Sorry, dazu kenne ich keinen externen Link). Dies erklärt auch, warum die Source nicht über ihren Klassennamen inkl. Namespace von einem zentralen Buffer (Factory) geholt wird, sondern einfach mit new() erzeugt wird. Innerhalb der Komponente müssen die entsprechenden Klassen sehen wie die Source geteilt wird.

Die korrelierende Auswertung mit Microsoft Service Trace Viewer gefällt, schnell war der Wunsch da, auch SQL-Statements in diesem vorzufinden. Gewählt und umgesetzt wurde daher eine Mischvariante aus den obigen zwei Varianten:

Für den Menschen bestimmte Log-Dateien werden über Log4Net erstellt (Variante 1). WCF wird aber nicht integriert, sondern bleibt eigenständig. Für die SQL-Statements aus NHibernate wird ein weiterer, nicht additiver Logger eingerichtet (Variante 2), der nach TraceSource loggt. Die korrelierten Auswertungen inkl. SQL können mit Microsoft Service Trace Viewer betrachtet werden. Auch der UDP-Logger kann weiterhin eingesetzt werden. Anbei noch ein Bild des Service Trace Viewers.

Das Thema Logging ist damit aber noch nicht erschöpft, diesen Beitrag möchte ich aber an dieser Stelle beenden. Bitten möchte ich um Voting/Comments von drei Fehlern, die wir im Rahmen der Einführung gefunden haben, nämlich den obig erwähnten Punkt [4], dann noch unnötige Referenzen bei Log4Net [7] und einen Fehler bei der Codeausgabe von Common.Logging [8].

Euer
CL@coopXarch

Links

[1] http://logging.apache.org/log4j/

[2] http://logging.apache.org/log4net/

[3] http://netcommon.sourceforge.net/

[4] http://216.121.112.228/browse/NH-1554
[5] http://netlogclient.sourceforge.net/
[6] http://logging.apache.org/log4net/release/faq.html  
[7] https://issues.apache.org/jira/browse/LOG4NET-174
[8] http://sourceforge.net/tracker/?func=detail&aid=3044182&group_id=182424&atid=901156

Software Architektur – Versuch einer Definition

Liebe Leser,

inspiriert durch unzählige Artikel, erlebte Diskussionen, Vorträge, etc. wollte ich meine ganz persönliche Definition von Software Architektur in diesem Beitrag zum Besten geben. Anfänglich dachte ich an eine glanzvolle, plakative und prägnante Formulierung. Umso mehr ich darüber reflektiert habe, desto weiter habe ich mich von diesem Ziel entfernen müssen. Es gibt viele Definitionen, wovon einige ganz brauchbar sind und andere besser gleich wieder vergessen werden sollten. Von den brauchbaren betrachten alle immer nur einen Aspekt des Themas. Darum möchte ich die für mich relevanten Gedanken zur Definition von Software Architektur in Folge kurz erläutern.

Immer wieder hört man auf die Frage nach der Software Architektur eines konkreten Produktes Antworten, die sich auf die eingesetzten Technologien oder Frameworks beziehen. Eventuell wurden sogar Architekturentscheidungen rein auf Basis der Technologien getroffen. Manchmal bekommt man auch als Antwort, dass keine dedizierte Architektur existiere. Bei Ersterem ist aus meiner Sicht der Architekturansatz viel zu kurz gegriffen. Was alles in eine Architekturbetrachtung einfließen sollte, werde ich in Kürze ausführen. Die zweite Aussage ist schlicht weg falsch. Es gibt immer eine Architektur. Ob diese gut oder schlecht ist, geplant oder im Laufe der Umsetzung zustande gekommen ist, das sei dahingestellt. Extremisten unter den Verfechtern von agilen Vorgehensmodellen vertreten die Meinung, dass sich die Architektur durch Refactoring ergibt. Andere glauben daran, dass sich ein Teammitglied im Sinne der Gruppendynamik die Rolle des Architekten auferlegen wird und dann die Architektur definiert. Ich bin zwar auch ein Anhänger von agilem Vorgehen, teile dennoch nicht diese Überzeugungen.

Worum dreht sich eine Architektur?
Eine Architektur kann man aus mehreren Sichten betrachten. Hier herrscht keine Einigkeit, aber oft werden fachliche Architektur, Anwendungsarchitektur, technologische Architektur und Systemarchitektur unterschieden. Es obliegt dem Architekten in Verbindung mit dem konkreten Fall, welche Sichten für die Umsetzung betrachtet werden sollten. Wichtig ist an dieser Stelle, dass es sich nicht um eine eindimensionale Drehscheibe handelt und man immer auch eine technologieneutrale konzeptionelle Sicht vornehmen muss. Eine einfach aufbauende Herangehensweise würde ausgehend von einer konzeptionellen Architektur in eine Anwendungsarchitektur überführen, bei welcher die Konzepte verwendet werden um die fallspezifische Domäne zu beschreiben. Daran geknüpft würde man dann ein Technologiemapping vornehmen und erhält als Ergebnis eine gesamtheitliche Architektur.

Wie steht es um das Profil eines guten Software Architekten?
Eine knackige Aussage, welche ich einmal zu der Primärtätigkeit eines Software Architekten gehört habe, lautet: "ein Software Architekt erstellt eine Blaupause und die Dokumentation, wie man zu deren Umsetzung kommt". Dem kann ich mich voll anschließen. In meinen Augen entwirft ein guter Architekt ein System passend zu den von ihm selbst vorgegebenen Technologien in enger Anlehnung an den Kunden bzw. das Projekt (Produkt).

"An architect always implements"
Ich bin grundsätzlich davon überzeugt, dass diese Aussage unumstößlich ist. Ich habe sogar schon Jobangebote gesehen, wo dieser Satz – ein wenig ausgeschmückt – direkt in den Anforderungen an den Bewerber enthalten war. Ein Software Architekt hat nicht zwangsläufig Produktcode beizusteuern, aber er muss schon über die eingesetzten Technologien Bescheid wissen und diese auch ausprobiert haben und kennen, wenn gleich er lediglich auf einer Spielwiese experimentiert hat.

Ein Software Architekt muss auch eine kommunikative Persönlichkeit sein. Er hat immerhin die Aufgabe mit relativ vielen Stakeholdern zu interagieren und die Architektur zu beschreiben bzw. diese zu vermitteln.

Architektur vs. Design
Architektur kann man als strategisches Design umschreiben, bei welchem sowohl die nicht funktionalen Anforderungen, als auch die Anforderungen mit systemweitem Einfluss in die fachliche Domäne eingeführt werden. Dem gegenüber steht das taktische Design, welches mehr oder weniger den Rest bis hin zu einer Featureumsetzung abbildet.

Abschließend möchte ich noch eine Aussage von Ralph Johnson anführen, der in einer Mailingliste einmal zum Abschluss einer Diskussion über die offizielle IEEE Definition von Architektur folgenden Satz geschrieben hat: "Architecture is about the important stuff". Er hat sich darauf bezogen, dass eine Architektur auf den für die Entwicklung wichtigsten Dingen basieren sollte, welche das auch immer im konkreten Fall sein mögen. In Anlehnung daran sei es mir gestattet darauf hinzuweisen, dass Architekten keine gottähnlichen, allwissenden, alles könnenden Wesen sind, sondern im tiefsten Inneren Softwareentwickler mit hoffentlich viel Erfahrung und Weitblick.

Euer
JL@coopXarch

Java in the Cloud - Erfahrungen beim Deployen einer Applikation mit der Spring "CloudFoundry"

Liebe Leser!

Gestern habe ich erstmals eine Java Applikation in der Cloud gestartet. Das Spring Service CloudFoundry stellt einen vollständigen Spring Stack zur Verfügung:

• Apache
• Spring tc Server (das ist der Spring Enterprise Tomcat) oder Tomcat 5.5
• mySQL.

CloudFoundry verwendet als Träger-Cloud-Service Amazon EC2 und bietet also einen Platform as a Service (PaaS) Aufsatz auf das Amazon Infrastructure as a Service (IaaS) Angebot.

Soweit - so gut. Was waren nun die Fallstricke?

• Zuerst muss man einen Amazon Web Services Account anlegen.Wenn man danach in CloudFoundry seinen Amazon Access Key validieren will, schlägt das fehl. Warum? 
• Nun, man muss sich zuvor bei Amazon für EC2 anmelden, dann funktioniert auch die Validierung. Danach kann man sich die notwendigen Key Pairs von CloudFoundry generieren lassen.
• Beim Deployen einer Applikation wird das Eingabefeld "Web Server - Public IP" angezeigt. Sobald man hier etwas einfüllt, schlägt die Feldvalidierung immer fehl. Was tun? 
• Nun, das Feld einfach freilassen, dann wird die Applikation deployed und man gelangt über einen angebotenen Link auf die deployte Applikation in der Cloud - Voila!

Weiterführende Probleme, die mir bei meinem ersten Test aufgefallen sind:

• Applikations-Logfiles
• Beim Tracen von Problemen ist es essentiell, ein "tail -f" auf die Applikationslogfiles mitlaufen zu lassen. Fraglich ist, wie das über CloudFoundry geht bzw. ob so etwas Feines wie bei Hudson (CI Server) angeboten wird - hier kann man einem Build in Echtzeit im Web beobachten. Alternative: Ich nehme an, man kann auch auf den Amazon Server direkt verbinden und die Logfiles dort auswerten.
• Daten in der Datenbank
• Falls die Instanz gestoppt wird - aus welchem Grund auch immer - wie kommt man zu den Daten in der Datenbank? Vermutung: Wie oben direkt auf die Amazon Instanz verbinden und einen Export machen - ist das auch automatisierbar?
• Deployment einer Version mit minimaler Downtime
• Das Deployen einer Mini Applikation hat ca. 4 Minuten gedauert. Wenn ich eine neue Version deployen will (und vorausgesetzt, es ist keine Änderung der Datenstruktur mit Datenmigration notwendig), wie halte ich die Downtime so gering als möglich? So wie ich es verstanden habe, kann man nicht einfach den Apache auf einen neu deployten Stack umschalten bzw. habe ich dazu noch keine Informationen gefunden. Wahrscheinlich muss man dazu wieder auf die Amazon Instanz gehen und das Procedere händisch ausführen.

Ad Kosten: Soweit ich gesehen habe, routet CloudFoundry - das übrigens noch im BETA Stadium ist - einfach die Amazon kosten durch und verrechnet keinen Aufschlag. Die Frage ist, ob mit der Verfügbarkeit von VMforce das CloudFoundry Service nicht eingestellt werden wird. VMWare tut sich ja mit Salesforce.com zusammen, um nicht Amazon das Geschäft mit dem IaaS zuschanzen zu müssen.

Euer 

JWR@coopXarch.

Ich bau mir einen Cluster oder "Die Geschichte des BossBlade"...

In der Vergangenheit habe ich mich auch mit dem Bau von Cluster Systemen beschäftigt und den "BossBlade" entwickelt - damals waren Blade Server noch in aller Munde und die Cloud noch nicht erfunden. Ich dachte mir, das könnte Euch interessieren - im Folgenden also der Werbetext des BossBlade "Produkts"...

Der "BossBlade" ist ein komplett auf Open Source basierender, hochausfallsicherer, skalierbarer Shared Nothing Cluster ohne Single Point of Failure: HA HTTP/HTTPS Load Balancer, HA JBoss Cluster mit Cache Synchronization und Farming, HA Datenbank Cluster (PostgreSQL, mySQL, etc.).

Bis jetzt waren hochausfallssichere, skalierbare Applikationsserver-Cluster grossen Unternehmen vorbehalten, die die beträchtlichen Summen für Serverhardware und Speichersubsysteme (RAID, SAN, NAS) und Lizenzen für Betriebssystem, Clustersoftware, Datenbanken, Applikationsserver, Web Server, Netwerkmanagementsoftware nebst Wartungsverträgen aufbringen konnten. Diese Servercluster sind die Basis für Enterprise Java Softwaresysteme (J2EE), die sich durch zentralisierte Architektur, hohe Wartbarkeit und Flexibilität und bedarfsgerechte Skalierbarkeit auszeichnen. In kleinen und mittleren Unternehmen regiert bis heute oft ein Flickwerk an unterschiedlichen Applikationen in verschiedenen Skript- und Programmiersprachen auf verschiedenen Plattformen ohne zentrales Software-Architektur-Konzept. Mit dem BossBlade steht nun erstmals auch kleinen und mittleren Firmen eine vollständig auf Open Source Software basierende, skalierbare Infrastruktur für Enterprise Software zu Verfügung, die kostengünstig und stabil ist und mit dem Unternehmen wächst. Die Migration und Zentralisierung der historischen Softwarelösungen auf das BossBlade bringt Kostenvorteile bei der Weiterentwicklung und Wartung der Software und erhöht die Stabilität, Verfügbarkeit und Skalierbarkeit des Systems. Durch die Shared Nothing Technologie (keine einfach ausgelegten gemeinsamen Komponenten - z.B. externes RAID) kann das BossBlade auf zwei Serverräume aufgeteilt werden, um die Systemverfügbarkeit bei Strom- und Leitungsausfall bzw. anderen physischen Einflüssen zu garantieren.

Der "BossBlade" - Links die Säule der 2 Webserver, mittig die Applikationsserver, rechts die Datenbankserver - soviel zur anschaulichen Darstellung von "Tiers" - die Ausfallsicherheit im Testaufbau ist natürlich durch die Verwendung einer Steckerleiste und eines Switches begrenzt ;-)

JWR@coopXarch.

Korrektive Wartung - wer bezahlt für Fehler?

Folgendes schreibt mir ein Bekannter, der IT Koordinator in einem größeren Betrieb ist, zum Thema korrektive Software Wartung, da er meine Vorlesungsfolien (TU Wien - Software Wartung und Evolution) im Internet gefunden hat:

In der Praxis läuft es aber immer wieder auf die selben Diskussionspunkte hinaus:

• Fehler oder "works as designed"
• Fehler oder Änderungswunsch -> Unterscheidung korrektive bzw. adaptive Wartung
• Fehler: bezahlen oder nicht.

Gerade der letzte Punkt ist strittig, da die korrektive Wartung in unserer Wartungspauschale enthalten ist. Jedoch wird eine Entwicklung erst nach Abnahme produktiv gesetzt. Der Fehler wurde also beim Test nicht festgestellt. Und wer ist nun schuld, dass es den Fehler im Produktivsystem überhaupt gibt?

Und das ist meine Antwort:

Die Probleme sind mir – als Individualsoftwarehersteller und Ziviltechniker für Informatik – gut bekannt. Also kurz mein Statement dazu:

Die Korrektheit ist der Grad, zu dem ein implementiertes Feature einer Anforderungsspezifikation entspricht. Das Problem ist, dass Anforderungen in den meisten Fällen nicht eindeutig sind (weil sie meist in Prosa und nicht mathematisch abgefasst sind; ein paar UML Grafiken helfen da auch nur ein bisschen) und daher im Nachhinein immer Interpretationsspielraum bieten – das kann nun der Hersteller für seine Zwecke ausnutzen (das ist „works as designed“). Leider ist es ebenso schwierig, eine ganz eindeutige Anforderungsspezifikation im Vorhinein („up-front“) zu liefern, daher sind neuerdings lernende Ansätze wie Scrum so populär.

Es liegt im Interesse des Herstellers, einen Fehler („korrektive Wartung“) wenn möglich als Änderungswunsch zu titulieren, um den Aufwand für die Änderung (Behebung des Fehlers oder Erweiterung der Funktionalität) bezahlt zu bekommen.

Bei meinem Projekten/Kunden halten wir es mit Fehlern – auch in Übereinstimmung mit der mir bekannten relevanten Gesetzgebung - so: Es gibt 6 Monate Gewährleistung ab der Abnahme (6 Monate weil B2B und nicht B2C), in dieser Zeit sind Fehler der Klasse 1 (betriebsverhindernd) und Klasse 2 (betriebsstörend) auf Kosten des Herstellers zu beheben. Dabei ist es auch irrelevant, ob der Fehler im Test nicht aufgefallen ist („versteckter Mangel“), selbst wenn der Kunde mitgetestet hat. Es ist dem Kunden nicht zuzumuten, alle Fehler beim Akzeptanztest aufzudecken – selbst wenn eine Mitwirkungspflicht bei der Durchführung der Tests vertraglich vereinbart ist. Bei Fehlern der Klasse 3 (Kosmetik) weisen wir unserer Kunden darauf hin, dass hier eine strenge Auslegung der Anforderungen besteht – für den Hersteller ist es schwer, wirtschaftlich zu bleiben, wenn der Kunde ab der Abnahme alle 3 Tage meldet, dass er jene Farbe und jenen Dialog gern anders gestaltet hätte. Hier wird generell der Dialog gesucht und Mediation durch den Projektleiter betrieben. Größere Änderungen in der Klasse 3 sind vom Kunden zu bezahlen.

Ist die korrektive Wartung in der Wartungspauschale enthalten, liegt also die Behebung von Fehlern beim Hersteller – hier ist eine genaue Definition von Fehlerklassen - siehe oben - zu empfehlen. Neben dem Fehlergewicht kann man z.B. auch den Fehlertyp (falsch, fehlend, überflüssig, ungenau) zur Klassifizierung heranziehen.

Ein weiteres Problem hierbei ist die Arbeitsweise in der adaptiven oder erweiternden Wartung – wenn der Kunde schlechte Anforderungsqualität „auf Zuruf“ liefert und den Entwicklungsprozess chaotisch managed, kommen wir bei der Verantwortlichkeit für Fehler im System auch ins Diskutieren.

Wie auch immer – denke ich – dass dieses Thema immer Spielraum für Diskussion bietet. Daher muss man möglichst viel Munition vorrätig haben - und eine Mediation von außen - vor allem in heiklen Fällen - kann hier auch helfen, um dem Hersteller zu zeigen, dass er nicht nur den Kunden überzeugen muss (bzw. überrumpeln kann). 

Und was denkt ihr?

Euer

JWR@coopXarch.

Und wo ist die Dokumentation?

Das Thema Softwaredokumentation ist kein leichtes - oft fragt man sich am Ende des Projektes, welche Dokumentation eigentlich beauftragt war und nun zu liefern ist. Damit das nicht passieren kann, habe ich vor einiger Zeit einen Projektauftrag für Softwaredokumentation erstellt. Dieser ist in der Projektstartphase gemeinsam mit dem Kunden auszufüllen und formal zu bestätigen (z.B. durch Unterschrift oder Commitment-Abgabe). Man beachte, dass z.B. ein Pflichtenheft nicht verpflichtend zu erstellen und zu liefern ist - in kleineren Projekten kann das Pflichtenheft aus einer Reihe von Einträgen (z.B. User Stories) in einem Issue Management Tool bestehen. Den QS-Plan samt Testdokumentation würde ich aus heutiger Sicht aber in den verpflichtenden Teil aufnehmen. Vielleicht findet Ihr die Idee ja nett und könnt das Template verwenden bzw. ergänzen - ich bin sicher, es gibt noch ganz viele andere Arten von Dokumentation...

Projektname
Projektcode
Mandatorisch
	Projekthandbuch (IPMA konform, Ausfüllungsgrad je nach Projektgröße)
	Technische Spezifikation
	Source Code Kommentare
	Entwickler Javadoc
Optional
	Pflichtenheft
	Requirementsspezifikation
	Dokumentation der Machbarkeitsstudie
	Architekturspezifikation
	Designspezifikation
	GUI Spezifikation
	Package- oder Modulspezifikation
	Qualitätssicherungsplan und Testdokumentation
	Wartungshandbuch
	API Javadoc
	API Dokument
	Benutzerhandbuch
	Administrationshandbuch
	Installationshandbuch
	Betriebshandbuch
	Schulungsunterlagen
Name
Datum, Ort
Unterschrift

JWR@coopXarch.

Was macht die IT Abteilung?

Dies scheint eine generelle Frage zu sein: Schaffe ich es, meine verstreuten Architekturen auf einige wenige zu reduzieren und damit Kosten und Personal zu sparen? Manche Firmen müssen laut der Hackett-Group täglich damit kämpfen, "einfach nur alles am Laufen zu halten, statt IT-Investitionen zu tätigen, die ihre Gesamtkosten reduzieren oder ihre Effektivität steigern". Tappen wir in die Wartungsfalle, in der alle organisatorische Kapazität darauf verwendet werden muss, das rasch aufgebaute komplexe soziotechnische System am Leben zu erhalten, ohne Chance auf Optimierung und Innovation? Was kann man dagegen tun? Und in welcher Reihenfolge? Antworten bitte als Kommentare! Danke!

JWR@coopXarch.

Vortrag am 4. Oktober 2010 in der Wirtschaftskammer Österreich in Wien

Liebe Leser!

Ich spreche in meinem Vortrag im Rahmen der CON.ECT Eventmanagement Veranstaltung "Software Trends" über das Spannungsfeld Qualitätssteigerung versus Kostensenkung im Kontext von Individualsoftware.

Das Prinzip der Ökonomie: Höhere Qualität zu geringeren Kosten - ist das für Individualsoftware machbar?

Warum ist Software so teuer, nie fertig und funktioniert nicht optimal? In der Softwareindustrie ist man fast täglich mit diesen Fragen konfrontiert und der Druck, weitere Kosteneinsparungen zu erzielen, erscheint angesichts der ungelösten Qualitätsprobleme kontraproduktiv. Das Spannungsfeld Kosten versus Qualität führt zu folgender Frage: Werden Produktivitätssteigerungen durch Technologie- und Prozessinnovationen in absehbarer Zeit zu höherer Kosteneffizienz in der Fertigung von Individualsoftware führen oder wird dieser Kostenvorteil durch Investitionen in die Qualitätssicherung immer komplexerer Systeme kompensiert? Der Sprecher nimmt sich als Softwarearchitekt und  Projektmanager dieser spannenden Frage an und kommentiert in diesem Kontext aktuelle Trends zur Qualitätssteigerung bzw. Kostensenkung.

Montag, 04. Oktober 2010 von 13:20 bis 14:00 Uhr (Die Gesamt-Veranstaltung findet von 12:00 bis 18:00 statt: Veranstaltungsprogramm). Anmeldung erforderlich.

Wirtschaftskammer Österreich, HS 7, 1040 Wien, Wiedner Hauptstraße 63

Ich freue mich natürlich über Euren Besuch!

Euer
JWR@coopXarch.

Was ist Software Architektur? Gibt es eine klare Antwort? Eine Betrachtung.

Wenn wir über Architektur sprechen, denken wir intuitiv, wir alle sprächen über das gleiche Thema. Jedoch gibt es viele Definitionen von Software Architektur und noch mehr Darstellungen derselben. Es gibt Architecural Views, Styles und Patterns, Architekturbeschreibungssprachen und -notationen und Architekturbewertungsverfahren. Ist Architektur immer auch Design und umgekehrt? Was tut ein Software Architekt den lieben langen Tag?

James: "Wir suchen einen Software Architekten!"
Dean: "Was werde ich am ersten Tag machen?"
James: "Wir wollen die Architektur unserer Software dokumentieren!"
Dean: "Kein Problem! In welchem Format?"
James: "Ich hoffte, das würdest Du uns sagen!"
Dean: "Ich kann mich ja mal in den Code einlesen..."

Es gibt viele Wege, Architektur zu beschreiben - sicher gibt es besser und schlechter geeignete Repräsentation, was ist aber nun wichtig, wenn man über Architektur spricht?

• Erstens sollten wir in einer Gruppe eine einheitliche Sprache entwickeln. Nach der Sapir-Whorf Hypothese schafft Sprache Wirklichkeit, und um uns nicht in einem semantischen Albtraum zu verlieren, ist es sinnvoll eine "Gesamtsprache" - so etwas wie die Ubiquitous Language (UL) aus dem Domain Driven Design Bereich - zu entwickeln. Erzeugen wir dieselben Bilder im Kopf, können wir zufrieden sein. Ein Bild sagt mehr als 1000 Worte - und darum ist eine grafische Architekturbeschreibung auch so sinnvoll.
• Zweitens sollten wir uns nicht panisch an postulierte Vorgaben halten - legt man alle Bücher zu Software Architektur aufeinander, kann man bald getrost dem Eiffelturm Konkurrenz machen. Gut ist, was gefällt - was unserem Problem in unserer Umgebung am Effektivsten zu Leibe rückt. Mut zum Anderssein - wenn es Sinn macht. Mut zum Experiment, wenn man das Gefühl hat, da ginge noch etwas besser - und Mut, sinnlose Ansätze formlos wieder zu verwerfen.
• Drittens sollten wir als Entwickler Architekten nicht vorsorglich verdammen und als Architekten Entwickler nicht bevormunden. Diversität der Meinungen und der konstruktive Dialog produzieren - ein Aufeinander hacken, sei es, um Justament Standpunkte zu verteidigen oder persönliche Überzeugungen aus Eigeninteresse zum Postulat hochzustilisieren, zerstört. Zerstörte Architektur ist auch Architektur - nur macht sie keinen Spaß. Erfahrene Architekten haben so ein ungutes Gefühl in der Magengegend, wenn ihnen ein zerrüttetes soziotechnisches System eine zerstörte Architektur als "einzig machbaren Weg" vorstellt - da weiß man, dass Arbeit auf einen zukommt.

Architektur (und Architekturmanagement) ist die Courage, aus einer Menge von möglichen Wegen einen gangbaren (viablen, würden die Konstruktivisten sagen) einzuschlagen, ihn konsequent zu verfolgen und evolutionär anzupassen. Dann wird der Weg durch den steinigen Entwicklungsalltag breiter und sicherer, das Produkt übersichtlicher und seine Evolution einfacher - und es macht bedeutend mehr Spaß, mit von der Partie zu sein.

Euer
JWR@coopXarch.

Oath of Non-Allegiance

Hallo!

Als interdisziplinäre Gruppe unterstützt coopXarch den Oath of Non-Allegiance von Alistair Cockburn.

JWR@coopXarch.

coopXarch - cooperation of eXperienced architects

Liebe Leser!

coopXarch ist eine Vereinigung von engagierten Architekten im Java und .NET Bereich und eine Arbeitsgruppe für Ideen, Innovationen und Blueprints. Wir wünschen viel Spaß beim Lesen unserer Posts!

Die coopXarch-onauten.