Category

Allgemein

Die sieben Regeln für gute Dokumentation in Stein gemeißelt? — Tafel 3 (von 3)

By | Allgemein, Inhaltliches

In den zwei vorherigen Beiträgen hatte ich bereits mit der kurzen Diskussion der klassischen sieben Regeln für gute Dokumentation begonnen. Ich schließe sie in diesem Beitrag mit den beiden verbleibenden Regeln 3 und 7 ab. Hier noch einmal kurz zur Erinnerung alle sieben im Überblick:

Sieben Regeln für gute Dokumentation
book
1. Schreibe aus Sicht des Lesers. (Tafel 1)
2. Vermeide unnötige Wiederholungen. (Tafel 2)
3. Vermeide Mehrdeutigkeit. Erkläre Deine Notation. (Tafel 3)
4. Verwende eine Standardstrukturierung. (Tafel 2)
5. Halte Begründungen für Entscheidungen fest. (Tafel 1)
6. Halte Dokumentation aktuell, aber auch nicht zu aktuell. (Tafel 2)
7. Überprüfe Dokumentation auf ihre Gebrauchstauglichkeit. (Tafel 3)

Vermeide Mehrdeutigkeit. Erkläre Deine Notation (Regel 3)

Es ist unstrittig, dass sich bestimmte Informationen mit Bildern besser kommunizieren lassen als mit Text allein. Das gilt für Strukturen (Elemente und deren Beziehungen untereinander) ebenso wie für Abläufe (Folgen von Aktionen mit Alternativen, Wiederholungen, Parallelität). Ab einer gewissen Komplexität lässt sich das mit Stichpunkten oder Prosa nicht gut beschreiben. Diagramme und mitunter auch Screenshots kommen ins Spiel, bei Diagrammen ist in der Softwarearchitektur immer noch UML recht verbreitet.

In diesem Zusammenhang höre ich in Projekten oft: „Wir benutzen für unsere Architekturdiagramme UML. Die Notation ist standardisiert. Kann jeder lesen.“ Das mit dem standardisiert stimmt, meine Erfahrungen mit „kann jeder lesen“ sind andere.

In der Projektpraxis werden übrigens oft gar keine Architekturdiagramme angefertigt. Auch weil die Teammitglieder unsicher in der Notation sind. Sie glauben sie müssten UML nehmen aber haben Angst sich damit zu blamieren. Aus meiner Sicht ist UML zu verwenden kein Automatismus, und bei den vielen Zielgruppen (vgl. Regel 1) wird auch bei der UML Erklärungsbedarf da sein.

In diesem Zusammenhang zwei persönliche Ratschläge von mir rund um Diagramme:

  • Schreibt zu jedem Diagramm einen Satz der auf den Punkt bringt was zu sehen ist (“Mission Statement”, Kernaussage). In der Dokumentation (egal ob Dokument, Wiki, Poster …) platziert Ihr diesen Satz oberhalb der Abbildung.
  • Lasst Euch nicht von der Notation behindern. Benutzt stattdessen wenige Elemente, und erklärt diese in einer Legende.

Der erste Tipp sorgt zum einen dazu, dass Betrachter nicht rätseln müssen, was Ihr mit dem Bild sagen wollt. Zum anderen (und das ist das Entscheidende) hilft es Euch zu entscheiden, ob etwas „noch ins Bild reingehört“ oder nicht. Ihr vermeidet Diagramme voller Prachtfülle, in denen der Leser die relevanten Informationen dann aber suchen muss wie in einem Wimmelbild. Hier ein schönes Fundstück aus dem Netz dazu (Quelle, beachtet die beschönigende Überschrift).

complex-system-architecture-diagram-2292510

Immerhin: Eine Legende hat dieses Diagramm. Die Regel „Erkläre Deine Notation“ wende ich durchaus auch auf UML an. Und wenn Ihr dort wenige Elemente verwendet braucht Ihr auch nur wenig erklären. Die wenigen UML-Elemente dann aber bitte richtig verwenden. Sonst verwirrt Ihr diejenigen, die UML lesen können (gibt es auch).

Überprüfe Dokumentation auf ihre Gebrauchstauglichkeit (Regel 7)

Hinter dieser Regel stecken Reviews, zumindest suggeriert das Wort „überprüfen“ das. Dokumentation kann man auf zwei Arten überprüfen. Die erste nenne ich gern „Überprüfung auf Standardkonformität“. Hier werden Kriterien an die Dokumentation gelegt und Fragen folgender Art gestellt (Beispiele):

  • Hat die Architekturbeschreibung mindestens 60 Seiten?
  • Ist sie nach arc42 gegliedert?
  • Ist jeder Abschnitt ausgefüllt?
  • Wird für die Diagramme als Notation UML verwendet?
  • Hat jedes Diagramm eine Legende?

Fragen dieser Art eignen sich prima für Checklisten, diese können in der Regel von einer QS-Abteilung abgearbeitet werden. Mitunter erfordern regulative Randbedingungen einen solchen Check auf Standardkonformität. Mit der Überprüfung auf Gebrauchstauglichkeit ist aber etwas anderes gemeint.

Nämlich dass die Dokumentation tatsächlich bei der Arbeit unterstützt. Diejenigen, welche Architektur kommunizieren wollen, und diejenigen, welche sich dafür interessieren. Also für Architekturtreiber, Lösungsansätze, Entscheidungen, Konzepte. Die geschlossenen Fragen von oben können das nicht leisten.
Architektur-Spicker #1, Seite 3
Die Überprüfung auf Gebrauchstauglichkeit findet als Test mit den Zielgruppen statt. Und hier schließt sich der Kreis von Regel 7 zu Regel 1 („Schreibe aus Sicht des Lesers“). Das Anfertigen eines Architekturüberblicks stelle ich überhaupt gerne als Kreislauf dar (initial klein Starten, dann schrittweise Verfeinern). Eine Darstellung dieser Idee findet Ihr zum Beispiel in unseren Architektur-Spicker #1 („Der Architekturüberblick“, Download als PDF) auf Seite 3 oben.

Die sieben Regeln für gute Dokumentation in Stein gemeißelt? — Tafel 2 (von 3)

By | Allgemein, Inhaltliches | No Comments

In einem früheren Beitrag hatte ich bereits mit der kurzen Diskussion von zwei der sieben Regeln für gute Dokumentation begonnen. Hier geht es weiter. Nochmal kurz zur Erinnerung alle Regeln im Überblick:

 

book

1. Schreibe aus Sicht des Lesers. (Tafel 1)
2. Vermeide unnötige Wiederholungen. (Tafel 2)
3. Vermeide Mehrdeutigkeit. Erkläre Deine Notation.
4. Verwende eine Standardstrukturierung. (Tafel 2)
5. Halte Begründungen für Entscheidungen fest. (Tafel 1)
6. Halte Dokumentation aktuell, aber auch nicht zu aktuell. (Tafel 2)
7. Überprüfe Dokumentation auf ihre Gebrauchstauglichkeit.

Starten möchte ich mit einer Regel die falsch angewendet sogar richtig Schaden anrichten kann. Der vierten.

Verwende eine Standardstrukturierung (Regel 4)

Wenn Ihr Dokumentationszutaten über den Quelltext hinaus anfertigt (beispielsweise Schritt-für-Schritt-Anleitungen zu übergreifenden Themen wie Persistenz oder Security) stellt sich die Frage wo Ihr das Ganze ablegt und strukturiert. Dies vierte Regel wird gerne als Reklamesatz für arc42 herangezogen. arc42 stellt eine Standardgliederung für Architekturbeschreibungen dar (in D-A-CH De-facto-Standard).
list-2
Tatsächlich findet alles irgendwie seinen Platz in arc42 (der Abschnitt „Konzepte“ entpuppt sich dabei in der Praxis als Joker). Ich rate Euch aber davon ab, Architekturdokumentation initial anzufertigen, in dem Ihr eine vollständige arc42-Gliederung (immerhin 12 Abschnitte) geschlossen z.B. als Word-Dokument „ausfüllt“.

Den Wert von arc42 sehe ich vor allem im Nennen möglicher Zutaten einer Dokumentation, die zusätzlich zum Quelltext im Team entstehen. Die Kontextabgrenzung etwa, oder Qualitätsziele. Hier gibt es übrigens große Überdeckungen zu Alternativen. Die arc42-Gliederung selbst hat dann ihren großen Auftritt, wenn Ihr eine Architekturbeschreibung aus den einzelnen Bestandteilen für eine bestimmte Zielgruppe zusammen setzt. Darüber hinaus hilft die Struktur auch beim Verwalten der Teile.

Standardgliederungen funktionieren übrigens auch in kleinerem Rahmen gut. Muss nicht gleich die ganze Architekturbeschreibung sein. Beispielsweise bei Schnittstellen und Entscheidungen ist die immer gleiche Struktur hilfreich. Sie gibt den Erstellern Sicherheit und Orientierung. Im Falle von Architekturentscheidungen unterstützt sie auch das Treffen derselben (die Dokumentation fällt ab). Dieser Beitrag enthält eine praxisbewährte Gliederung für Architekturentscheidungen.

Der Schaden, den diese vierte Regel nun anrichten kann, entfaltet sich in Kombination mit der nächsten.

Vermeide unnötige Wiederholungen (Regel 2)copy

Beim Nachdenken über diese Regel stolpere ich über das Wort „unnötig“. „Don’t repeat yourself“ ist ein prominentes Prinzip (auch DRY). Wenn hier explizit von „unnötigen“ Wiederholungen die Rede ist, scheint es auch solche zu geben, die nötig oder zumindest OK sind. DRY gibt mehr Orientierung … Was will und Regel 4 sagen?

Falls Ihr Architekturdokumentation wie oft gesehen in einem arc42-Dokument in Word anfertigt, geratet Ihr bei Anwendung von „Schreibe aus Sicht des Lesers“ (Regel 1) in ein Problem: Ein einziges Dokument  wird mehrere Zielgruppen nicht gerecht. Widersteht dem Reflex, einzelne Dokumente für die jeweiligen Zielgruppen anzufertigen (gute Idee eigentlich), und die betreffenden Inhalte dann jeweils hinein zu kopieren (schlechte Idee). Ihr lauft Gefahr, dass sich die geklonten Inhalte unabhängig voneinander ändern, und/oder habt hohe Wartungsaufwende.

Fertigt die Inhalte stattdessen jeweils einmal kleinteilig an, und führt sie bei Bedarf in unterschiedlichen  Dokumenten oder anderen Formen zusammen. Am besten geht dies automatisiert, etwa im Rahmen des Build-Prozesses. In der Projektpraxis sehen wir als Formate hier eher Markdown oder (häufiger) AsciiDoc als Word. Diese fühlen sich in einer Versionsverwaltung wohl; diff und merge funktionieren prima. Mit Hilfe von Includes entstehen passende Dokumente für unterschiedliche Zielgruppen durch Rekombinieren der Inhalte. Dieser Beitrag stellt eine entsprechende Werkzeugkette mit Markdown und Maven bzw. alternativ Gradle vor.

Ebenso wie einzelne Architekturdokumentation für unterschiedliche Zielgruppen durch Cut/Copy/Paste zu erzeugen solltet Ihr keine umfangreichen Inhalte aus anderen Teilen der Dokumentation (Klassiker: Anforderungen) in Eure Dokumentation kopieren. Verweist auf sie. OK ist aus meiner Sicht eine knappe Zusammenfassung, um den Lesern das Verfolgen des Links zu ersparen, die nur einen Überblick haben wollen. Hier handelt es sich um einen Kompromiss zwischen leichter Lesbarkeit und Wartbarkeit. Das führt zu Wiederholungen, die im Sinne der Regel OK sind.

Halte Dokumentation aktuell, aber auch nicht zu aktuell (Regel 6)file-2

Veraltete Dokumentation ist häufig eine Ausrede um überhaupt nicht zu dokumentieren. Dahinter stecken zwei Annahmen:

  1. Dokumentation veraltet sowieso
  2. Veraltete Dokumentation ist wertlos

Dazu lässt sich sagen: Eine festgehaltene (Architektur-)Entscheidung veraltet keineswegs, solange Ihr nicht von ihr abweicht. Vielleicht würdet Ihr heute anders entscheiden, mittlerweile haben sich Rahmenbedingungen oder Ziele geändert, Optionen sind dazugekommen, Annahmen haben sich als falsch herausgestellt. Kurz: Ihr seid schlauer. Um die Entscheidung nachvollziehen zu können ist aber der Zeitpunkt der Entscheidung relevant. Und da Architekturentscheidungen typischerweise schwer zurückzunehmen sind, ist eine spätere Umentscheidung unwahrscheinlich. Wenn Eurer Team in bestimmten Ausnahmefällen von dieser Entscheidung abweicht, ist es erst recht lohnenswert, diese Tatsache festzuhalten und das Wissen darum zum Beispiel an Neue weiterzugeben. Merke: Dokumentation unterstützt Kommunikation.

Neben den dokumentierten Entscheidungen gehören vor allem Lösungskonzepte und Mittel, die es leichter machen im Quelltext zurecht zu finden, in Eure Architekturdokumentation. Zu letzteren gehören Diagramme, die Strukturen und Abläufe zeigen (ungeliebte und unangefochtene Notation: UML). Die Wahrscheinlichkeit, dass Konzepte und Diagramme veralten, nimmt mit dem Detaillierungsgrad zu.

Veraltete Dokumentation weicht von der Lösungsrealität (dem Quelltext) ab. Das Team hat Änderungen und Ergänzungen also nicht nachgezogen.

Ich lese diese Regel daher vor allem so: Wenn Ihr merkt, dass Ihr viel Aufwand zum Nachziehen betreiben müsst, fragt Euch, ob dieser in einem gesunden Verhältnis zum Nutzen steht. Falls nein: Abstrahieren oder Automatisieren:

  • Abstrahieren — die Dokumentation beschreibt keine Lösungsdetails, sondern liefert einen Überblick
  • Automatisieren — Teile der Dokumentation werden z.B. im Rahmen des Builds aus dem Quelltext abgeleitet

Und die anderen Regeln?

In einem weiteren Beitrag hier im Blog führe ich die Diskussion mit den verbliebenen zwei Regeln fort. Bleibt dran …

embarc echo – Juli 2016

By | Allgemein, echo | No Comments

Frische Einblicke & Nützliches in Kürze – embarc echo

Entdecken Sie brandneue Erstauflagen und erleben Sie Interviews zu Stolperfallen und anderen Chancen. Lassen Sie sich von unseren Projekteinsätzen inspirieren, greifen Sie Impulse auf und finden Sie Anregungen in aktuellen Veröffentlichungen.
Auch im zweiten Halbjahr werden wir wieder auf Konferenzen und bei User Groups in ganz Deutschland ‚on tour‘ sein – unsere Landkarte bringt die nächsten Stationen auf einen Blick zusammen. Neben neuem Lesestoff gibt es dieses Mal noch ein kleines Goodie für unsere echo-Leser – viel Spaß beim Finden!

Download embarc echo II-2016 (PDF, 6 Seiten)

embarc_echo_7-2016 -- Klicken zum Download ...

Wie sehen iSAQB CPSA-Advanced Prüfungsaufgaben eigentlich aus?

By | Allgemein, Inhaltliches | One Comment

diploma-3Der iSAQB-Einstiegslevel Foundation der Certified Professional for Software Architecture-Zertifierung (kurz: CPSA-F) sieht einen Multiple Choice Test als Prüfung vor. Bei der zweiten Stufe, dem Advanced Level, bearbeitet der Prüfling hingegen eine Hausarbeit. Seine Lösung verteidigt er (bzw. sie) dann im Rahmen eines Interviews vor zwei Prüfern, die diese vorher durchgesehen und gegen Kriterien gehalten haben.

Beim Multiple Choice Test (CPSA-F) ist relativ klar, was auf den Prüfling zukommt. Auch wenn einzelne Lernziele mit Ankreuzfragen nur schwer überprüfbar sind, und man sich konkrete Fragen vielleicht nur schwer vorstellen kann, gilt das zumindest für die Form der Prüfung. Zum Advanced-Level höre ich in Workshops oder per Mail dagegen immer wieder die Frage: Wie sieht eine solche Prüfungsaufgabe inhaltlich aus? Das ist nicht unmittelbar klar.

Nun sind die Prüfungsaufgaben selbst natürlich vertraulich (genau wie der Prüfungsfragen im Foundation Level). Vorlagen und Checklisten zur Erstellung von Aufgaben sind jedoch frei zugänglich (auf der Webseite des iSAQB). Sie sind nicht unbedingt leicht verdaulich — falsche Zielgruppe: sie sind für Leute gedacht, die sich neue Aufgaben ausdenken. Ich beschreibe daher im Folgenden mal, wie Aufgaben aufgebaut sind – für Leute, die demnächst ein solche Aufgabe lösen müssen. Was Sie als Advanced-Prüfling also grob erwartet…

Überblick Prüfungsaufgabe

Wie sieht eine Aufgabe grundsätzlich aus?

Die Aufgabenstellung einer Prüfungsaufgabe für CPSA-Advanced umfasst mindestens 10 Seiten und höchstens 25 (siehe Abbildung rechte, die Seitenzahlen sind Beispielwerte).

Jede Aufgabe ist einer Systemart zugeordnet. Aktuell sind das

  • Informationssystem
  • Embedded System
  • Websystem

Ein Kandidat gibt bei der Anmeldung zur Prüfung die gewünschte Systemart an und erhält dann eine Aufgabe aus diesem Bereich. Damit soll verhindert werden, dass ein Prüfling mit einer Umfeld konfrontiert wird. das ihm völlig fremd ist. Darüber hinaus ermöglicht ein kurzer Abstract (2-3 Sätze) zur Aufgabenstellung dem Prüfling zu entscheiden, ob die Aufgabe grob passt.

Jede Aufgabe selbst zerfällt dann in zwei grobe Blöcke: Ein Fallbeispiel in Form inhaltlicher Inputs, und die Aufgabenstellung selbst. Letztere ist in Teilaufgaben gegliedert. Die konkreten Prüfungsaufgaben variieren dabei in der Zusammenstellung der inhaltlichen Inputs und den Teilaufgaben.

Das Fallbeispiel

Prüfungsaufgaben: FallbeispielBeim Fallbeispiel handelt es sich um ein fiktives Projekt, eine Produktentwicklung, eine Migration oder ähnliches. Nach einem kurzen Überblick liegen konkrete Informationen dazu in Form inhaltlicher Inputs vor. Im Wesentlichen sind das Anforderungen, die der Prüfling in den späteren Teilaufgaben berücksichtigen muss. Denkbar sind etwa folgende Inhalte:

  • Funktionale Anforderungen (z.B. wichtige Use Cases, User Stories, …)
  • Qualitätsziele, ggf. verfeinert in Szenerien
  • Stakeholder (z.B. Liste, Personas)
  • Interviews mit Stakeholdern
  • Technische und/oder organisatorische Rahmenbedingungen
  • Fachlicher Kontext, Benutzer und Fremdsysteme
  • Normen und Konventionen
  • Risiken

Nicht jede Aufgabenstellung enthält dabei alle diese Inhalte. Weiterhin kann es sein, dass bestimmte Anforderungen explizit genannt sind, andere jedoch im Rahmen der Aufgabe erarbeitet werden müssen. Beispielsweise liegen Interviews mit Stakeholdern vor, und die Rahmenbedingungen oder Qualitätsziele muss der Prüfling dann im Rahmen einer Teilaufgabe herausarbeiten und ggf. priorisieren.

Ihre Aufgabe

Prüfungsaufgaben: TeilaufgabenGanz ähnlich wie das Fallbeispiel mit seinen inhaltlichen Inputs ist auch die Aufgabe unterteilt — in mindestens 5 und maximal 10 Teilaufgaben, die unterschiedliche Aspekte der Architekturarbeit abdecken. In Summe soll die Bearbeitung zeigen, dass der Prüfling in der Lage ist, aus Anforderungen methodisch eine Architektur zu entwerfen und festzuhalten, sie zu reflektieren und zu kommunizieren. Analog zu den denkbaren Inputs oben beim Fallbeispiel hier mögliche Teilaufgaben:

  • Kontext abgrenzen
  • Qualitätsziele identifizieren, Qualitätsbaum und -szenarien erarbeiten
  • Offene Fragen an Stakeholder formulieren
  • Lösungsstrategie/Architekturvision anfertigen
  • Architekturentscheidungen treffen
  • Technische Fragestellung inkl. Alternativen und Begründung bearbeiten
  • System strukturieren, fachlich zerlegen, Verantwortlichkeiten festlegen
  • Schnittstellen entwerfen
  • technische und/oder übergreifende Aspekte bearbeiten
  • Lösung qualitativ bewerten
  • Risiken identifizieren und adressieren

Es gibt dabei Überschneidungen in inhaltlichen Inputs und Teilaufgaben: Der Systemkontext könnte etwa mit dem Fallbeispiel gegeben sein (als inhaltlicher Input) oder muss alternativ als Teilaufgabe erarbeitet werden.
Prüfungsaufgaben: FAQ

Häufige Fragen zu Prüfungsaufgaben

Wie wird sichergestellt, dass die Aufgabe zu den von mir besuchten Schulungen passt?

Eigentlich gar nicht. Durch die Angabe der Systemart (z.B. Web, Embedded) wird lediglich abgesichert, dass es technologisch grob passt. Ansonsten sind die Aufgaben nicht an bestimmte Module gebunden. Die Teilaufgaben (+ Interview) decken lediglich die drei Kompetenzbereiche („Säulen“) des Advanced-Levels ab.

Welchen Umfang hat meine Lösung?

Sie halten Ihre Lösung auf maximal 40 DIN A4-Seiten (inklusive Abbildungen) fest. Dazu haben Sie maximal 3 Monate Zeit (Details siehe Prüfungsordnung). Vom Aufwand sind die Teilaufgaben so bemessen, dass ein Prüfling sie in 40 Stunden erledigen kann.

Was wenn Technologien oder Methoden gefordert sind, die ich nicht beherrsche?

Die Aufgabenstellungen lassen Ihnen angemessenen Spielraum bezüglich Technologien, Werkzeugen, Notation und Ähnlichem. Wenn etwas explizit gefordert ist, so ist sichergestellt, dass Informationen dazu frei zugänglich sind. Entweder es liegt der Aufgabe bereits in den inhaltlichen Inputs oder in einem Anhang bei, oder es wird darauf verwiesen. Es kann natürlich vorkommen, dass Sie sich zur Lösung der Aufgabe noch Wissen aneignen müssen.

Was wenn mir die gegebenen Anforderungen zur Lösung nicht ausreichen?

Wie im richtigen Leben kann es sein, dass Ihnen zur Lösung der Aufgabe Informationen fehlen. Im Einzelfall scheinen sich Anforderungen sogar zu widersprechen (beispielsweise Aussagen in Interviews von Stakeholdern mit unterschiedlichen Prioritäten). Normalerweise klären sie das im Projekt mit den Beteiligten, finden Kompromisse, etc. Da Ihnen die Leute im Rahmen Ihrer Hausaufgabe nicht zur Verfügung stehen, treffen Sie Annahmen. Diese kennzeichnen Sie in Ihrer Lösung explizit als solche. Achten Sie darauf, dass diese sinnvoll und konsistent untereinander und zur Aufgabenstellung sind.

Weitere Informationen

Ich hoffe, ich konnte einen Eindruck vermitteln, wie die Prüfungsaufgaben im CPSA-Advanced-Level grundsätzlich aussehen. Wenn Sie Fragen zu dem Thema haben, kommen Sie gerne auf mich zu. Ansonsten: Auf der iSAQB-Seite finden Sie vieles rund um den Advanced-Level. Hier noch ein paar weiterführende Links …

softwarearchitektur-meetup-hamburg

Softwarearchitektur Meetup: Architekturarbeit in Hamburg

By | Allgemein | No Comments

Am 26. April wird im Hamburger Softwarearchitektur Meetup der Blick auf die Arbeitsweise von Architekten gerichtet.

Meetup
 Architekturarbeit in Hamburg
Referent: Jan Gentsch
Organisation: Harm Gnoyke
Veranstaltung beim Softwarearchitektur Meetup Hamburg
26. April 2016, 18:30 Uhr
HAW Hamburg, Raum 1281 im Berliner Tor 7

Zur kostenlosen Anmeldung

Architekturarbeit ist den letzten Jahren nicht einfacher geworden. Neue Technologien und Trends entwickeln sich oft rasant und wollen verstanden und bewältigt werden. Agile Entwicklungsmethoden haben den Mainstream erreicht und verändern etablierte Vorgehensweisen und Formen der Zusammenarbeit.

Uns interessiert: Wo steht Architekturarbeit heute?

Wo funktioniert sie gut? Was ist immer noch schwierig? Welchen Einfluss hat das Umfeld? Was bewährt sich? Was ist nur heiße Luft?

Um Antworten auf diese Fragen zu finden, werden vor dem Meetup dazu Stories zur Architekturarbeit gesammelt und dann im Meetup gemeinsam ausgewertet.

Dazu bitten wir Euch, um Eure eigenen Erlebnisse (= „Stories“) zur Architekturarbeit und um eine kurze strukturierte Einschätzung zu jeder Story. Die Stories erfassen wir mit einer eigens entwickelten App. Der Link dazu ist hier (dauert keine 15 Minuten!):

Zur Umfrage

Mit Hilfe dieser Methode bekommen wir nicht nur reine Statistik, sondern hoffentlich auch die greifbare Geschichte davon erzählt, wie ihr Architekturarbeit heute lebt.

Ihr dürft gerne mehrere Geschichten einreichen! Grundlegendes zur Umfrage: Die Teilnahme an der Umfrage ist anonym. Teilt nur Informationen, mit denen Ihr euch selber wohl fühlt und nennt bitte Beteiligte oder Unternehmen nicht namentlich.

Im Meetup selbst werden die Ergebnisse nach einem Überblick über die Umfrage dann gemeinsam analysiert und diskutiert. Wir sind schon gespannt auf die Erkenntnisse!

duke_JUG_Hamburg

Vortrag auf dem JUG Hamburg Special Day Architektur im April

By | Allgemein | No Comments

Stefan Zörner ist am 7. April mit einem Vortrag auf dem Special Day Architektur der Java User Group Hamburg dabei.

„Nörgeln ist einfach. Aber was (genau) ist eigentlich Architekturbewertung?“
Logo JUG Hamburg
Nörgeln ist einfach. Aber was (genau) ist eigentlich Architekturbewertung?
Sprecher: Stefan Zörner
Vortrag bei der Java User Group Hamburg
Anmeldung über Meetup erforderlich, beschränkte Platzkapazität
Donnerstag, 07. April 2016
HanseMerkur Versicherungsgruppe Siegfried-Wedells-Platz 1, Hamburg

Statler: „Nein, nein, das hätten sie wirklich anders machen sollen.“
Waldorf: „So, wie denn nach Deiner Meinung?“
Statler: „Besser!“
(aus der Muppet Show)

Jedes interessante Softwaresystem hat eine Softwarearchitektur. Diese ist kunstvoll geplant oder zufällig entstanden, meist aber irgendwas dazwischen. Hätte man es anders machen sollen? In diesem Vortrag stelle ich vor, wie Sie Ihre Softwarearchitektur bewerten! Sind Sie auf dem richtigen Weg? Können Ihre Architekturideen in der Umsetzung aufgetretene Probleme effektiv lösen? Helfen diese bei der Erreichung Ihrer Ziele oder behindern sie diese eher? Architekturbewertung kann Sicherheit schaffen und Risiken aufzeigen und damit helfen die Aufwände im Projekt zu fokussieren. Sie lernen quantitative und qualitative Analysemethoden kennen. Was argumentative, Workshop-basierte Verfahren wie ATAM leisten thematisiere ich ebenso wie welche Aspekte Ihrer Architekturziele sich mit statischen Code-Analysen verknüpfen lassen.

 

Zur Anmeldung bei der JUG Hamburg (Meetup)

embarc echo – Januar 2016

By | Allgemein, echo | No Comments

Impulse aufgreifen – embarc echo

Unser echo gibt Ihnen Einblicke in unsere Aktivitäten im letzten Halbjahr und bringt Nützliches kurzgefasst zusammen.

Finden Sie Anregungen und Wissenswertes in aktuellen Veröffentlichungen im Web und in Fachzeitschriften. Dazu etwas Filmmaterial, inspirierende Kundengeschichten und sorgfältig aufbereitetes Referenzwissen, mitunter in gespickter Form. Und für unsere Übersicht zu kommenden Veranstaltungen hätten wir dieses Mal fast die Weltkugel vektorisiert. Aber schauen Sie selbst…

Download embarc echo I-2016 (PDF, 8 Seiten)

embarc_echo_1-2016 -- Klicken zum Download ...

software_architecture_summit_muenchen

Softwarearchitektur Speed-Dating – im März beim Software Architecture Summit in München

By | Allgemein | No Comments

Am 17. März sind wir mit dem Softwarearchitektur Speed-Dating beim Software Architecture Summit in München dabei. Und am darauf folgenden Tag (am 18. März) nehmen wir in unserem Ganztagesworkshop Bewertungsmethoden unter die Lupe.

„Softwarearchitektur Speed-Dating“
Logo Software Architecture Summit
Softwarearchitektur-Speed-Dating
Sprecher: Stefan Zörner
Session auf dem Software Architecture Summit 2016
Donnerstag, 17. März 2016, 18 – 19:30 Uhr
Novotel München Messe, Willy-Brandt-Platz 1, 81829 München Riem

Zeitgemäße Softwarearchitektur ist nicht das Werk einzelner. Architekturansätze und Ideen entstehen im Team und werden gemeinsam reflektiert. Alle Entwickler müssen sie zumindest verstehen und mittragen können. Aber was genau müsst Ihr vermitteln? Reicht aufschreiben? Hilft UML?
Stefan Zörner zeigt auf lebendige Weise, wie Ihr Eure Softwarearchitektur wirkungsvoll kommunizieren könnt. Nach kurzen theoretischen Inputs rund um Architekturdokumentation und -bewertung probiert Ihr das Gehörte gleich aus. Ihr lernt die Lösungen anderer Teilnehmer kennen und erfahrt Schritt für Schritt, welche Zutaten in einem Architekturüberblick keinesfalls fehlen sollten – egal wie kurz er ist. Ihr lernt die richtigen Fragen zu stellen und passende Antworten parat zu haben.
Bringt bitte die Bereitschaft mit, Euch über Eure Projekte und Softwarelösungen auszutauschen, und anderen Teilnehmern Feedback zu geben. Die sonst üblichen Speed-Dating-Themen wie Kinderwünsche klammern wir aus.

Zur Ankündigung des embarc Ganztagesworkshops am 18. März 2016 auf dem Software Architecture Summit.

 

Zur Website der Veranstaltung

Meetup in Hamburg im Dezember: Size does matter – (Micro-)Services richtig schneiden

By | Allgemein | No Comments

Vorschau: Kurz vor Weihnachten sind beim Softwarearchitektur Meetup in Hamburg wieder Microservices das Thema.

Meetup
 Size does matter – (Micro-)Services richtig schneiden
Referent: Lars Röwekamp von open knowledge
Veranstaltung beim Softwarearchitektur Meetup Hamburg
15. Dezember 2015, 19:00 Uhr
HAW Hamburg, Hörsaal 1.12 im Berliner Tor 5

Zur kostenlosen Anmeldung

Der Vortrag knüpft thematisch direkt an die vergangenen Veranstaltungen zu dem Hype um Microservices an. Hier der Abstract von Lars:

„Die Idee, seine Anwendung in möglichst kleine, unabhängige Teile – a.k.a. (Micro-)Services -zu zerschneiden, die dann miteinander kommunizieren, hat einiges für sich. Was sich allerdings in der Theorie recht einfach anhört, stellt sich in der Praxis nicht selten als echte Herausforderung dar.

Lars Röwekamp
Die Kunst liegt darin, die richtige Größe für die einzelnen Services zu finden. Aber wie schneidet man die Services richtig? Wie bekommt man es hin, dass die Fachlichkeit nicht zerpflückt wird und so der Blick für das große Ganze verloren geht? Und wie sieht dann die Kommunikation der Services untereinander aus?

Anhand eines Praxisberichts zeige ich wie Domain Driven Design dabei helfen kann, diese Fragen – und noch einige mehr – sinnvoll zu beantworten.“

Netflix-Architektur Blogserie – Teil 3: Netflix Open Source Services (OSS)

By | Allgemein, Inhaltliches | No Comments

In Teil 1 der umgekehrten Architekturbewertung gab es eine kurze Einführung, Teil 2 kümmerte sich um den Microservice-Ansatz von Netflix. Nun kommen wir zu einem Teil der Netflix-Architektur, der auch von Ihnen potentiell gut nutzbar ist, wenn Sie sich für eine ähnliche Architekturrichtung entscheiden: Die Open Source Services (kurz OSS) von Netflix. Sie bilden einen guten Teil dessen ab, was Netflix neben der eigenen Fachlichkeit an Services baut. Nicht alle Plattform-Services und andere technisch motivierten Services haben es in die Open Source Welt geschafft, aber es werden stetig mehr. Insgesamt erleichtert Netflix damit anderen Firmen den Einstieg in die Welt von Microservices. Doch was hat Netflix selbst davon?

Was leisten die OSSs?

Das folgende Bild zeigt die zentrale Architekturidee hinter den Open Source zur Verfügung gestellten Services. Auf Basis der Infrastruktur der Amazon Cloud wird eine Plattform etabliert, die es einfacher macht individuelle Software bzw. individuelle Services zu schreiben. Netflix selbst sagt: „The Netflix Open Source Platform Components fill gaps in Amazon Web Services. The goal is to make cloud infrastructure more robust, flexible and glitch free.”

Netflix OSS als PaaS (vereinfacht)

Ein schönes Zitat von Dianne Marsh zu den Open Source Services: „Das haben wir nicht für Euch gebaut, das haben wir gebaut, weil wir es brauchten, und es nicht da war. Aber jetzt ist es da.”. Einige Firmen bedienen sich dieser Plattform auch bereits. Yelp, Yahoo, Sincorp oder Hotels.com wären Beispiele, über das Spring Cloud Projekt und die dortigen Netflix-Abstraktionen kommt auch noch einmal ein breiteres Publikum in den Genuss einiger Services.

Wie passen die Komponenten dieser technischen Plattform nun zu den Microservices, die Netflix baut? In Teil 2 dieser Serie habe ich einen Architekturüberblick beschrieben. Im Folgenden ist der gleiche Überblick um die Information ergänzt, wo sich OSS Projekte einfügen (und wo AWS bereits hilft).

OSS und AWS Komponenten in der Netflix Architektur (vereinfacht)

Neben den Projekten die direkt der Struktur und dem laufenden Programm zugeordnet werden können hat Netflix auch OSSs für Deployment, Monitoring oder zum Test der Fehlertoleranz (die berühmte Simian Army). Auf einige dieser Projekte kommen wir in Teil 4 dieser Serie noch zu sprechen. Eine vollständige und aktuelle Liste der Projekte finden Sie unter https://github.com/netflix.

Auswirkungen und Rückschlüsse

Was kann man aus der OSS-Initiative von Netflix für Rückschlüsse auf deren Ziele und Rahmenbedingungen ziehen?

  1. Netflix braucht Entwickler. Die Open Source Services sind gut sichtbar und auf vielen Konferenzen präsent. Damit erscheint Netflix als Vorreiter und attraktiver Arbeitgeber. Mit den Open Source Services sinken die Anforderungen an jeden einzelne Entwickler – sie werden bei der Entwicklung von vielen technischen Details entkoppelt und auch die Infrastruktur ist einfacher einzubinden und anzusprechen. Das ermöglicht wiederum schnelleres Wachstum.
  2. Für Netflix ist schnelle Handlungsfähigeit und Time-to-Market wichtig. Entwickler kennen den Stack vermutlich bevor sie sich bei Netflix bewerben und neue Services sind schnell aufgesetzt. Funktionale Erweiterbarkeit scheint ein wichtiges Qualitätskriterium zu sein.
  3. Innere Qualität der Services ist relevant. Fachliche Services werden mit intern anerkannten technischen Lösungen ergänzt, die sich bewährt haben. Die technischen Services selbst werden durch das Open Source stellen in ihrer Qualität gefördert. Es gibt damit ein Mindestmaß an Dokumentation im Wiki oder Techblog und das Design wird aufgeräumt. Ideen von Anwendern helfen zusätzlich.
  4. Netflix muss Qualitätsanforderungen wie Verfügbarkeit und Skalierbarkeit sicherstellen. Viele OSS-Projekte kümmern sich um diese beiden Themen und man kann so spezialisierte Teams mit Experten auf die Lösungen ansetzen. Gleichzeitig verhindert man damit Wildwuchs in diesen heiklen Gebieten (siehe auch letzter Absatz dieses Posts).

Im abschließenden Teil (5) dieser Blogserie werde ich diese Rückschlüsse noch einmal verdichten und gemeinsam mit den anderen Erkenntnissen dieser Serie aufgreifen.

Ein spannender Aspekt der Open Source Plattform von Netflix ist übrigens, dass technische Konzepte und Ideen damit kommuniziert werden. Durch die Verwendung von Hystrix müssen sich die Service-Eigner weniger Gedanken um Ausfälle und Latenzprobleme machen, gute Architektur-Prinzipien und –Patterns werden automatisch umgesetzt. Ribbon erleichtert die RESTvolle Kommunikation und fördert damit deren Einsatz. Es steht Teams bei Netflix frei was sie machen, aber eine gewisse „Anti-Zähigkeit im Design“ leitet sie mehr oder weniger sanft in eine bestimmte Richtung. Wenn ein Team vom einfachen Weg abweicht hat es bestimmt einen Grund und hat sich das gut überlegt. Ein interessanter Ansatz der Architekturboards, Unternehmensstandards und Assessments etwas alt aussehen lässt. Diese und andere Techniken der Architekturgestaltung werde ich am 22. Oktober auf einer Session beim Architecture Gathering in München vorstellen. Titel: NoBullshit – Architekturarbeit neu gedacht.