AI API Architektur Architekturbewertung Art Bimodale-IT Cloud Docs-as-Code Dokumentation Fehlersuche Fortbildung Improve Infrastruktur JavaScript Knigge Kommunikation Legacy Meteor Online-Training Persönlich Produktivität Qualität Req4Arcs Requirements Review Shell Tools Venom Video Vms Yoda aim42 arc42

AI

The ART-ificial Yoda Gallery

Dr. Gernot Starke

Recently, several AI (artificial intelligence) based image generation systems became popular.

This article gives a glimpse of what is currently (October 2022) possible with three major players in this league. In addition, you can learn a bit about different styles of art.

API

Kolumne: Knigge für Softwarearchitekten - Die API-tektin

Peter Hruschka, Dr. Gernot Starke

Unserer Einschätzung nach werden Schnittstellen oft als Dinge dritter Klasse behandelt. Technologie auswählen, Features bauen und Bugs fixen geht vor. Sogar Dokumentation schreiben scheint uns in manchen Projekten wichtiger als effektive Schnittstellen zu entwerfen. Wir wünschen Ihnen und uns die API-tektin, die gemeinsam mit Softwarearchitekten den Schnittstellen auf die Sprünge hilft.

Architektur

Grundlagen der Softwarearchitektur - Teil 5: Wie geht es weiter?

Dr. Gernot Starke

In dieser (fünften) Folge der Mini-Serie zu Softwarearchitektur verlassen wir die kleinen bis mittelgroßen Systeme, und werfen einen Blick auf große, riskante und komplexe Projekte. Sie können das als „Skalierung” der Rolle Softwarearchitektur betrachten.

Grundlagen der Softwarearchitektur - Teil 4: Wer macht das?

Dr. Gernot Starke

In dieser (vierten) Folge der Mini-Serie zu Softwarearchitektur klären wir, wer denn die Architekturaufgaben erledigen könnte, die ich in der vorigen Folge vorgestellt habe. Dazu stelle ich einige mögliche Rollenausprägungen für Softwarearchitektur mit ihren jeweiligen Vor- und Nachteilen vor.

Grundlagen der Softwarearchitektur - Teil 2: Begriffe

Dr. Gernot Starke

In der ersten Folge hatten wir auf die Architektur von Gebäuden geschaut, und einige Begriffe und Herausforderungen dieser Disziplin geklärt. Diesmal wenden wir uns der Informationstechnik zu und erklären, was Softwarearchitektur bedeutet.

Hinter den Kulissen des (neuen) Foundation-Level-Lehrplans

Dr. Gernot Starke

Es war wieder an der Zeit: Just in time erschien Anfang April 2023 das neue Release des iSAQB-Foundation-Lehrplans.

Neben den wesentlichen Unterschieden zur Vorgängerversion erklärt dieser Blogpost, wie die Arbeit in einem internationalen und dezentralen Verein funktioniert und welche Methoden und Werkzeuge wir dafür einsetzen.

1×1 guter Architekturdiagramme

Dr. Gernot Starke

Sie wollen oder müssen Architektur dokumentieren und möchten dafür grafische Darstellungen verwenden? Sie wünschen sich verständliche Diagramme, die auch zukünftig noch leicht änderbar sind? Sie möchten, dass Ihre Diagramme für unterschiedliche Zielgruppen nützlich sind? Und wenn Sie ganz ehrlich sind, wollen Sie dieses Doku-Zeugs in möglichst kurzer Zeit erledigen, damit Sie sich wieder anderen Dingen zuwenden können.

Sparsame Dokumentation

Dr. Gernot Starke

Ich weiß – Dokumentation ist nicht Ihr Lieblingsthema. Deswegen bekommen Sie hier ein paar Tipps für schmerzfreie Dokumentation. Die hier vorgestellten Ideen sparen Ihnen wertvolle Zeit, sowohl bei Erstellung als auch Pflege der Dokumentation. Sie funktionieren für jede Art von Softwaresystem, unabhängig von Werkzeugen, Technologien und Entwicklungsansätzen.

Documenting software architecture with arc42

Dr. Gernot Starke

arc42 is a template for architecture communication and documentation. It is a proven, practical and highly pragmatic approach and takes the pain out of documentation.

Eine kleine Geschichte über Qualität

Dr. Gernot Starke

Du denkst Dir nichts Böses, da bittet Dich Tante Lucy um einen kleinen Gefallen… und Du musst Dich entscheiden, wie Du das angehen sollst. Aber als Belohnung winkt ihr leckerer Erdbeerkuchen, außerdem sind wir doch alle Herausforderungen gewöhnt, oder?

Ähnlichkeiten zu konkreten IT-Systemen und Softwareprojekten wären zufällig, Analogien zu unserer Branche jedoch beabsichtigt

Im Stich gelassen - systematisch zu besseren Anforderungen

Dr. Peter Hruschka, Dr. Gernot Starke

Sie fühlen sich als Architekt:innen und Designer:innen von Ihren Requirements Engineers, Product Owners oder Produktmanager:innen alleine gelassen, was klare Anforderungen angeht? Sie leiden unter vagen, unklaren oder fehlenden Anforderungen ohne konsistente Prioritäten? Sie werden für falsche Architekturentscheidungen kritisiert, obwohl Sie sie nach bestem Wissen und Gewissen (leider aber ohne Kenntnis der wahren Anforderungen) getroffen haben? Willkommen im Club der „Im-Stich-Gelassenen“.

Blog-Post: Awesome presentations deserve beautiful code

Gernot Starke

Occasionally we need to put parts of our source code onto slides for presentations. The common presentation programs (such as PowerPoint or Keynote) fail miserably at this task because they interpret code as normal text. Syntax highlighting is lost, as are indentations. It looks lousy, and it’s no fun. This post introduces carbon.now.sh, a quick and free solution, created by the awesome people from @carbon_app.

Quality Driven Software Architecture - Revised

Gernot Starke

Quality is the raison d’être for software architects: Our systems should be reliable, performant, scalable and user-friendly. Systems should be build and maintained cost-effective and future-proof. Every IT professional knows that this combination of characteristics means hard work. The article shows how you can methodically construct quality. This is the revised and updated version of the article “Quality Driven Software Architecture” first published in 2012 (only available in German).

What is Software Architecture?

Gernot Starke

As the importance of software continues to increase in our everyday lifes, the underlying methodical foundation, known as software architecture, should become common developer knowledge and skill. In a short series of blog posts, we like to briefly introduce this topic.

Kolumne: Req4Arcs - Miteinander statt gegeneinander

Dr. Peter Hruschka, Dr. Gernot Starke

Nach vielen inhaltlichen Folgen zum Umgang mit Requirements greifen wir diesmal ein ganz anderes Thema auf: Wie sollten Architekt(inn)en mit Requirements-Spezialisten zusammenarbeiten?

Kolumne: Req4Arcs - Ausführbare Spezifikationen (und eine Portion BDD)

Dr. Peter Hruschka, Dr. Gernot Starke

In einer der letzten Folgen haben wir bereits über beispielhafte Spezifikationen geschrieben. Diesmal möchten wir konrekter auf die Möglichkeit der Ausführbarkeit solcher Spezifikationen eingehen. Dazu werden wir einen Ausflug in die großartigen Möglichkeiten von Behavior-driven Development unternehmen.

Kolumne: Req4Arcs - Qualitätsanforderungen konkret formulieren

Dr. Peter Hruschka, Dr. Gernot Starke

In der letzen Folge hatten wir das Thema “Qualität” top-down erklärt und Ihnen dazu das generische Qualitätsmodell ISO 25010 vorgestellt. Das komplette Modell umfasst insgesamt 45 Eigenschaften. Das ergibt eine ziemlich breite Themenvielfalt rund um “Qualität”, ist aber als Grundlage für konkrete Entscheidungen viel zu abstrakt. Wir benötigen mehr Details, wir müssen genauer wissen und beschreiben, was Stakeholder denn nun wirklich von unseren Systemen erwarten oder benötigen.

Kolumne: Req4Arcs - Qualität fällt nicht vom Himmel

Dr. Peter Hruschka, Dr. Gernot Starke

In den vergangegen drei Folgen haben Sie erfahren, wie Sie systematisch mit funktionalen Anforderungen umgehen können. In den nächsten Folgen wenden wir uns den Qualitätsanforderungen IT-Sicherheit, Performance und Zuverlässigkeit zu.

Kolumne: Req4Arcs - Gute Beispiele statt schlechter Abstraktionen

Dr. Peter Hruschka, Dr. Gernot Starke

In den letzten Folgen haben wir Ihnen Optionen für die Darstellung und Klärung funktionaler Anforderungen aufgezeigt. Nun stellen wir Ihnen noch eine dritte Perspektive für funktionale Anforderungen vor, nämlich Beispiele.

Kolumne: Req4Arcs - Anforderungen mit DDD klären

Dr. Peter Hruschka, Dr. Gernot Starke

In der letzten Folge haben Sie gesehen, wie wir Überblick über die wesentlichen funktionalen Anforderungen bekommen können - nämlich indem wir von groben Zielen ausgehend die Granularität von Anforderungen verfeinern und dabei Geschäftsprozesse und Ende-Zu-Ende-Abläufe (Use Cases oder User Stories) untersuchen. In dieser Folge möchten wir das Thema Domain-driven Design (DDD) aufgreifen und auf dessen Ansätze in puncto “Requirements” eingehen.

Kolumne: Req4Arcs - Scope ist nicht gleich Scope

Dr. Peter Hruschka, Dr. Gernot Starke

In der vorigen Folge haben wir Ihnen drei Zutaten vorgestellt, die Sie als Architekt(in) von anderen auf jeden Fall einfordern sollten, bevor sie mit Designentscheidungen loslegen: klare Ziele, die Kenntnis der Stakeholder und die Festlegung Ihres Scopes. Starten wir mit dem Scope.

Kolumne: Req4Arcs - Clean Start

Dr. Peter Hruschka, Dr. Gernot Starke

In der zweiten Folge unserer Kolumne stellen wir Ihnen drei Zutaten vor, die sie als Architekt(in) auf jeden Fall von anderen einfordern sollten. Wir nennen das zusammenfassend einen “Clean Start” für Ihr Projekt oder ihre Produktentwicklung.

Kolumne: Req4Arcs - Das Dilemma

Dr. Peter Hruschka, Dr. Gernot Starke

Nachdem Sie von uns über die letzten Jahre in zahlreichen Ausgaben des “Knigge für Softwarearchitekten” hoffentlich ein paar Ideen für gute Lösungsfindung bekommen haben, geht es in dieser neuen Kolumne um diverse Dilemmata. Das Dilemma diesmal: Softwarearchitekten und Entwickler leiden immer wieder unter schlechten beziehungsweise fehlenden Anforderungen für Ihre Arbeit.

Blog-Post: What's in a name: Projekt (und Produkt)

Gernot Starke

Wir verwenden den Begriff „Projekt“ in der IT leider fälschlicherweise als Stellvertreter für Produkt oder System. Dabei sollten wir, insbesondere bei iterativ-inkrementeller Entwicklung, primär auf die entstehenden Ergebnisse, also das System, achten sowie auf dessen Geschäftswert, Qualität und Nützlichkeit. Der irrige Begriff Projekt lenkt davon ab.

Evolution statt Verschlimmbesserung - mit aim42 Architektur systematisch verbessern

Dr. Gernot Starke

Erweitern, Ändern und Korrigieren bestehender Software - meistens unter Zeitdruck - führt in vielen Fällen zu schleichendem Verfall. Dadurch werden Änderungen einerseits immer schwieriger, andererseits auch immer teurer und riskanter. Das Open-Source-Projekt aim42 (architecture improvement method) setzt genau dort an - mit Praktiken und Patterns für systematische Verbesserung - technologieneutral und leichtgewichtig.

Kolumne: Knigge für Softwarearchitekten - Die API-tektin

Peter Hruschka, Dr. Gernot Starke

Unserer Einschätzung nach werden Schnittstellen oft als Dinge dritter Klasse behandelt. Technologie auswählen, Features bauen und Bugs fixen geht vor. Sogar Dokumentation schreiben scheint uns in manchen Projekten wichtiger als effektive Schnittstellen zu entwerfen. Wir wünschen Ihnen und uns die API-tektin, die gemeinsam mit Softwarearchitekten den Schnittstellen auf die Sprünge hilft.

Architektur und Objektorientierung

Dr. Gernot Starke

Programmiersprachen haben auf Architektur direkt zur wenig Einfluss - indirekt aber ganz gewaltig. Im Artikel löse ich diesen scheinbaren Widerspruch auf. Ergebnis: Aus meiner Sicht bieten polyglotte Systeme aus rein architektonischer Sicht mehr Potenzial, dafür schwächeln sie bei organisatorischen Aspekten.

Blog-Post: What's in a name: Architecture

Gernot Starke

The term architecture is used with slightly different meanings throughout the IT industry. This post clarifies what (software) architecture is all about - and which misunderstandings might linger on your way to common understanding.

Blog-Post: What's in a name: Bimodale IT

Gernot Starke

Der Ausdruck „bimodale IT“, manchmal auch „IT der zwei Geschwindigkeiten“, steht seit einiger Zeit auf der Agenda vieler IT-Manager ziemlich weit oben. Daher möchte ich hier einerseits den Begriff erklären, andererseits einige (persönliche) Einschätzungen dazu abgeben.

Blog-Post: What's in a name: Transparency

Gernot Starke

The term transparent denotes something translucent, where light can shine through. It is, for example, used in context of economics (transparent markets), meaning markets where much is known by many, and nothing is hidden. Sometimes geeks tend to inverse this meaning, saying transparency where they mean opaqueness. This post illustrates that your favorite XY-framework by no means makes XY transparent for developers.

Blog-Post: What's in a name: Consistency

Gernot Starke

The term consistency has several different meanings. This post identifies and clarifies those - especially consistency as synonym for conceptual integrity, one of the most important features for long-lasting software systems.

Gut genug? - Softwarearchitekturen bewerten

Stefan Toth, Phillip Ghadir, Dr. Gernot Starke

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.

Keilschrift reloaded - Softwarearchitektur besser dokumentieren

Stefan Zörner, Dr. Gernot Starke

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 nirgend 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.

Kolumne: Knigge für Softwarearchitekten - Entwurf von Softwarearchitekturen

Peter Hruschka, Dr. Gernot Starke

In den letzten Folgen haben wir begonnen, Sie mit dem Lehrplan des iSAQB e.V. bekannt zu machen. In dieser Ausgabe sprechen wir eine Kernaufgabe an: den Entwurf von Softwarearchitekturen. Der iSAQB-e.V.-Lehrplan räumt dieser wichtigen Aktivität großen Raum ein – weshalb wir Ihnen im Java Magazin auch eine Doppelfolge dazu gönnen.

Quality Driven Software Architecture - mit Fokus auf Qualität bessere Software schaffen

Dr. Gernot Starke

Qualität bildet die Existenzberechtigung für Softwarearchitekten: Zuverlässig, performant, skalierbar und benutzerfreundlich sollen unsere Systeme sein, das alles kosteneffektiv und zukunftssicher. Jeder IT’ler weiss, dass diese Kombination von Eigenschaften harte Arbeit bedeutet. Lesen Sie hier, wie Softwarearchitekten systematisch Qualität konstruieren können.

Architekturbewertung

The Art of Software Reviews - Probleme und Risiken zielsicher identifizieren

Dr. Gernot Starke

Auch in erfolgreichen Softwaresystemen lauern praktisch immer Probleme. Durch systematische Reviews können Teams diese Probleme zielgerichtet identifizieren - und damit eine robuste Grundlage für zukünftige Verbesserungen schaffen. Der Artikel stellt die Breitensuche als den zentralen Ansatz methodischer Software-Reviews vor und beleuchtet einige der wesentlichen Untersuchungsansätze.

Blog-Post: What's in a name: Evaluate

Gernot Starke

The term evaluation is often used in the context of system and architecture reviews. In my opinion, this term is often misleading and such activities should be named differently.

Kolumne: Knigge für Softwarearchitekten - Die Qualitätsverbesserer

Peter Hruschka, Dr. Gernot Starke

Systematische Architekturbewertung, etwa gemäß der gekannten Methode ATAM, gehört zu den Aufgaben verantwortungsbewusster Softwarearchitekten und -architektinnen. Leider sind ATAM und Co. relativ formal und aufwendig, sodass wir Ihnen eine pragmatische Alternative für den Alltageinsatz aufzeigen möchten, die wir Mikrobewertung nennen.

Gut genug? - Softwarearchitekturen bewerten

Stefan Toth, Phillip Ghadir, Dr. Gernot Starke

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.

Art

The ART-ificial Yoda Gallery

Dr. Gernot Starke

Recently, several AI (artificial intelligence) based image generation systems became popular.

This article gives a glimpse of what is currently (October 2022) possible with three major players in this league. In addition, you can learn a bit about different styles of art.

Bimodale-IT

Kolumne: Knigge für Softwarearchitekten - Bimodale IT

Peter Hruschka, Dr. Gernot Starke

Seit 2014 hören wir in IT-Diskussionen immer wieder das Stichwort “Bimodale IT”, oder auch “IT der zwei Geschwindigkeiten”. Ein wenig Englisch möchten wir Ihnen diesmal zumuten, damit Sie die volle Schönheit der Erklärung bimodaler IT direkt von den Erfindern, der Gartner Group, lesen können: “Bimodal is the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed”.

Blog-Post: What's in a name: Bimodale IT

Gernot Starke

Der Ausdruck „bimodale IT“, manchmal auch „IT der zwei Geschwindigkeiten“, steht seit einiger Zeit auf der Agenda vieler IT-Manager ziemlich weit oben. Daher möchte ich hier einerseits den Begriff erklären, andererseits einige (persönliche) Einschätzungen dazu abgeben.

Cloud

Pixie und der Sumpf

Dr. Gernot Starke

Die Cloud … das sind die Computer von jemand anderem. Die Strom benötigen, installiert und konfiguriert werden müssen. Obwohl wir Container oder VMs nach jedem Gebrauch (fachgerecht) entsorgen (sprich: löschen) – die darunter liegenden echten Computer sind ja immer noch da. Auch in Cloud-Native Zeiten solltest Du wissen, wie ein Computer überhaupt in einen betriebsfähigen Zustand und zu einem Betriebssystem kommt. Das Fachwort dafür lautet bare metal provisioning, und hat rein gar nichts mit Provisionszahlungen zu tun.

Docs-as-Code

Docs as Code: Internationalisierung von Dokumenten - i18n-light mit AsciiDoc & Co.

Dr. Gernot Starke

Die Herausforderung, in verteilten Teams an gemeinsamen Artefakten zu arbeiten, ist zwar in der Softwareentwicklung gelöst, nicht aber für Textdokumente. In vielen internationalen Open-Source-Projekten oder bei anderer ehrenamtlicher Entwicklung von Dokumenten ist die Mitarbeit der einzelnen Autorinnen und Autoren schwer planbar. Lesen Sie, wie sich binäre Bastelei an komplexen (Office-)Dokumenten vermeiden lässt!

Kolumne: Hitchhiker's Guide to Docs as Code - Websites mit Asciidoctor

Ralf D. Müller, Dr. Gernot Starke

Wir zeigen Ihnen in dieser Folge, wie Sie statische Websites mithilfe von AsciiDoc erstellen und pflegen können. Dazu greifen wir etwas tiefer in die Werkzeugkiste der Softwareentwicklung, nämlich zum Ruby-basierten Generator Jekyll. Ebenso diskutieren wir Alternativen zu Jekyll.

Kolumne: Hitchhiker's Guide to Docs as Code - PDF-Output

Ralf D. Müller, Dr. Gernot Starke

In Folge 3 unserer Kolumne hatten wir die Generierung von PDFs aus AsciiDoc bereits kurz angerissen. In dieser Folge gehen wir auf ein paar Details ein, mit denen Sie die Klippen bei der Erstellung von PDFs gezielt umschiffen können (und davon gibt es leider noch einige …).

Kolumne: Hitchhiker's Guide to Docs as Code - Build-Magie

Ralf D. Müller, Dr. Gernot Starke

“Jede hinreichend fortschrittliche Technologie ist von Magie nicht zu unterscheiden.” Dieses Zitat von Arthur C. Clarke trifft auf vieles zu, was ein modernes Build-Skript stellenweise leistet. In dierser Folge unserer Kolumne lüften wir das Geheimnis und erklären einige der nützen Gradle-Features, die Sie für Ihre Dokumentation verwenden können.

Kolumne: Hitchhiker's Guide to Docs as Code - Beautiful Code

Ralf D. Müller, Dr. Gernot Starke

Ein halbes Dutzend Folgen dieser Kolumne, bevor wir endlich zum Thema Sourcecode kommen: Wir möchten in Architekturdokumentation an manchen Stellen Code integrieren, etwa zur Beschreibung wichtiger Schnittstellen. AsciiDoc bietet hierfür schicke Features.

Kolumne: Hitchhiker's Guide to Docs as Code - Diagramme, jetzt wird modelliert

Ralf D. Müller, Dr. Gernot Starke

Wenn es um die Modellierung von Architekturen geht, also das Erstellen eines Modells mit verschiedenen Sichten anstelle von unkorrelierten Zeichnungen, dann reicht das Einbinden von statischen Diagrammen oder PlantUML nicht mehr aus. Deshalb greifen wir in dieser Folge etwas tiefer in den Werkzeugkasten und integrieren echte Modelle in unseren Docs-As-Code Ansatz.

Kolumne: Hitchhiker's Guide to Docs as Code - Des Doktors neue Kleider

Ralf D. Müller, Dr. Gernot Starke

In der letzen Ausgabe haben wir gezeigt, wie Sie Ihre AsciiDoc-Dokumente modular aufbauen können. In der dritten Folge der Kolumne erklären wir am Beispiel der Formate PDF, DOCX, Confluence und EPUB, wie sich verschiedene Ausgabeformate aus Ihrem AsciiDoc-Input erzeugen lassen.

Kolumne: Hitchhiker's Guide to Docs as Code - Modulare Dokumentationen erstellen

Ralf D. Müller, Dr. Gernot Starke

In der letzten Ausgabe haben wir gezeigt, wie Sie mithilfe von AsciiDoc schnell zu ordentlich gestalteten Dokumenten kommen können. In der zweiten Folge unserer Kolumne möchten wir Ihnen die Möglichkeiten zur Strukturierung und Modularisierung von Dokumentation vorstellen, was einerseits zur Erleichterung von Teamarbeit, andererseits zur Verwendung einzelner Doku-Teile für verschiedene Zielgruppen dient.

Kolumne: Hitchhiker's Guide to Docs as Code - Nenn' mich einfach Doktor

Ralf D. Müller, Dr. Gernot Starke

Wir kennen das alle, diese gewisse Abscheu des Entwicklungsteams in puncto Dokumentation. Der Horror von ungeeigneten Werkzeugen, fehlender Versionierung und binären Datenformaten. Wir schaffen Abhilfe. Schritt für Schritt führen wir Sie in dieser Kolumne an das Konzept Docs as Code heran, bei dem Sie Ihre technische Dokumentation genauso behandeln wie Ihren Code: Schreiben, bauen, testen, comitten, mergen. Gut, oder?

Dokumentation

Babylon as a Feature - Multi-lingual documentation, made simple

Dr. Gernot Starke

The Tower of Babylon is a myth meant to explain why the world’s peoples speak different languages. In modern IT systems, it’s often a requirement to support multiple languages. Such internationalization (i18n for short) is a tough challenge – and this post describes a simple solution to just the tiny part of multilingual documents. Our solution combines the simplicity of the plain-text format AsciiDoc with a simple yet versatile build script to support multiple languages (like EN and DE) and multiple output formats (like PDF and HTML).

1×1 guter Architekturdiagramme

Dr. Gernot Starke

Sie wollen oder müssen Architektur dokumentieren und möchten dafür grafische Darstellungen verwenden? Sie wünschen sich verständliche Diagramme, die auch zukünftig noch leicht änderbar sind? Sie möchten, dass Ihre Diagramme für unterschiedliche Zielgruppen nützlich sind? Und wenn Sie ganz ehrlich sind, wollen Sie dieses Doku-Zeugs in möglichst kurzer Zeit erledigen, damit Sie sich wieder anderen Dingen zuwenden können.

Sparsame Dokumentation

Dr. Gernot Starke

Ich weiß – Dokumentation ist nicht Ihr Lieblingsthema. Deswegen bekommen Sie hier ein paar Tipps für schmerzfreie Dokumentation. Die hier vorgestellten Ideen sparen Ihnen wertvolle Zeit, sowohl bei Erstellung als auch Pflege der Dokumentation. Sie funktionieren für jede Art von Softwaresystem, unabhängig von Werkzeugen, Technologien und Entwicklungsansätzen.

Documenting software architecture with arc42

Dr. Gernot Starke

arc42 is a template for architecture communication and documentation. It is a proven, practical and highly pragmatic approach and takes the pain out of documentation.

Docs as Code: Internationalisierung von Dokumenten - i18n-light mit AsciiDoc & Co.

Dr. Gernot Starke

Die Herausforderung, in verteilten Teams an gemeinsamen Artefakten zu arbeiten, ist zwar in der Softwareentwicklung gelöst, nicht aber für Textdokumente. In vielen internationalen Open-Source-Projekten oder bei anderer ehrenamtlicher Entwicklung von Dokumenten ist die Mitarbeit der einzelnen Autorinnen und Autoren schwer planbar. Lesen Sie, wie sich binäre Bastelei an komplexen (Office-)Dokumenten vermeiden lässt!

Kolumne: Hitchhiker's Guide to Docs as Code - Websites mit Asciidoctor

Ralf D. Müller, Dr. Gernot Starke

Wir zeigen Ihnen in dieser Folge, wie Sie statische Websites mithilfe von AsciiDoc erstellen und pflegen können. Dazu greifen wir etwas tiefer in die Werkzeugkiste der Softwareentwicklung, nämlich zum Ruby-basierten Generator Jekyll. Ebenso diskutieren wir Alternativen zu Jekyll.

Kolumne: Hitchhiker's Guide to Docs as Code - PDF-Output

Ralf D. Müller, Dr. Gernot Starke

In Folge 3 unserer Kolumne hatten wir die Generierung von PDFs aus AsciiDoc bereits kurz angerissen. In dieser Folge gehen wir auf ein paar Details ein, mit denen Sie die Klippen bei der Erstellung von PDFs gezielt umschiffen können (und davon gibt es leider noch einige …).

Kolumne: Hitchhiker's Guide to Docs as Code - Build-Magie

Ralf D. Müller, Dr. Gernot Starke

“Jede hinreichend fortschrittliche Technologie ist von Magie nicht zu unterscheiden.” Dieses Zitat von Arthur C. Clarke trifft auf vieles zu, was ein modernes Build-Skript stellenweise leistet. In dierser Folge unserer Kolumne lüften wir das Geheimnis und erklären einige der nützen Gradle-Features, die Sie für Ihre Dokumentation verwenden können.

Kolumne: Hitchhiker's Guide to Docs as Code - Beautiful Code

Ralf D. Müller, Dr. Gernot Starke

Ein halbes Dutzend Folgen dieser Kolumne, bevor wir endlich zum Thema Sourcecode kommen: Wir möchten in Architekturdokumentation an manchen Stellen Code integrieren, etwa zur Beschreibung wichtiger Schnittstellen. AsciiDoc bietet hierfür schicke Features.

Kolumne: Hitchhiker's Guide to Docs as Code - Diagramme, jetzt wird modelliert

Ralf D. Müller, Dr. Gernot Starke

Wenn es um die Modellierung von Architekturen geht, also das Erstellen eines Modells mit verschiedenen Sichten anstelle von unkorrelierten Zeichnungen, dann reicht das Einbinden von statischen Diagrammen oder PlantUML nicht mehr aus. Deshalb greifen wir in dieser Folge etwas tiefer in den Werkzeugkasten und integrieren echte Modelle in unseren Docs-As-Code Ansatz.

Kolumne: Hitchhiker's Guide to Docs as Code - Des Doktors neue Kleider

Ralf D. Müller, Dr. Gernot Starke

In der letzen Ausgabe haben wir gezeigt, wie Sie Ihre AsciiDoc-Dokumente modular aufbauen können. In der dritten Folge der Kolumne erklären wir am Beispiel der Formate PDF, DOCX, Confluence und EPUB, wie sich verschiedene Ausgabeformate aus Ihrem AsciiDoc-Input erzeugen lassen.

Kolumne: Hitchhiker's Guide to Docs as Code - Modulare Dokumentationen erstellen

Ralf D. Müller, Dr. Gernot Starke

In der letzten Ausgabe haben wir gezeigt, wie Sie mithilfe von AsciiDoc schnell zu ordentlich gestalteten Dokumenten kommen können. In der zweiten Folge unserer Kolumne möchten wir Ihnen die Möglichkeiten zur Strukturierung und Modularisierung von Dokumentation vorstellen, was einerseits zur Erleichterung von Teamarbeit, andererseits zur Verwendung einzelner Doku-Teile für verschiedene Zielgruppen dient.

Kolumne: Hitchhiker's Guide to Docs as Code - Nenn' mich einfach Doktor

Ralf D. Müller, Dr. Gernot Starke

Wir kennen das alle, diese gewisse Abscheu des Entwicklungsteams in puncto Dokumentation. Der Horror von ungeeigneten Werkzeugen, fehlender Versionierung und binären Datenformaten. Wir schaffen Abhilfe. Schritt für Schritt führen wir Sie in dieser Kolumne an das Konzept Docs as Code heran, bei dem Sie Ihre technische Dokumentation genauso behandeln wie Ihren Code: Schreiben, bauen, testen, comitten, mergen. Gut, oder?

Keilschrift reloaded - Softwarearchitektur besser dokumentieren

Stefan Zörner, Dr. Gernot Starke

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 nirgend 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.

Fehlersuche

Kolumne: Knigge für Softwarearchitekten - Der Fahnder Teil 3

Peter Hruschka, Dr. Gernot Starke

In den letzten beiden Folgen haben wir den Fahnder vorgestellt, der nach Architektur- o der Codesünden und ähnlichen Missetaten in bestehenden Systemen sucht (siehe Teil 1 „Der Fahnder“ und Teil 2 „Spuren verfolgen“). Die Fahnder suchten in den letzten Folgen nach technischen Schulden, Risiken und anderen Sünden, und zwar durch Opfer- und Zeugenvernehmung sowie Bestandsaufnahmen im Code und der Dokumentation. Sie überprüften ihre Funde durch Kreuzverhöre und schlugen für die wirklichen Sünden im Code Maßnahmen vor. Im dritten Teil diskutieren wir, wie Fahnder mit den Ergebnissen ihrer Arbeit umgehen sollten.

Kolumne: Knigge für Softwarearchitekten - Der Fahnder Teil 2: Spuren verfolgen

Peter Hruschka, Dr. Gernot Starke

In der letzten Folge haben Sie den Fahnder kennengelernt, der nach Architektur- oder Codesünden, technischen Schulden, Risiken und ähnlichen Missetaten in bestehenden Systemen sucht. Im zweiten Teil diskutieren wir, wie Fahnder mit den Ergebnissen dieser Suche weiterverfahren sollten.

Kolumne: Knigge für Softwarearchitekten - Der Fahnder Teil 1

Peter Hruschka, Dr. Gernot Starke

Willkommen zur zweiten Folge unserer Kolumne über Änderung, Evolution und Sanierung bestehender Software. Diesmal fahnden wir nach Softwareverbrechen, Codesünden oder risikoträchtigen Teilen der Software.

Kolumne: Knigge für Softwarearchitekten - Ändern als Normalfall

Peter Hruschka, Dr. Gernot Starke

Willkommen zu einer neuen Serie unserer Kolumne für Softwarearchitekten. In den bisherigen Folgen hatten wir Sie mit Verhaltensmustern und der Ausbildung von Softwarearchitekten traktiert. Nun geht’s in eine andere Richtung weiter: Wir beleuchten das Thema „Ändern bestehender Software“ aus architektonischer Sicht.

Fortbildung

Hinter den Kulissen des (neuen) Foundation-Level-Lehrplans

Dr. Gernot Starke

Es war wieder an der Zeit: Just in time erschien Anfang April 2023 das neue Release des iSAQB-Foundation-Lehrplans.

Neben den wesentlichen Unterschieden zur Vorgängerversion erklärt dieser Blogpost, wie die Arbeit in einem internationalen und dezentralen Verein funktioniert und welche Methoden und Werkzeuge wir dafür einsetzen.

Blog-Post: Setup für Hybrid-Workshops

Martina Meng, Gernot Starke

In hybriden Workshops können Menschen online und vor Ort zusammenarbeiten, sowohl in Schulungen als auch bei anderen Arten von Meetings. In diesem Post zeigen wir euch, wie ihr solche hybriden Workshops oder Trainings durchführen könnt. Ihr erfahrt, wie ihr die wesentlichen (technischen) Herausforderungen meistert, was ihr an Equipment benötigt, und wie ihr das einrichtet. Dazu gibt’s eine Menge lessons learned über kombinierte online- und vor-Ort Veranstaltungen.

Blog-Post: ISAQB Advanced Level examination anti-patterns

Gerrit Beine, Gernot Starke

As the “crowning glory” of the iSAQB(R) Advanced Certification, you have to write an approximately 40-page-long paper (AKA architectural solution) to a given problem. During our 5+ years of experience in reviewing such papers, we found several anti-patterns. This blog post aims to help future CPSA-A aspirants to avoid these nasty glitches.

Blog-Post: Setup für Online Trainings

Gernot Starke

Schauen wir mal, wie unser Fellow Gernot Starke seinen Arbeitsplatz für Online-Trainings organisiert hat und warum dort so furchtbar viele Apps und Fenster offen sind …

Zertifizierung für Fortgeschrittene - ISAQB CPSA-A (Advanced)

Phillip Ghadir, Dr. Gernot Starke

Als Softwareentwickler oder Softwarearchitekt sollten Sie sich stets auf dem Laufenden halten, um auch langfristig attraktiv für den Arbeitsmarkt zu sein. Fundierte Kenntnisse gängiger Technologien und Frameworks sind genauso wichtig wie methodische Fähigkeiten. Die Weiterbildung im Bereich Softwarearchitektur hilft Ihnen dabei, mehr Einfluss auf das Wohlergehen Ihrer Systeme nehmen zu können. Unterstützen Sie Ihren Karrierepfad als Softwarearchitekt mit dem “Certified Professional for Software Architecture”!

Kolumne: Knigge für Softwarearchitekten - Die Kommunikatorin

Peter Hruschka, Dr. Gernot Starke

In den letzten Folgen hatten wir begonnen, Sie mit dem Lehrplan des iSAQB e.V. bekannt zu machen. Eine wichtige Aufgabe auf Ihrem Weg zum produktiven Architekten ist ein solides Verständnis, wie Sie Architekturen und Architekturentscheidungen sinnvoll “weitergeben” - sowohl mündlich wie schriftlich. Der iSAQB-e.V.-Lehrplan widmet dieser Aufgabe ein eigenes Kapitel namens “Beschreibung und Kommunikation”.

Kolumne: Knigge für Softwarearchitekten - Der Zehnkämpfer

Peter Hruschka, Dr. Gernot Starke

In der letzten Folge haben wir Sie mit dem Lehrplan des iSAQB e.V. [1] bekannt gemacht. Einer der wichtigsten Punkte auf Ihrem Weg zum Zertifikat „CPSA-F“ (Certified Professional for Software Architecture, Foundation Level) ist ein solides Verständnis des Berufsbilds eines Softwarearchitekten.

Kolumne: Knigge für Softwarearchitekten - Die ständig Lernenden

Peter Hruschka, Dr. Gernot Starke

Willkommen zu einer neuen Serie unserer Kolumne rund um Verhaltensmuster von Softwarearchitekten. In den bisherigen Folgen hatten wir Sie mit guten und schlechten Verhaltensweisen traktiert. Nun geht’s in eine etwas andere Richtung weiter – die nächsten Beiträge zeigen Ihnen, wie Sie systematisch Basiswissen zum Thema Softwarearchitektur erlangen – und so die Voraussetzungen für das Zertifikat „CPSA-F“ (Certified Professional for Software Architecture, Foundation Level) des iSAQB e.V. [1] erwerben können.

Improve

The Art of Software Reviews - Probleme und Risiken zielsicher identifizieren

Dr. Gernot Starke

Auch in erfolgreichen Softwaresystemen lauern praktisch immer Probleme. Durch systematische Reviews können Teams diese Probleme zielgerichtet identifizieren - und damit eine robuste Grundlage für zukünftige Verbesserungen schaffen. Der Artikel stellt die Breitensuche als den zentralen Ansatz methodischer Software-Reviews vor und beleuchtet einige der wesentlichen Untersuchungsansätze.

Die VENOM Story: Strategische Anwendungsmodernisierung mit Split+Extract-Strategien

Dr. Gernot Starke

Sie erfahren anhand eines (komplett anonymisierten) realen Beispiels, wie die inkrementelle Modernisierung eines historisch gewachsenen Systems funktionieren kann. Das riesige, gewucherte System VENOM mit mehr als 2 Mio. Codezeilen zu modernisieren oder komplett neu zu schreiben - vor dieser schweren Entscheidung stand die (fiktive, aber sehr realitätsnahe) Firma SAMM Inc.

Evolution statt Verschlimmbesserung - mit aim42 Architektur systematisch verbessern

Dr. Gernot Starke

Erweitern, Ändern und Korrigieren bestehender Software - meistens unter Zeitdruck - führt in vielen Fällen zu schleichendem Verfall. Dadurch werden Änderungen einerseits immer schwieriger, andererseits auch immer teurer und riskanter. Das Open-Source-Projekt aim42 (architecture improvement method) setzt genau dort an - mit Praktiken und Patterns für systematische Verbesserung - technologieneutral und leichtgewichtig.

Kolumne: Knigge für Softwarearchitekten - Fortschritt oder Verschlimmbesserung?

Peter Hruschka, Dr. Gernot Starke

Ändern und erweitern unter Zeitdruck - das ist traurigerweise Normalität für viele Softwerker. Ständig zwingen und widrige Umstände under dunkle Mächte dazu, mit zu wenigen Informationen oder zu wenig Zeit neue Features oder auch notwendige Änderungen suboptimal umzusetzen. Wir mächten gerne besser arbeiten, aber zur selten geben uns die dunklen Mächte die Chance dazu. Bevor wir Ihnen die Auswege aus dieser Misere verraten, wollen wir Ihnen die beiden Dimensionen aufziegen, auf die es bei jeder Verbesserung ankommt.

Gegen die dunkle Macht - Verbessern, aber richtig!

Dr. Carola Lilienthal, Peter Hruschka, Dr. Gernot Starke

Ein ganz normaler Tag: Morgens frage ich mich, welche Katastrophe mich heute erwartet. Ich bin einiges gewohnt, aber die letzten Monate wurde es immer schlimmer: Früher gab es nur Fehler im Test oder Schwierigkeiten bei der Entwicklung. Jetzt kommen auch noch Laufzeitfehler dazu, die den Betrieb im Rechenzentrum stören und unsere Endkunden massiv irritieren. Als hätte sich die dunkle Macht gegen uns verschworen - dabei haben wir doch nur ganz normale Anforderungen. Aber sicherlich das schlechteste Softwaresystem der Welt…

Kolumne: Knigge für Softwarearchitekten - Die Systematischverbesserin

Peter Hruschka, Dr. Gernot Starke

Oftmals ist die Forderung nach Verbesserung von Software eine Folge aus zu hohen Kosten von Änderungen oder Erweiterungen – denn unsere (fachlich oder betriebswirtschaftlich motivierten) Auftraggeber interessiert die innere Qualität von Systemen oftmals nur wenig. Veränderung von Software zum Besseren hin ist daher meist ein langwieriger Prozess, den Sie systematisch und schrittweise angehen müssen.

Infrastruktur

Pixie und der Sumpf

Dr. Gernot Starke

Die Cloud … das sind die Computer von jemand anderem. Die Strom benötigen, installiert und konfiguriert werden müssen. Obwohl wir Container oder VMs nach jedem Gebrauch (fachgerecht) entsorgen (sprich: löschen) – die darunter liegenden echten Computer sind ja immer noch da. Auch in Cloud-Native Zeiten solltest Du wissen, wie ein Computer überhaupt in einen betriebsfähigen Zustand und zu einem Betriebssystem kommt. Das Fachwort dafür lautet bare metal provisioning, und hat rein gar nichts mit Provisionszahlungen zu tun.

JavaScript

Aufbau von Meteor-Apps - Gleichmacherei in JavaScript

Dr. Gernot Starke

Vollständige Webanwendungen in JavaScript - sowohl auf dem Client als auch auf dem Server. Mit diesem vollmundigen Versprechen tritt Meteor an - und hat damit von namhaften Investoren einen großen Berg Kapital eingesammelt und in kurzer Zeit eine ordentlich große Community für sich begeistert. Grund genug, dieses “Ding” mal gründlicher zu betrachten und einen Blick “unter die Haube” zu werfen, auf die Architektur von “Live-Update” und “Ultra-Responsive”.

Knigge

Kolumne: Knigge für Softwarearchitekten - Die API-tektin

Peter Hruschka, Dr. Gernot Starke

Unserer Einschätzung nach werden Schnittstellen oft als Dinge dritter Klasse behandelt. Technologie auswählen, Features bauen und Bugs fixen geht vor. Sogar Dokumentation schreiben scheint uns in manchen Projekten wichtiger als effektive Schnittstellen zu entwerfen. Wir wünschen Ihnen und uns die API-tektin, die gemeinsam mit Softwarearchitekten den Schnittstellen auf die Sprünge hilft.

Kolumne: Knigge für Softwarearchitekten - Die Qualitätsverbesserer

Peter Hruschka, Dr. Gernot Starke

Systematische Architekturbewertung, etwa gemäß der gekannten Methode ATAM, gehört zu den Aufgaben verantwortungsbewusster Softwarearchitekten und -architektinnen. Leider sind ATAM und Co. relativ formal und aufwendig, sodass wir Ihnen eine pragmatische Alternative für den Alltageinsatz aufzeigen möchten, die wir Mikrobewertung nennen.

Kolumne: Knigge für Softwarearchitekten - Fortschritt oder Verschlimmbesserung?

Peter Hruschka, Dr. Gernot Starke

Ändern und erweitern unter Zeitdruck - das ist traurigerweise Normalität für viele Softwerker. Ständig zwingen und widrige Umstände under dunkle Mächte dazu, mit zu wenigen Informationen oder zu wenig Zeit neue Features oder auch notwendige Änderungen suboptimal umzusetzen. Wir mächten gerne besser arbeiten, aber zur selten geben uns die dunklen Mächte die Chance dazu. Bevor wir Ihnen die Auswege aus dieser Misere verraten, wollen wir Ihnen die beiden Dimensionen aufziegen, auf die es bei jeder Verbesserung ankommt.

Kolumne: Knigge für Softwarearchitekten - Der Flexibilisator

Peter Hruschka, Dr. Gernot Starke

Der Flexibilisator implementiert seine Komponenten oder Systeme am liebsten so: generisch, möglichst auf viele zukünftige Gegebenheiten vorbereitet, universell einsetzbar und grezenlos flexibel in alle Richtungen. Er findet den ultimativen Kick, wenn er über den beschränkten Spezialfall der aktuellen User Story hinaus quasi ein zeitloses Denkmal der Flexibilität schaffen kann.

Kolumne: Knigge für Softwarearchitekten - Bimodale IT

Peter Hruschka, Dr. Gernot Starke

Seit 2014 hören wir in IT-Diskussionen immer wieder das Stichwort “Bimodale IT”, oder auch “IT der zwei Geschwindigkeiten”. Ein wenig Englisch möchten wir Ihnen diesmal zumuten, damit Sie die volle Schönheit der Erklärung bimodaler IT direkt von den Erfindern, der Gartner Group, lesen können: “Bimodal is the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed”.

Kolumne: Knigge für Softwarearchitekten - Die 4.0-Zukunft mitgestalten

Peter Hruschka, Dr. Gernot Starke

Remote is the new local: Waren, Menschen, Fabriken, Lieferanten, Kunden, Menschen und Bots koordinieren automatisch Entwicklung, Lieferung, Produktion, Bestellung und Abwicklung von Produkten und Dienstleistungen. Hinter dem globalen Stichwort Industrie 4.0 verbirt sich die nächste Evolutionsstufe unserer ohehin schon ziemlich elektronifiziert-vernetzten Gesellschaft: die postindustrielle Revolution. Fabriken erhalten jetzt neben der physischen Dimension eine zusätzliche, nämlich die komplette Interorganisationsvernetzung.

Kolumne: Knigge für Softwarearchitekten - Einstieg in die vierte Staffel: Software is eating the world

Peter Hruschka, Dr. Gernot Starke

Wilkommen zu einer neuen Staffel unseres “Knigge für Softwarearchitekten”. In den bisherigen Staffeln, die zwischen 2012 und 2014 im Java Magazin erschienen sind und inzwischen auch als Buch vorliegen, hatten wir Ihnen vielerlei gute und schlechte Verhaltensmuster von Softwarearchitekten vorgestellt. Nun geht’s ganz im Trend von “Industrie 4.0” innovativ weiter: Wir beleuchten allerlei neue Themen, mit denen sich unserer Ansicht nach Softwarearchitekten und -entwickler jenseits von React, Angular, Spring Boot und JShell noch beschäftigen sollten.

Kolumne: Knigge für Softwarearchitekten - Die Gegner

Peter Hruschka, Dr. Gernot Starke

Diese Folge unserer Kolumne skizziert mögliche Reaktionen, die Sie bei Reviews von Softwaresystemen erleben können. Wir beschäftigen uns mit Gegnern und verschiedenen Stufen der Ablehnung.

Kolumne: Knigge für Softwarearchitekten - Der Domäniker

Peter Hruschka, Dr. Gernot Starke

Eine der empfohlenen Entwicklungsmethodiken für Softwarearchitekturen ist Domain-driven Design. Dieses sieht vor, die Konzepte der Domäne, d. h. die Entities, die verarbeitet werden und die Services, die fachlich gebraucht werden, zuerst zu modellieren und dann möglichst unverändert eins zu eins im Sourcecode zu verankern. Das klingt einfach und fast selbstverständlich. Je stärker die Codestruktur mit der realen Welt übereinstimmt, desto leichter sind die Wartbarkeit und die Erweiterbarkeit der Software.

Kolumne: Knigge für Softwarearchitekten - Die Systematischverbesserin

Peter Hruschka, Dr. Gernot Starke

Oftmals ist die Forderung nach Verbesserung von Software eine Folge aus zu hohen Kosten von Änderungen oder Erweiterungen – denn unsere (fachlich oder betriebswirtschaftlich motivierten) Auftraggeber interessiert die innere Qualität von Systemen oftmals nur wenig. Veränderung von Software zum Besseren hin ist daher meist ein langwieriger Prozess, den Sie systematisch und schrittweise angehen müssen.

Kolumne: Knigge für Softwarearchitekten - Die Meisterin der kleinen Schritte

Peter Hruschka, Dr. Gernot Starke

Nach einigen Typen wie dem Fahnder und dem Schmutzfink, die sich mehr oder weniger professionell mit Sourcecode auseinander gesetzt haben, diskutieren wir in dieser Folge ein anderes Problem bei der Wartung existierender Systeme: Man hat Ihnen viel Code übertragen, den Sie aufrechterhalten und weiterentwickeln müssen, zu dem aber keine geeignete Dokumentation vorhanden ist. So geht es Beate, die mit Ihrem Team gerade 840 000 Zeilen C++ geerbt hat – und die nächsten Wünsche der Kunden stehen schon an.

Kolumne: Knigge für Softwarearchitekten - Der Schmutzfink

Peter Hruschka, Dr. Gernot Starke

Diese Folge unserer Kolumne handelt von Schmutzfinken, einer Spezies, die so alt ist wie das Programmieren selbst. Sie besitzen einen überaus starken Überlebenswillen und lassen sich auch durch Technologiewechsel nicht aus ihrem Konzept bringen. Im Gegenteil: Mit jeder neuen Technologie, Programmiersprache oder Framework entdecken Schmutzfinken neue und kreative Möglichkeiten, ihrer Passion zu frönen.

Kolumne: Knigge für Softwarearchitekten - Der Saubermann

Peter Hruschka, Dr. Gernot Starke

Schlechter Code stinkt, verursacht Unwohlsein, Kopfschmerzen und eine Menge anderer übler Probleme. Schlechter Code kann in ganz verschiedenen Ausprägungen daherkommen – die wir mit unterschiedlichen Maßnahmen bekämpfen oder verbessern sollten. In dieser Folge des „Knigge für Softwarearchitekten“ möchten wir Ihnen den Saubermann vorstellen, der Chaos und Unordnung von schlechtem Code beseitigt.

Kolumne: Knigge für Softwarearchitekten - Der Fahnder Teil 3

Peter Hruschka, Dr. Gernot Starke

In den letzten beiden Folgen haben wir den Fahnder vorgestellt, der nach Architektur- o der Codesünden und ähnlichen Missetaten in bestehenden Systemen sucht (siehe Teil 1 „Der Fahnder“ und Teil 2 „Spuren verfolgen“). Die Fahnder suchten in den letzten Folgen nach technischen Schulden, Risiken und anderen Sünden, und zwar durch Opfer- und Zeugenvernehmung sowie Bestandsaufnahmen im Code und der Dokumentation. Sie überprüften ihre Funde durch Kreuzverhöre und schlugen für die wirklichen Sünden im Code Maßnahmen vor. Im dritten Teil diskutieren wir, wie Fahnder mit den Ergebnissen ihrer Arbeit umgehen sollten.

Kolumne: Knigge für Softwarearchitekten - Der Fahnder Teil 2: Spuren verfolgen

Peter Hruschka, Dr. Gernot Starke

In der letzten Folge haben Sie den Fahnder kennengelernt, der nach Architektur- oder Codesünden, technischen Schulden, Risiken und ähnlichen Missetaten in bestehenden Systemen sucht. Im zweiten Teil diskutieren wir, wie Fahnder mit den Ergebnissen dieser Suche weiterverfahren sollten.

Kolumne: Knigge für Softwarearchitekten - Der Fahnder Teil 1

Peter Hruschka, Dr. Gernot Starke

Willkommen zur zweiten Folge unserer Kolumne über Änderung, Evolution und Sanierung bestehender Software. Diesmal fahnden wir nach Softwareverbrechen, Codesünden oder risikoträchtigen Teilen der Software.

Kolumne: Knigge für Softwarearchitekten - Ändern als Normalfall

Peter Hruschka, Dr. Gernot Starke

Willkommen zu einer neuen Serie unserer Kolumne für Softwarearchitekten. In den bisherigen Folgen hatten wir Sie mit Verhaltensmustern und der Ausbildung von Softwarearchitekten traktiert. Nun geht’s in eine andere Richtung weiter: Wir beleuchten das Thema „Ändern bestehender Software“ aus architektonischer Sicht.

Kolumne: Knigge für Softwarearchitekten - Entwurf von Softwarearchitekturen

Peter Hruschka, Dr. Gernot Starke

In den letzten Folgen haben wir begonnen, Sie mit dem Lehrplan des iSAQB e.V. bekannt zu machen. In dieser Ausgabe sprechen wir eine Kernaufgabe an: den Entwurf von Softwarearchitekturen. Der iSAQB-e.V.-Lehrplan räumt dieser wichtigen Aktivität großen Raum ein – weshalb wir Ihnen im Java Magazin auch eine Doppelfolge dazu gönnen.

Kolumne: Knigge für Softwarearchitekten - Die Kommunikatorin

Peter Hruschka, Dr. Gernot Starke

In den letzten Folgen hatten wir begonnen, Sie mit dem Lehrplan des iSAQB e.V. bekannt zu machen. Eine wichtige Aufgabe auf Ihrem Weg zum produktiven Architekten ist ein solides Verständnis, wie Sie Architekturen und Architekturentscheidungen sinnvoll “weitergeben” - sowohl mündlich wie schriftlich. Der iSAQB-e.V.-Lehrplan widmet dieser Aufgabe ein eigenes Kapitel namens “Beschreibung und Kommunikation”.

Kolumne: Knigge für Softwarearchitekten - Der Zehnkämpfer

Peter Hruschka, Dr. Gernot Starke

In der letzten Folge haben wir Sie mit dem Lehrplan des iSAQB e.V. [1] bekannt gemacht. Einer der wichtigsten Punkte auf Ihrem Weg zum Zertifikat „CPSA-F“ (Certified Professional for Software Architecture, Foundation Level) ist ein solides Verständnis des Berufsbilds eines Softwarearchitekten.

Kolumne: Knigge für Softwarearchitekten - Die ständig Lernenden

Peter Hruschka, Dr. Gernot Starke

Willkommen zu einer neuen Serie unserer Kolumne rund um Verhaltensmuster von Softwarearchitekten. In den bisherigen Folgen hatten wir Sie mit guten und schlechten Verhaltensweisen traktiert. Nun geht’s in eine etwas andere Richtung weiter – die nächsten Beiträge zeigen Ihnen, wie Sie systematisch Basiswissen zum Thema Softwarearchitektur erlangen – und so die Voraussetzungen für das Zertifikat „CPSA-F“ (Certified Professional for Software Architecture, Foundation Level) des iSAQB e.V. [1] erwerben können.

Kolumne: Knigge für Softwarearchitekten - Der Entscheider

Peter Hruschka, Dr. Gernot Starke

Nachdem wir in der vorigen Folge die Unsitte des Verschätzens angeprangert haben, möchten wir heute das Thema Entscheidungen angehen. Das Entwicklungsteam muss ein GUI-Framework auswählen, mit dem die Benutzeroberfläche zukünftig entwickelt werden soll. Die Manager fragen, welche Hardware sie einkaufen sollen. Die Architekten müssen bestimmen, welches Protokoll zwischen den Serverkomponenten gesprochen werden soll. Schließlich kommt die Konzernsicherheit und verlangt eine Entscheidung zum Thema Authentifizierung mit SAML oder OAuth. Fragen über Fragen, und alle liegen bei den Softwarearchitekten auf dem Tisch.

Kolumne: Knigge für Softwarearchitekten - Der Verschätzer

Peter Hruschka, Dr. Gernot Starke

Diesmal widmen wir uns dem leidigen Thema Aufwandsschätzungen. Weil es in unserer Beobachtung öfter schief als gut geht, haben wir es auch als Antipattern formuliert. Passen Sie als Architekt auf, dass Sie nicht in die Verschätzer-Falle tappen. Zu leicht lässt man sich durch „Druck von oben“ zu Zahlen hinreißen, die einem später nicht nur leid tun, sondern oft auch Ärger einbringen.

Kolumne: Knigge für Softwarearchitekten - Die Lektorin

Peter Hruschka, Dr. Gernot Starke

Nachdem wir Ihnen im letzten Teil die starke Fokussierung auf Ergebnisse (statt Prozesse!) nahe gelegt haben, möchten wir diesmal auf Details eben dieser Ergebnisse eingehen: Da Schriftsprache ja immer noch das bevorzugte Mittel langfristiger menschlicher Kommunikation und Dokumentation bildet, sollten Sie als Architekt einige Grundregeln dazu beherzigen.

Kommunikation

Kolumne: Knigge für Softwarearchitekten - Die Kommunikatorin

Peter Hruschka, Dr. Gernot Starke

In den letzten Folgen hatten wir begonnen, Sie mit dem Lehrplan des iSAQB e.V. bekannt zu machen. Eine wichtige Aufgabe auf Ihrem Weg zum produktiven Architekten ist ein solides Verständnis, wie Sie Architekturen und Architekturentscheidungen sinnvoll “weitergeben” - sowohl mündlich wie schriftlich. Der iSAQB-e.V.-Lehrplan widmet dieser Aufgabe ein eigenes Kapitel namens “Beschreibung und Kommunikation”.

Kolumne: Knigge für Softwarearchitekten - Die Lektorin

Peter Hruschka, Dr. Gernot Starke

Nachdem wir Ihnen im letzten Teil die starke Fokussierung auf Ergebnisse (statt Prozesse!) nahe gelegt haben, möchten wir diesmal auf Details eben dieser Ergebnisse eingehen: Da Schriftsprache ja immer noch das bevorzugte Mittel langfristiger menschlicher Kommunikation und Dokumentation bildet, sollten Sie als Architekt einige Grundregeln dazu beherzigen.

Legacy

Blog-Post: What's in a name: Legacy

Gernot Starke

The term “legacy” has a negative connotation in IT, and stands for an old, somehow bad piece of software. In real-life, legacy has a completely different and often positive meaning.

Meteor

Aufbau von Meteor-Apps - Gleichmacherei in JavaScript

Dr. Gernot Starke

Vollständige Webanwendungen in JavaScript - sowohl auf dem Client als auch auf dem Server. Mit diesem vollmundigen Versprechen tritt Meteor an - und hat damit von namhaften Investoren einen großen Berg Kapital eingesammelt und in kurzer Zeit eine ordentlich große Community für sich begeistert. Grund genug, dieses “Ding” mal gründlicher zu betrachten und einen Blick “unter die Haube” zu werfen, auf die Architektur von “Live-Update” und “Ultra-Responsive”.

Online-Training

Blog-Post: Setup für Hybrid-Workshops

Martina Meng, Gernot Starke

In hybriden Workshops können Menschen online und vor Ort zusammenarbeiten, sowohl in Schulungen als auch bei anderen Arten von Meetings. In diesem Post zeigen wir euch, wie ihr solche hybriden Workshops oder Trainings durchführen könnt. Ihr erfahrt, wie ihr die wesentlichen (technischen) Herausforderungen meistert, was ihr an Equipment benötigt, und wie ihr das einrichtet. Dazu gibt’s eine Menge lessons learned über kombinierte online- und vor-Ort Veranstaltungen.

Blog-Post: Setup für Online Trainings

Gernot Starke

Schauen wir mal, wie unser Fellow Gernot Starke seinen Arbeitsplatz für Online-Trainings organisiert hat und warum dort so furchtbar viele Apps und Fenster offen sind …

Persönlich

Blog-Post: How I regained concentration and focus

Dr. Gernot Starke

No sooner had I started a task the next thing I knew I was doing something else. I distracted myself by checking my email inbox every so often, and I was addicted to checking what was going on in the world on various news websites – constantly interrupting the original task. You’re perfectly right – this sounds completely insane. Somehow these bad habits had sneaked silently into my life.

News is to the mind what sugar is to the body.
Rolf Dobelli, Author, Entrepreneur

And then two lightning bolts struck almost simultaneously: a book and a blog post. I significantly changed my (digital) life as a result and within only two weeks I was able to get more done again, sleep better, and am significantly happier. The short version: news diet and productive smartphone use.

The article explains how I escaped this trap.

Smartphone neu konfiguriert

The article was also published on dev.to.

Blog-Post: Wie ich meine Konzentration wiederfand

Dr. Gernot Starke

Jahrelang habe ich mit Begeisterung Content produziert, in Form von Büchern, Artikeln, Blogposts, Vorträgen – im Durchschnitt anderthalb Buchauflagen und fünf Artikel pro Jahr. Seit ca. 2020 ist meine Produktivität krass gesunken – was mich total frustriert hat. Äußere Ursachen gab’s keine – also keine Ausreden. Um aus der Misere einen Ausweg zu finden, habe ich mal meine eigene Arbeitsweise auf den Prüfstand gestellt – und einen massiven Verlust an Konzentrationsfähigkeit diagnostiziert.

Kaum hatte ich eine Aufgabe angefangen, habe ich nach kurzer Zeit schon wieder etwas anderes dazwischengeschoben – oder mich mit Mails oder diversen News-Websites abgelenkt.

Und dann sind zwei Blitze nahezu gleichzeitig eingeschlagen: Ein Buch und ein Blogpost: Ich habe daraufhin mein (digitales) Leben deutlich umgestellt: Resultat innerhalb von nur zwei Wochen: Ich schaffe wieder mehr, schlafe besser und bin signifikant zufriedener. Die Kurzfassung: News-Diät und produktive Smartphone-Nutzung.

Im Artikel erkläre ich, wie ich dieser Konzentrationsfalle entwichen bin…

Smartphone neu konfiguriert

Produktivität

Blog-Post: How I regained concentration and focus

Dr. Gernot Starke

No sooner had I started a task the next thing I knew I was doing something else. I distracted myself by checking my email inbox every so often, and I was addicted to checking what was going on in the world on various news websites – constantly interrupting the original task. You’re perfectly right – this sounds completely insane. Somehow these bad habits had sneaked silently into my life.

News is to the mind what sugar is to the body.
Rolf Dobelli, Author, Entrepreneur

And then two lightning bolts struck almost simultaneously: a book and a blog post. I significantly changed my (digital) life as a result and within only two weeks I was able to get more done again, sleep better, and am significantly happier. The short version: news diet and productive smartphone use.

The article explains how I escaped this trap.

Smartphone neu konfiguriert

The article was also published on dev.to.

Blog-Post: Wie ich meine Konzentration wiederfand

Dr. Gernot Starke

Jahrelang habe ich mit Begeisterung Content produziert, in Form von Büchern, Artikeln, Blogposts, Vorträgen – im Durchschnitt anderthalb Buchauflagen und fünf Artikel pro Jahr. Seit ca. 2020 ist meine Produktivität krass gesunken – was mich total frustriert hat. Äußere Ursachen gab’s keine – also keine Ausreden. Um aus der Misere einen Ausweg zu finden, habe ich mal meine eigene Arbeitsweise auf den Prüfstand gestellt – und einen massiven Verlust an Konzentrationsfähigkeit diagnostiziert.

Kaum hatte ich eine Aufgabe angefangen, habe ich nach kurzer Zeit schon wieder etwas anderes dazwischengeschoben – oder mich mit Mails oder diversen News-Websites abgelenkt.

Und dann sind zwei Blitze nahezu gleichzeitig eingeschlagen: Ein Buch und ein Blogpost: Ich habe daraufhin mein (digitales) Leben deutlich umgestellt: Resultat innerhalb von nur zwei Wochen: Ich schaffe wieder mehr, schlafe besser und bin signifikant zufriedener. Die Kurzfassung: News-Diät und produktive Smartphone-Nutzung.

Im Artikel erkläre ich, wie ich dieser Konzentrationsfalle entwichen bin…

Smartphone neu konfiguriert

Qualität

Shortcomings of ISO 25010

Dr. Gernot Starke

Published in 2011, the ISO 25010 standard on software product quality lacks pragmatism and practical applicability. Terms like scalability, deployability, energy efficiency, safety, or code quality are missing. This article explains these shortcomings and shows that even the (draft) update from 2022 still needs polishing…

Read more about the arc42 Quality Model on quality.arc42.org.

Kolumne: QDSA - Herausforderung mit Qualität

Dr. Gernot Starke

Quality-driven Software Architecture stellt einen praxisorientierten Ansatz dar, um die wesentlichen Qualitätseigenschaften zielsicher zu erreichen. Mit bewährten Ansätzen wie Domain-driven Design bekommen wir die Fachlichkeit von Systemen gut strukturiert, aber Performance, Robustheit, Flexibilität, Sicherheit und andere wichtige Eigenschaften bleiben dabei außen vor. Qualität gehört dabei zu den zentralen Themen von Entwicklungsteams.

Kolumne: QDSA - Fast Food oder Gourmetteller

Dr. Gernot Starke

Nachdem wir in der ersten Folge ein paar Herausforderungen beim Begriff „Qualität“ kennengelernt haben, greifen wir in dieser Folge mal eine (brand-)aktuelle Entwicklung auf, nämlich die (geplante) neue Version des aktuellen ISO-Standards 25010. Im Jahre 2011, also vor einer IT-Ewigkeit, veröffentlichte die Standardisierungsorganisation ISO den 25010er-Standard zur Softwareproduktqualität, der seither als weitverbreitet bei Softwarequalitätsmodellen gilt [1]. Aber ist diese weite Verbreitung überhaupt gerechtfertigt? In dieser Folge prüfen wir diesen Standard mal auf seine Praxistauglichkeit.

Eine kleine Geschichte über Qualität

Dr. Gernot Starke

Du denkst Dir nichts Böses, da bittet Dich Tante Lucy um einen kleinen Gefallen… und Du musst Dich entscheiden, wie Du das angehen sollst. Aber als Belohnung winkt ihr leckerer Erdbeerkuchen, außerdem sind wir doch alle Herausforderungen gewöhnt, oder?

Ähnlichkeiten zu konkreten IT-Systemen und Softwareprojekten wären zufällig, Analogien zu unserer Branche jedoch beabsichtigt

Quality Driven Software Architecture - Revised

Gernot Starke

Quality is the raison d’être for software architects: Our systems should be reliable, performant, scalable and user-friendly. Systems should be build and maintained cost-effective and future-proof. Every IT professional knows that this combination of characteristics means hard work. The article shows how you can methodically construct quality. This is the revised and updated version of the article “Quality Driven Software Architecture” first published in 2012 (only available in German).

Blog-Post: What's in a name: Quality

Gernot Starke

Das Wort Qualität verwenden wir umgangssprachlich für etwas “Gutes” – aber wir lassen meist offen, was wir darunter genau verstehen. Der Artikel zeigt, dass wir uns in dieser Hinsicht etwas exakter ausdrücken sollten.

Kolumne: Req4Arcs - Qualitätsanforderungen konkret formulieren

Dr. Peter Hruschka, Dr. Gernot Starke

In der letzen Folge hatten wir das Thema “Qualität” top-down erklärt und Ihnen dazu das generische Qualitätsmodell ISO 25010 vorgestellt. Das komplette Modell umfasst insgesamt 45 Eigenschaften. Das ergibt eine ziemlich breite Themenvielfalt rund um “Qualität”, ist aber als Grundlage für konkrete Entscheidungen viel zu abstrakt. Wir benötigen mehr Details, wir müssen genauer wissen und beschreiben, was Stakeholder denn nun wirklich von unseren Systemen erwarten oder benötigen.

Kolumne: Req4Arcs - Qualität fällt nicht vom Himmel

Dr. Peter Hruschka, Dr. Gernot Starke

In den vergangegen drei Folgen haben Sie erfahren, wie Sie systematisch mit funktionalen Anforderungen umgehen können. In den nächsten Folgen wenden wir uns den Qualitätsanforderungen IT-Sicherheit, Performance und Zuverlässigkeit zu.

Kolumne: Knigge für Softwarearchitekten - Die Qualitätsverbesserer

Peter Hruschka, Dr. Gernot Starke

Systematische Architekturbewertung, etwa gemäß der gekannten Methode ATAM, gehört zu den Aufgaben verantwortungsbewusster Softwarearchitekten und -architektinnen. Leider sind ATAM und Co. relativ formal und aufwendig, sodass wir Ihnen eine pragmatische Alternative für den Alltageinsatz aufzeigen möchten, die wir Mikrobewertung nennen.

Quality Driven Software Architecture - mit Fokus auf Qualität bessere Software schaffen

Dr. Gernot Starke

Qualität bildet die Existenzberechtigung für Softwarearchitekten: Zuverlässig, performant, skalierbar und benutzerfreundlich sollen unsere Systeme sein, das alles kosteneffektiv und zukunftssicher. Jeder IT’ler weiss, dass diese Kombination von Eigenschaften harte Arbeit bedeutet. Lesen Sie hier, wie Softwarearchitekten systematisch Qualität konstruieren können.

Req4Arcs

Kolumne: Req4Arcs - Miteinander statt gegeneinander

Dr. Peter Hruschka, Dr. Gernot Starke

Nach vielen inhaltlichen Folgen zum Umgang mit Requirements greifen wir diesmal ein ganz anderes Thema auf: Wie sollten Architekt(inn)en mit Requirements-Spezialisten zusammenarbeiten?

Kolumne: Req4Arcs - Ausführbare Spezifikationen (und eine Portion BDD)

Dr. Peter Hruschka, Dr. Gernot Starke

In einer der letzten Folgen haben wir bereits über beispielhafte Spezifikationen geschrieben. Diesmal möchten wir konrekter auf die Möglichkeit der Ausführbarkeit solcher Spezifikationen eingehen. Dazu werden wir einen Ausflug in die großartigen Möglichkeiten von Behavior-driven Development unternehmen.

Kolumne: Req4Arcs - Qualitätsanforderungen konkret formulieren

Dr. Peter Hruschka, Dr. Gernot Starke

In der letzen Folge hatten wir das Thema “Qualität” top-down erklärt und Ihnen dazu das generische Qualitätsmodell ISO 25010 vorgestellt. Das komplette Modell umfasst insgesamt 45 Eigenschaften. Das ergibt eine ziemlich breite Themenvielfalt rund um “Qualität”, ist aber als Grundlage für konkrete Entscheidungen viel zu abstrakt. Wir benötigen mehr Details, wir müssen genauer wissen und beschreiben, was Stakeholder denn nun wirklich von unseren Systemen erwarten oder benötigen.

Kolumne: Req4Arcs - Qualität fällt nicht vom Himmel

Dr. Peter Hruschka, Dr. Gernot Starke

In den vergangegen drei Folgen haben Sie erfahren, wie Sie systematisch mit funktionalen Anforderungen umgehen können. In den nächsten Folgen wenden wir uns den Qualitätsanforderungen IT-Sicherheit, Performance und Zuverlässigkeit zu.

Kolumne: Req4Arcs - Gute Beispiele statt schlechter Abstraktionen

Dr. Peter Hruschka, Dr. Gernot Starke

In den letzten Folgen haben wir Ihnen Optionen für die Darstellung und Klärung funktionaler Anforderungen aufgezeigt. Nun stellen wir Ihnen noch eine dritte Perspektive für funktionale Anforderungen vor, nämlich Beispiele.

Kolumne: Req4Arcs - Anforderungen mit DDD klären

Dr. Peter Hruschka, Dr. Gernot Starke

In der letzten Folge haben Sie gesehen, wie wir Überblick über die wesentlichen funktionalen Anforderungen bekommen können - nämlich indem wir von groben Zielen ausgehend die Granularität von Anforderungen verfeinern und dabei Geschäftsprozesse und Ende-Zu-Ende-Abläufe (Use Cases oder User Stories) untersuchen. In dieser Folge möchten wir das Thema Domain-driven Design (DDD) aufgreifen und auf dessen Ansätze in puncto “Requirements” eingehen.

Kolumne: Req4Arcs - Scope ist nicht gleich Scope

Dr. Peter Hruschka, Dr. Gernot Starke

In der vorigen Folge haben wir Ihnen drei Zutaten vorgestellt, die Sie als Architekt(in) von anderen auf jeden Fall einfordern sollten, bevor sie mit Designentscheidungen loslegen: klare Ziele, die Kenntnis der Stakeholder und die Festlegung Ihres Scopes. Starten wir mit dem Scope.

Kolumne: Req4Arcs - Clean Start

Dr. Peter Hruschka, Dr. Gernot Starke

In der zweiten Folge unserer Kolumne stellen wir Ihnen drei Zutaten vor, die sie als Architekt(in) auf jeden Fall von anderen einfordern sollten. Wir nennen das zusammenfassend einen “Clean Start” für Ihr Projekt oder ihre Produktentwicklung.

Kolumne: Req4Arcs - Das Dilemma

Dr. Peter Hruschka, Dr. Gernot Starke

Nachdem Sie von uns über die letzten Jahre in zahlreichen Ausgaben des “Knigge für Softwarearchitekten” hoffentlich ein paar Ideen für gute Lösungsfindung bekommen haben, geht es in dieser neuen Kolumne um diverse Dilemmata. Das Dilemma diesmal: Softwarearchitekten und Entwickler leiden immer wieder unter schlechten beziehungsweise fehlenden Anforderungen für Ihre Arbeit.

Requirements

Im Stich gelassen - systematisch zu besseren Anforderungen

Dr. Peter Hruschka, Dr. Gernot Starke

Sie fühlen sich als Architekt:innen und Designer:innen von Ihren Requirements Engineers, Product Owners oder Produktmanager:innen alleine gelassen, was klare Anforderungen angeht? Sie leiden unter vagen, unklaren oder fehlenden Anforderungen ohne konsistente Prioritäten? Sie werden für falsche Architekturentscheidungen kritisiert, obwohl Sie sie nach bestem Wissen und Gewissen (leider aber ohne Kenntnis der wahren Anforderungen) getroffen haben? Willkommen im Club der „Im-Stich-Gelassenen“.

Kolumne: Req4Arcs - Miteinander statt gegeneinander

Dr. Peter Hruschka, Dr. Gernot Starke

Nach vielen inhaltlichen Folgen zum Umgang mit Requirements greifen wir diesmal ein ganz anderes Thema auf: Wie sollten Architekt(inn)en mit Requirements-Spezialisten zusammenarbeiten?

Kolumne: Req4Arcs - Ausführbare Spezifikationen (und eine Portion BDD)

Dr. Peter Hruschka, Dr. Gernot Starke

In einer der letzten Folgen haben wir bereits über beispielhafte Spezifikationen geschrieben. Diesmal möchten wir konrekter auf die Möglichkeit der Ausführbarkeit solcher Spezifikationen eingehen. Dazu werden wir einen Ausflug in die großartigen Möglichkeiten von Behavior-driven Development unternehmen.

Kolumne: Req4Arcs - Qualitätsanforderungen konkret formulieren

Dr. Peter Hruschka, Dr. Gernot Starke

In der letzen Folge hatten wir das Thema “Qualität” top-down erklärt und Ihnen dazu das generische Qualitätsmodell ISO 25010 vorgestellt. Das komplette Modell umfasst insgesamt 45 Eigenschaften. Das ergibt eine ziemlich breite Themenvielfalt rund um “Qualität”, ist aber als Grundlage für konkrete Entscheidungen viel zu abstrakt. Wir benötigen mehr Details, wir müssen genauer wissen und beschreiben, was Stakeholder denn nun wirklich von unseren Systemen erwarten oder benötigen.

Kolumne: Req4Arcs - Qualität fällt nicht vom Himmel

Dr. Peter Hruschka, Dr. Gernot Starke

In den vergangegen drei Folgen haben Sie erfahren, wie Sie systematisch mit funktionalen Anforderungen umgehen können. In den nächsten Folgen wenden wir uns den Qualitätsanforderungen IT-Sicherheit, Performance und Zuverlässigkeit zu.

Kolumne: Req4Arcs - Gute Beispiele statt schlechter Abstraktionen

Dr. Peter Hruschka, Dr. Gernot Starke

In den letzten Folgen haben wir Ihnen Optionen für die Darstellung und Klärung funktionaler Anforderungen aufgezeigt. Nun stellen wir Ihnen noch eine dritte Perspektive für funktionale Anforderungen vor, nämlich Beispiele.

Kolumne: Req4Arcs - Anforderungen mit DDD klären

Dr. Peter Hruschka, Dr. Gernot Starke

In der letzten Folge haben Sie gesehen, wie wir Überblick über die wesentlichen funktionalen Anforderungen bekommen können - nämlich indem wir von groben Zielen ausgehend die Granularität von Anforderungen verfeinern und dabei Geschäftsprozesse und Ende-Zu-Ende-Abläufe (Use Cases oder User Stories) untersuchen. In dieser Folge möchten wir das Thema Domain-driven Design (DDD) aufgreifen und auf dessen Ansätze in puncto “Requirements” eingehen.

Kolumne: Req4Arcs - Scope ist nicht gleich Scope

Dr. Peter Hruschka, Dr. Gernot Starke

In der vorigen Folge haben wir Ihnen drei Zutaten vorgestellt, die Sie als Architekt(in) von anderen auf jeden Fall einfordern sollten, bevor sie mit Designentscheidungen loslegen: klare Ziele, die Kenntnis der Stakeholder und die Festlegung Ihres Scopes. Starten wir mit dem Scope.

Kolumne: Req4Arcs - Clean Start

Dr. Peter Hruschka, Dr. Gernot Starke

In der zweiten Folge unserer Kolumne stellen wir Ihnen drei Zutaten vor, die sie als Architekt(in) auf jeden Fall von anderen einfordern sollten. Wir nennen das zusammenfassend einen “Clean Start” für Ihr Projekt oder ihre Produktentwicklung.

Kolumne: Req4Arcs - Das Dilemma

Dr. Peter Hruschka, Dr. Gernot Starke

Nachdem Sie von uns über die letzten Jahre in zahlreichen Ausgaben des “Knigge für Softwarearchitekten” hoffentlich ein paar Ideen für gute Lösungsfindung bekommen haben, geht es in dieser neuen Kolumne um diverse Dilemmata. Das Dilemma diesmal: Softwarearchitekten und Entwickler leiden immer wieder unter schlechten beziehungsweise fehlenden Anforderungen für Ihre Arbeit.

Review

Software-Reviews: Systematisch Probleme und Risiken in IT-Systemen finden

Dr. Gernot Starke

Egal, wie erfolgreich oder bewährt Ihre IT-Systeme sind, aufgrund ihrer Größe und Komplexität enthalten sie mit großer Wahrscheinlichkeit einiges an Verbesserungspotenzial. Durch systematische Reviews können Sie (respektive Ihr Entwicklungsteam) dieses Potenzial identifizieren, und dadurch die perfekte Grundlage für systematische Verbesserung schaffen.

Shell

Speed up your video

Dr. Gernot Starke

Sometimes you need to speed up a video. In this short post I describe how to use the free ffmpeg command line tool to change the duration of videos.

The slow video (original)

The fast video

Tools

Speed up your video

Dr. Gernot Starke

Sometimes you need to speed up a video. In this short post I describe how to use the free ffmpeg command line tool to change the duration of videos.

The slow video (original)

The fast video

Merge PDF files with QPDF

Dr. Gernot Starke

You want to merge (concatenate) several PDF files. It is not possible to just append one PDF after the other, let’s say by command-line append operations.

Other simple PDF utilities fail in preserving internal hyperlinks (cross references).

I needed a programatic solution that works completely automated (controlled via make) within a Docker container.

Venom

Die VENOM Story: Strategische Anwendungsmodernisierung mit Split+Extract-Strategien

Dr. Gernot Starke

Sie erfahren anhand eines (komplett anonymisierten) realen Beispiels, wie die inkrementelle Modernisierung eines historisch gewachsenen Systems funktionieren kann. Das riesige, gewucherte System VENOM mit mehr als 2 Mio. Codezeilen zu modernisieren oder komplett neu zu schreiben - vor dieser schweren Entscheidung stand die (fiktive, aber sehr realitätsnahe) Firma SAMM Inc.

Video

Speed up your video

Dr. Gernot Starke

Sometimes you need to speed up a video. In this short post I describe how to use the free ffmpeg command line tool to change the duration of videos.

The slow video (original)

The fast video

Vms

Enable ssh access to multipass vms

Gernot Starke

The problem: You are using multipass to create lightweight virtual (Ubuntu) machines. You want to ssh into those machines, because you cannot or don’t want to use the standard shell command multipass shell < name-of-vm >.

The naive approach fails with permission denied - Permission denied, although there is a route to this virtual machine available…

Yoda

The ART-ificial Yoda Gallery

Dr. Gernot Starke

Recently, several AI (artificial intelligence) based image generation systems became popular.

This article gives a glimpse of what is currently (October 2022) possible with three major players in this league. In addition, you can learn a bit about different styles of art.

aim42

The Art of Software Reviews - Probleme und Risiken zielsicher identifizieren

Dr. Gernot Starke

Auch in erfolgreichen Softwaresystemen lauern praktisch immer Probleme. Durch systematische Reviews können Teams diese Probleme zielgerichtet identifizieren - und damit eine robuste Grundlage für zukünftige Verbesserungen schaffen. Der Artikel stellt die Breitensuche als den zentralen Ansatz methodischer Software-Reviews vor und beleuchtet einige der wesentlichen Untersuchungsansätze.

Die VENOM Story: Strategische Anwendungsmodernisierung mit Split+Extract-Strategien

Dr. Gernot Starke

Sie erfahren anhand eines (komplett anonymisierten) realen Beispiels, wie die inkrementelle Modernisierung eines historisch gewachsenen Systems funktionieren kann. Das riesige, gewucherte System VENOM mit mehr als 2 Mio. Codezeilen zu modernisieren oder komplett neu zu schreiben - vor dieser schweren Entscheidung stand die (fiktive, aber sehr realitätsnahe) Firma SAMM Inc.

Evolution statt Verschlimmbesserung - mit aim42 Architektur systematisch verbessern

Dr. Gernot Starke

Erweitern, Ändern und Korrigieren bestehender Software - meistens unter Zeitdruck - führt in vielen Fällen zu schleichendem Verfall. Dadurch werden Änderungen einerseits immer schwieriger, andererseits auch immer teurer und riskanter. Das Open-Source-Projekt aim42 (architecture improvement method) setzt genau dort an - mit Praktiken und Patterns für systematische Verbesserung - technologieneutral und leichtgewichtig.

Kolumne: Knigge für Softwarearchitekten - Fortschritt oder Verschlimmbesserung?

Peter Hruschka, Dr. Gernot Starke

Ändern und erweitern unter Zeitdruck - das ist traurigerweise Normalität für viele Softwerker. Ständig zwingen und widrige Umstände under dunkle Mächte dazu, mit zu wenigen Informationen oder zu wenig Zeit neue Features oder auch notwendige Änderungen suboptimal umzusetzen. Wir mächten gerne besser arbeiten, aber zur selten geben uns die dunklen Mächte die Chance dazu. Bevor wir Ihnen die Auswege aus dieser Misere verraten, wollen wir Ihnen die beiden Dimensionen aufziegen, auf die es bei jeder Verbesserung ankommt.

Gegen die dunkle Macht - Verbessern, aber richtig!

Dr. Carola Lilienthal, Peter Hruschka, Dr. Gernot Starke

Ein ganz normaler Tag: Morgens frage ich mich, welche Katastrophe mich heute erwartet. Ich bin einiges gewohnt, aber die letzten Monate wurde es immer schlimmer: Früher gab es nur Fehler im Test oder Schwierigkeiten bei der Entwicklung. Jetzt kommen auch noch Laufzeitfehler dazu, die den Betrieb im Rechenzentrum stören und unsere Endkunden massiv irritieren. Als hätte sich die dunkle Macht gegen uns verschworen - dabei haben wir doch nur ganz normale Anforderungen. Aber sicherlich das schlechteste Softwaresystem der Welt…

Software systematisch verbessern - Evolution, Änderung und Wartung, aber richtig!

Dr. Gernot Starke

Die Informatik-Ausbildung fokussiert auf die Neuentwicklung von Software – den Alltag vieler Softwerker prägen jedoch meist Pflege, Änderung oder Erweiterung von Systemen. In diesem Artikel stelle ich Ihnen aim42 vor, ein systematisches Vorgehen zur Verbesserung von Software. aim42 ist frei verfügbar und kondensiert Praktiken und Patterns rund um Evolution, Änderung und Wartung von IT-Systemen.

arc42

Sparsame Dokumentation

Dr. Gernot Starke

Ich weiß – Dokumentation ist nicht Ihr Lieblingsthema. Deswegen bekommen Sie hier ein paar Tipps für schmerzfreie Dokumentation. Die hier vorgestellten Ideen sparen Ihnen wertvolle Zeit, sowohl bei Erstellung als auch Pflege der Dokumentation. Sie funktionieren für jede Art von Softwaresystem, unabhängig von Werkzeugen, Technologien und Entwicklungsansätzen.

Documenting software architecture with arc42

Dr. Gernot Starke

arc42 is a template for architecture communication and documentation. It is a proven, practical and highly pragmatic approach and takes the pain out of documentation.

Die Antwort auf alle Fragen: arc42 - die Siebte

Dr. Gernot Starke

Hier finden Sie einen Überblick über alle relevanten Änderungen von arc42, Version 7 - der aktuellen Version des bekannten Templates zur Dokumentation und Kommunikation von Softwarearchitekturen. In Kürze: arc42 V7, erschienen im Januar 2017, bleibt kompatibel zu der Vorversion 6.1. Insgesamt ist arc42 noch kompakter, pragmatischer und konsistener geworden.

Blog-Post: Arc42 - die Siebte

Gernot Starke

Das bewährte arc42 Template ist gerade in Version 7 erschienen - mit deutlichen Erweiterungen im Ökosystem. Grundsätzlich bleibt arc42 V7 kompatibel mit den Vorgängerversionen, ist insgesamt noch kompakter und pragmatischer geworden.

Keilschrift reloaded - Softwarearchitektur besser dokumentieren

Stefan Zörner, Dr. Gernot Starke

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 nirgend 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.