Peter Hruschka

Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Beiträge dieses Autors

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

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 grenzenlos 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 erschaffen kann. Kennen Sie das auch, diesen Drang nach Verallgemeinerung, den tiefen Wunsch, etwas Großes zu schaffen? Wir möchten in dieser Folge zuerst etwas über mögliche Arten der Flexibilität von Software klarstellen, auf einige Vor- und Nachteile davon eingehen und anschließend kräftiges Bashing auf Flexibilisatoren betreiben.

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. Hätte man diese Wünsche rechtzeitig und klar geäußert, dann wäre die Lösung auch skalierbar, erweiterbar, performant und sicher. Fachbereiche oder Marketingabteilungen kontern: Es war doch klar, dass wir nach dem europäischen auch den asiatischen Markt erobern wollen. Selbstverständlich muss das Produkt leicht an neue Gesetze, Standards und Normen adaptiert werden können. Warum hätten wir das explizit sagen sollen?

Knigge für Softwarearchitekten: Wider die IT der zwei Geschwindigkeiten

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

Knigge für Softwarearchitekten: Wie Sie die Industrie-4.0-Zukunft mitgestalten

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

Knigge für Softwarearchitekten: Software is eating the World

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

Embedded Systems – die andere Welt

Wenn Sie wieder einmal böse sind, dass Ihre Textverarbeitung crasht, denken Sie einmal daran, dass das harmlos ist im Vergleich zu einem Ausfall des Avionic-Systems von Flugzeugen, dem Airbag Ihres Autos, einem Herzschrittmacher oder dem Regelsystem zur Produktionsüberwachung bei der Herstellung hochgiftiger Chemikalien.

Gegen die dunkle Macht: Software verbessern – aber richtig!

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 …

Knigge für Softwarearchitekten: Der Domäniker

Eine der empfohlenen Entwicklungsmethodiken für Softwarearchitekturen ist Domain-driven Design (Literatur dazu siehe hier, hier und hier). 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.

Die Systematischverbesserin [Knigge für Softwarearchitekten]

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.

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.

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.

Knigge für Softwarearchitekten: Fahndungsergebnisse

In den letzten beiden Folgen haben wir den Fahnder vorgestellt, der nach Architektur- oder 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.