Moderne Architekten machen erheblich mehr als UML Diagramme zeichnen oder Architekturstile zu katalogisieren. Sie liefern enormen Wert, indem sie die Unternehmensstrategie mit technischen Entscheidungen im Maschinenraum verknüpfen. Dies erfordert Fingerspitzengefühl und die Fähigkeit, komplexe technische Zusammenhänge und Abwägungen auf verschiedenen Ebene zu kommunizieren, ohne die Inhalte zu verwässern oder das Publikum zu verwirren. Dieser Talk hilft Architekten dabei, den “Architect Elevator” zwischen Maschinenraum zur Firmenleitung zu fahren.

Im Zuge der Modernisierung von Software-Landschaften werden Services (und damit die Code-Basis) immer kleiner.

Architekten sind mehr damit beschäftigt, die Kommunikation der Services untereinander in den Griff zu kriegen.

Für die Implementierung der einzelnen Services brauchen man ja (fast) keine Architektur, oder? Schwergewichtige Upfront-Architekturen sind doch meistens eh nur im Weg und verlangsamen den Entwicklungsprozess.

In der Session wollen wir diskutieren, wie viel Architektur innerhalb eines Microservices nötig ist und wie man diese gestalten kann, so dass sie bei der Umsetzung hilft und nicht im Weg ist.

Infrastructure as Code ist schon fast ein alter Hut, und gerade in der cloud-basierten Entwicklung im Mainstream angekommen. Mit Werkzeugen wie AWS CDK und Pulumi geht der Trend hierbei zu einem klaren Fokus auf „as Code“ - im Gegensatz zum bisher oft üblichen "as Configuration".

Auf der anderen Seite des * as Code Spektrums etabliert sich „Architecture as Code“. Mit Angeboten wie Structurizr ist es nun auch möglich, System- und Anwendungs-Architektur in Form von Code zu beschreiben und wie anderen Code zu versionieren. Dass aus diesem Architekturmodell auch hübsche Diagramme gerendert werden können, ist ein netter Nebeneffekt.

Dieser Vortrag geht auf verfügbare Frameworks ein, zeigt Beispiele und welche Vorteile daraus entstehen Architektur zu modellieren statt nur zu zeichnen.

Keycloak ist eine Open Source Lösung für Identity und Access Management, die seit vielen Jahren weltweit in großen und kleinen Installationen eingesetzt wird.

Von Anfang an unterstütze es relationalen Datenbanken via JPA/Hibernate. Über die Zeit kamen weitere Speichermöglichkeiten für Caching und ein In-Memory-Grid dazu, außerdem wurden Directory-Dienste wie LDAP integriert. Mit der Zeit verwoben sich die verschiedenen Bereiche, so dass neue Funktionen schwieriger umzusetzen waren.

Dieser Vortrag zeichnet die Aktivitäten auf der Architektur- und Technik-Ebene nach, mit denen die Bereiche entflochten und eine neue, flexible Storage-Struktur erstellt wurde. Diese ermöglicht unter anderem Zero-Downtime-Upgrades und skalierbare Installationen.

Der Sessiontitel ist Leitsatz des Persistenz-Managers JOOQ und Ausdruck der Grundeinstellung, dass SQL ein zu mächtiges Werkzeug ist, um es hinter komplizierten und dennoch einschränkenden Abstraktionen wie JPA zu verbergen. SQL-freies CRUD ist OK, aber ansonsten sollte keine Pseudo-Intelligenz zwischen dem Entwickler und der DB stehen und ein Gefühl von Kontrollverlust verbreiten. Für Web-UIs gibt es Micro-Frameworks, und auch für die Persistenz gibt es durchschaubare und magiefreie Frameworks wie PriDE und JOOQ. Small ist beautiful, und das merkt man besonders dann, wenn die Applikationen komplizierter und größer werden. Grund genug einmal vorzustellen, wie diese Dinger funktionieren und was sie so anders macht.

Der Vortrag stellt aktuelle Ansätze für die Sicherheitsbewertung auf Architekturebene vor. Häufig verwendete Muster für Architekturen werden auf ihre Sicherheitseigenschaften analysiert und grundlegen Prinzipien für sicheres Design vorgestellt. Ein vorgestellter Leitfaden gibt Hinweise für ein systematisches Vorgehen zur Erstellung sicherer Softwarearchitekturen. Als Werkzeuge zum praktischen Einsatz in der Sicherheitsanalyse von Architekturen kommen u.a. SonarQube und das Microsoft Threat Modelling Tool.

Maximale Teilnehmerzahl: 20

Architektur: Die soll doch das Stabile sein! Und die Wahl der richtigen Architektur sorgt dafür, dass die Software auch in Zukunft weiterentwickelt werden kann! Was zunächst sinnvoll erscheint, erweist sich in der Realität oft als erster Schritt hin zu einem Architektur-Fehlschlag. Wenn sich die Anforderungen, die Erkenntnisse oder die Technologien ändern, muss sich leider die Architektur auch ändern. Wie kann sie dann zukunftssicher sein? Diese Präsentation zeigt, wie das Paradoxon aufgelöst werden kann, und vielleicht keine zukunftssichere Architektur entsteht - aber langfristiger Projekterfolg.

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:

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.

Guckst du auf Wikipedia, es ist total doof beschrieben. Fragst du Leute auf der Straße, so haben die auch keine Ahnung was es ist. Nutzt du die Metapher Architekt, so trägt sie nicht weit. Was also ist der Softwarearchitekt in der Organisation wert?

Die technische Verantwortung innerhalb der Organisation trägt der CTO. Wie nun kann diese Verantwortung in die Teams und zu den Architekt:innen delegiert werden.

Topics:

• Organisationspattern
• Rollen in der Organisation
• Antipattern in Rolle und Organisation
• KPIs