Category

Artikel

Artikel im Java Magazin 12/2015: Agil, Lean oder einfach nur komplex?

By | Artikel, Publikationen | No Comments

 

Agil, Lean oder einfach nur komplex?

Java Magazin 12/2015

Agil, Lean oder einfach nur komplex?
Autor: Stefan Toth
Artikel im Java Magazin 12/2015, 5 Seiten, ab S. 64
erschienen am 04. November 2015

Online lesen auf JAXenter

Projekte und Produktentwicklungen sind unterschiedlich. Fest steht jedoch: Nirgendwo findet man ein perfektes Umfeld mit ausreichend Geld, Zeit und fähigen Leuten, ohne störende Legacy-Lasten, fehlende Libraries oder böse Überraschungen. Selbst wenn viele dieser Parameter passen, ist Ihr Kunde oder Fachbereich vielleicht wankelmütig oder das Management wechselt während des Vorhabens die eigene Linie (falls es eine gibt). Moderne Softwareentwicklung ist komplex und wenig schablonenhaft. Zeitgemäße Arbeit an der Softwarearchitektur muss deshalb Reaktionsfähigkeit stärken, fokussieren und sich davon verabschieden, dass alles vorab plan- und analysierbar ist.

Agile Vorgehensmodelle versuchen mit Unsicherheit zu leben, Flexibilität im Vorgehen zu ermöglichen und Zusammenarbeit zu stärken. Die richtige Reaktion ist wichtiger als der richtige Plan. Lean stellt das Lernen und die stetige Verbesserung in den Vordergrund, versucht Verschwendung zu eliminieren und unser Vorgehen auf wichtige Aspekte zu fokussieren. Der Trend geht weit über die Softwarearchitektur hinaus, und selbst wenn Sie den Begriff „Agil“ oder den (abflachenden) Hype darum nicht mögen – es hat sich etwas im Projektalltag verändert und die Disziplin der Softwarearchitektur muss darauf reagieren…

weitere Infos zum Heft

 
follow us on Twitter – @embarced

Single Page-Anwendungen – Vorteile von Web und Desktop kombiniert

By | Artikel, Inhaltliches | No Comments

Desktop-Anwendungen und klassische Web-Anwendungen haben – jede für sich – große Vorteile. Eine Desktop-Anwendung ist in ihrem Bedienkomfort und auch in ihrer Reaktionsgeschwindigkeit typischerweise der klassischen Web-Anwendung überlegen. Diese muss nämlich für jede Interaktion mit dem Benutzer eine komplett neue Seite auf dem Server rendern und diese wieder zum Browser übertragen. Das ist auch bei modernster Technik zu langsam, um mit einer Desktop-Anwendung zu konkurrieren. Dazu schließt sich ein Offline-Betrieb einer solchen Web-Anwendung schon von selbst aus: ohne Verbindung zum Server kann man auch nichts darstellen. Auf der anderen Seite läuft eine Web-Anwendung auf jeder Plattform, die einen Internet-Browser hat und muss nicht installiert oder aktualisiert werden. Wenn man sich etwas Mühe mit Responsive Layout gibt, funktioniert eine solche Anwendung sogar auf einem mobilen Gerät.

Die klassische Web-Anwendung

Gucken wir uns dazu die folgende Darstellung einer klassischen Web-Anwendung an. Der Anwendungszustand, die Geschäftslogik und der UI-Teil, der die Anwendung in HTML transformiert, ist auf dem Server. Der Browser macht lediglich Anfragen über HTTP und bekommt HTML-Seiten geliefert, die er nur noch darstellen muss. Jede Interaktion erfordert also einen Request zum Server, gefolgt von der Response mit der neuen Darstellung:

Classic Web Application

Klassische Web-Anwendung, Lila: Browser, Blau: Server

Grenzen der klassischen Web-Anwendung

Dieser Ansatz ist erfreulich einfach, kommt aber immer mehr an seine Grenzen, je interaktiver die Anwendung wird. Stellen Sie sich z.B. eine Tabelle vor, bei der sich die Breite jeder einzelnen Spalte durch Ziehen mit der Maus ändert. Oder einen interaktiven Editor für Text, wie diesen. Wenn wir das Modell beibehalten wollten, müssten wir bei jeder Interaktion einen Request/Response-Roundtrip durchführen. Das ist zum Einen technisch ohne den Einsatz von JavaScript-Logik im Browser nicht möglich, zum Anderen hätten wir dann eine große Anzahl von Anfragen (jeder Click und jeder Tastendruck im Extremfall). Eine derartige Anwendung wäre zwar technisch denkbar, würde aber nicht zu einer guten Benutzer-Erfahrung führen. Die Anwendung wäre langsam, würde flackern und wäre generell von der Latenz von Server und Netz abhängig.

Gängige Muster nutzen für derartige Anwendungen daher eher punktuelle JavaScript-Logik, z.B. in Form eines jQuery-Plugins für einen Text-Editor oder eine Tabelle. Dies erfordert allerdings das Halten von Zustand im Browser zusätzlich zu dem Zustand auf dem Server. Soll der Zustand des Browsers über eine Request/Response-Grenze hinweg gehalten werden, so muss dieser als Teil des Requests zum Server übertragen und als Teil des Response zurück übertragen werden. Für einen Text-Editor würde das z.B. auch die Cursor-Position, die Scroll-Position und alle aktuell gewählten Format-Optionen beinhalten. Dies stößt oft an die Grenzen der Plugins und würde auch keinen Best-Practice darstellen. Stattdessen wird für die Lebensdauer einer solchen Komponente häufig auf komplette Server-Roundtrips verzichtet und man hat eher eine Ansammlung von kleinen Browser-Anwendungen innerhalb der klassischen Web-Anwendung. Eine solche Architektur ist möglich, ist aus unser Erfahrung aber ein Grund für den schlechten Ruf von Web-Anwendungen. Die temporäre Verteilung des Zustands auf Browser und Server, die unklare Trennung der Verantwortlichkeiten, die Mischung von Darstellung des HTMLs auf Browser und Server machen eine solche Anwendung häufig aufwändig in der Entwicklung und Wartung.

Single-Page Applications als Lösung

Der Kern des Problems liegt dabei darin, dass Benutzer-Interaktion, Zustand und Programmlogik nicht oder nur zeitweilig nahe beieinander liegen. Der Zustand ist zudem verteilt über Server und Browser, teilweise redundant und zeitweise sogar inkonsistent. Architektonisch ist es reizvoll, dies zu vereinheitlichen und alles nah bei einander zu haben. Da die Benutzer-Interaktion per Definition im Browser liegt, gibt es Ansätze auch Zustand und zumindest den UI-Teil der Programmlogik ebenfalls in den Browser zu verschieben. Das Versprechen ist dabei auch, die Vorteile der Welten Desktop und klassischer Web-Anwendung kombinieren zu können. Den Bedienkomfort, die Reaktionsgeschwindigkeit und die Offline-Fähigkeit der Desktop-Anwendung mit der Verfügbarkeit und der einfachen Installation einer Web-Anwendung? Das geht in der Tat. Und es gibt sogar einen Namen dafür: eine Single-Page Application oder kurz SPA:

SPA Web Client

Single-Page Application, Lila: Browser, Blau: Server

Die Idee dabei ist, die Anwendungs- und UI-Logik näher an den Anwender, also in den Browser, zu bringen und hier auch die komplette Darstellung zu implementieren. Dabei wandert auch der Zustand der Anwendung vom Server komplett in den Browser und damit wäre der Zustand immer synchron, da es schlicht keinen Server-seitigen Zustand mehr gibt. Der Server liefert am Anfang nur eine einzige Webseite aus, die allen Code enthält. Danach dient der Server nur noch dazu, die SPA mit Daten zu versorgen oder Daten zum Speichern entgegenzunehmen. Auf diese Weise kann eine SPA tatsächlich mit einer Desktop-Anwendung konkurrieren. Selbst ein Offline-Betrieb wäre möglich, hierzu müsste zumindest ein Teil der Geschäftslogik im Browser vorhanden sein. Für den Fall einer ungenügenden Internet-Versorgung könnte das nützlich sein, z.B. während Reisen mit der Bahn oder im Flugzeug. Beispiele solcher Anwendungen sind Google Docs und Spreadsheets, Word Online oder auch Facebook.

Herausforderungen bei Single-Page Applications

Es ergeben sich allerdings für SPAs eine Reihe von Herausforderungen. Selten haben Unternehmen ein großes Know-How in der Anwendungsentwicklung mit JavaScript. Entwickler beherrschen vielleicht Java oder C# und stehen JavaScript und seiner Kultur skeptisch gegenüber. In den Grafiken oben stellen wir zudem die Beziehung der Anwendungsschichten zu Anforderungen im Bereich Stabilität und Langlebigkeit dar. Je weiter wir uns in der Pyramide nach unten bewegen, desto höher die Anforderung. In unseren Blog-Posts JavaScript im Großprojekt – TypeScript und andere Typensysteme beschäftigen wir uns mit den Mängeln von JavaScript im Unternehmenskontext und was man dagegen tun kann. Hier empfehlen wir auch für Enterprise-Projekte auf TypeScript zu setzen. In verschiedenen Projekten haben wir direkt miterlebt, wie schnell die Sprache TypeScript unter Java- und C#-Entwicklern zur Gewohnheit wird.

Die Auswahl eines passenden JavaScript Web-Frameworks ist leider auch keine einfache Aufgabe, da der Bereich unübersichtlich und in ständiger Bewegung ist. Unsere Erfahrungen dazu haben wir in den Blogposts über JavaScript-Web-Frameworks und UI-Architektur festgehalten.

Blogserie auf JAXenter: „LiesMich.jar – Bewusster Umgang mit 3rd Party Libraries“

By | Artikel, Publikationen | No Comments
„LiesMich.jar – Bewusster Umgang mit 3rd Party Libraries“ (Blogserie auf JAXenter)

JAXenter Logo

LiesMich.jar – Bewusster Umgang mit 3rd Party Libraries
Blogserie von Harm Gnoyke
Teil 1
Teil 2
erschienen am 22./29. September 2015

Eine 3rd Party Library ist in Java schnell und unkompliziert eingebunden. Entwickler freuen sich über die gesparte Zeit und die geschenkte Funktionalität. Auch der Projektleiter ist froh, kann er nun den Entwickler wieder an richtigen Features arbeiten lassen. Doch heißt „geschenkt“ auch wirklich kostenlos? Natürlich ist die Antwort darauf „Nein“, denn ein Projektteam sollte Folgekosten und Risiken bei solch einer Entscheidung immer berücksichtigen. (mehr …)

zu Teil 1 zu Teil 2

Artikel im Java Magazin 9/2015: Architekturdokumentation mit Entwicklerwerkzeugen

By | Artikel, Publikationen | No Comments

 

Architekturdokumentation: Leichtgewichtig bleiben mit Markdown, Git und Co.

Java Magazin 09/2015

Architekturdokumentation: Leichtgewichtig bleiben mit Markdown, Git und Co.
Autoren: Peter Götz und Stefan Zörner
Artikel im Java Magazin 9/2015, 6 Seiten, ab S. 52
Erschienen 5. August 2015

Online lesen auf JAXenter

Wohl jeder kennt die Situation: ein neues Projekt startet und diesmal wollen wir alles richtig machen. Wir machen uns erste Gedanken über die Architektur des Systems und schreiben unsere Ideen auf. Wir halten fest, was wir mit welchen Technologien, Mustern, Prinzipien, Konzepten etc. lösen wollen. Dazu verwenden wir Word oder unser Wiki. Am Anfang klappt auch alles super. Die ersten Änderungen, die sich während der Entwicklung ergeben, schaffen es noch in die Dokumentation. Doch je älter das Projekt wird und je größer das Team, desto seltener werden Änderungen an der Architektur in der Dokumentation nachgezogen. So passiert am Ende genau das, was wir vermeiden wollten: Die Dokumentation unserer Architektur spiegelt nicht die Realität wider und keiner weiß so genau, welche Teile noch richtig sind und welche nicht mehr.

Online lesen

 
follow us on Twitter – @embarced

Artikel im Java Magazin 5/2015: Netflix – Resilience konsequent zu Ende gedacht

By | Artikel, Publikationen | No Comments
Netflix: Resilience konsequent zu Ende gedacht

Java Magazin 05/2015

 „Keine Angst vor Chaos“ – Netflix: Resilience konsequent zu Ende gedacht
Autor: Stefan Toth
online auf JAXenter
vorab erschienen im Java Magazin 5/2015 (8. April 2015)

Fehler sind unvermeidbar. Sie testen Ihre Software auf unterschiedlichen Ebenen, unterziehen sie Reviews, Sie lassen BugFinder und Metriken auf Ihre Applikationen los und trotzdem: Völlige Bug-Freiheit ist illusorisch. Es ist jedoch nicht alleine die schiere Menge an Fehlerquellen die problematisch ist, sondern auch deren zufällige und nicht vorhersagbare Verteilung.
Es gibt mehrere Strategien, wie Sie trotzdem zuverlässige und verfügbare Systeme bauen können. Eine davon ist besonders effektiv und bietet sozusagen ein zweites Fangnetz: „resilient Design“. Wenn Fehler nicht vermieden werden können (oder deren Vermeidung sehr teuer wäre), sollte das System gut damit umgehen können und nicht als Ganzes gefährdet sein. Resilience ist also eine Eigenschaft, die es Systemen erlaubt Defekte und Fehler zu überstehen, sie zu isolieren, ihre Auswirkungen gering zu halten und sie idealer Weise zu korrigieren. Für manche Systeme ist Resilience der einzige Weg zur Ausfallssicherheit, für andere einfach die billigere Alternative zu teuren Simulationen, Analysen und Testumgebungen. Netflix ist ein Pionier des resilient Design und setzt neue Maßstäbe was die Entwicklung für Fehlertoleranz angeht. Sehen wir warum das so ist, was Netflix genau macht und wie Sie davon profitieren können. (mehr…)

 

follow us on Twitter – @embarced

Artikel im Java Magazin 3/2015: Gut genug?

By | Artikel, Publikationen | No Comments
„Gut genug?…“

Java Magazin 03/2015

 „Gut genug? – Softwarearchitekturen bewerten“
Autoren: Stefan Toth, Dr. Gernot Starke und Phillip Ghadir
online bei JAXenter (ursprünglich veröffentlicht im JavaMagazin)
Erschienen 4. Februar 2015

Mein Haus, mein Auto, mein Urlaub…
Menschen vergleichen gerne. Auch im Bereich der Softwareentwicklung finden wir genügend Möglichkeiten für Vergleiche. Sie können jede publizierte oder informell vorgestellte Lösung auf Ihr Projekt projizieren und werden sicherlich auf Unterschiede stoßen. Kein System gleicht dem andern. Online-Shops, Systeme zur Massendatenverarbeitung und Flugsicherungssoftware werden sich vielen bis allen grundlegenden technischen (architektonischen) Fragestellungen unterscheiden. Trotz dieser Unterschiede kann die gewählte Architektur in allen drei Fällen ideal sein.
Bei einer Architekturbewertung geht es darum herauszufinden, ob Ihre Architektur für Ihren Kontext gut genug ist. Rahmenbedingungen und Anforderungen sind der Schlüssel für jede Bewertungstätigkeit. Von ihnen ausgehend eröffnet sich eine Menge an Möglichkeiten zur Bewertung von zentralen Entwurfsentscheidungen, gewählten Datenstrukturen oder Technologien, eingehaltenen Prinzipien oder extern zur Verfügung gestellten Schnittstellen. (mehr…)

 

follow us on Twitter – @embarced

Artikel Java Magazin 12/2014: Keilschrift reloaded

By | Artikel, Publikationen | No Comments
„Keilschrift reloaded“

Keilschrift reloaded — Softwarearchitekturen besser dokumentieren
Autoren: Gernot Starke und Stefan Zörner
Artikel im Java Magazin, 12/2014, 4 Seiten, ab S. 102
Erschienen 3. November 2014

Stellen Sie sich vor, Sie sollen Interessierten die Architektur Ihrer Software erklären – und es gibt keinerlei Dokumentation. Oder es stehen größere Änderungen an einem Altsystem an – und Sie können nirgendwo erkennen, welche Risiken dabei drohen, oder ob man das System doch besser neu entwickelt. Ach, in diesem Dilemma stecken Sie wirklich? Dann sind Sie hier richtig.

Interview auf JAXenter: „Softwarearchitektur wird immer mehr zum Entwickler-Skill“

By | Artikel, Publikationen | No Comments
„Softwarearchitektur wird immer mehr zum Entwickler-Skill“ (Interview auf JAXenter)

Softwarearchitektur wird immer mehr zum Entwickler-Skill
Interview mit Stefan Zörner (Fragen von Hartmut Schlosser)
online bei JAXenter (W-JAX Countdown)
erschienen 13. Oktober 2014

Die Zeiten, in denen Softwarearchitekturen isoliert auf dem Reißbrett entworfen und dann von fleißigen Entwicklerbienen umgesetzt werden, sind vorbei. Entwickler wollen heute Verantwortung für die Lösung als ganzes mitübernehmen – sagt Stefan Zörner, W-JAX-Speaker und Software-Architekt bei embarc Software Consulting. Wir haben uns mit ihm über die heutige Rolle von Softwarearchitekten, Kriterien für gelungene Architekturen und aktuelle Architektur-Trends wie Microservices unterhalten. (mehr …)

zum Interview

Artikelserie: Zeitgemäße Softwarearchitektur

By | Artikel, Publikationen | No Comments
„Zeitgemäße Softwarearchitektur: Der Umgang mit beschränkten Mitteln“ (Online-Artikel)

Zeitgemäße Softwarearchitektur: Der Umgang mit beschränkten Mitteln
Artikel von Stefan Toth
online bei JAXenter (ursprünglich veröffentlicht im JavaMagazin)
Erschienen 30. September 2014

„Haben Sie schon einmal erklärt bekommen, wie das mit der Softwarearchitektur richtig funktioniert? Haben Sie schon mal ein Buch gelesen und gedacht: So müssten wir mal arbeiten? Bei mir war beides öfter der Fall, und am Ende hat der Projektalltag alles zunichtegemacht: kein Geld, keine Zeit, die falschen Leute oder zu viel „Legacy“. Arbeit an der Softwarearchitektur findet (leider) selten ideale Voraussetzungen. Eine moderne Disziplin muss deshalb mit der Unvollkommenheit unserer Projekte zurechtkommen. Ein Schlüssel dazu: der Umgang mit beschränkten Mitteln.“ (mehr …)

zum Artikel

Online-Beitrag bei Hanser Update: Ist dieses arc42 eigentlich alternativlos?

By | Artikel, Publikationen | No Comments
„arc42 vs. … — Ist dieses arc42 eigentlich alternativlos? “ (Blog-Beitrag)
 arc42 vs. … — Ist dieses arc42 eigentlich alternativlos?
Blog-Beitrag von Stefan Zörner
online bei Hanser Update
Erschienen 30. Juli 2014

„Haben Sie King Kong vs. Godzilla gesehen? Oder Alien vs. Predator (Teile 1 und 2)? Oder Dracula vs. Frankenstein (Deutscher Titel: “Draculas Bluthochzeit mit Frankenstein”)? Dieser Beitrag liefert etwas sehr Ähnliches: nur ohne Monster.“ (mehr …)

zum Beitrag