Speaker

Tobias Voß

Tobias Voß

Modernization Architect | viadee Unternehmensberatung AG

Modernisierungs-Architekt | viadee Unternehmensberatung AG

Münster, Germany

Actions

Tobias works as a modernization architect at viadee Unternehmensberatung. He supports customers of the insurance and finance sector in the modernization and migration of individual software systems. At viadee he leads the competence cluster Java & Architecture.

Tobias Voß arbeitet als Modernisierungs-Architekt bei der viadee Unternehmensberatung. Er berät Kunden im Versicherungs- und Bankenumfeld bei der Modernisierung und Migration individueller Softwaresysteme und leitet den Kompetenzbereich Java & Architektur der viadee.

Area of Expertise

  • Information & Communications Technology

Topics

  • Application Modernization
  • Software Architecture
  • Agile Architecture
  • Cloud Architecture
  • Enterprise Architecture
  • Enterprise Java

Sessions

Software-Archäologie - Was wir von der Mondlandefähre lernen können! en

Die Mondlandung ist gut 50 Jahre her und die Menschheit plant erneut große Raumfahrtprogramme. Bei der ersten Mondlandung hat IT eine wichtige Rolle gespielt und es wurden wichtige Fundamente des Software Engineering geschaffen. Der Begriff selbst wurde von Margaret Hamilton während der Entwicklung des Apollo Guidance Computer (AGC), des Steuermoduls der Mondlandefähre, geprägt.

Ich möchte etwas Software-Archäologie betreiben und mit einem Rückblick auf die bahnbrechenden Erfindungen des AGC einen Kontrastpunkt zum Technologie-Hype setzen. Für eines der ersten eingebetteten Systeme wurden Prioritätsscheduling, Multitasking und ein Echtzeitbetriebssystem entwickelt. Die Fly-by-wire-Technologie für die elektronische Steuerung der Mondlandefähre setzte Maßstäbe, die bis heute Standard sind und in ihrer Fortsetzung Drive-by-wire eine wichtige Rolle für autonom fahrende Autos spielen. Ein wesentlicher Erfolgsfaktor war die Robustheit der Software, die sich durch eine gute Fehlerbehandlung auszeichnete und vor Bedienungsfehlern abgesichert wurde, nachdem Margaret Hamiltons Tochter beim Herumspielen mit dem AGC einen Absturz verursacht hatte. Werfen wir einen Blick zurück in die Zukunft!

How to design the architecture in two weeks? - Architecture evaluation in agile projects en de

What needs to be done as an architect in an agile team, if we have to decide about the architectural patterns in sprint 1 or about the technologies to use? And what if the decision has to be made during the first sprint? Start simple and refactor later? What if there are different views about the meaning of simple?
One good method for decision-making is the SWOT analysis to evaluate the strengths, weaknesses, opportunities and risks of architectural decisions. We employ the SWOT analysis in a case-study to decide between a microservice architecture and a modular monolith. Basis on the SWOT analysis a well-founded decision can be made by the team. As soon as the prototype from sprint 1 is ready, the team is able to verify the assumptions from the SWOT analysis. With every following sprint, strengths and opportunities can be utilized and weaknesses and risiks minimized - or the decision may be revised.

Strategies, Tactics, and Patterns of Legacy Migration en

Several strategies exist for the migration of legacy applications and a complete greenfield rebuild from scratch is not always recommended. The talk presents the different 5R strategies (retire, replace, rehost, retain, reengineer) for legacy migration and makes a comparison with their advantages and drawbacks. Special characteristics of the strategies for a migration to the cloud (e.g. lift & shift) are also considered.

A strategy for itself will not be enough to master the challenges of legacy migration. Dependencies to other applications are sometimes ignored when the strategy is chosen and often it is necessary to prepare the application to meet the preconditions for the migration. At this point concrete tactics or patterns are used to convert the strategy to a successful project. Some tactics are the usage of bridging technologies or the layer-based approach for an iterative modernization of the complete application. The strangler fig pattern is quite popular for the stepwise migration of legacy applications. The talk presents concrete examples from successful migration projects for these and other tactics and patterns.

Software Archaeology: How the Web was born en de

Some 30 years ago one of the most influential technologies was created at a European research facility: The WorldWideWeb. Originally designed to share information about high energy physics experiments between researchers, the Web quickly became a commercial success and is now dominating our daily life.

This talk will look back at the origins of HTML, HTTP and URLs which where implemented in the first web server and web browser at CERN. The basic technologies still prevail today, as well as the principles of open standards and open source software which were established by the inventor Tim Berners-Lee.

"Yes, but..." - (non-)constructive feedback culture during code reviews en

Code reviews are essential for agile teams and very often part of the Definition of Done. But to give feedback and to accept feedback is something that has to be learned. Constructive feedback needs to be practised in order to handle conflicts between team members and to work together in the fashion of a solution-oriented team culture. "Yes, but" is a typical example for a pitfall in communication. Dialogues that start like "Yes, but I would have done that otherwise..." are examples for a bad feedback culture during a code review. We perform four concrete antipatterns of bad feedback with entertaining role plays and discuss with the audience how to give better feedback. Be prepared to reflect your own behaviour during code reviews!

Software archaeology - Learning from the landing on the moon! en de

The landing on the moon was about 50 years ago and mankind plans again big space programs. IT played a major role at the first moon landing and many important fundaments of software engineering were established. The term itself was coined by Margaret Hamilton during the design of the Apollo Guidance Computer (AGC), the control software of the Apollo lunar lander.

I want to practice a bit of software archaeology in contrast to current technology hypes with a retrospection of the groundbreaking achievements of the AGC. Priority scheduling, multitasking and a realtime operating system were implemented for one of the first embedded systems. A virtual machine - a new concept as well - provided mathematical functions and abstracted from the hardware. One of the main success factors was the robustness of the software, which was characterized by excellent error handling and prevented human user errors - an important learning after Hamiltons daughter crashed the AGC while playing with it. This quality kicked in minutes before the landing and prevented the failure of the mission. Let us take a look back to the future!

Strategien, Taktiken und Muster der Legacy-Ablösung en

Für die Ablösung von Legacy-Anwendungen existieren verschiedene Strategien und eine komplette Neuimplementierung "auf der grünen Wiese" ist nicht immer ratsam. Der Vortrag wird die verschiedenen 5R-Strategien (Retire, Replace, Rehost, Retain, Reengineer) zur Legacy-Migration vorstellen und mit ihren Vor- und Nachteilen vergleichen. Dabei werden die Strategien auch in ihren besonderen Ausprägungen für die Migration in die Cloud (z.B. Lift&Shift) betrachtet.

Eine Strategie allein wird den Herausforderungen der Legacy-Ablösung selten gerecht, da die Abhängigkeiten zu anderen Anwendungen bei der Wahl der Strategie oft ausgeblendet werden und die Voraussetzungen zur Migration erst geschaffen werden müssen. An der Stelle kommen häufig konkrete Taktiken oder Muster ins Spiel, um die Strategie in ein erfolgreiches Projekt zu überführen. Das kann die Nutzung von Brückentechnologien sein, die Anwendung des Strangler Fig Patterns zur schrittweisen Ablösung der Legacy-Anwendung oder die schichtenweise Modernisierung des Gesamtsystems. Für diese und andere Taktiken und Muster werden konkrete Erfolgsbeispiele aus der Praxis vorgestellt.

Software-Archäologie - Was wir von der Mondlandefähre lernen können! en de

Die Mondlandung ist gut 50 Jahre her und die Menschheit plant erneut große Raumfahrtprogramme. Bei der ersten Mondlandung hat die IT eine wesentliche Rolle gespielt und es wurden wichtige Fundamente des Software Engineering geschaffen. Der Begriff selbst wurde von Margaret Hamilton während der Entwicklung des Apollo Guidance Computer (AGC), des Steuermoduls der Mondlandefähre, geprägt.

Ich möchte etwas Software-Archäologie betreiben und mit einem Rückblick auf die bahnbrechenden Erfindungen des AGC einen Kontrastpunkt zum Technologie-Hype setzen. Für eines der ersten eingebetteten Systeme wurden Prioritätsscheduling, Multitasking und ein Echtzeitbetriebssystem entwickelt. Eine der ersten virtuellen Maschinen stellte mathematische Funktionen bereit und abstrahierte von der Hardware. Ein wesentlicher Erfolgsfaktor war die Robustheit der Software, die sich durch eine gute Fehlerbehandlung auszeichnete und vor Bedienungsfehlern abgesichert wurde, nachdem Hamiltons Tochter beim Herumspielen mit dem AGC einen Absturz verursacht hatte. Diese Eigenschaft kam Minuten vor der Landung zum Tragen und bewahrte die Mission vor dem Abbruch. Werfen wir einen Blick zurück in die Zukunft!

Software Archaeology: How the Web was born en de

Vor über dreißig Jahren wurde eine der einflussreichsten Technologien aller Zeiten in einem europäischen Forschungszentrum entwickelt: Das World Wide Web. Ursprünglich entwickelt um Informationen über Hochenergiephysik-Experimente zwischen Forschen zu teilen, wurde das Web schnell ein kommerzieller Erfolg und dominiert nun unser tägliches Leben.

Dieser Vortrag wirft einen Blick zurück zu den Ursprüngen von HTML, HTTP und URLs, die im ersten Web Server und Web Browser am Forschungszentrum CERN implementiert wurden. Die grundlegenden Technologien haben bis in die heutige Zeit überdauert, genauso wie das Prinzipien von offenen Standards und Open Source Software, die vom Erfinder Tim Berners-Lee etabliert wurden.

Cloud Architecture Kata de

Wie lernt man eine gute Architektur zu entwerfen? Indem man viele Architekturentwürfe macht, diese diskutiert, vorstellt, sich Feedback einholt und dann verbessert. Genau das wollen wir in dieser Architektur-Kata praktizieren. Wenn ihr Code-Katas kennt, sind Architektur-Katas ein sehr ähnliches Format, nur dass wir keine Programme schreiben, sondern Architekturentwürfe zeichnen. Wir werden eine konkrete Problemstellung für ein zu entwerfendes System angehen und in kleinen Teams von 4-5 Personen jeweils einen Architekturentwurf für die Problemstellung entwickeln. Die fachlichen Anforderungen und Qualitätsanforderungen sind festgelegt und eure Aufgabe ist es, eine passgenaue Architektur zu entwerfen.

Nach der Entwurfsphase bekommt jedes Team Zeit, um seinen Architekturentwurf in der großen Gruppe vorzustellen und Feedback einzuholen. Anschließend bekommt jedes Team nochmal Zeit, den eigenen Architekturentwurf auf Basis des Feedbacks oder der Entwürfe der anderen Teams zu verbessern.

Wie komme ich zu einer Architektur in zwei Wochen? - Architekturbewertung in agilen Projekten en de

Was tue ich als Architekt in einem agilen Team, wenn wir im Sprint 1 vor der Entscheidung stehen, welches Architekturmuster oder welche Technologien wir einsetzen wollen? Und wir innerhalb des Sprints entscheiden wollen? Einfach machen und dann refactoren? Und wenn es verschiedene Ansichten gibt, wie wir es „einfach“ machen wollen? Eine gute Methode zur Entscheidungsfindung ist die SWOT-Analyse, die Stärken (strengths), Schwächen (weaknesses), Chancen (opportunities) und Risiken (threats) der Architekturentscheidung expliziert. Wir werden als Beispiel die Entscheidung zwischen einer Microservice-Architektur und einem modularen Monolithen mittels der SWOT-Analyse bewerten. Auf Basis der Analyse kann das Team eine fundierte Entscheidung treffen. Wenn der Prototyp aus Sprint 1 dann fertig ist, kann das Team die ersten Annahmen der SWOT-Analyse verifizieren und mit jedem Sprint weitere Stärken und Chancen ausbauen oder Schwächen und Risiken minimieren - oder die Entscheidung revidieren.

Tobias Voß

Modernization Architect | viadee Unternehmensberatung AG

Münster, Germany

Actions

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