Hendrik Lösch
Sustainability in Software, Software Evolution, Software Architecture, Resource Efficency, Quality Assurance,
Dresden, Germany
Actions
Hendrik Lösch is a management consultant and architect at ZEISS Digital Innovation. The focus of his work is on the development and evaluation of software, based on Microsoft technologies. He also enjoys writing and talking about his work as well as his enthusiasm for clean code, software evolution and test automation in its various forms.
Area of Expertise
Topics
Confessions of a Software Archaeologist: What I Did Wrong in 10 Years of Restructuring Software
While AI tools promise enormous efficiency gains, deploying them often reveals a hard truth: our legacy systems aren't ready. This pressure to modernize shines a harsh light on issues we have ignored for years.
It turns out that refactoring code is actually the easy part. The real bottlenecks are hidden in a tangled mess of stakeholder management, ossified organizational structures, and the "human factor." These are non-technical problems that no AI can fix for us.
With over 10 years of experience as a Lead Dev, Architect, and TPM, I’m looking at the big picture. Having navigated these exact traps in numerous restructuring projects, I will share actionable lessons to help you spot and overcome these barriers. We’ll look past the code to focus on building a project environment that allows modernization to succeed.
Why (most) software projects fail silently...
Software has several unique features that differentiate it from other products. It is not bound by natural laws, can be easily modified, can be replicated indefinitely, and is largely intangible. These traits create a specific kind of complexity that can make it challenging for even experienced software developers and architects to successfully manage their projects.
In this talk, we will explore how these characteristics affect different software systems, whether they are small mobile apps or large enterprise cloud solutions.
The goal of this presentation is to help everyone involved in projects gain a better understanding of each other's perspectives and to provide insights that can improve awareness of potential project risks.
Modulith Instead of Monolith - Pragmatically Towards Microservices
Monolithic architecture approaches are currently not held in high regard, as they are considered to be complex, sluggish, and difficult to modify. On the other hand, Microservices are seen as fast, flexible, and adaptable, even though they also have various disadvantages in practice. Additionally, transitioning from a monolithic to a microservices architecture is not straightforward.
Therefore, this session will first examine both approaches and compare them. It will then explain a hybrid approach, the "Modulith," and demonstrate the scenarios in which it leads to remarkable results.
Der Software auf den Zahn gefühlt
Eine Softwarearchitektur ist kein starres Gebilde. Sie wird nicht einmal festgelegt, dann errichtet und danach nie wieder angefasst. Softwarearchitekturen leben. Sie verändern sich und können gegebenenfalls auch mutieren. Aus diesem Grund sollten sie regelmäßig überprüft und bewertet werden, denn sonst droht der Verfall.
In diesem Workshop sehen wir uns verschiedene Vorgehen und Werkzeuge zur Bewertung von Softwarearchitekturen an. Wir betrachten Qualitätsziele, erstellen passende Überprüfungsszenarien und widmen uns objektiven Risikobewertungen. Nebenbei lernen wir außerdem verschiedene Werkzeuge kennen, die uns bei der Bewertung helfen, wodurch es Ihnen im Anschluss an den Workshop möglich sein sollte Ihrer Software gleich selbst auf den Zahn zu fühlen.
Quality! What's that?
There is a lot of discussion about the quality of software. The difficult part is that this topic is not as straightforward as it might seem at first glance. This is especially true when moving away from describing specific functions and instead focusing on general quality characteristics.
For this reason, this session will initially differentiate between the most important terms. These include "Quality Attribute" and "Quality Requirement", as well as "Functional Requirements" and "Non-Functional Requirements". The latter will be extensively explained using practical examples, clarifying their impact on architecture and the approach to testing.
We (don't) need a software architect!?!
"Software architect" - in times of agile development, this term seems almost outdated and gives the impression that there is one person who primarily creates designs that are then cast in concrete by others and never change again. This is not correct. Software changes continuously and evolutionarily. If this is not taken into account, significant problems can arise.
For this reason, the talk will give an insight into the work of software architects and show what can happen if they do not exist or their work is misunderstood. It also discusses different types of software and the composition of teams, as well as which aspects of software development can particularly benefit from software architects.
How-To Domain Model – Ein Beispiel aus der Fertigung
Ein Domain Model ist ein abstraktes Modell, das die wichtigsten Konzepte und Beziehungen innerhalb eines bestimmten Fachgebiets darstellt. Im Bereich der Fertigung kann ein Domain Model beispielsweise die verschiedenen Arten von Maschinen und Anlagen, die bei der Herstellung von Produkten verwendet werden, abbilden. Das Ziel eines Domain Models ist es dabei, die Komplexität eines Fachgebiets zu reduzieren und die Kommunikation und Zusammenarbeit innerhalb eines Entwicklungsteams sowie zwischen verschiedenen Steakholdern zu verbessern.
In diesem Vortrag klären wir zunächst die allgemeinen Theorien hinter Domänenmodellen auf Basis des Domain Driven Designs und der Enterprise Architecture Patterns von Martin Fowler. Anschließend werden wir uns auf die spezielle Anwendung von Domänenmodellen in der Fertigungsindustrie konzentrieren und Beispiele für ihre Verwendung in diesem Kontext aufzeigen. Dies ermöglicht es uns, die Vorteile des Vorgehens an realen Komplexbeispielen darzustellen, statt sie nur aus den simplifizierten Szenarien abzuleiten, die sonst in der Theorie gern verwendet werden.
Das Ziel des Vortrags ist es somit, allen Beteiligten die Wichtigkeit des Vorgehen zu verdeutlichen und einen klaren Weg aufzuzeigen wie es in realen Umgebungen eingesetzt werden kann.
Von Schichten, Ringen und Adaptern – Der Rundumschlag zum Thema Softwarearchitektur
Das Thema Softwarearchitektur ist wahrlich kein einfaches, gibt es doch dort so viele unterschiedliche Begriffe, Muster und Konzepte, die man kennen muss, um eine langfristig stabile Software designen zu können. Mit diesem Vortrag soll daher einmal ein kompletter Rundumschlag zum Thema Architekturmuster gemacht werden.
Dabei behandeln wir die wichtigsten Muster ausgehend von den Anfängen der Softwareentwicklung bis zum Nonplusultra heutiger Softwarearchitekturen. Wir starten dabei, bei den rein prozeduralen System der 70er Jahre, gehen über die klassische Schichtenarchitektur, widmen uns der Zwiebelarchitektur, machen einen Abstecher zum Domain Driven Design und landen letztendlich in der Clean-Architecture. Auf diesem Weg klären wir wichtige Begriffe wie zum Beispiel Layer und Tiers und warum diese nicht das Gleiche sind. Darüber hinaus betrachten wir aber auch wichtige Entwurfsmuster wie zum Beispiel das Domänenmodell oder das Repository.
Ziel des Vortrags ist es den Teilnehmern zu verdeutlichen welches Architekturmuster für sie tatsächlich verwendet werden sollte und wie sie die unterschiedlichen Ausprägungen zu bewerten haben.
Restructuring vs. Refactoring – Wie gräbt man ein ganzes Softwaresystem um?
Der Zahn der Zeit nagt in völlig unterschiedlichen Weisen an einem Softwaresystem. Mal kommt er in Form von geänderten Technologien (.NET Core?), mal in Form von geänderten Nutzererwartungen (Mobile?) und mal in Form von geänderten Gesetzesgrundlagen (DSGVO?). Er kann sich aber auch in der Gestalt von unsauberer Implementierung, schlechten Architekturentscheidungen oder fehlender Dokumentation entfalten. Will man ihm begegnen, bedeutet dies in aller Regel Investitionen in die Erhaltung des Wertes der Software, statt in die Steigerung ihres Funktionsumfangs.
Diesem Umstand begegnen Entwickler in aller Regel mit Refactorings. Vergleichsweise kleine Code-Änderungen, die sich groß entfalten sollen und es im Alltag dann aber leider nicht wie erwartet tun. Dies bedeutet nicht, dass Refactorings sinnlos oder gar schlecht sind. Im großen Maßstab gedacht sind sie nur eben nicht ausreichend.
Um dem auf den Grund zu gehen, schauen wir uns an was Refactorings tatsächlich sind, wie man Software im großen Maße restrukturieren kann und welche technischen, sowie organisatorischen Maßnahmen notwendig sind, um umfassendere Vorhaben zu einem Erfolg zu führen.
3D Sudoku for Advanced Players – Software Product Line Engineering
Software Product Line Engineering describes the development of a series of software products based on a common foundation of components and a unified architecture. This strategy is particularly beneficial in scenarios where multiple software products require similar functionalities but need individual customizations or variants. A notable example can be found in the Human-Machine Interfaces within the manufacturing industry, where a variety of customer-specific workflows interact with different hardware configurations.
The presentation explains the theoretical foundations of Software Product Line Engineering and demonstrates, using a practical example from the manufacturing industry, how such an architecture can be realized. The focus is on creating reusable and scalable software components that allow a wide range of product variations in different combinations.
Furthermore, the presentation addresses the efficient management of the variety of variants in software product lines. It discusses how a balanced relationship between the standardization of software modules and the necessary flexibility for customer-specific customizations can be achieved.
The Laws of Software Entropy: Why Success is Just an Edge Case of Failure
We like to think of software engineering as a disciplined science, yet our daily reality often feels like a constant battle against chaos. Why do projects inevitably slow down? Why do "finished" features come back to haunt us? And why does adding more code often feel like adding more problems?
In this session, I will introduce the "Laws of Software Entropy" which are a set of counter-intuitive principles that govern the lifecycle of every software system. Presented with a wink but rooted in serious observation, these insights are drawn from over 20 years in software development and more than a decade as a software architect. We will explore the hidden dynamics that turn assets into liabilities and promises into disappointments.
This is not a talk about specific tools or frameworks. It is a tongue-in-cheek yet painfully honest reality check on the economic and human forces that silently shape our work. Join me to discover why your intuition about productivity might be wrong and how accepting these unwritten laws is the first step toward regaining control.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top