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.