SlideShare ist ein Scribd-Unternehmen logo
maketechsimple.wordpress.com@atsticks
Wie man Applikationen NICHT bauen
sollte…
Anatole Tresch, Principal Consultant ZH AD
2 2019 – Wie man Applikationen nicht bauen sollte...
Anatole Tresch
Principal Consultant, Trivadis AG (Switzerland)
Spec Lead JSR 352 (Money and Currency)
JSR 382 EG Member
PPMC Member Apache Tamaya
@atsticks
anatole@apache.org
anatole.tresch@trivadis.com
About me
3 2019 – Wie man Applikationen nicht bauen sollte...
Agenda
▪ Warum dieser Vortrag?
▪ Was so alles "schiefgehen" kann...
Bauplanung
Modularisierung
Know How
Management
Mensch
Organisation
▪ Das Resultat...
4 2019 – Wie man Applikationen nicht bauen sollte...
Warum dieser Vortrag?
• Immer wieder angetroffene Muster:
Erzeugen enorme unnötige Kosten
Beeinflussen die Qualität der IT-Leistung und damit die
Konkurrenzfähigkeit
Verhindern Innovation und Fortschritt
Erhöhen den Kaffeekonsum beträchtlich
5 2019 – Wie man Applikationen nicht bauen sollte...
Ziele des Vortrages?
• Ich wünsche mir, dass Sie am Ende des Vortrages
Gewisse Muster in Ihrem Arbeitsumfeld erkennen
Ideen haben, wie sie diese verbessern können
Einfache Lösungen suchen
Oder sich wenigstens wohlgefühlt haben
6 2019 – Wie man Applikationen nicht bauen sollte...
Bauplanung
7 2019 – Wie man Applikationen nicht bauen sollte...
Software-Architektur
• Komponenten/Bausteine mit Schnittstellen und Beziehungen
• Strukturen und übergreifende Konzepte
• Nutzen und Ziele
Langlebigkeit, Wartbarkeit, Änderbarkeit, Robustheit
Unterstützung Erstellung und Wartung von Software
Erreichung von Qualitätsanforderungen
Softwarearchitektur unterstützt das Verständnis über das System, bezogen auf
sämtliche relevanten Stakeholder
8 2019 – Wie man Applikationen nicht bauen sollte...
Wichtige Fragen
• Sind die Projektziele klar?
• Sind die Architekturziele definiert?
• Kennen die Architekten die Technologien?
• Ist das Entwicklungsteam qualifiziert?
• Sind übergreifende Aspekte gelöst?
• Passt die Projekt-Planung und Organisation zu den Zielen & Voraussetzungen?
9 2019 – Wie man Applikationen nicht bauen sollte...
Ziele?
• Beispiele:
Verbessern unseres Online-Auftrittes
Einführung von Kubernetes
Ablösen eines bestehenden Legacy-Systems.
24/7 Betrieb mit 97.7% Verfügbarkeit
«Cloud Native» Applikation
10 2019 – Wie man Applikationen nicht bauen sollte...
Module
11 2019 – Wie man Applikationen nicht bauen sollte...
Module
• Fundamentales Prinzip für die Konstruktion von Software-Systemen:
Wahl der Modularisierungs-Ebene
Bestimmung der dominanten Modularisierungs-Dimension
Berücksichtigung von Conways' Gesetz
Einsatz von Zerlegungskriterien
12 2019 – Wie man Applikationen nicht bauen sollte...
Modularisierungsebenen
• Methode
• Klasse (ohne Interface).
• Interface
• Package
• Bibliotheken
• Java-Module
• Anwendung (JVM)
• Container
• Pod
• Applikation (mehrere Pods)
• Cloud
• Multi-Cloud
13 2019 – Wie man Applikationen nicht bauen sollte...
Modularisierungsdimensionen
• Primäre Dimension meistens der Business Context (DDD)
• Sekundäre Dimensionen möglich, z.B. Aufteilung in internals, beans, api
• Bei mehreren gleichberechtigten Dimensionen kommen klassische Konzepte an
ihre Grenzen:
Aspekt-Orientierung
Interzeptoren
…
14 2019 – Wie man Applikationen nicht bauen sollte...
Das Gesetz von Conway
"Organisationen, die Systeme modellieren, […] sind auf Modelle
festgelegt, welche die Kommunikationsstrukturen dieser
Organisationen abbilden." [Conway1968]
15 2019 – Wie man Applikationen nicht bauen sollte...
Zerlegungskriterien
• Geheimnisprinzip
• Hohe Kohäsion
• Lose Kopplung
• Single-Responsibility
• Separation of Concerns
• "Don't Repeat Yourself!"
Ursprung: [Parnas1972] – On the Criteria To Be Used in Decomposing Systems into
Modules, David L. Parnas, in: Communications of the ACM, 1972
16 2019 – Wie man Applikationen nicht bauen sollte...
Know How
17 2019 – Wie man Applikationen nicht bauen sollte...
Know How
https://landscape.cncf.io/
18 2019 – Wie man Applikationen nicht bauen sollte...
Hmmm...
19 2019 – Wie man Applikationen nicht bauen sollte...
"Es macht keinen Sinn, kluge Köpfe einzustellen und ihnen
dann zu sagen, was sie zu tun haben. Wir stellen kluge
Köpfe ein, damit sie uns sagen, was wir tun können."
Stephe Jobs, CEO, Apple
20 2019 – Wie man Applikationen nicht bauen sollte...
Management
21 2019 – Wie man Applikationen nicht bauen sollte...
Probleme im Management
Fehlende/unpassende Skills
Unrealistische Zeitvorgaben und fehlende Ressourcen
Replanning und Micromanagement
Hohe Fluktuation
Unklarer Aufträge («Agiles Projekt»)
Unklare Verantwortlichkeiten, fehlende Prozesse
Fehlende Anreize
22 2019 – Wie man Applikationen nicht bauen sollte...
Faktor Mensch
23 2019 – Wie man Applikationen nicht bauen sollte...
Faktor Mensch
• Gute Programmierer sind faul
• Gute Programmierer schätzen und fordern Qualität
• Gute Programmierer sind 10-100 Mal effizienter als schlechte
• Gute Programmierer sind manchmal auch kleine Diven
• Gute Programmierer sind … ?
• Gute Manager sind...?
• Gute Leader sind...?
• Gute Menschen sind...?
24 2019 – Wie man Applikationen nicht bauen sollte...
Faktor Mensch
String reportType;
reportType = VERTRAGSSTADIUM.$1.equals(vertrag.getStadium()) ? Report.VORS : null;
reportType = VERTRAGSSTADIUM.$2.equals(vertrag.getStadium()) ? Report.ANTRAG : null;
switch (vertrag.getStadium()) {
case VERTRAGSSTADIUM.$1:
reportType = Report.VORS;
Break;
case VERTRAGSSTADIUM.$2:
reportType = Report.ANTRAG;
break;
}
25 2019 – Wie man Applikationen nicht bauen sollte...
Faktor Mensch
return bo.getDokument() != null && bo.getArchivDetail() != null
&& DOKUMENTABLAGE_ART.C.equals(bo.getDokument().getDokablart())
? new Blob(FilenetClient.getInstance().retrieveDocument(DocumentClass.GFB,
bo.getSession().getUserId(),
bo.getArchivDetail().toString()))
:
bo.extractBlob();
26 2019 – Wie man Applikationen nicht bauen sollte...
Organisation
27 2019 – Wie man Applikationen nicht bauen sollte...
Organisation
Können wir morgen einen Release bauen?
Da muss ich mal mit dem Buildmanagement
reden.
Und sind die Übersetzungen nun durch das
Backend-Team gefixt?
Können wir denn auch
deployen Ende Woche.
Ja, ich glaube, wir haben eine
Lieferung erhalten, ich muss testen, ob es
nun funktioniert.
Wohl kaum, es ist kein Slot reserviert
worden bei Operations und
das Buidmanagement ist eh überlastet.
28 2019 – Wie man Applikationen nicht bauen sollte...
Organisation
Können wir nicht einfach bei Azure einen
private Cluster bestellen?
Nein das geht nicht, wir müssen die Systeme
des Mutterhauses benützen.
Aber die funktionieren nicht richtig, oder
hast du schon mal was zum Laufen
gekriegt?
Ist totmühsam, ja, aber wir müssen diese
benutzen: ist einfach so.
29 2019 – Wie man Applikationen nicht bauen sollte...
Organisation
Können wir nicht einfach einen Kubernetes
Cluster hinstellen, statt uns täglich bis zum
Umfallen manuell zu deployen.
Nein das geht nicht, du weisst ja, dass Hans
unser IT-Leiter Mitgründer ist, und halt auch
noch von der alten Schule. Der hält nichts
von dem neuen Kram...
30 2019 – Wie man Applikationen nicht bauen sollte...
Organisation
Können wir nicht einfach das RAM auf den
Servern erhöhen? Das wäre eine kleine
Sache und die Probleme wären gelöst...
Ich befürchte, dass mit den Prozessen hier,
wohl zuerst noch das Wasser aufwärts
fliessen wird...
...könnt ihr das nicht bei Euch in der Software
fixen?
31 2019 – Wie man Applikationen nicht bauen sollte...
Organisation
Wo ist den Beni heute?
Keine Ahnung. Wir werden das wohl
eskalieren müssen. Sonst wir das nichts mit
dem Release nächste Woche...
Und Bea und Remo?
OK, und wer kann den jetzt unsere Backend-
Bugs analysieren?
Der ist nicht mehr im Projekt, arbeitet jetzt
oben bei den Betriebskollegen...
Die kommen später, sind aber auch nur noch
heute da...
32 2019 – Wie man Applikationen nicht bauen sollte...
Das Resultat...
33 2019 – Wie man Applikationen nicht bauen sollte...
Ein Beispiel
• Applikation zur Ablösung eines bestehenden Fat Client im Versicherungsumfeld
• Benutzer Makler, Vermittler, Partner und Direktions-MA
-> Max. 40 parallele Benutzer
• Mehrstufiger Ausbau, Start mit Motorfahrzeug-Sparte
34 2019 – Wie man Applikationen nicht bauen sollte...
Architekturziel
• «Moderne» browser-basierte Applikation
• Basis Java
• Bestehendes Backend-System muss verwendet werden
• Betrieb auf eigener Infrastruktur
• Performanz nicht schlechter oder besser als bestehendes System
• "Blueprint" auch für andere Applikationen
35 2019 – Wie man Applikationen nicht bauen sollte...
System-Kontext
36 2019 – Wie man Applikationen nicht bauen sollte...
Architekturentscheide
• Angular-basiertes Single-Page-UI
• SpringBoot/Java 8
• Maven Build
• Versionsverwaltung mit Subversion
• Laufzeit: Bestehende JBoss-Server
• "Stateless": State wird im UI verwaltet
• UI/Business Layer benutzt eigenen ValueObject-Layer
• Generalisierte Funktionen als Microservices
• Projekt soll auch wiederverwendbare Artifakte für andere Projekte liefern
37 2019 – Wie man Applikationen nicht bauen sollte...
Reality-Check
• SpringBoot/Java 8
• Laufzeit: Bestehende JBoss-Server
-> Spring Boot verhält sich Standalone, in Tomcat und in JBoss nicht immer gleich
-> Deployment durch eigenes (überlastetes) Build-Management Team
-> Keine clean deployments, marginale Prozesskontrollen
-> Kein Applikationsmonitoring
-> Intrasparente Security Mechanismen
38 2019 – Wie man Applikationen nicht bauen sollte...
Reality-Check
• Projekt soll auch wiederverwandbare Artifakte für andere Projekte liefern
-> Generalisierte Funktionalität, Bibliotheken und Applikationsartifakte in einem
einzigen Maven-Multimodule-Projekt/Repository
-> Vermischung mit Deployment-Artifakten des Build-Management
-> Keine Architekturvision
• -> keine separate Versionierung generalisierter Artifakte und Applikationen
39 2019 – Wie man Applikationen nicht bauen sollte...
Reality-Check
• "Stateless": State wird im UI verwaltet
• UI benutzt eigenen ValueObject-Layer
-> Alle Benutzerdaten gehen bei UI-Absturz verloren
-> Legacy Backend verlangt Vorhalten des ganzen Arbeitskontextes
-> Hohe Komplexität im UI
-> RPC-artige Schnittstelle zum Business-Tier
-> Duplizierung der Backend Logik auf dem Business-Tier
40 2019 – Wie man Applikationen nicht bauen sollte...
Reality-Check
• Angular-basiertes Single-Page-UI
-> eigenes UI Team/UI Projekt
-> höhere Komplexität und Kommunikationsaufwendungen
-> bei 40 parallelen Benutzern technisch nicht nötig
41 2019 – Wie man Applikationen nicht bauen sollte...
Reality-Check
• Versionsverwaltung: Subversion
-> Mehrere Projekt-Teams auf demselben Repository
-> Qualitäts- und Stabilitätsprobleme
-> Enorme Merge-Aufwendungen
42 2019 – Wie man Applikationen nicht bauen sollte...
Problembereich Backend
43 2019 – Wie man Applikationen nicht bauen sollte...
Backend - Database
• Versionierung Datenbank ausserhalb Kontrolle des Projektteams
• Regelmässige Updates
• Oft mit unvorhergesehenen Verhaltensänderungen verbunden
• Termine nur sehr eingeschränkt beeinflussbar
• Update-Zwang
44 2019 – Wie man Applikationen nicht bauen sollte...
Backend – Legacy-Server
• Komplexe Eclipse OSGI basierte Installation
• Intransparente Architektur
• Regelmässige Serverupdates (parallel zu DB) mit Verhaltensänderungen und
gebrochenen Schnittstellen
• Erweiterungen/Anpassungen unter Kontrolle des Server-Teams (Antrags-gesteuert)
• Eingeschränkt skalierfähig (pro 5 Benutzer = 1 Instanz)
• Nur spezifische Bereiche unter Kontrolle Applikations-Projektteam
45 2019 – Wie man Applikationen nicht bauen sollte...
Das Resultat...
46 2019 – Wie man Applikationen nicht bauen sollte...
Erreichte Verbesserungen
47 2019 – Wie man Applikationen nicht bauen sollte...
Erreichte Verbesserungen
• Vereinfachung/Entkopplung des Maven Build-Baums, Minimalisierung der
Querabhängigkeiten, Entfernung von Redundanzen
• Halbierung der benötigten Deployments
• Einführung eines Spring-basierten Modulkonzeptes
• Definition von Service-Schnittstellen
• Reduktion des manuell zu wartenden Codes durch
• Entfernen eines VO-Layers
• Generierung Swagger Client-API
48 2019 – Wie man Applikationen nicht bauen sollte...
Erreichte Verbesserungen
49 2019 – Wie man Applikationen nicht bauen sollte... 49
⚫ Recap!
50 2019 – Wie man Applikationen nicht bauen sollte... 50
Recap
• Managementprobleme potenzieren sich in der IT-Entwicklung
• Overengineering und funktionale Zersplitterung sind des Teufels
• Falsche Anreize wirken extrem demotivierend
• Trotzdem ist vieles möglich mit
Entsprechendem Know How
Ein wenig Durchsetzungsvermögen
Und Mut!
51 2019 – Wie man Applikationen nicht bauen sollte...
DANKE!
Q&A
@atsticks
Anatole.tresch@trivadis.com

Weitere ähnliche Inhalte

Ähnlich wie Wie man Applikationen nicht bauen sollte...

Skalierung & Performance
Skalierung & PerformanceSkalierung & Performance
Skalierung & Performance
glembotzky
 
Roadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'sRoadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht's
camunda services GmbH
 
Digitale Zusammenarbeit - Anwendungsfälle und Erfolgsfaktoren
Digitale Zusammenarbeit - Anwendungsfälle und ErfolgsfaktorenDigitale Zusammenarbeit - Anwendungsfälle und Erfolgsfaktoren
Digitale Zusammenarbeit - Anwendungsfälle und Erfolgsfaktoren
Beck et al. GmbH
 
Erfolgsfaktoren der Wikieinführung in KMU
Erfolgsfaktoren der Wikieinführung in KMUErfolgsfaktoren der Wikieinführung in KMU
Erfolgsfaktoren der Wikieinführung in KMU
Martin Koser
 
2010 10-28-dms expo-mk-v2.pptx
2010 10-28-dms expo-mk-v2.pptx2010 10-28-dms expo-mk-v2.pptx
2010 10-28-dms expo-mk-v2.pptx
Forschungsgruppe Kooperationssysteme
 
ASP.NET Core – Troublemaker oder Problemsolver?
ASP.NET Core – Troublemaker oder Problemsolver?ASP.NET Core – Troublemaker oder Problemsolver?
ASP.NET Core – Troublemaker oder Problemsolver?
POINT. Consulting GmbH
 
CON•ECT Business Academy Katalog 2018/19
CON•ECT Business Academy Katalog 2018/19CON•ECT Business Academy Katalog 2018/19
CON•ECT Business Academy Katalog 2018/19
CON.ECT Eventmanagement
 
Teil 1 - BIM Planung die Spass macht
Teil 1 - BIM Planung die Spass machtTeil 1 - BIM Planung die Spass macht
Teil 1 - BIM Planung die Spass macht
Clive Jordan - fighter of Evil BIM
 
SAP IdM Wartungsende 2027... und was nun?
SAP IdM Wartungsende 2027... und was nun?SAP IdM Wartungsende 2027... und was nun?
SAP IdM Wartungsende 2027... und was nun?
IBsolution GmbH
 
Management of the system architecture in large-scale projects
Management of the system architecture in large-scale projectsManagement of the system architecture in large-scale projects
Management of the system architecture in large-scale projects
Capgemini
 
IBM Connections im Business Einsatz - Webinar 2 der IBM Connections Webinarreihe
IBM Connections im Business Einsatz - Webinar 2 der IBM Connections WebinarreiheIBM Connections im Business Einsatz - Webinar 2 der IBM Connections Webinarreihe
IBM Connections im Business Einsatz - Webinar 2 der IBM Connections Webinarreihe
Beck et al. GmbH
 
C Level Brunch Timo Salzsieder "Herausforderungen moderner Plattformen"
C Level Brunch Timo Salzsieder "Herausforderungen moderner Plattformen"C Level Brunch Timo Salzsieder "Herausforderungen moderner Plattformen"
C Level Brunch Timo Salzsieder "Herausforderungen moderner Plattformen"
TFT TIE Kinetix GmbH
 
IAK13 Darwin und die Kreativen
IAK13 Darwin und die KreativenIAK13 Darwin und die Kreativen
IAK13 Darwin und die Kreativen
Webster59
 
Vom Hype zur gelebten Normalität Wie entsteht echter Nutzen durch Web 2.0 im...
Vom Hype zur gelebten NormalitätWie entsteht echter Nutzen durch Web 2.0 im...Vom Hype zur gelebten NormalitätWie entsteht echter Nutzen durch Web 2.0 im...
Vom Hype zur gelebten Normalität Wie entsteht echter Nutzen durch Web 2.0 im...
Telekom MMS
 
Anleitung zum Handeln: Wissensmanagement im Enterprise 2.0
Anleitung zum Handeln: Wissensmanagement im Enterprise 2.0Anleitung zum Handeln: Wissensmanagement im Enterprise 2.0
Anleitung zum Handeln: Wissensmanagement im Enterprise 2.0
SoftwareSaxony
 
SharePoint Forum Stuttgart 2019 - Beitrag Beck et al.
SharePoint Forum Stuttgart 2019 - Beitrag Beck et al. SharePoint Forum Stuttgart 2019 - Beitrag Beck et al.
SharePoint Forum Stuttgart 2019 - Beitrag Beck et al.
Beck et al. GmbH
 
Business Turbo Enterprise 2.0 Qualysoft
Business Turbo Enterprise 2.0 QualysoftBusiness Turbo Enterprise 2.0 Qualysoft
Business Turbo Enterprise 2.0 Qualysoft
Joseph A. Bayer
 
DevOps: Revolution im IT Betrieb?
DevOps: Revolution im IT Betrieb?DevOps: Revolution im IT Betrieb?
DevOps: Revolution im IT Betrieb?
Digicomp Academy AG
 

Ähnlich wie Wie man Applikationen nicht bauen sollte... (20)

Skalierung & Performance
Skalierung & PerformanceSkalierung & Performance
Skalierung & Performance
 
Roadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'sRoadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht's
 
Digitale Zusammenarbeit - Anwendungsfälle und Erfolgsfaktoren
Digitale Zusammenarbeit - Anwendungsfälle und ErfolgsfaktorenDigitale Zusammenarbeit - Anwendungsfälle und Erfolgsfaktoren
Digitale Zusammenarbeit - Anwendungsfälle und Erfolgsfaktoren
 
Erfolgsfaktoren der Wikieinführung in KMU
Erfolgsfaktoren der Wikieinführung in KMUErfolgsfaktoren der Wikieinführung in KMU
Erfolgsfaktoren der Wikieinführung in KMU
 
2010 10-28-dms expo-mk-v2.pptx
2010 10-28-dms expo-mk-v2.pptx2010 10-28-dms expo-mk-v2.pptx
2010 10-28-dms expo-mk-v2.pptx
 
ASP.NET Core – Troublemaker oder Problemsolver?
ASP.NET Core – Troublemaker oder Problemsolver?ASP.NET Core – Troublemaker oder Problemsolver?
ASP.NET Core – Troublemaker oder Problemsolver?
 
CON•ECT Business Academy Katalog 2018/19
CON•ECT Business Academy Katalog 2018/19CON•ECT Business Academy Katalog 2018/19
CON•ECT Business Academy Katalog 2018/19
 
Teil 1 - BIM Planung die Spass macht
Teil 1 - BIM Planung die Spass machtTeil 1 - BIM Planung die Spass macht
Teil 1 - BIM Planung die Spass macht
 
20110203 jug stuttgart
20110203 jug stuttgart20110203 jug stuttgart
20110203 jug stuttgart
 
SAP IdM Wartungsende 2027... und was nun?
SAP IdM Wartungsende 2027... und was nun?SAP IdM Wartungsende 2027... und was nun?
SAP IdM Wartungsende 2027... und was nun?
 
Management of the system architecture in large-scale projects
Management of the system architecture in large-scale projectsManagement of the system architecture in large-scale projects
Management of the system architecture in large-scale projects
 
IBM Connections im Business Einsatz - Webinar 2 der IBM Connections Webinarreihe
IBM Connections im Business Einsatz - Webinar 2 der IBM Connections WebinarreiheIBM Connections im Business Einsatz - Webinar 2 der IBM Connections Webinarreihe
IBM Connections im Business Einsatz - Webinar 2 der IBM Connections Webinarreihe
 
C Level Brunch Timo Salzsieder "Herausforderungen moderner Plattformen"
C Level Brunch Timo Salzsieder "Herausforderungen moderner Plattformen"C Level Brunch Timo Salzsieder "Herausforderungen moderner Plattformen"
C Level Brunch Timo Salzsieder "Herausforderungen moderner Plattformen"
 
IAK13 Darwin und die Kreativen
IAK13 Darwin und die KreativenIAK13 Darwin und die Kreativen
IAK13 Darwin und die Kreativen
 
Vom Hype zur gelebten Normalität Wie entsteht echter Nutzen durch Web 2.0 im...
Vom Hype zur gelebten NormalitätWie entsteht echter Nutzen durch Web 2.0 im...Vom Hype zur gelebten NormalitätWie entsteht echter Nutzen durch Web 2.0 im...
Vom Hype zur gelebten Normalität Wie entsteht echter Nutzen durch Web 2.0 im...
 
Anleitung zum Handeln: Wissensmanagement im Enterprise 2.0
Anleitung zum Handeln: Wissensmanagement im Enterprise 2.0Anleitung zum Handeln: Wissensmanagement im Enterprise 2.0
Anleitung zum Handeln: Wissensmanagement im Enterprise 2.0
 
SharePoint Forum Stuttgart 2019 - Beitrag Beck et al.
SharePoint Forum Stuttgart 2019 - Beitrag Beck et al. SharePoint Forum Stuttgart 2019 - Beitrag Beck et al.
SharePoint Forum Stuttgart 2019 - Beitrag Beck et al.
 
Business Turbo Enterprise 2.0 Qualysoft
Business Turbo Enterprise 2.0 QualysoftBusiness Turbo Enterprise 2.0 Qualysoft
Business Turbo Enterprise 2.0 Qualysoft
 
DevOps: Revolution im IT Betrieb?
DevOps: Revolution im IT Betrieb?DevOps: Revolution im IT Betrieb?
DevOps: Revolution im IT Betrieb?
 
20110223 activiti
20110223 activiti20110223 activiti
20110223 activiti
 

Mehr von Anatole Tresch

Jsr382: Konfiguration in Java
Jsr382: Konfiguration in JavaJsr382: Konfiguration in Java
Jsr382: Konfiguration in Java
Anatole Tresch
 
The Gib Five - Modern IT Architecture
The Gib Five - Modern IT ArchitectureThe Gib Five - Modern IT Architecture
The Gib Five - Modern IT Architecture
Anatole Tresch
 
The Big Five - IT Architektur Heute
The Big Five - IT Architektur HeuteThe Big Five - IT Architektur Heute
The Big Five - IT Architektur Heute
Anatole Tresch
 
Microservices in Java
Microservices in JavaMicroservices in Java
Microservices in Java
Anatole Tresch
 
Disruption is Change is Future
Disruption is Change is FutureDisruption is Change is Future
Disruption is Change is Future
Anatole Tresch
 
Configuration with Microprofile and Apache Tamaya
Configuration with Microprofile and Apache TamayaConfiguration with Microprofile and Apache Tamaya
Configuration with Microprofile and Apache Tamaya
Anatole Tresch
 
Configuration beyond Java EE 8
Configuration beyond Java EE 8Configuration beyond Java EE 8
Configuration beyond Java EE 8
Anatole Tresch
 
Alles Docker oder Was ?
Alles Docker oder Was ?Alles Docker oder Was ?
Alles Docker oder Was ?
Anatole Tresch
 
Going Resilient...
Going Resilient...Going Resilient...
Going Resilient...
Anatole Tresch
 
Configure once, run everywhere 2016
Configure once, run everywhere 2016Configure once, run everywhere 2016
Configure once, run everywhere 2016
Anatole Tresch
 
Configuration with Apache Tamaya
Configuration with Apache TamayaConfiguration with Apache Tamaya
Configuration with Apache Tamaya
Anatole Tresch
 
Wie Monolithen für die Zukuft trimmen
Wie Monolithen für die Zukuft trimmenWie Monolithen für die Zukuft trimmen
Wie Monolithen für die Zukuft trimmen
Anatole Tresch
 
Configure Your Projects with Apache Tamaya
Configure Your Projects with Apache TamayaConfigure Your Projects with Apache Tamaya
Configure Your Projects with Apache Tamaya
Anatole Tresch
 
JSR 354 Hackday - What you can do...
JSR 354 Hackday - What you can do...JSR 354 Hackday - What you can do...
JSR 354 Hackday - What you can do...
Anatole Tresch
 
Legacy Renewal of Central Framework in the Enterprise
Legacy Renewal of Central Framework in the EnterpriseLegacy Renewal of Central Framework in the Enterprise
Legacy Renewal of Central Framework in the Enterprise
Anatole Tresch
 
Go for the Money: eine Einführung in JSR 354 - Java aktuell 2014 - Anatole Tr...
Go for the Money: eine Einführung in JSR 354 - Java aktuell 2014 - Anatole Tr...Go for the Money: eine Einführung in JSR 354 - Java aktuell 2014 - Anatole Tr...
Go for the Money: eine Einführung in JSR 354 - Java aktuell 2014 - Anatole Tr...
Anatole Tresch
 
A first Draft to Java Configuration
A first Draft to Java ConfigurationA first Draft to Java Configuration
A first Draft to Java Configuration
Anatole Tresch
 
JSR 354 LJC-Hackday
JSR 354 LJC-HackdayJSR 354 LJC-Hackday
JSR 354 LJC-Hackday
Anatole Tresch
 
Adopt JSR 354
Adopt JSR 354Adopt JSR 354
Adopt JSR 354
Anatole Tresch
 
Go for the Money - JSR 354
Go for the Money - JSR 354Go for the Money - JSR 354
Go for the Money - JSR 354
Anatole Tresch
 

Mehr von Anatole Tresch (20)

Jsr382: Konfiguration in Java
Jsr382: Konfiguration in JavaJsr382: Konfiguration in Java
Jsr382: Konfiguration in Java
 
The Gib Five - Modern IT Architecture
The Gib Five - Modern IT ArchitectureThe Gib Five - Modern IT Architecture
The Gib Five - Modern IT Architecture
 
The Big Five - IT Architektur Heute
The Big Five - IT Architektur HeuteThe Big Five - IT Architektur Heute
The Big Five - IT Architektur Heute
 
Microservices in Java
Microservices in JavaMicroservices in Java
Microservices in Java
 
Disruption is Change is Future
Disruption is Change is FutureDisruption is Change is Future
Disruption is Change is Future
 
Configuration with Microprofile and Apache Tamaya
Configuration with Microprofile and Apache TamayaConfiguration with Microprofile and Apache Tamaya
Configuration with Microprofile and Apache Tamaya
 
Configuration beyond Java EE 8
Configuration beyond Java EE 8Configuration beyond Java EE 8
Configuration beyond Java EE 8
 
Alles Docker oder Was ?
Alles Docker oder Was ?Alles Docker oder Was ?
Alles Docker oder Was ?
 
Going Resilient...
Going Resilient...Going Resilient...
Going Resilient...
 
Configure once, run everywhere 2016
Configure once, run everywhere 2016Configure once, run everywhere 2016
Configure once, run everywhere 2016
 
Configuration with Apache Tamaya
Configuration with Apache TamayaConfiguration with Apache Tamaya
Configuration with Apache Tamaya
 
Wie Monolithen für die Zukuft trimmen
Wie Monolithen für die Zukuft trimmenWie Monolithen für die Zukuft trimmen
Wie Monolithen für die Zukuft trimmen
 
Configure Your Projects with Apache Tamaya
Configure Your Projects with Apache TamayaConfigure Your Projects with Apache Tamaya
Configure Your Projects with Apache Tamaya
 
JSR 354 Hackday - What you can do...
JSR 354 Hackday - What you can do...JSR 354 Hackday - What you can do...
JSR 354 Hackday - What you can do...
 
Legacy Renewal of Central Framework in the Enterprise
Legacy Renewal of Central Framework in the EnterpriseLegacy Renewal of Central Framework in the Enterprise
Legacy Renewal of Central Framework in the Enterprise
 
Go for the Money: eine Einführung in JSR 354 - Java aktuell 2014 - Anatole Tr...
Go for the Money: eine Einführung in JSR 354 - Java aktuell 2014 - Anatole Tr...Go for the Money: eine Einführung in JSR 354 - Java aktuell 2014 - Anatole Tr...
Go for the Money: eine Einführung in JSR 354 - Java aktuell 2014 - Anatole Tr...
 
A first Draft to Java Configuration
A first Draft to Java ConfigurationA first Draft to Java Configuration
A first Draft to Java Configuration
 
JSR 354 LJC-Hackday
JSR 354 LJC-HackdayJSR 354 LJC-Hackday
JSR 354 LJC-Hackday
 
Adopt JSR 354
Adopt JSR 354Adopt JSR 354
Adopt JSR 354
 
Go for the Money - JSR 354
Go for the Money - JSR 354Go for the Money - JSR 354
Go for the Money - JSR 354
 

Wie man Applikationen nicht bauen sollte...

  • 1. maketechsimple.wordpress.com@atsticks Wie man Applikationen NICHT bauen sollte… Anatole Tresch, Principal Consultant ZH AD
  • 2. 2 2019 – Wie man Applikationen nicht bauen sollte... Anatole Tresch Principal Consultant, Trivadis AG (Switzerland) Spec Lead JSR 352 (Money and Currency) JSR 382 EG Member PPMC Member Apache Tamaya @atsticks anatole@apache.org anatole.tresch@trivadis.com About me
  • 3. 3 2019 – Wie man Applikationen nicht bauen sollte... Agenda ▪ Warum dieser Vortrag? ▪ Was so alles "schiefgehen" kann... Bauplanung Modularisierung Know How Management Mensch Organisation ▪ Das Resultat...
  • 4. 4 2019 – Wie man Applikationen nicht bauen sollte... Warum dieser Vortrag? • Immer wieder angetroffene Muster: Erzeugen enorme unnötige Kosten Beeinflussen die Qualität der IT-Leistung und damit die Konkurrenzfähigkeit Verhindern Innovation und Fortschritt Erhöhen den Kaffeekonsum beträchtlich
  • 5. 5 2019 – Wie man Applikationen nicht bauen sollte... Ziele des Vortrages? • Ich wünsche mir, dass Sie am Ende des Vortrages Gewisse Muster in Ihrem Arbeitsumfeld erkennen Ideen haben, wie sie diese verbessern können Einfache Lösungen suchen Oder sich wenigstens wohlgefühlt haben
  • 6. 6 2019 – Wie man Applikationen nicht bauen sollte... Bauplanung
  • 7. 7 2019 – Wie man Applikationen nicht bauen sollte... Software-Architektur • Komponenten/Bausteine mit Schnittstellen und Beziehungen • Strukturen und übergreifende Konzepte • Nutzen und Ziele Langlebigkeit, Wartbarkeit, Änderbarkeit, Robustheit Unterstützung Erstellung und Wartung von Software Erreichung von Qualitätsanforderungen Softwarearchitektur unterstützt das Verständnis über das System, bezogen auf sämtliche relevanten Stakeholder
  • 8. 8 2019 – Wie man Applikationen nicht bauen sollte... Wichtige Fragen • Sind die Projektziele klar? • Sind die Architekturziele definiert? • Kennen die Architekten die Technologien? • Ist das Entwicklungsteam qualifiziert? • Sind übergreifende Aspekte gelöst? • Passt die Projekt-Planung und Organisation zu den Zielen & Voraussetzungen?
  • 9. 9 2019 – Wie man Applikationen nicht bauen sollte... Ziele? • Beispiele: Verbessern unseres Online-Auftrittes Einführung von Kubernetes Ablösen eines bestehenden Legacy-Systems. 24/7 Betrieb mit 97.7% Verfügbarkeit «Cloud Native» Applikation
  • 10. 10 2019 – Wie man Applikationen nicht bauen sollte... Module
  • 11. 11 2019 – Wie man Applikationen nicht bauen sollte... Module • Fundamentales Prinzip für die Konstruktion von Software-Systemen: Wahl der Modularisierungs-Ebene Bestimmung der dominanten Modularisierungs-Dimension Berücksichtigung von Conways' Gesetz Einsatz von Zerlegungskriterien
  • 12. 12 2019 – Wie man Applikationen nicht bauen sollte... Modularisierungsebenen • Methode • Klasse (ohne Interface). • Interface • Package • Bibliotheken • Java-Module • Anwendung (JVM) • Container • Pod • Applikation (mehrere Pods) • Cloud • Multi-Cloud
  • 13. 13 2019 – Wie man Applikationen nicht bauen sollte... Modularisierungsdimensionen • Primäre Dimension meistens der Business Context (DDD) • Sekundäre Dimensionen möglich, z.B. Aufteilung in internals, beans, api • Bei mehreren gleichberechtigten Dimensionen kommen klassische Konzepte an ihre Grenzen: Aspekt-Orientierung Interzeptoren …
  • 14. 14 2019 – Wie man Applikationen nicht bauen sollte... Das Gesetz von Conway "Organisationen, die Systeme modellieren, […] sind auf Modelle festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden." [Conway1968]
  • 15. 15 2019 – Wie man Applikationen nicht bauen sollte... Zerlegungskriterien • Geheimnisprinzip • Hohe Kohäsion • Lose Kopplung • Single-Responsibility • Separation of Concerns • "Don't Repeat Yourself!" Ursprung: [Parnas1972] – On the Criteria To Be Used in Decomposing Systems into Modules, David L. Parnas, in: Communications of the ACM, 1972
  • 16. 16 2019 – Wie man Applikationen nicht bauen sollte... Know How
  • 17. 17 2019 – Wie man Applikationen nicht bauen sollte... Know How https://landscape.cncf.io/
  • 18. 18 2019 – Wie man Applikationen nicht bauen sollte... Hmmm...
  • 19. 19 2019 – Wie man Applikationen nicht bauen sollte... "Es macht keinen Sinn, kluge Köpfe einzustellen und ihnen dann zu sagen, was sie zu tun haben. Wir stellen kluge Köpfe ein, damit sie uns sagen, was wir tun können." Stephe Jobs, CEO, Apple
  • 20. 20 2019 – Wie man Applikationen nicht bauen sollte... Management
  • 21. 21 2019 – Wie man Applikationen nicht bauen sollte... Probleme im Management Fehlende/unpassende Skills Unrealistische Zeitvorgaben und fehlende Ressourcen Replanning und Micromanagement Hohe Fluktuation Unklarer Aufträge («Agiles Projekt») Unklare Verantwortlichkeiten, fehlende Prozesse Fehlende Anreize
  • 22. 22 2019 – Wie man Applikationen nicht bauen sollte... Faktor Mensch
  • 23. 23 2019 – Wie man Applikationen nicht bauen sollte... Faktor Mensch • Gute Programmierer sind faul • Gute Programmierer schätzen und fordern Qualität • Gute Programmierer sind 10-100 Mal effizienter als schlechte • Gute Programmierer sind manchmal auch kleine Diven • Gute Programmierer sind … ? • Gute Manager sind...? • Gute Leader sind...? • Gute Menschen sind...?
  • 24. 24 2019 – Wie man Applikationen nicht bauen sollte... Faktor Mensch String reportType; reportType = VERTRAGSSTADIUM.$1.equals(vertrag.getStadium()) ? Report.VORS : null; reportType = VERTRAGSSTADIUM.$2.equals(vertrag.getStadium()) ? Report.ANTRAG : null; switch (vertrag.getStadium()) { case VERTRAGSSTADIUM.$1: reportType = Report.VORS; Break; case VERTRAGSSTADIUM.$2: reportType = Report.ANTRAG; break; }
  • 25. 25 2019 – Wie man Applikationen nicht bauen sollte... Faktor Mensch return bo.getDokument() != null && bo.getArchivDetail() != null && DOKUMENTABLAGE_ART.C.equals(bo.getDokument().getDokablart()) ? new Blob(FilenetClient.getInstance().retrieveDocument(DocumentClass.GFB, bo.getSession().getUserId(), bo.getArchivDetail().toString())) : bo.extractBlob();
  • 26. 26 2019 – Wie man Applikationen nicht bauen sollte... Organisation
  • 27. 27 2019 – Wie man Applikationen nicht bauen sollte... Organisation Können wir morgen einen Release bauen? Da muss ich mal mit dem Buildmanagement reden. Und sind die Übersetzungen nun durch das Backend-Team gefixt? Können wir denn auch deployen Ende Woche. Ja, ich glaube, wir haben eine Lieferung erhalten, ich muss testen, ob es nun funktioniert. Wohl kaum, es ist kein Slot reserviert worden bei Operations und das Buidmanagement ist eh überlastet.
  • 28. 28 2019 – Wie man Applikationen nicht bauen sollte... Organisation Können wir nicht einfach bei Azure einen private Cluster bestellen? Nein das geht nicht, wir müssen die Systeme des Mutterhauses benützen. Aber die funktionieren nicht richtig, oder hast du schon mal was zum Laufen gekriegt? Ist totmühsam, ja, aber wir müssen diese benutzen: ist einfach so.
  • 29. 29 2019 – Wie man Applikationen nicht bauen sollte... Organisation Können wir nicht einfach einen Kubernetes Cluster hinstellen, statt uns täglich bis zum Umfallen manuell zu deployen. Nein das geht nicht, du weisst ja, dass Hans unser IT-Leiter Mitgründer ist, und halt auch noch von der alten Schule. Der hält nichts von dem neuen Kram...
  • 30. 30 2019 – Wie man Applikationen nicht bauen sollte... Organisation Können wir nicht einfach das RAM auf den Servern erhöhen? Das wäre eine kleine Sache und die Probleme wären gelöst... Ich befürchte, dass mit den Prozessen hier, wohl zuerst noch das Wasser aufwärts fliessen wird... ...könnt ihr das nicht bei Euch in der Software fixen?
  • 31. 31 2019 – Wie man Applikationen nicht bauen sollte... Organisation Wo ist den Beni heute? Keine Ahnung. Wir werden das wohl eskalieren müssen. Sonst wir das nichts mit dem Release nächste Woche... Und Bea und Remo? OK, und wer kann den jetzt unsere Backend- Bugs analysieren? Der ist nicht mehr im Projekt, arbeitet jetzt oben bei den Betriebskollegen... Die kommen später, sind aber auch nur noch heute da...
  • 32. 32 2019 – Wie man Applikationen nicht bauen sollte... Das Resultat...
  • 33. 33 2019 – Wie man Applikationen nicht bauen sollte... Ein Beispiel • Applikation zur Ablösung eines bestehenden Fat Client im Versicherungsumfeld • Benutzer Makler, Vermittler, Partner und Direktions-MA -> Max. 40 parallele Benutzer • Mehrstufiger Ausbau, Start mit Motorfahrzeug-Sparte
  • 34. 34 2019 – Wie man Applikationen nicht bauen sollte... Architekturziel • «Moderne» browser-basierte Applikation • Basis Java • Bestehendes Backend-System muss verwendet werden • Betrieb auf eigener Infrastruktur • Performanz nicht schlechter oder besser als bestehendes System • "Blueprint" auch für andere Applikationen
  • 35. 35 2019 – Wie man Applikationen nicht bauen sollte... System-Kontext
  • 36. 36 2019 – Wie man Applikationen nicht bauen sollte... Architekturentscheide • Angular-basiertes Single-Page-UI • SpringBoot/Java 8 • Maven Build • Versionsverwaltung mit Subversion • Laufzeit: Bestehende JBoss-Server • "Stateless": State wird im UI verwaltet • UI/Business Layer benutzt eigenen ValueObject-Layer • Generalisierte Funktionen als Microservices • Projekt soll auch wiederverwendbare Artifakte für andere Projekte liefern
  • 37. 37 2019 – Wie man Applikationen nicht bauen sollte... Reality-Check • SpringBoot/Java 8 • Laufzeit: Bestehende JBoss-Server -> Spring Boot verhält sich Standalone, in Tomcat und in JBoss nicht immer gleich -> Deployment durch eigenes (überlastetes) Build-Management Team -> Keine clean deployments, marginale Prozesskontrollen -> Kein Applikationsmonitoring -> Intrasparente Security Mechanismen
  • 38. 38 2019 – Wie man Applikationen nicht bauen sollte... Reality-Check • Projekt soll auch wiederverwandbare Artifakte für andere Projekte liefern -> Generalisierte Funktionalität, Bibliotheken und Applikationsartifakte in einem einzigen Maven-Multimodule-Projekt/Repository -> Vermischung mit Deployment-Artifakten des Build-Management -> Keine Architekturvision • -> keine separate Versionierung generalisierter Artifakte und Applikationen
  • 39. 39 2019 – Wie man Applikationen nicht bauen sollte... Reality-Check • "Stateless": State wird im UI verwaltet • UI benutzt eigenen ValueObject-Layer -> Alle Benutzerdaten gehen bei UI-Absturz verloren -> Legacy Backend verlangt Vorhalten des ganzen Arbeitskontextes -> Hohe Komplexität im UI -> RPC-artige Schnittstelle zum Business-Tier -> Duplizierung der Backend Logik auf dem Business-Tier
  • 40. 40 2019 – Wie man Applikationen nicht bauen sollte... Reality-Check • Angular-basiertes Single-Page-UI -> eigenes UI Team/UI Projekt -> höhere Komplexität und Kommunikationsaufwendungen -> bei 40 parallelen Benutzern technisch nicht nötig
  • 41. 41 2019 – Wie man Applikationen nicht bauen sollte... Reality-Check • Versionsverwaltung: Subversion -> Mehrere Projekt-Teams auf demselben Repository -> Qualitäts- und Stabilitätsprobleme -> Enorme Merge-Aufwendungen
  • 42. 42 2019 – Wie man Applikationen nicht bauen sollte... Problembereich Backend
  • 43. 43 2019 – Wie man Applikationen nicht bauen sollte... Backend - Database • Versionierung Datenbank ausserhalb Kontrolle des Projektteams • Regelmässige Updates • Oft mit unvorhergesehenen Verhaltensänderungen verbunden • Termine nur sehr eingeschränkt beeinflussbar • Update-Zwang
  • 44. 44 2019 – Wie man Applikationen nicht bauen sollte... Backend – Legacy-Server • Komplexe Eclipse OSGI basierte Installation • Intransparente Architektur • Regelmässige Serverupdates (parallel zu DB) mit Verhaltensänderungen und gebrochenen Schnittstellen • Erweiterungen/Anpassungen unter Kontrolle des Server-Teams (Antrags-gesteuert) • Eingeschränkt skalierfähig (pro 5 Benutzer = 1 Instanz) • Nur spezifische Bereiche unter Kontrolle Applikations-Projektteam
  • 45. 45 2019 – Wie man Applikationen nicht bauen sollte... Das Resultat...
  • 46. 46 2019 – Wie man Applikationen nicht bauen sollte... Erreichte Verbesserungen
  • 47. 47 2019 – Wie man Applikationen nicht bauen sollte... Erreichte Verbesserungen • Vereinfachung/Entkopplung des Maven Build-Baums, Minimalisierung der Querabhängigkeiten, Entfernung von Redundanzen • Halbierung der benötigten Deployments • Einführung eines Spring-basierten Modulkonzeptes • Definition von Service-Schnittstellen • Reduktion des manuell zu wartenden Codes durch • Entfernen eines VO-Layers • Generierung Swagger Client-API
  • 48. 48 2019 – Wie man Applikationen nicht bauen sollte... Erreichte Verbesserungen
  • 49. 49 2019 – Wie man Applikationen nicht bauen sollte... 49 ⚫ Recap!
  • 50. 50 2019 – Wie man Applikationen nicht bauen sollte... 50 Recap • Managementprobleme potenzieren sich in der IT-Entwicklung • Overengineering und funktionale Zersplitterung sind des Teufels • Falsche Anreize wirken extrem demotivierend • Trotzdem ist vieles möglich mit Entsprechendem Know How Ein wenig Durchsetzungsvermögen Und Mut!
  • 51. 51 2019 – Wie man Applikationen nicht bauen sollte... DANKE! Q&A @atsticks Anatole.tresch@trivadis.com