Sven Johann

Sven Johann ist Senior Consultant bei innoQ und beschäftigt sich seit vielen Jahren mit der Modernisierung von mittleren und großen Java-Anwendungen. Er ist aktiver Teilnehmer verschiedener Workshops des Software Engineering Institutes (Managing Technical Debt) und des Leibnitz Zentrums für Informatik (Dagstuhl Seminar “Managing Technical Debt”). Zudem ist er Program Chair der GOTO Amsterdam und Show Host von Software Engineering Radio.

Vorträge

  • From Brownfield to DevOps

    Topconf Düsseldorf 2017 06. Oktober 2017

    In urban planning, a brownfield is when we build on land that was previously used for industrial purposes, potentially contaminated with hazardous waste or pollution. In order to improve the land, existing structures need to be demolished or toxic materials need to be removed. In software development, a brownfield comes often with significant Technical Debt such as having no automated tests or running on unsupported platforms. A greenfield in software development means to start from scratch and worry less about existing code bases, processes and teams.

    Many people believe that DevOps, which requires a software architecture optimised for testability and deployability, is only possible for greenfield projects, but many companies, such as Etsy or LinkedIn showed how to close the large performance gap between what customers needed and what the organisation was able to deliver by selecting the right value streams and improving their software architecture along those value streams.

    This talk starts with defining the Technical Debt landscape from Code Smells to the Technology Gap and shows why solving the problems of the landscape unsystematically is neither economical nor goal oriented and won’t lead you anywhere. We then look at the specific goals DevOps wants to achieve and how certain parts of the Technical Debt landscape interfere with these goals unequally strong. The presentation will offer conceptual background and concrete steps and examples on how to understand and select the right value stream for a brownfield DevOps transformation, how to get started and measure progress, select the right technologies at a certain point in time and finally move towards continuous architecting for DevOps.

    Mehr lesen
  • Lean Prinzipien und das Management von Technical Debt

    XP Days Germany 2016 21. November 2016

    Viele Systeme haben allerhand unsichtbare Probleme, die man heutzutage als Technical Debt zusammenfassen kann: Code Smells, fehlende Tests und Dokumentation, schlechtes Design, unangemessene Architektur und/oder veraltete Technologie. Kleine Probleme wie Code Smells sind noch einfach zu beheben, aber substantielle Probleme, die große Teile der Codebase betreffen sind aus vielen Gründen weitaus schwieriger anzupacken. Risiko, Kosten und Wert der “Rückzahlung” von Technical Debt sind zudem schwer abzuschätzen.

    Es heißt oft, dass Technical Debt zu vermeiden sei, dies ist aber letztenendes unmöglich und deshalb rückt mehr und mehr das Maximieren des Wertes von “Technical Debt Management” in den Vordergrund. Ein in die Jahre gekommenes System hat fast immer so viel Verbesserungsbedarf, dass Verbesserungen nicht blind gemacht werden dürfen. Es ist wichtig, die Stellen anzupacken, die am meisten Wert versprechen.

    Hier kommen Lean Prinzipien ins Spiel um zu entscheiden, was man wann und wie verbessern sollte.

    Dieser Vortrag gibt erst einen Überblick über die Technical Debt Landkarte und warum man Technical Debt managen sollte, statt einfach nur blind zu verbessern. Danach werden die Lean Prinzipien “Eliminate Waste”, “Decide as late as possible”, “Deliver as fast as possible” und “See the whole” diskutiert und wie man sie nutzen kann, um ein System wertorientiert zu verbessern.

    Mehr lesen
  • Managing Technical Debt

    The Architecture Gathering 2016 12. Oktober 2016

    Viele Systeme haben allerhand unsichtbare Probleme, die man heutzutage als Technical Debt zusammenfassen kann: Code Smells, fehlende Tests und Dokumentation, schlechtes Design, unangemessene Architektur und/oder veraltete Technologie. Kleine Probleme wie Code Smells sind noch einfach zu beheben, aber substantielle Probleme, die große Teile der Codebase betreffen, sind aus vielen Gründen weitaus schwieriger anzupacken. Risiko, Kosten und Wert der “Rückzahlung” von Technical Debt sind zudem schwer abzuschätzen.

    Es heißt oft, dass Technical Debt zu vermeiden sei, dies ist aber letztenendes unmöglich. Deshalb rückt mehr und mehr das Maximieren des Wertes von “Technical Debt Management” in den Vordergrund.

    Dieser Vortrag diskutiert anhand mehrerer Beispiele, z.B. Ablösung von Alt-Frameworks oder Totalumbau eines Domänenmodells, angewandte Ideen, wie man mit Hilfe unterschiedlichster Ideen wie Shearing Layers oder Value-Chain-Analysis den Wert einer Verbesserung innerhalb eines Entwicklungsprozesses für alle Stakeholder sichtbar und nachvollziehbar machen kann, und wie man dies in einen Standard-Entwicklungsprozess wie z.B. Scrum einbetten kann.

    Mehr lesen