2020

2020-05

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.

2019

2019-11

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?

2019-10

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.

2019-09

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.

2019-08

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.

2019-07

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.

2019-06

Legacy ist keine Krankheit - Vermächtnis in kleinen Schritten kontinuierlich fortentwickeln

Dr. Gernot Starke

Was ist dieses “Legacy” überhaupt, warum ist es vermutlich ziemlich gut (obwohl das Entwicklungsteam anders denkt), und warum müssen wir uns drum kümmern? Und was hat das mit Leonardo da Vinci und Mozart zu tun?

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.

2019-05

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: Req4Arcs - Vom Umgang mit funktionalen Anforderungen

Dr. Peter Hruschka, Dr. Gernot Starke

Der saubere Start hat geklappt. Wir haben uns auf Ziele, Stakeholder und Scope geeinigt. Jetzt wollen wir die Anforderungen verstehen und klären - und zwar sowohl die funktionalen Anforderungen als auch Qualitätsanforderungen und Randbedingungen. Die letzteren beiden stellen wir noch etwas zurück und konzentrieren uns in den nächsten Folgen auf die funktionalen Anforderungen.

2019-04

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.

2019-03

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.

2019-02

Kolumne: Req4Arcs - Das Dilemma

Dr. Peter Hruschka, Dr. Gernot Starke

Nachdem Sie von uns über die letzen 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 dieverse Dilemmata. Das Dilemma diesmal: Softwarearchitekten und Entwickler leiden immer wieder unter schlechten beziehungsweise fehlenden Anforderungen für Ihre Arbeit.

2018

2018-08

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.

2018-07

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 …).

2018-06

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.

2018-04

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.

2018-03

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.

2017

2017-12

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.

2017-11

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.

2017-10

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 Konhzept Docs as Code heran, bei dem Sie Ihre technische Dokumentation genauso behandeln wie Ihren Code: Schreiben, bauen, testen, comitten, mergen. Gut, oder?

2017-06

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.

2017-04

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.

2017-03

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.

2017-02

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.

2017-01

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.

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.

2016

2016-12

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.

2016-11

Kolumne: Knigge für Softwarearchitekten - Schlechte Requirements? Handeln statt Jammern!

Peter Hruschka, Dr. Gernot Starke

Immer wieder jammern Kunden, dass Systeme schlecht seien und die IT die Anforderungen überhaupt nicht erfüllt habe. Entwicklungsteams verteidigen sich damit, dass ihnen niemand egsagt hat, was das Produkt wirklich könen soll. Sie schieben die Schuld auf schlechte Anforderungen.

2016-10

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

2016-08

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.

2016-07

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.

2015

2015-04

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: Frpher 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…

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 betrachtenund einen Blick “unter die Haube” zu werfen, auf die Architektur von “Live-Update” und “Ultra-Responsive”.

2015-03

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.

2014

2014-12

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.

2014-09

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

2014-08

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.

2014-07

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.

2014-06

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.

2014-05

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.

2014-04

Kolumne: Knigge für Softwarearchitekten - Der Kammerjäger

Peter Hruschka, Dr. Gernot Starke

Zum Umbauen und Ändern von Software gehört nach unserer Erfahrung auch die Suche nach Fehlern – daher erwarten Sie diesmal Tipps zum zielgerichteten Debuggen.

2014-03

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.

2014-02

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.

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.

2014-01

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.

2013

2013-12

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.

2013-11

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.

2012

2012-11

Kolumne: Knigge für Softwarearchitekten - Reise durch Toolistan

Peter Hruschka, Dr. Gernot Starke

Architekten kommen nicht nur mit Papier und Bleistift aus. Deshalb gehört das Thema “Werkzeuge” ausdrücklich zum Lehrplan des iSAQB e.V.

Kolumne: Knigge für Softwarearchitekten - Antimuster: Der Prozessprediger

Peter Hruschka, Dr. Gernot Starke

Willkommen in der fünfzehnten Ausgabe unserer Kolumne rund um Verhaltensmuster von Softwarearchitekten.

2012-10

Kolumne: Knigge für Softwarearchitekten - Qualität

Peter Hruschka, Dr. Gernot Starke

Im Lehrplan des iSAQB e.V. besitzt Qualität einen hohen Stellenwert – der Lehrplan widmet ihr ein eigenes Kapitel. Grund genug, Ihnen das Thema näher zu bringen.

2012-09

Kolumne: Knigge für Softwarearchitekten - Entwurf von Softwarearchitekturen (Teil 2)

Peter Hruschka, Dr. Gernot Starke

In der letzten Folge haben wir Ihnen aus dem Lehrplan des iSAQB e.V. [1] den Entwurf von Softwarearchitekturen vorgestellt. Der iSAQB-e.V.-Lehrplan räumt dieser wichtigen Aktivität großen Raum ein – weshalb wir dieses Thema in unserer Kolumne erneut aufgreifen.

2012-08

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.

2012-07

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

2012-06

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.

2012-05

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.

2012-04

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.

2012-03

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.

2012-02

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.

2012-01

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.