Eberhard Wolff
Head of Architecture, SWAGLab
Head of Architecture, SWAGLab
Kaiserslautern, Germany
Eberhard Wolff has 20+ years of experience as an architect and consultant - often on the intersection of business and technology. He is Head of Architecture at SWAGLab. As a speaker, he has given talks at international conferences and as an author, he has written more than 100 articles and books e.g. about Microservices and Continuous Delivery. His technological focus is on modern architectures – often involving Cloud, Continuous Delivery, DevOps, Microservices or NoSQL.
Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Continuous Delivery und Microservices, trägt regelmäßig als Sprecher auf internationalen Konferenzen vor und streamt wöchentlich zum Thema Software-Architektur. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-driven Design und Microservices.
Awards
Area of Expertise
Topics
Conway's Law? I'm Tired of It. en
Hardly any talk about software architecture nowadays gets by without mentioning Conway's Law. But as is so often the case, few people have actually read the original paper. And people who work on software are rarely experts in organization or communication, which they now understand to be an important element of architectural work. This talk discusses misconceptions about Conway's Law and shows what impact but also opportunities Conway's Law actually provides.
Legacy Software: Really a Problem? en
Legacy software makes even experienced developers shudder. But the word "legacy" actually has a negative connotation only in IT. And legacy software practically always solves a business problem successfully, while a newly developed software must first find its niche. This presentation shows how to use these and other insights to come up with strategies for dealing more productively and successfully with legacy software. And that's how to turn the "problem" of legacy into an opportunity.
Microservices? Monoliths? An Annoying Discussion! en
Microservices set out to solve the problem of monoliths. Or do they? After all, it is now fashionable to condemn microservices - then monoliths must have been the right solution! The discussion is quite annoying and the fact that it exists at all already shows a fundamental misunderstanding of what architecture is actually about and that our industry unfortunately has significant weaknesses when it comes to making serious progress.
Don't Overdose on Domain-Driven Design en
"Domain-driven Design" (DDD) is a concept introduced by Eric Evans 20 years ago. Today, DDD has become a complex collection of various approaches and techniques. In this complexity, the essence of DDD can easily be lost. Projects may appear to implement DDD, but they are not successful despite incorporating a multitude of DDD techniques because crucial aspects are overlooked. This presentation demonstrates how to focus on the core of DDD and truly achieve success in its implementation. Only a few specific approaches are actually necessary for this.
Technical Debt: Maintaining Software Long Term en
Software often becomes less maintainable the longer development teams work on it. The metaphor "technical debt" has been established for this. But technical debt can happen "just like that" and it doesn't always make sense to eliminate it. That's what this talk is about - and about the foundations of the metaphor, how it helps when communicating with managers, why the metaphor is actually not very well chosen, and of course how to deal with technical debt in a sensible way.
Software Architecture for Humans! en
Software architecture is only appearing to be a technical topic. Of course, software needs to have technologies and structures, but people have to be at the focus of the architecture. After all, the key challenge of software development and software architecture is that the software systems the we build are too complex for a single human to understand. However, the organization and management of people can also solve problems that relate to software architecture. Thus, the talk shows the dependencies between architecture, people, and organization - and how to use them to develop software more successfully.
Scaling Software Architecture and Projects en
Software architecture was invented in the sixties to enable larger teams to work on complex software. In this workshop, we will examine how architecture can achieve this concretely today - and how modern architectural approaches such as microservices or the separation of architecture into micro- and macro-architecture help to achieve this. This enables engineering teams to scale and also enables the architecture work by larger groups of people. In addition, we will discuss how this approach can help to scale agile projects.
No Future-Proof Architecture! en
Software architecture should be stable! Choosing the right architecture ensures that software can be successfully maintained in the future! What seems to make sense at the beginning often turns out to be the first step towards an architecture failure. When requirements, know-how or technologies change, the architecture needs to change as well. How can it then be future-proof? The presentation shows how the paradox can be resolved and no future-proof architecture is created - but long-term project success.
Microservices: Spring vs Dapr vs Istio en
Java frameworks like Spring provide support for microservices features such as tracing, metrics, or resilience. Service meshes like Istio provide these features as part of the infrastructure - and Dapr supports developers with many other features. This talk compares the three approaches and show their strength and weaknesses by using a common example that is available on GitHub. This helps developers to choose the approach that best supports them.
How Much Architecture Do We Need? en
Software architecture seems to be from the ivory tower and therefore too remote from reality to really help. Sometimes it even looks as if the architecture is just standing in the way. So how much architecture is enough? And why do we even need one? This talk shows why architecture is needed und how it is useful so that projects can be more successful.
Domain-driven Design - More Than "Just" Sensible Software Development? en
By now, Domain-driven Design (DDD) is a confusing set of techniques that is talked and written about a lot. But at its core, it is about the domain driving the design. This requires a good knowledge of the domain and structuring the system accordingly. If that already doesn't work, then more advanced techniques are hardly useful. This talk is about the essence of DDD and the fact that DDD is based on well-known basic concepts of software development. That makes it possible to concentrate on the essentials and thus improves the chances of success of the projects.
Architecture: Improving the Human Factor! en
Good software architecture organizes complex software systems so that humans with their limited mental capacity can understand and evolve them. Therefore, the human factor is at the core of software architecture. However, architecture cannot solely focus on structuring the software; it must also address the human aspects. This presentation explores specific approaches and experiences aimed at the human factor and thereby improving software development further.
Legacy Software: Nur scheinbar ein Problem! de
Legacy Software - dabei erschaudern auch erfahrene Techniker:innen. Aber Legacy heißt eigentlich so viel wie "Erbe" und ist nur in der IT rein negativ besetzt. Und Legacy Software löst praktisch immer ein Business-Problem erfolgreich, während eine Neuentwicklung ihre Nische erst finden muss. Der Vortrag zeigt, wie man diese und andere Erkenntnisse nutzen kann, um Strategien zu entwickeln, mit denen man produktiver und erfolgreicher mit Legacy-Software umgehen kann. Und so wird aus dem Problem "Legacy" eine Chance.
Microservices, Monolithen - Hauptsache Module! de
Microservices haben den Hype lange hinter sich - und wegen der scheinbaren Komplexität fangen Architekt:innen wieder an, Monolithen zu bauen. Schließlich war früher alles besser. Aber warum sind dann Monolithen heute oft unwartbar? Das zeigt: die Diskussion zu Monolithen und Microservices geht am eigentlichen Thema vorbei. Das Mittel gegen überbordende Komplexität und mangelnde Wartbarkeit kennen wir schon lange: Modularisierung. Und deswegen geht es in diesem Vortrag um Module - und damit um Ansätze, um sowohl vernünftige Monolithen als auch Microservices-Systeme zu entwickeln.
Microservices - Wo sind meine Transaktionen und meine Konsistenz hin???? de
Verteilte Systeme sind kompliziert. Gerade Transaktionen und Konsistenz von Daten stellen ernsthafte Herausforderungen dar. Dieser Vortrag zeigt, wie ein guter Schnitt eines Microservices-System für Lösung dieser Probleme so wichtig sind, wie Domain-driven Design hilft und was in der Praxis zu beachten ist.
Domain-driven Design - mehr als "nur" sinnvolle Softwareentwicklung? de
Mittlerweile ist Domain-driven Design (DDD) eine unübersichtliche Menge von Techniken, über die viel geredet und geschrieben wird. Aber im Kern geht es darum, dass die Domäne das Design treibt. Das bedingt eine gute Kenntnis der Domäne und eine dementsprechende Strukturierung des Systems. Wenn schon das nicht klappt, sind weitergehende Techniken kaum sinnvoll. In diesem Vortrag geht es um die Essenz von DDD und darum, dass DDD im Kern auf wohlbekannten Grundkonzepten der Software-Entwicklung aufsetzt. Das ermöglicht die Konzentration auf das wesentliche und verbessert so die Erfolgsaussichten der Projekte.
Architektur: bitte nicht zukunftssicher! de
Architektur soll stabil sein! Die Wahl der richtigen Architektur sorgt dafür, dass Software in Zukunft weiterentwickelt werden kann! Was zunächst sinnvoll erscheint, erweist sich oft als erster Schritt hin zu einem Architektur-Fehlschlag. Wenn sich die Anforderungen, das Wissen oder die Technologien ändern, sollte sich die Architektur auch ändern. Wie kann sie dann zukunftssicher sein? Die Präsentation zeigt, wie das Paradoxon aufgelöst werden kann, und keine zukunftssichere Architektur entsteht - aber langfristiger Projekterfolg.
Architektur: Den menschlichen Faktor verbessern! de
Gute Software-Architektur strukturiert komplexe Software-Systeme so übersichtlich, dass Menschen sie verstehen und weiterentwickeln können. Also geht es bei der Software-Architektur um den Faktor Mensch. Deswegen kann sich Architektur aber nicht auf Maßnahmen für die Strukturierung der Software begrenzen, sondern muss sich auch mit den Menschen beschäftigen. In diesem Vortrag geht es um einige konkrete Ansätze und Erfahrungen, die Entwicklung durch Maßnahmen in Bezug auf den Faktor Mensch zu verbessern.
Architektur für Menschen - nicht Software! de
Software-Architektur ist nur scheinbar ein technisches Thema. Software muss zwar Technologien und Strukturen haben, aber im Mittelpunkt der Architektur muss der Mensch stehen. Schließlich ist die Kern-Herausforderung der Software-Entwicklung und Software-Architektur, dass die entworfenen Systeme zu komplex sind, als dass eine Mensch sie verstehen kann. Die Organisation und der Umgang mit Menschen können aber auch Probleme im Umfeld von Software-Architekturen lösen. Daher zeigt der Vortrag die wechselseitigen Abhängigkeiten zwischen Architektur, Menschen und Organisation auf - und wie man sie nutzen kann, um erfolgreicher Software zu entwickeln.
Domain-driven Design: Konzepte und Fallstricke de
Domain-driven Design (DDD) steht für eine Vielzahl an Techniken wie strategisches DDD, taktisches DDD und kollaborative Modellierung. Dieser Vortrag gibt einen Überblick über das DDD-Universum. Dabei stellt er nicht nur die verschiedenen Konzept vor. Er zeigt außerdem auch die jeweiligen Vor- und Nachteile der Praktiken auf und weist auf die typischen Fallstricke hin - und wie man sie vermeiden kann.
Warum (agile) Projekte kippen de
Agilität bietet höhere Produktivität und bessere Ergebnisse für die Projekte - daher wird sie sich durchsetzen! Die Realität sieht leider manchmal ganz anders aus: Erst ist das Projekt agil, produktiv und alle sind begeistert. Wenige Monate später: wichtige Personen haben das Projekt verlassen und von den agilen Techniken ist nur noch wenig übrig . In diesem Vortrag geht es uns um das "Kippen" von Projekten und Gründe sowie Möglichkeiten diskutieren, um mit einer solchen Situation umzugehen.
Developer Week '24 Sessionize Event Upcoming
JCON EUROPE 2024 Sessionize Event Upcoming
iSAQB Software Architecture Gathering – Digital 2023 Sessionize Event
JCON WORLD 2023 Sessionize Event
Agile meets Architecture 2023 Sessionize Event
BED-Con 2023 Sessionize Event
Java Forum Nord 2023 Sessionize Event
WeAreDevelopers World Congress 2023 Sessionize Event
Developer Week '23 Sessionize Event
JCON EUROPE 2023 Sessionize Event
iSAQB Software Architecture Gathering – Digital 2022 Sessionize Event
JCON 2022 ONLINE (virtual) Sessionize Event
iSAQB Software Architecture Gathering 2021 Sessionize Event
JCON 2021 Sessionize Event
Developer Week '20 Sessionize Event
BED-Con 2019 Sessionize Event
BED-Con 2018 Sessionize Event
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