2017-04

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

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

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

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

Ä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-12

Kolumne: Knigge für Softwarearchitekten - Der Flexibilisator

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!

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 gesagt hat, was das Produkt wirklich können soll. Sie schieben die Schuld auf schlechte Anforderungen.

2016-10

Kolumne: Knigge für Softwarearchitekten - Bimodale IT

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

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

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.

2014-09

Kolumne: Knigge für Softwarearchitekten - Die Gegner

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

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

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

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

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

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

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

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.

2014-01

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

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

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

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

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

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

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

2012-11

Kolumne: Knigge für Softwarearchitekten - Reise durch Toolistan

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

2012-10

Kolumne: Knigge für Softwarearchitekten - Qualität

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)

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

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

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

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

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

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

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

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.