Decentralization was a big theme of the 2010s. Software architectures became more fine-grained and distributed, and the teams that build and evolve them became more autonomous and empowered, giving rise to product-centric, as opposed to project-centric, operating models. It became clear that architecture is a key enabler of greater organizational performance.
 
Ignoring architecture results in organizations that struggle trying to adopt modern product development approaches as they fight against architecture designed for a different operating model. There's a symbiotic relationship between software architecture and organization architecture. In order to create high-performing teams, it's necessary to co-design a modern architecture.
 
Optimize for business outcomes, align with business domains, and leverage platform thinking are three of the key aspects to modernization that will be discussed in this session.

Software ist nie fertig und unterliegt ständigen Änderungen durch Anforderungen, neue Technologien oder Fehlerbehebungen. Wenn diese Änderungen unter Druck realisiert werden müssen, leidet die Software-Qualität. Typische Herausforderungen: Kurz vor dem Release wird noch eine Anforderung geändert, Produktionsprobleme verzögern die aktuelle Entwicklung & das Testing kommt durch Fehlentscheidungen zu kurz. Wie in einer Küche mit vielen Köchen, arbeiten Entwickler Tag für Tag an einer gemeinsamen Codebasis, manchmal über Jahre hinweg. Wer seinen Quellcode da nicht unter Kontrolle hat, bewegt sich rasant auf einen wirtschaftlichen Totalschaden zu, verursacht durch technische Schulden. Dieser Gefahr können wir mit Clean Code (CC) wirksam entgegenwirken. In meinem Vortrag verdeutliche ich die Wichtigkeit/Vorteile von CC und gebe einen unterhaltsamen/praxisnahen Einblick zu den Folgen von unlesbarem Code sowie BestPractises und Beispielen der CC-Basics.

Zielpublikum: Entwickler, Projektleiter, Architekten
Voraussetzungen: Allgemeine Projekterfahrung,  Coding Basics
Schwierigkeitsgrad: Einsteiger

Heutzutage führt kein Weg an Single Page Applications vorbei. Ob React, Angular, VueJS oder eines der anderen Frameworks. Die Standardantwort auf die Frage nach der Frontend-Architektur heißt SPA. Doch was kaum jemand bemerkt:
Die SPA Idee ist legacy! Mit AngularJS wurde vor 10 Jahren diese Idee breit umgesetzt.

Ich möchte im Vortrag zeigen, aufgrund welcher Frontend-Probleme man ursprünglich SPAs entwickelt hat und ob es für diese Probleme nicht heutzutage innovativere Lösungen gibt:Hier kommt Hotwire ins Spiel, dass mit einer sehr schlauen, auf low-level Standards setzenden, Lösung ganz neue Möglichkeiten für saubere Architekturen schafft ohne die UX-Vorteile einer SPA zu verlieren!

Ganz anders als SPAs lässt sich mit Hotwire eine lose Kopplung und geringe Abhängigkeiten zwischen verschiedenen Teams wahren und so Skalierungsfähigkeit erhalten.

Mehr dazu im Talk, kommt vorbei!

Zielpublikum: Architekten, Entwickler, Frontend, Backend
Voraussetzungen: Keine
Schwierigkeitsgrad: Einsteiger

Die Ära der Projekte in der Softwareentwicklung ist vorbei. Mit Projekten ist es nicht mehr möglich, die heutige IT-Welt in den Griff zu bekommen. Komplexe Zusammenhänge zwischen Stakeholdern und Umsystemen sowie rasant ändernde Technologien sind nicht mehr beherrschbar.
Das Resultat: zu teuer, zu spät, am Problem vorbei entwickelt.
Statt in Projekten zu denken, müssen wir uns auf den Produkt-Lebenszyklus ausrichten: Geburt, Weiterentwicklung, Ablösung.
Ein Denkanstoss für neue Wege in der Softwarenentwicklung.

Architekturen, die Unfälle waren und warum es zu diesen Unfällen kam. 

1. Unfallszenario Von der Brücke direkt in den Maschinenraum
2. Unfallszenario Es kommt nicht nur auf die inneren Werte an
3. Unfallszenario Ali Baba und die 40 Microservices'

Der Vortrag erläutert die Szenarien und warum die vorgestellten Architekturen Unfälle sind und wie es dazu kam. Als Take Aways werden Hinweise gegeben, wie man Unfälle vermeiden kann.

Video Abstract

Zielpublikum: Manager, Architekten, Studierende
Voraussetzungen: Keine
Schwierigkeitsgrad: Einsteiger

Von On-Prem zu AWS Serverless Anwendungen in Nullkommanix?
Klingt komisch, ist aber so.
Wir berichten aus der Praxis, wie wir diesen Weg beschritten haben.
Gestartet sind wir mit einem sehr langen Katalog von Cloud-Maßnahmen, die es umzusetzen galt.
Als Enabler-Team war es unser Ziel, diese Komplexität den meist ahnungslosen On-Prem Entwicklern abzunehmen.
Herausgekommen ist ein lebendiges Produkt, der Blueprint.
Er umfasst neben textueller Beschreibung der Cloud-Konzepte auch begleitende Beispielanwendungen die mittels einer Pipeline nach AWS gebracht, und mit automatisch provisionierter Infrastruktur (Terraform sei Dank) verheiratet werden.

Für die IT-Sicherheit kam auch etwas Brauchbares raus: durch die Zusammenarbeit haben wir die Komponenten des Blueprints gehärtet, so daß einzelne Freigaben schneller erfolgen - sie beruhen auf bereits abgenommenen Standards.
Eine Win-Win Situation für alle Beteiligten!

Zielpublikum: Cloud-native Gänger, Software-Architekten, DevOps Teams
Voraussetzungen: Grundkenntnisse in Public Cloud & Anwendungsentwicklung
Schwierigkeitsgrad: Fortgeschritten

Um alle Chancen der Digitalisierung nutzen zu können, müssen wir offen sein für Innovation, für Zusammenarbeit und für Menschen.' Dieses Zitat aus dem Jahr 2016 stammt von Dr. Dieter Zetsche, dem damaligen CEO der Daimler AG.

Die Organisation der Zusammenarbeit von Menschen, die ein gemeinsames Ziel verfolgen (das nicht zwingend innovativ sein muss), nennt man Teamentwicklung. Warum die in diesem Zusammenhang vielzitierte Teamuhr von Tuckman in der gängigen Interpretation falsch liegt und wie eine nachhaltige Teamentwicklung auch in einem komplexen Umfeld wie der Digitalisierung funktionieren kann, beleuchten wir in Theorie und (fiktiver) Praxis in unserem interaktiven Vortrag.

Spoiler: Best Practices für die Teamentwicklung kann es unserer Meinung nach nicht geben, denn jedes Team ist anders. Stattdessen präsentieren wir Good Practices in Form eines iterativen Vorgehensmodells.

Zielpublikum: Führungskräfte, Verantwortliche in Projektteams, Agile Coaches
Voraussetzungen: Erfahrungen mit der Arbeit in/mit Teams
Schwierigkeitsgrad: Einsteiger

Zugegeben, kaum jemand fällt beim Thema Architekturdokumentation vor Begeisterung vom Stuhl, aber spätestens bei mittelgroßen Systemen geht es nicht mehr ohne. 
Obwohl Architekturdokumentation eine wichtige Rolle im Entwicklungsprozess einnimmt, wird sie ganz häufig stiefmütterlich behandelt. In unseren Projekten treffen wir viel häufiger auf tolle Architekturen als auf tolle Architekturdokumentationen. Dabei begegnen uns immer wieder die gleichen Defizite: Überbetonung von technischen Aspekten oder Vermischung von Lauf- und Entwicklungszeitaspekten sind nur einige Beispiele. 
In diesem Vortrag berichten wir von unseren Erfahrungen rund um Architekturdokumentation von unterschiedlichsten Systemen und Branchen. Wir fassen 7 Anti-Pattern zusammen und geben Tipps wie jede:r durch einfache Mittel die Architekturdokumentation verbessern kann. Unsere Tipps sind unabhängig vom verwendeten Vorgehen und natürlich auch kombinierbar mit Templates wie arc42.

Zielpublikum: Entwickler:innen, Software Ingenieur:inen, Architekt:inen
Voraussetzungen: Grundkenntnisse in Softwarearchitektur
Schwierigkeitsgrad: Fortgeschritten

In diesem Vortrag werden Bereiche wie die Migration von einem Mainframe System auf ein LUW-System ebenso betrachtet, wie die Umstellungen von Quellcode von zum Beispiel COBOL nach Java. Auch notwendige Anpassungen der Anwendung an der Nutzerschnittstelle werden dargestellt, um dem Anwender einen Zugriff auf das Programm in der Cloud-Umgebung zu ermöglichen.
Es muss auch eine umfangreiche Abwägung getroffen werden, was sich von der Migration in die Cloud erhofft wird, denn daraus resultiert der Aufwand der Umsetzung. Soll es optisch nach wie vor aussehen wie eine Mainframe Applikation? Möchte ich nur die Anwendung in der Cloud hosten (SaaS) oder die ganze Infrastruktur (IaaS)? Was für Kontrollmechanismen gebe ich damit auf und wie wird die angepasste Anwendung in Zukunft betrieben, getestet und Veränderungen veröffentlicht? All diese Fragen sollen übersichtlich betrachtet werden, um eine Migration hin zu einer Cloud-Architektur zu ermöglichen.

Zielpublikum: Entwickler, Architekten, Technik/Manager
Voraussetzungen: Grundkenntnisse in Programmierung
Schwierigkeitsgrad: Fortgeschritten

Die DevOps-Bewegung versucht, Silos zwischen Entwicklung und Betrieb aufzubrechen und durch eine intensive Kollaboration zu ersetzen. Etliche Unternehmen sind intern auf dieser Reise weit gekommen und haben sich mehr und mehr DevOps-Praktiken angeeignet. Sobald sie jedoch externe IT-Lieferanten beauftragen, entstehen oft wieder die alten Silos: Die Lösung wird vom Lieferanten gebaut und nach der Übergabe vom Kunden betrieben. Dabei muss das nicht so sein. Auch externe IT-Lieferanten können gemäß der DevOps-Philosophie mit ihren Kunden (zusammen-) arbeiten. Ich zeige euch in seinem TechTalk einige Muster und praktische Beispiele dafür.

Zielpublikum: Entwickler, Product Owner
Voraussetzungen: Zusammenarbeit mit Kunden
Schwierigkeitsgrad: Einsteiger

Konzerne haben über die Jahre viele große Monolithen angesammelt. Diese sind erfolgsentscheidend für das tägliche Geschäft, kurz Mission Critical für die Kunden. Doch der Druck steigt, diese zu modernisieren und in eine moderne Architektur zu überführen. Gründe hierfür sind vielfältig: von besserem Time-to-Market bei Änderungen bis hin zur Ablösung von veralteten Programmiersprachen, wo die Entwickler und Tools ausaltern.
Für große Transformationen finden sich jedoch kaum publizierte Success Storys. Es bleibt nach wie vor ein sehr herausforderndes Unterfangen, wie ein solches Vorhaben bei den großen, komplexen Kernsystemen funktionieren kann. Wir bei Capgemini haben in den vergangenen Jahrzehnten viel Wissen über die Konzeption und Implementierung dieser Mission Critical Backbones gesammelt und modernisieren sie für unsere Kunden. In unserem Vortrag teilen wir dabei gemachte Lessons Learned verschiedener System-Archetypen garniert mit der einen oder anderen Anekdote aus dem realen Projektleben.

Die Digitalisierung traditioneller Unternehmen und damit meist zwingend verbundene Modernisierung der IT macht auch vor dem Sektor der Finanzdienstleister nicht Halt.

In diesem Vortrag berichtet die SüdLeasing - eine 100% Tochter einer Landesbank - von ihrem Weg von der 'legacy IT' zur modernen cloud-basierten Umgebung. Aufgrund der Sensitivität der Daten lag von der ersten Sekunde ein besonderer Fokus auf dem Thema Cloud Security.

Hier berichten Tamira Horn und Thorsten Jakoby von der Reise eines BaFin regulierten Finanzdienstleisters in die Cloud. Statt 'das sichern wir durch eine Firewall und Netzwerke', wurden Multi-Tenant-Zero-Trust-Architekturen aufgebaut.

Business Continuity und Disaster Recovery wurden voll automatisiert mit Hilfe von Terraform, Access Control Lists und Microsoft Azure aufgebaut.

Zielpublikum: Architekten, DevOps Teams
Voraussetzungen: Keine
Schwierigkeitsgrad: Einsteiger

Wenn Transformationen gegen die Wand fahren, liegt es häufig daran, dass Fehlentwicklungen zu spät erkannt werden. Mit den richtigen KPIs und einer guten Mustererkennung in Veränderungsprozessen kann man frühzeitig feststellen, ob die Transformation erfolgreich wird und konsequent die richtigen nächsten Schritte einleiten.
In unserem Vortrag berichten wir, welche KPIs wir in unserer Transformation bei PWC Deutschland nutzen und wie datengestützte Mustererkennung zum Erreichen unserer Ziele beiträgt. Anhand konkreter Beispiele gehen wir darauf ein, welche transformations-gefährdenden Muster wir KPI-gestützt beobachtet haben, wie wir damit umgegangen sind und was wir daraus gelernt haben.

Doing agile statt Being agile? Conway's Law hits back? Transformation gescheitert? 
Um das zu verhindern, versuchen wir bei Scalamento anhand von Mustern zu erkennen, wo ein Unternehmen auf dem Weg zur Business Agility steht. Durch die Analyse der Muster können wir Transformationsrisiken frühzeitig erkennen und nachhaltige Veränderungen umsetzen. Unser Fokus liegt dabei auf Mustern, die sich über verschiedene Ebenen einer Organisation ziehen, von der Technologie- über die Struktur- bis hin zur Führungsebene. 
Wir möchten mit euch teilen, anhand welcher Beobachtungen wir relevante Muster erkennen. Am Beispiel der Begleitung eines Großkonzerns zeigen wir, welche transformations-hemmenden Muster im Corporate Umfeld häufig auftreten, vom LONELY-ISLAND- über das THOUSAND THINGS-Syndrom bis hin zum WRONG-TOOL-FOR-THE-JOB-Muster. Wir berichten, wie wir mit solchen Mustern umgehen, wo wir auch mal gescheitert sind und was wir daraus gelernt haben.

Zielpublikum: Transformations-Verantwortliche, Manager:innen, Projektleiter:innen, Entscheider:innen,
Voraussetzungen: Keine
Schwierigkeitsgrad: Einsteiger

Gartner prognostiziert, dass bis zum Jahr 2025 Cloud-native Plattformen die Grundlage für mehr als 95 % der neuen Digitalinitiativen dienen werden und damit in die Überlebenstaschen für aufkommende digitale Wirbelstürme gehören. Für Linux hält beispielsweise eine Differenzierung zwischen Linux auf dem Host (Container Host Linux) und Linux im Container Einzug, die ihre jeweils unterschiedlichen Funktionen abbildet. Wir stellen beide Ökosysteme in ihrer zeitlichen Entwicklung und inhaltlichen Ausgestaltung vor und zeigen anhand der konkreten Open Source Beispiele Amazon Bottlerocket und Microsoft/Kinvolk Flatcar Besonderheiten wie den Aufbau eigener Build Pipelines und Zusatzinstallationen. Abschließend runden wir den Überblick ab mit Auswirkungen auf Betriebsprozesse (Automatisierung, Immutability), Entwicklungsprozesse (Testen und Debuggen in minimierten Umgebungen) und übergreifend auf Digitale Souveränität mit dem Einsatz von Open Source.

Zielpublikum: Digitalization Strategists, Cloud Native Architects, Cloud Native Engineers, Leaders, Managers
Voraussetzungen: Verständnis von Kubernetes und Linux auf Einsteigerebene
Schwierigkeitsgrad: Fortgeschritten

Cloud-Infrastrukturen sind schon lange in aller Munde. Große DAX-Konzerne sind jedoch erst in den letzten Jahren dazu übergegangen, ihre businesskritischen Bestandsapplikationen großflächig zu Cloud-Dienstleistern wie Google Cloud, AWS oder Azure zu migrieren. Oft sind diese Anwendungen system-architektonisch indes noch nicht für eine dynamische Infrastruktur-Umgebung ausgelegt. Aber auch angesichts knapper Budgets und Sparzielen sind einige Anpassungen unbedingt zu empfehlen, weil sie sich, insbesondere bei größeren Applikationen, im Umfeld der agilen digitalen Transformation auch finanziell lohnen. Der Vortrag von Dr. Andreas Witsch zeigt, welche Fragen sich bei der Cloud-Migration stellen und wie wir sie sinnvoll beantworten. Zum Beispiel: Welche Anpassungen sind fachlich und technisch sinnvoll? Welche sind sogar gesetzlich notwendig? Welche Pitfalls sollten vermieden werden? Lohnt sich eine Migration - und wenn ja, in welchem Umfang?

Zielpublikum: Projektmanager, Softwarearchitekten
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Reinforcement Learning (RL) is a type of machine learning technique that enables to learn from experiences and interactions between intelligent agents and the environment. This ability is not naturally provided by classical supervised learning wherein the entire training process is based on past experiences. In RL, the training target is mainly formulated as composite rewards for the decisions made by agents at particular states (of the system in the problem environment). Over time, the agents learn to improve their future cumulative rewards which, depending on the problem being solved, can appear to address a particular case where a specific goal is achieved or an optimal state is reached. This phenomenon could help addressing the problems for which insufficient data or modeling knowledge is available and also problems with significant levels of uncertainly. In particular, such cases are referred to as partially observable problems and regarding the fact that most RL solutions are provided under the assumption of the Markov property, RL methods nowadays are most significantly incorporated to address Partially Observable Markov Decision Processes (POMDP). RL has recently had a significant contribution to robotic controllers at different industrial roles. For the lowest level, training robots how to grasp an object quickly with a correct amount of force and appropriate rotations of the hand-like end-effectors as well as the paths the serially connected prismatic arms should move through can be learned via the use of RL. For curious people in the field, Deep-mind has provided efficient simulation environments and diverse parametric functionality to facilitate an enhanced understanding of the problem space. In addition, RL can assist with even more complex situations, such as when there is a variety of sensory data, but insufficient knowledge about the environmental reaction to the decisions made by the robot. The RL-controller can learn how to improve its reward or reach its goal optimally by choosing appropriate actions and receiving the corresponding feedback from the environment. Siemens Corporate Technology is one of the many who used RL based robotic controllers to drive its manufacturing assembly processes. In general, in a real-world application of RL for robotic control, the process of building the RL controller begins with defining an appropriate reward, identifying appropriate state variables and listing action space. Selecting an appropriate RL method out of value based, policy based or mixed approaches such as actor-critic methods is the next step. Simulations are repeated in an episodical manner and the success of the developed controller in achieving the learning objectives can be monitored in the growth (or decline) of the value of the reward. RL has recently played a more significant role in providing decentralized and interconnected autonomous systems where multiple agents negotiate and cooperate to handle complex tasks and multi-objective problems. Such solutions are referred to as Multi-agent Reinforcement Learning (MARL). Depending on the problem, such environments are massively complex for humans to model and an appropriate solution cannot be achieved without dealing with the curse of dimensionality without the use of MARL techniques. Distributed manufacturing systems are the next generation of such application as a significant number of industrial and academic research projects have recently been undertaken on the topic. 

Wo finde ich die passenden MitgründerInnen? Wie finanzieren wir das Ganze? Wer sind unsere wichtigsten PartnerInnen? Wie baut man ein skalierbares Unternehmen auf? Wie positionieren wir uns und wer sind unsere KundInnen? Als Gründerin eines Tech und Design Startups aus Berlin, möchte ich gerne den Weg von der Idee, über die ersten entstanden Prototypen inklusive App-Entwicklung bis hin zum ready-to-use MVP mit euch teilen. Wie wichtig es ist, neben der Produktentwicklung auch das Storytelling, die Vision und das Team Alignment zu priorisieren. Welche Erfahrungen wir als all-female-in-tech Team mit dem Gender Investment Gap machen und was mögliche Lösungsansätze sind. Und wie wir über ein Lifestyle Produkt eine gesellschaftliche Diskussion über das Thema „Gewalt gegen Frauen“ aus einem neuen, empowernden Blickwinkel anregen wollen. Ich freue mich auf eine offene und anregende Diskussion und eure Fragen.

Hybrides Arbeiten, hybrid, was ist das eigentlich? Reaktionäre sagen, alle zusammen in der Firma, das wäre doch super. Alle remote, das wäre doch super, sagen die Corona-Berater-Opportunisten (dann muss man nicht mehr so viel reisen). Die Open-Sourcler lachen sich derweil einen Ast. Hybrid, also egal wann wo, das ist die Zukunft? Ne, gibt es schon. Und funktioniert. Und ist super! Und das nicht zu machen ist reaktionär!! Spätestens nun gibt es Streit zwischen Anke und Hannes. Fantastisch? Realistisch? Geschichten aus der Arbeitswelt verschiedener Firmen (_k_, intersoft, NewStore, LV1871, …).