Die Lizenz zum Entwerfen: JWR@coopXarch ist nun "Certified Professional for Software Architecture - Foundation Level"

Liebe Leser!

Nachdem ich nun erfolgreich die Prüfung zum CPSA-F abgelegt habe (Certified Professional for Software Architecture - Foundation Level), will ich hier ein wenig darüber berichten.

Das Zertifizierungsprogramm zum "CPSA" ist eine Initiative der iSAQB, einer Organisation bestehend aus Experten zum Thema "Software Architektur". Laut Homepage ist die iSAQB ein "unabhängiges, neutrales Gremium, das die fachliche Qualität des Certified-Professional for Software Architecture Schemas und das zugehörige Prüfungswesen überwacht."

Ich habe in Wien den 3-tägigen Kurs "Certified Mastering Software Architectures - Seminar mit Zertifikat CPSA nach ISAQB" besucht und im Anschluss die Zertifizierungsprüfung abgelegt. Der Vortragende war Dipl. Math. Manfred Ferken, den ich als sympathischen und kompetenten Seminarleiter wärmstens weiterempfehlen kann. Das Seminar besteht aus einem Theorievortrag auf Basis von Folien und praktischen Übungen. Das Seminar orientiert sich am "arc42 Framework" von Peter Hruschka (Atlantic Systems Guild) und Gernot Starke (unabhängiger Berater) - beide keine Unbekannten und sehr umtriebig auf dem Gebiet der Software Architektur. Ich hatte als praktischer Anwender des arc42 Templates für Architektur-Dokumentation einen kleinen Vorsprung vor den anderen Teilnehmern - trotzdem hat mir das Seminar neue Sichtweisen und viele Fallbeispiele aus der Praxis vermittelt. Vor allem die Diskussionen mit dem Seminarleiter und den Teilnehmern waren sehr lebhaft und lehrreich - ab und zu muss man einfach über den Tellerrand schauen.

Die Prüfung ist ein Multiple Choice Test und doch ziemlich anspruchsvoll - interessanterweise unterschreibt man ein NDA und daher kann ich über den Inhalt natürlich nichts erzählen. Für den engagierten Software Architekten ist die erfolgreiche Ablegung der Prüfung aber sicher kein Problem.

Übrigens: Durch die Ablegung des CPSA-F bin ich als Ziviltechniker für Informatik nun Österreichs einziger staatlich befugter, beeideter und unabhängig zertifizierter Software Architekt (CPSA-F) und Senior Projektmanager (IPMA-Level B). Ich hoffe, damit meine Kompetenz auf meinen Kernarbeitsgebieten dementsprechend fundiert untermauern zu können.

Euer
JWR@coopXarch.

coopXarch wünscht Frohe Weihnachten!

Liebe Leser!

Ein spannendes und arbeitsreiches Jahr liegt hinter uns - angesichts des unmittelbar bevorstehenden Weihnachtsfestes ist es an der Zeit, 2011 Revue passieren zu lassen.

Das Thema im Jahr 2011 aus Sicht der coopXarch war "Cloud Computing". Und wir nahmen und nehmen uns dieses Themas mit viel Engagement und Enthusiasmus an. Nach einer Zeit der Informationsrecherche, Veranstaltungsbesuche und Diskussionen war es im Frühjahr an der Zeit, selbst aktiv zu werden.

Mit joinMe! haben wir im Oktober eine Referenzarchitektur und -implementierung für ein elastisch skalierbares location-based social service vorgelegt, das auf einer Platform-as-a-Service (PaaS) läuft. Dabei ist es irrelevant, ob ein public PaaS Angebot (wie z.B. VMware CloudFoundry) gewählt wird, oder eine private PaaS (z.B. VMware vFabric) aufgebaut wird, um das Service zu betreiben. Die Softwarekomponenten sind so beschaffen, dass sie ohne eine einzige Code-Änderung in einem lokalen Tomcat, dem vFabric tc Server oder in der CloudFoundry Laufzeitumgebung betrieben werden können! Das zeigt die unglaubliche Deployment-Flexibilität und Umgebungs-Agnostik heutiger Enterprise Frameworks (in diesem Falle Spring).

joinMe! zeigt auch, wie "application-level modularization" erreicht werden kann, die eine Grundlage für elastische Skalierbarkeit ist, aber auch andere Vorteile wie Fehlerlokalisation und "always-on" Deployments bietet. Insofern bietet Cloud Computing für die Software Engineering Praxis die Möglichkeit, auch im Business Software Bereich ein Umdenken weg von monolithischem Applikationsdesign hin zu "loosely coupled" Systemen herbei zu führen.

Schade finden wir es, dass es keinen österreichischen Platform-as-a-Service Anbieter gibt - egal ob für public hosting oder als Anbieter für private PaaS Clouds für Unternehmen. Das würde unseres Erachtens Software-as-a-Service Anbietern die Möglichkeit geben, zu österreichischen Qualitätskriterien und unter österreichischer Gesetzgebung SaaS Angebote zu lancieren. Ob wir uns darum kümmern sollten?

Schlussendlich haben wir - durch die Entwicklung von Apps für Smart Devices für drei unterschiedliche Betriebssysteme (Android, iOS und Windows Phone 7) - einiges an Know How in diesem Bereich hinzu gewonnen. Zentral ist nach wie vor die Frage: "Soll ich nativ für jedes OS entwickeln oder auf 'one-serves-all' Frameworks wie PhoneGap setzen?". Hier haben wir unsere Antwort gefunden.

Unbedingt muss auch der große Erfolg erwähnt werden, den unser coopXarch Architekt Jürgen und unser erfahrener WP7 Entwickler Robert mit der "Spritpreise AT" App für Windows Phone 7 eingefahren haben. Diese App war lange unter den Top 3 Apps im österreichischen Windows Phone Marketplace. Das macht uns stolz und wir freuen uns mit Euch!

Die coopXarch Architekten wünschen ein frohes und besinnliches Weihnachtsfest: Zeit, um inne zu halten und zu reflektieren, Ruhe, um Kraft und Zuversicht zu schöpfen und viel Motivation und Mut, um im neuen Jahr neue Herausforderungen anzugehen und innovative Ideen Realität werden zu lassen.

Euer
JWR@coopXarch.

joinMe! - ein Cloud2Mobile Showcase von coopXarch und Xion IT Systems AG

Liebe Leser!

Unser Cloud- und Mobile-Computing Showcase "joinMe!" ist fertig! joinMe! präsentiert sich für den Benutzer als App für Android, iOS oder Windows Phone 7 Smartphones und Tablets, die es ermöglicht, Personen in der Nähe mit dem gleichen Interesse zu finden. Das Datenhandling, der Geo-Location und Interessens-Match und die Notifikationen an die mobilen Geräte werden dabei von einem losen Applikationsverbund in der Cloud - in unserem Fall CloudFoundry von SpringSource/VMWare - durchgeführt. Durch die lose Kopplung ist eine elastische Skalierbarkeit der Services - so wie man es von den großen Anbietern Facebook, Twitter und Co. gewohnt ist - ermöglicht.

Die Homepage zu joinMe! findet sich hier. Wir haben auch einen Produktflyer mit QR Codes zu den einzelnen Apps erstellt.

In Kürze werden wir in einer Reihe von Blogbeiträgen die technischen Grundlagen, Architekturentscheidungen und den Umsetzungsweg vorstellen und auf Fallstricke und Lessons Learned eingehen.

Cloud- und Mobile-Computing ermöglichen innovative und elastisch skalierbare Services. Unternehmen werden in Zukunft durch die Nutzung von Plattform-as-a-Service Clouds weitere Homogenisierung und Konsolidierung zusammen mit den entsprechenden Einsparungspotentialen erzielen können.

Unser Ziel ist es, durch die frühest mögliche technologische und strategische Erschließung der Grundlagentechnologien als Berater und Umsetzer auf diesem spannenden und innovativen Gebiet erfolgreich tätig zu sein.

Euer
JWR@coopXarch.

"Sehnsucht nach Scrum"

Liebe Leser!

Ich halte am Donnerstag, 03. November 2011, 09:00 einen Vortrag zum Thema "Agile Softwareentwicklung" mit dem Titel "Sehnsucht nach Scrum" im Rahmen der Vortragsveranstaltung des IT-Clusters Wien "Agile Software-Entwicklung trifft auf agiles Qualitätsmanagement".

Hier der Link mit näheren Information und der Anmeldung!

Wenn auch Ihr von einer Sehnsucht nach agilen Vorgehensmodellen beschlichen seid (oder die Existenz derjenigen bezweifelt), würde ich mich freuen, Euch zu sehen!

Euer
JWR@coopXarch.

"Elastische Skalierbarkeit in der Cloud" - spritpreisrechner.at zeigt, wie man es nicht macht...

Liebe Leser!

Zugegeben - es ist immer ungleich viel schwerer, Leistung zu erbringen, als Fehlleistung zu kritisieren (als Beispiel sei die österreichische Fußball-Nationalmannschaft angeführt) - aber "die Initiative des BMWFJ für mehr Preistransparenz und Wettbewerb" hat nicht gerade einen Blitzstart hingelegt. Siehe hierfür z.B. http://diepresse.com/home/meinung/marginalien/685968/BenzinpreisRechner-stuerzt-ab_Die-Roboter-sind-schuld, wo es - sehr sarkastisch - heißt:

"Die lange erwartete 'Spritpreis-Datenbank' hätte am Dienstag online gehen sollen. Doch die Homepage kollabierte. Mit so einem Ansturm konnte ja wirklich niemand rechnen."

Seit nunmehr ca. 2 Jahren ist "Cloud Computing" in aller Munde - und die Vorteile, die das neue Paradigma ins Rennen führt, und hier interessiert uns insbesonder das Modell "Platform as a Service (PaaS)" gemeinsam mit elastischer Skalierbarkeit, auch "Auto-Scaling" genannt. Der Anwendungsfall "Spritpreis-Datenbank" - ein paar Clients melden Daten ein (Anforderung 1), viele viele (ev. auch extrem viele - Entschuldigung, wieder sarkastisch) Clients holen Daten ab (Anforderung 2), und die Daten müssen nicht transaktional-aktuell sein (Anforderung 3: soll heißen - es ist ok, wenn ein Client noch kurz den alten Preis bekommt, auch wenn der neue Preis gerade eingemeldet wurde), man verzeihe den Terminus - schreit gerade nach dem Lösungsmuster "PaaS-Cloud mit Auto-Scaling".

Wie hätte coopXarch nun die Architektur ausgelegt:

1. Web Role spritpreis-meldung@cloudanbieter.com
1. Eine "Web Role" (wir folgen hier der Microsoft Windows Azure Nomenklatur) ist das Eingangstor für Web Requests und läuft normalerweise auf einer Cloud Instanz (i.e. früher "ein Server"). Diese Web Role ist für die Melder, egal ob es Menschen über ein Web Formular sind, oder ein Automatismus, der die Preise updated (wieder über ein HTTP-basiertes Protokoll, z.B. REST).
2. Da es eine bekannte Anzahl an Meldern gibt, ist es leicht die Anzahl der Knoten zu dimensionieren - z.B. ein Knoten pro 150 potentielle Benutzer (Warum 150? weil z.B. der Apache Web Server Konfigurations-Wert "maxClients" auf 150 eingestellt ist oder der Tomcat maximal 150 worker threads bietet).
2. Web Role spritpreis-auskunft@cloudanbieter.com
1. Das ist nun die Web Role für die Auskunftsapplikation - wieder können hier Menschen vor einen Web Browser oder einer "mobilen App" sitzen bzw. Robots / Crawler, welche die Web Role für Preisauskünfte ansteuern. Hier ist die elastische Skalierbarkeit unumgänglich, da zum Design-Zeitpunkt nicht gesagt werden kann, wie viele Clients auf das Auskunftsservice zugreifen werden. Noch dazu ist mit Spitzen zu rechnen - eben (sic!) bei der Inbetriebnahme. Die Skalierung in Form des Hochstarts neuer Serverinstanzen, um die Last der Anfragen bewältigen zu können, übernimmt nun der Cloud Controller des PaaS Anbieters. Das Starten dieser zusätzlichen Instanzen muss dabei nicht länger als 10-30 Sekunden dauern - daher die Bezeichnung "elastisch", i.e. "quasi in Echtzeit je nach aktuellem Bedarf".
3. NoSQL Datenbank
1. Nachdem Konsistenz hier eine untergeordnete Rolle spielt (siehe Anforderung 3), wird eine NoSQL Datenbank verwendet, die hoch skalierbar ist und z.B. dokumentenorientiert arbeitet (Dokument "Tankstelle", Embedded Dokument "Produkt", Embedded Dokument "Preis") - ich würde hier die MongoDB als geeignet vorschlagen, da sie auch (Index-basierte) Geo-Abfragen bietet (z.B. für den Anwendungsfall "Zeige mir den billigsten Diesel im Umkreis von 5km"). Die VMWare CloudFoundry PaaS Cloud bietet etwa die MongoDB als persistenten Storage an.
4. Worker Roles "Datenbank Cleanup", "Report Generator" etc.
1. Eine "Worker Role" arbeitet "im Hintergrund" auf einer Datenbasis, um gewisse Aufgaben auszuführen. In diesem Falle könnten alle Spritpreise, die älter als die gehaltene Historie von 14 Tagen (Anforderung 4) sind, aus der Datenbank gelöscht werden. Oder es könnten Preisverlaufskurven generiert und als Bilder abgelegt werden, um Abfragen möglichst effizient mit den Verlaufskurven ausliefern zu können (Anforderung 5).

Zugegeben - viele PaaS Anbieter sind noch im Beta-Stadium bzw. bieten eventuell nur unzureichende Service Levels - ich als staatlich befugter und beeideter Ziviltechniker für Informatik finde es jedoch besonders schade, dass der Staat (in Gestalt des BMWFJ) diese unsere Kompetenz nicht zu Rate gezogen hat, um ein innovatives Service mittels innovativer Technik umzusetzen (und dieser somit ein Stückchen mehr zum Durchbruch zu verhelfen) und verbleibe, mit besten Grüßen,

Euer,
JWR@coopXarch.

Architektur vs. Agile Software-Entwicklung

Liebe Leser,

angespornt durch einige Aussagen von Kollegen und Branchengrößen möchte ich meine Gedanken zur vermeintlichen Kontroverse von Software-Architektur und agiler Software-Entwicklung zum Besten geben.

Architektur
Mein generelles Verständnis zur Definition von Software Architektur habe ich bereits in einem früheren Blogpost beschrieben.

Agile Software-Entwicklung
Unter agiler Software-Entwicklung verstehe ich kein konkretes Vorgehensmodell. Ich bin der Überzeugung, dass man Agilität auf unterschiedlichste Art und Weise in der Praxis ausleben kann. Sei dies in Form von XP, Scrum, Kanban, einem weniger verbreiteten Modell oder einfach nur der individuellen Mixtur aus mehreren davon. Persönlich kann ich jedem der namentlich genannten Vorgehensmodelle etwas abgewinnen. Wie schon oft zitiert ist das Agile Manifesto die Wurzel all dieser Ausprägungen.

Die beiden Extreme
Zwei extreme Einstellungen sind in Bezug auf diese Kontroverse durchaus verbreitet:

1) Wir arbeiten agil und können daher keine Architektur vorhab festlegen.
2) Wir legen unsere Architektur vorab fest und können daher nicht agil arbeiten.

Diese Extreme sind meiner Ansicht nach schlicht weg falsch! Natürlich sind beide Themen unter einen Hut zu bringen. Eine einfach klingende Regel, die allerdings nicht so leicht in die Praxis umzusetzen ist, sollte lauten: So wenig Architektur wie möglich und so viel wie nötig.

Wie kommt es zu diesen Extremen?
Warum glauben dennoch viele Agilisten, dass Architektur nicht zur Agilen Software-Entwicklung passt? Ich denke, dies ist fälschlichen Interpretationen geschuldet. Kent Beck hat in seinem Buch "Extreme Programming Explained: Embrace Change" den Begriff "YAGNI" geprägt. YAGNI steht für "You aren't / ain't gonna need it" und bedeutet, dass man nicht alle Möglichkeiten und Varianten vorab berücksichten, sondern lediglich die vorhanden Anforderungen umsetzen soll. Dies vor dem Hintergrund, da nicht bekannt ist wie sich ein System - basierend auf ändernden Anforderungen - in Zukunft entwickeln wird. So wie auch viele das agile Manifest fälschlich interpretieren (aber das ist eine andere Geschichte), so wird auch dieser Begriff meiner Meinung nach oft zu hart ausgelegt. Das YAGNI-Prinzip hat in der Feature-Entwicklung seine Berechtigung, darf aber nicht auf den gesamten Software-Entwicklungsprozess umgelegt werden.

Meiner Ansicht nach sind die grundlegende System-Architektur und die notwendigen Design-Entscheidungen vorab festzulegen und können nicht laufend anhand von Anforderungen angepasst werden. Die Betonung liegt hier auf dem Wort "grundlegend". Ein gewisses Maß an Flexibilität ist durchaus wünschenswert und gerade durch eine vorab durchdachte Architektur gewährleistet. Ein einfaches Beispiel soll die Notwendigkeit von Architektur und Design-Entscheidungen veranschaulichen:

Bei der Umsetzung einer konkreten Anforderung wird festgestellt, dass gewisse Daten persistiert werden müssen. Ohne zuvor festgelegte Architektur bzw. grundlegende Design-Entscheidungen kann es nun sehr schnell passieren, dass ein momentan passend wirkender Datenspeicher - nehmen wir eine relationale Datenbank an - eingeführt wird. Die Persistenz wird, weil es gerade zur Anforderung passt, als Active Record Pattern umgesetzt. Im Zuge der späteren Entwicklung stellt das Team fest, dass die aktuellen Persistenzobjekte besser als Domain Entities konzipiert gewesen wären und für die Datenpersistenz ein Repository Pattern Ansatz auch brauchbarer wäre. Ich wage zu behaupten, dass man in diesem Fall vor einem nicht unwesentlichen und aufwändigen Refactoring stünde, welches die Grundfesten des gesamten Systems erschüttern würde.

Warum glauben Architektur Hardliner, dass agile Vorgehen nicht anwendbar sind? Einerseits vermute ich, dass dies einem Umkehrschluss aus der agilen Extremeinstellung zuzuschreiben ist (Architektur passt nicht zu einem agilen Vorgehen - s.o.). Andererseits kann am Beispiel von Scrum auch wieder eine Misinterpretation oder zu strikte Auslegung des Vorgehensmodells zu dieser Ansicht führen. Scrum gibt einen Rahmen vor, welcher natürlich absichtlich sehr offen gehalten ist. Es gibt defacto keine Design-Phase. Warum sollte man dennoch nicht in der ersten Iteration auch die Architektur gestalten? Auch wenn es in der Scrum-Community eine Diskussion zu "Sprint Zero" gibt, ist es in meinen Augen alternativ durchaus legitim eine Initialisierung vorab der Featureimplementierung in einer eigenen Iteration auf Basis des bekannten Product Backlogs durchzuführen. Man sollte ausserdem nicht vergessen, dass Scrum-Projekte mit Planning Meetings beginnen in denen nicht ausschließlich die Anforderungen besprochen werden, sondern auch die gesamte Vision im Mittelpunkt steht. Auf Basis der Anforderungen und der Produktvision kann man auch eine Architektur(vision) ableiten.

Mein Fazit
Die Ära der voll durchgeplanten und bis ins letzte Detail designten Software-Systeme ist vorbei. BDUF (Bug Design Up Front) sollte vermieden werden. Software-Architektur darf allerdings auch in einer zunehmend agilen Software-Entwicklungswelt dennoch nicht zu locker gesehen oder gar gänzlich vernachlässigt werden, da einem sonst die vermeintlich günstig erkaufte Flexibilität schnell sehr teuer kommen kann. Der Weg liegt wie so oft in der Mitte und diesen zu finden ist mitunter Aufgabe von agil denkenden Software-Architekten. Ob die Rolle des Architekten nun im Team gemeinschaftlich wahrgenommen wird, ein Teammitglied dazu auserkoren wird oder ein konsultierender Architekt dem Team zu Beginn zur Verfügung gestellt wird soll an dieser Stelle nicht weiter behandelt werden. Software-Architektur ist auf jeden Fall weiterhin ein wichtiger Bestandteil in der Software-Entwicklung, auch wenn sich die Umwelt durch agile Vorgehensmodelle geändert hat.

Euer,
JL@coopXarch

These zur mangelnden Investitionsbereitschaft in Software Qualität betrieblicher Informationssysteme

Liebe Leser!

Sperriger Titel, aber folgender Gedanke beschlich mich beim morgendlichen Zähneputzen:

These:

Investitionsbereitschaft in Software Qualität ist reziprok proportional zum zeitlichen Abstand des Eintritts eines - kausal auf ein Qualitätsproblem folgendes - negativen Ereignisses, dessen Eintrittswahrscheinlichkeit und dessen Auswirkung.

Argumentation anhand von Beispielen (die angeführten Zahlen sind meine persönlichen Annahmen):

Softwareversagen im Bereich Avionik:

Zeitlicher Abstand -> wenige Minuten

Negatives Ereignis -> Absturz

Eintrittswahrscheinlichkeit -> nahezu 100%

Auswirkung -> Multiple Todesfälle nahezu 100%

Softwareversagen im Bereich Automotive:

Zeitlicher Abstand -> wenige Sekunden

Negatives Ereignis -> Unfall

Eintrittswahrscheinlichkeit -> ca. 50%

Auswirkung -> Tod zu 40%, Verletzung zu 60%

Softwareversagen im Bereich betrieblicher Informationssysteme:

Zeitlicher Abstand -> Stunden, Tage, Monate, Jahre

Negatives Ereignis -> Fehler, verletzte Datenintegrität und Konsistenz, Datenverlust, Finanzieller Verlust, überproportional steigende Wartungskosten

Eintrittswahrscheinlichkeit -> ca. 99%

Auswirkung -> Imageschaden, finanzieller Schaden, Kundenunzufriedenheit, Haftungen (bis hin zur Haftstrafe)

Interpretation:

Trotz hoher Eintrittswahrscheinlichkeit eines negativen Ereignisses ist der zeitliche Abstand in vielen Fällen derart groß, dass eine Investitionsbereitschaft stark gebremst wird, noch dazu, wo die Auswirkungen nicht als lebensbedrohlich gewertet werden und Folgen wie mögliche Haftungen oft nicht transparent sind.

Ergo: 

Um die Investitionsbereitschaft zu steigern, müssen die möglichen Auswirkungen transparenter dargestellt werden, um Entscheidungsträger nach dem Kosten-Nutzen Prinzip geeignet aufzuklären. Eine Darstellung des Ablaufs im Zeitraffer ist anzuraten, um dem Gefühl der „Sicherheit aufgrund eines ausreichenden zeitlichen Puffers“ entgegen zu wirken. Geeignete Simulationsmodelle sind auszuarbeiten.

Einen sonnigen Juni wünscht

Euer 

JWR@coopXarch.