Uwe Friedrichsen (00:00:00)

• Uwe Friedrichsen, CTO bei codecentric.de
• Seit über 30 Jahren in der IT Szene unterwegs
• Hat Kinder, Studieren bereits
• Vor 33 Jahren erste kommerzielle Software verkauft
• Hat Informatik studiert
• Hat so ziemlich alles gemacht rund um Softwareentwicklung
• Von Anforderungserhebung über Architekturdesign und Entwicklung bis Testmanagement
• Aktuell für thematische Entwicklung und Aufstellung von codecentric.de zuständig
• Interesse an skalierbare verteile Systeme

Trendgeschichte der IT (00:06:00)

• Erste Züge von CORBA mitbekommen
• Anschließend JAVA Komponenten (EJB)
• SOA Welle mit SOAP
• WS* Standards
• RESTafarians
• Funktionsorientierung vs Ressourcenorientierung
• Objekte als Ressourcen?
• Ressourcen auf Funktionen aufsetzen?

Designgrundlage: UseCase (00:14:00)

• Viele versuchen Ressourcenmodell auf Entitätsmodell aufzubauen
• Sinnvollerer Ansatz: UseCase Modell
  • Ressource soll Ende-zu-Ende Dienstleistung anbieten
  • System nach UseCases zuschneiden
  • UseCases sinnvoll kapseln
  • Services autonom gestalten

Problem etablierte Ansätze und Konzepte (00:21:20)

• CORBA, ECB, SOA
  • Fingen alle mit fluffiger, leichter Idee an
  • Niedrige Lernkurve
  • Dann ging Fragerei los (was ist mit Naming? wie ist das mit verteilten Transaktionen?, usw.)
  • Einzelne Lösungen für immer mehr Probleme
  • Ansätze unter eigener Last zusammengebrochen
• REST ist REST geblieben

Qualitativer unterschied zwischen Server und Mainframe (00:29:00)

• Mainframe
  • Hat das Verfügbarkeitsproblem und das Verteilungsproblem für lange Zeit sehr gut gelöst
  • War von seiner Hardware so gestaltet, dass er extrem hoch verfügbar ist
  • Hat hervorragendes Ressourcenmanagement (Ressourcenallokation)
  • Für frühere Verhältnisse sehr vertikal skalierbar
  • Keine Notwendigkeit für Verteiltheit
  • Man konnte alles auf einer Maschine laufen lassen
  • EJB Container auf Steroiden
  • Auf einem 266er Pentium konnten simultan über 250 User bedient werden (Benchmark)
  • Extreme Verfügbarkeit durch Infrastruktur
  • Probleme
    • Schwierigkeit für international agierende Unternehmen
    • Monolitisches System für lokal verteilte Nutzer
    • Geschäftsmodelle haben sich geändert
    • Neukunden steigen nicht mehr mit Mainframe ein
    • Neugeschäft dümpelt auf sehr niedrigem Niveau
    • Vertikale Skalierung ist irgendwann zu ende
    • Preise für CPU, Storage und Netzzeit sind irgendwann nicht mehr konkurrenzfähig
    • Fehlendes Know-How und Preis töten Mainframes
    • Ära ist einfach vorbei
  • Anekdote von Uwe
    • Kunde mit Online Suchmaschine
    • 2 große Unix-Maschinen
    • Darauf liegt sehr namenhafte Suchmaschine
    • Lizenzkosten waren sehr hoch (jährlich im 7-stelligen Bereich)
    • (SLA) 300 Anfragen/s mit der Antwortzeit von 250ms
    • "Das können wir billiger."
    • 3 normale "Kisten" von Dell (o.ä.) mit 2 Xenon, 12 Kerne (24 virtuell)
    • ca. 5000€ pro Kiste
    • 20 Mio. Datensätze des Kunden
    • Proof of Concept System: MongoDB, Solr, UI
    • Lasttest wurde bei 3000 simultanen Clients wurde abgebrochen, weil das Testnetz nicht mehr Leistung hergegeben hat
    • Es konnte nicht mehr Durchsatz erzeugt werden
    • Normale Kiste lief im "Idle"; es wurde nur eine von drei benötigt

Ab wann ist Data Big? (00:41:50)

• 20 Mio. Datensätze ist Micky Mouse Data
• IBM Mitarbeiter erzählte das BigData bei 40MB anfängt
• BigData ist dann, wenn du wirklich viele Daten bekommst!
• BigData sind Datensätze im Milliardenbereich
  • 20 Mio. Datensätze kann man entspannt in relationaler Datenbank verwalten
  • BigData ist auch, wenn man Daten so schnell bekommt (Velocity-Thema), dass man nicht mehr in der Lage ist, diese zu speichern und dann zu bearbeiten, sondern im vorbeifliegen bearbeiten muss

Angemessene Lösungen finden (00:44:40)

• Ziel ist es immer, eine angemessene Lösung zu finden
• Kunde will Hadoop Cluster für 20 Mio. Datensätze
• Mit Hadoop hat man mehr Stress
• Diese Menge an Daten kann man entspannt in transaktionaler Datenbank verwalten
• Weniger komplexes Programmiermodell
• Unterschied ob man im Moment kein echtes BigData hat aber Thema lernen will
• ODER
• Ob man in einem Produktionsszenario ist, Wartung, Betrieb, Weiterentwicklung etc. hat und BigData Technologien einsetzen will
• Ergebnis ist dann oftmals:
  • Betrieb wird aufwendiger,
  • Überwachung wird aufwendiger,
  • Rausfinden was schief geht, wird aufwendiger
  • Tooling ist schlechter
  • Laufzeiten sind höher,
  • Mehr Ressourcen werden benötigt,
  • Weiterentwicklung ist lausiger
• --> Dann wurde keine gute Designentscheidung/Architekturentscheidung getroffen

Spieltrieb (00:48:05)

• Jeder, der in die IT Branche kommt, weil er gerne programmiert, hat ausgeprägten Spieltrieb
• Problem ist, dass Unternehmen diesen kreativen Menschen jedoch kein Ventil für diesen Spieltrieb geben
• Diese Menschen wollen neue Dinge irgendwo ausprobieren
• Das nächste Projekt wird dann als Spielwiese missbraucht

Entscheider und Entscheidungen (00:49:40)

• Sehr viele IT Entscheider haben keine Ahnung was sie da entscheiden
• Zwei Möglichkeiten: entweder was von der Materie verstehen oder man braucht einen Vertrauten, der etwas davon versteht
• Es gibt zu viele Entscheider die ihre Themen nur auf Basis von Computerwoche verstehen
• Computerwoche ist Bildzeitung der Computerbranche
• Artikel sind Informationshäppchen, die nicht in die Tiefe gehen
• Keine Grundlage für Entscheidung, die sich auf Unternehmen auswirkt
• Entscheider versuchen sich über diese Zeitung zu informieren
• Letztendlich Entscheidung auf Basis von Buzzword-Bingo durch Zeitung, Marketing, Sales- und Consultants

Buzzword Standards (00:53:00)

• Buzzwords wie Agil, Microservices, ... lassen Interpretationsspielraum
• Problem der Verwässerung
• Multimilliardenmarkt IT Branche ist von Entscheidern durchsetzt, die keine Ahnung haben
• Bzw. keine Ahnung auf der Ebene, als dass sie sagen können: "Du erzählst mir gerade hier jede Menge Bullshit."
• Anforderung: Auf einer Flughöhe von 3000m sollte ein Entscheider ein Verständnis dafür haben, was da unten passiert
• Grundverständnis aufbauen, was das tut, warum das tut, usw...

Microservices aus dem Gewürzregal (00:56:00)

• Kunde macht neues System und das soll auch mit Microservices
• Will eigtl. klassischen Deploymentzyklus haben (1 Mal im Monat)
• Skalierung reicht wenn man innerhalb von 1-3 Tagen skalieren kann
• Gegenüberstellung von monolitischem System und Microservices
• In 10 Minuten erzählt, was das ist und wo die Unterschiede sind, Vor- und Nachteile aufgezeigt
• Spannungsfeld zwischen den beiden Entwürfen
• Dann gefragt, was er haben will
• --> für Monolit entschieden

Monolitische Microservices zur Laufzeit (00:59:13)

• Abhängigkeiten von Services zur Build-Zeit auflösen
• Services, im Java Umfeld, als Jar File im Repo reinnehmen
• Einbinden von Bibliotheken in Anwendung, die an sich unabhängig sind
• Zur Laufzeit von aussen wie ein Monolit, der zur Build-Zeit aus einzelnen Services zusammengesetzt wird
• Nachteil: man hat immer Full Deployment
• Wenn System logisch diese Komponenten rausgeformt hat, dann sollte der Schritt, dass man zur Laufzeit das System in unabhängige Komponten bringt, nicht mehr so weit hin sein
• Services, die man hat, als externe Schnittstelle zur Verfügung stellen
• Zur Laufzeit zugreifbar machen
• Problem: man hat verteiltes System
  • Bislang hatte man nur einen großen Brocken
  • Plötzlich hat man statt 2-3 deployment Einheiten, 20-30 Deployment-Einheiten
  • Jetzt schlagen die ganzen Verfügbarkeits-Wahrscheinlichkeiten zu

Verteilte Systeme (01:03:18)

• Uwe ist absoluter Liebhaber verteilter Systeme
• Es gibt 2 Harte Themen in der IT: Security und verteilte Systeme
  • Oder Naming und Cache-Invalidation?
• Naming ist Teilaspekt von verteilten Systemen
• Projekt mit guten Anwendungsentwicklern, die aber keine Cracks in verteilter Systementwicklung sind
  • Wenn ich die auf ein verteiltes System los lasse
  • Und gleichzeitig Sicherstellen, dass man das System zur Laufzeit überwachen kann
  • Dem System Selbstheilungsfähigkeiten beibringen
  • Da kein Admin ein System dieser Größe unter Kontrolle halten kann
  • Bevor ich mir diesen Schmerz nehme, brauch ich auch einen Treiber für diesen Schmerz

Einfluss von SOA und Microservices auf Organisationen (01:07:55)

• Märkte haben sich verändert
• Wir waren lange Zeit im industriellen Zeitalter, geprägt von Taylorismus
  • Sehr flexibel, sehr spezifisch, handgefertigt
  • Sehr individuell auf Kundenbedürfnisse eingegangen
  • Problem: Man konnte nicht skalieren
• Heute hat man große, weite, nahezu unlimitierte Märkte
  • Wie will man diesen Markt bedienen?
  • --> Standardisieren
  • Vereinfachung und Zerlegung der einzelnen Schritte der Prozesskette
  • Dadurch relativ langsam sich veränderten Markt skaliert
• (seit 70er/80er) Marktsättigung, stärkere Globalisierung
  • Märkte immer enger, die Kunden wurden wählerischer, mehr Wettbewerber
  • Plötzlich musste man wankelmütigen Kunden schneller angehen
  • Dynamisch robustes Unternehmen für dynamischen, sehr aktiven Markt
  • Nicht mehr skalierung das Hauptthema, sondern die Reaktionsgeschwindigkeit
  • "Time To Market"
• Markt hat sich massiv gewandelt
  • Wirtschafts-Darwinismus
  • IT ist das Nervensystem eines jeden Unternehmens
    • IT hatte Skalierungsproblem
    • Problem war: es konnte nicht so schnell geliefert werden, wie es gefordert wurde
    • Ideen des Software Engineering (Ende 60er)
      • Prinzipien aus Taylorismus
    • 80er Siegeszug der PCs
    • Vernetzung
    • Immer komplexere Sachen durch IT gelöst
    • Bis auf Geschäftsprozessebene
    • Irgendwann kam Internet dazu
    • Internet Handel
    • Noch mehr Vernetzung
  • Gesamte IT Landschaft war soweit, dass es das komplette Nervensystem eines Unternehmens geworden ist
    • Jetzt haben wir das Problem:
      • Wenn IT 2 Stunden ausfällt, haben wir ein massives Problem.
    • Entscheider haben das wiederwillig akzeptiert
    • --> Sicherungsmaßnahmen wurden eingerichtet
    • Mit dem Ziel: Stabilen und zuverlässigen Betrieb
    • Problem Heute: Wenn IT Nervensystem des Unternehmens ist, dann sind sämtliche Geschäftsprozesse wie DNA in IT reincodiert
    • Man kann kein neues Produkt launchen, kein Feature, kein neuen Prozess auf der Businessebene ändern, ohne die IT anzufassen
    • IT ist integraler Bestandteil eines Unternehmens
• IT als Nervensystem
  • Mittlerweile keine komplizierten Projekte mehr, sondern komplexe Projekte
  • Weil man nicht mehr einzelne Geschäftsfunktionen unterstützt, sondern kompletter Dynamik des Marktes ausgeliefert ist
  • Nicht mehr Anforderung, dass man skalieren muss, sondern dass die Reaktionsgeschwindigkeit das neue A und O wird
  • "Mehrwert ist erst in Produktion"
  • Anforderung von Geschäftsseite: *Man möchte in der Lage sein, etwas in Tages- oder Wochenzeitraum rausbringen
  • Teilfeature raus hauen, um die Kundenreaktion einzuholen

PDCA vs OODA (01:20:25)

• Plan Do Check Act vs. Observe Orient Decide Act
• Bei beiden macht man einen Schritt, guckt wie die Leute reagieren und macht den nächsten Schritt
• Example A
  • Unternehmen stellt Hypothese auf:
    • "Kunden werden auf dieses Produkt fliegen."
  • Baut Produkt und ist nach 9-15 Monaten live
• Example B
  • Lean Start Up
  • Hypothese
  • Man macht Minimal Viable Product
  • Bringt das raus, misst
  • Passt Produkt an
• Frage: Wer wird nach einem Jahr näher an den Kundenbedürfnissen dran sein?

Organisationsstrukturen im Wandel (01:23:15)

• Aufstellung nicht mehr nach Skalierung und Fehlervermeidung, sondern nach Reaktiongeschwindigkeit
• Reaktionsgeschwindigkeit benötigt autonome Teams, dezentrale Steuerung, usw...
• Ende zu Ende Verantwortung für meine Themen
• Man landet bei DevOps,
• Wertschöpfungskette wird nicht mehr nach Spezialistenteams aufgebaut, mit dem Ziel der maximalen Fehlervermeidung
• Sondern jetzt mit dem Ziel der Reaktionsgeschwindigkeit
• Daher crossfunktionale Teams, die Ende zu Ende alles machen können
• Die ganzen Leute sind beieinander und interagieren direkt miteinander
• Notwendige Komplexität auf der Lösungsseite aufgebaut, die auf der Anforderungsseite entsteht
• "Die Architektur meines Systems wird normalerweise immer der Kommunikationsstrukturen in meinem Unternehmen entsprechen." - Conway's Law
• Organisation kann nur effektiv und effizient werden, wenn Architektur, die ich auf der technischen Seite anbiete, zur Unternehmensstruktur passt
• Problem: Man kann keine autonomen Teams, die reaktionsschnell sein sollen, auf einem großen Monoliten zusammen arbeiten lassen
• Microservices liefern das Architekturparadigma, um diese Autonomie auf der IT-Organisationsebene zu liefern
• Wird über DevOps Teams abgebildet

Von Visionen und Agilität (01:27:30)

• Man Benötigt eine gemeinsame Vision
• Aufgabe eines Architekten ist es die Vision darzustellen, das Zielbild
• Agile Teams: Selbstorganisation als indirekte Steuerung
• "Ich will, dass ihr da ankommt, unter diesen Rahmenbedingungen."
• Man muss Lücken zwischen Teams füllen
• Team muss mit Services von anderen Teams reden
• Damit Kommunikation zwischen Teams und Services funktioniert, muss es Satz an Constraints geben
• Spielregeln zur effizienten Zusammenarbeit definieren
• Auf Prozessebene hat man Agilität der Lean- und DevOps Prinzipien
• Auf Organisationsebene fängt man mit autonome Teams an, End-to-End Verantwortung
• Auf menschlicher Seite hat man Craftmanship
  • bzw. die Gedankenwelt hinter Craftmanship: Professionalisierung der Arbeitsweise und Kollaboration miteinander
• Auf technischer Ebene wird Diversität zugelassen:
  • Microservices
  • Cloudinfrastruktur
  • Self-Service-Prinzip

Der Homo-Ja-Aber (01:35:40)

• Unternemerischer und Organisatorischer Wandel ist die Hölle, besonders in Deutschland
• Hindernisse in der deutschen IT Szene:
  • Der Deutsche ist die Weiterentwicklung des Homosapians in den Homo-Ja-Aber
  • Der Deutsche neigt dazu, Gründe gegen eine Veränderung zu finden
  • SWAT Analyse (aus Marketing), Deutsche guckt nur auf Weaknesses und Threats
    • Beharrungsvermögen der Deutschen (Ja, aber...)
  • Unternehmen haben Kultur, die seit 20 Jahren oder länger entwickelt wurde
    • Deutsche Unternehmen sind träger
  • Viele Unternehmen stellen fest, dass sie ein Problem haben, dass es so nicht weiter gehen kann
  • Erkennen, dass sie sich ändern müssen, haben jedoch keine Idee wohin und wie
• Viele Unternehmen bauen Piloten nebenan, StartUps im Unternehmen
  • Wird so weit wie möglich entkoppelt
  • Ist notwendig, da man bis hin zu Governance Modellen (Führung, Steuerung) die IT neu gedacht werden muss
  • Man will hohe Reaktionsgeschwindigkeit erschaffen in den Teams
  • Entkopplung von dynamischen, agilen Teams aus trägem System
  • Um zu lernen, wie anderer Ansatz funktioniert, muss sich so weit wie möglich entkoppelt werden
• Zu verstehen wie neue Struktur funktioniert ist Lernzyklus
  • Man muss Zyklus auf Metaebene durchlaufen
    • Bis man kapiert hat wie neue Organisation auf allen Ebenen wie Technologie, Prozessorganisation und Governance Modell funktioniert

Unternehmen bei denen der Wandel funktioniert hat? (01:45:40)

• Bei Otto wurde Shop neu aufgestellt, mit neuen Prinzipien, sowohl technisch als auch organisatorisch
• Bei der Post ist man mit einigen internen StartUps unterwegs
• Telekom hat auch Ansätze in dieser Richtung
• Einige weitere versuchen es
• Bei Organisationen, die einen hohen Wettbewerbsdruck haben, sieht man Änderungen massiv

Ausnahmen (01:51:00)

• Wann kann ich mich dem Wettbewerbsdruck entziehen?
  1. Wenn ich einen nicht-effizienten Markt habe
     • Markt wird künstlich träge gehalten (Lobbyismus)
  2. Auf technischer Ebene
     • Wenn technische Ebene komplett intern ist und keinem Marktdruck ausgesetzt ist
  3. Produkt-Lebenszyklus:
     • Neues Produkt, dass ich durch die IT unterstütze, bzw. IT ist selber das Produkt
     • Boston Consulting Group Hype Cycle
     • Versuche rauszufinden, was die Kunden haben wollen
     • Kosten überschaubar halten
     • Ding hebt ab
     • Mich interessiert keine Kosteneffizient
     • Versuchen jeden potentiellen Kunden auf mein Produkt drauf kriegen
     • Solange dran drehen (IT Systeme nacharbeiten) bis ich maximalen Marktanteil rausgeholt habe
     • Dann wechsel ich den Zyklus in Cash Cow rüber
     • Markt ist klar, Anteile sind vergeben
     • Reaktionsgeschwindigkeit runter fahren, Kosteneffizienz hoch fahren
     • Kann in anderes Paradigma wechseln, rein auf Kosteneffizient trimmen
     • Quality of Service wird aufrecht erhalten, um keine Kunde zu verlieren

Von Null auf Legacy in unter 3 Monaten (01:56:00)

• Agile Projekte die nur Code gekloppt haben
• Velocity ist runter gegangen
• Der normale ITler ist ein Messi, löscht keinen Code
• Man hat auf der Fachseite Leute die gar nicht wissen warum Sachen gemacht werden, sondern nur wie sie gemacht werden
• Haben den Sinn nicht verstanden
• Auf der IT Seite hat man sehr viele Entwickler, die sich wehren Fachlogik zu verstehen
• können daher kein gutes Design machen und wissen nicht, ob Code noch irgendwo gebraucht wird

Beim neu Bauen wird alles besser (02:00:30)

• Wenn ein System komplett neu gebaut wird, begeht man zwar die alten Fehler nicht mehr, dafür aber sehr viele neue
• Man hat keine Chance wenn man keine guten Leute im Design hat
• Wenn man ein gutes, wartbares System haben möchte, ist Design das wichtigste
• Unternehme erkennen nur schwer: Wenn ich so etwas hoch ziehe, muss ich gute Leute reinsetzen, die Dinge gut beurteilen und abwägen und entscheiden können
• Das sind dann die Leute, auf die man dann in einem kosteneffizienten Unternehmen niemals in dem Fachbereichen verzichten kann, weil sie unersetzlich sind
• Hybridlösung: 30% der Zeit, Tauchen 2 Stunden die Woche mal auf
• Entwickler sind wo anders untergebracht als der Fachbereich: verteilte Entwicklung
• Das macht es schwierig
• Idealzustand:
  • Crossfunktionales Team
  • Alle Kompetenzen vorhanden
  • Alle vor Ort
  • Idealerweise in einem Büro
  • Wenn das richtig gemacht ist, kann das gut funktionieren.

Schlusswort (02:08:20)

• Markt hat sich geändert
• IT muss sich darauf anpassen und sich neu erfinden
• Amazon, Google, Netflix usw. haben vorgemacht wie es funktionieren kann
• haben Lernkurven hinter sich. Da kann man wunderbar drauf gucken
• man muss aufhören Ja-Aber zu sagen und gucken, was man da raus ziehen kann