SCRUM

Skillbyte Podcast #45: Das Spring Boot Framework

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Das Spring Boot Framework

// Inhalt //
02:35 – Was ist Spring Boot?
03:26 – Erfahrungsbericht: Spring Boot Anwendungsentwicklung
14:43 – Spring Boot Paradigma: Convention over Configuration
15:16 – Lohnt sich der Einsatz von Spring Boot? Lernkurve?
16:39 – Ein kleiner Vergleich mit der Pyhton Welt
18:16 – Features von Spring Boot
22:31 – Spring initilizr auf start.spring.io
23:45 – Spring Support von IntelliJ IDEA
26:41 – Spring Boot Banner
27:44 – Dokumentation der Spring Boot Anwendung
29:00 – Fallstricke & Tipps
33:02 – Fazit: Ist Spring Boot empfehlenswert?

Show Notes:

Podcast #29: Die Zwölf Faktoren des Cloud Native Development (Teil 1)
-> https://soundcloud.com/skillbyte/podcast-29-die-zwolf-faktoren-des-cloud-native-development-teil-1

Podcast #30: Die Zwölf Faktoren des Cloud Native Development (Teil 2)
-> https://soundcloud.com/skillbyte/podcast-30-die-zwolf-faktoren-des-cloud-native-development-teil-2

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Ich denke auch, dass sich das als Blaupause und Grundlage für die voll regelrecht für Java Anwendungsentwicklung nehmen würde, weil die meisten Anforderungen aus Umgebungen kommen, wo man das eben gut umsetzen kann. Ich meine missis in den letzten Jahren nichts untergekommen, wo man jetzt auf einen klassischen ein Maschienen Server oder einen großen Mainframe irgendwas hätte entwickeln müssen, sondern man kommt eben immer eigentlich gerade wenn es Java sein soll in diese Microservices Richtung bzw. kann seine Anwendung zum Lösen eines Problems so designen, dass sie auch sinnvoll so umzusetzen ist.

Und dann ist Spring Boot wirklich ein Top Tool.

Herzlich willkommen zu unserer Skill bei Podcast Episode Nummer fünfundvierzig Das Spring Boot Framework abonniert unseren Kanal für mehr spannende Themen aus dem Technologie Umfeld. Wenn ihr die Entscheider oder die Fachkraft seid, wenn ihr eine höhrer Frage habt im Verlauf der Episode sendet uns gerne eine E-Mail an Podcast Skill Bild.de:. Wir freuen uns immer über Bewertungen und weitere Empfehlungen dieses Podcasts an eure Freunde und Kollegen, die sich ebenfalls für diese Themen interessieren.

Wenn ihr aktuell in der IT-Branche auf Jobsuche seid, schaut auch auf Skill weite Isles Jobs vorbei. Ich bin heute hier mit den beiden Skill BYD Data Ingenieurs Oliver und Andreas.

Hallo ihr zwei Callboys. Schön wieder dabei zu sein. Hallo Moritz Fela, endlich mal dabei zu sein.

Oli kennen ja schon einige Zuhörer, Andreas. Für dich ist es heute ein Novum. Aber ich freue mich wirklich, euch beide dabei zu haben, weil ihr euch sehr intensiv jetzt in dem letzten halben Jahr bzw. kann man so sagen die zweite Jahreshälfte 2000 und 20 mit dem Spring Boot Framework beschäftigt habt und auch eine recht komplexe Anwendung darauf entwickelt hat.

Genau. Wir haben als Projekt. Ich glaube, so ab August letzten Jahres bis Ende des Kalenderjahres genau haben wir eine Spring gut basierte Anwendung für den Kunden gebaut, was für uns ein völlig neuer Text steckt. Zu dem Zeitpunkt war uns aber die Möglichkeit gegeben hat, da sehr, sehr schnell production ready zu werden und eine Anwendung zu haben, mit der wir sehr schnell weiterentwickeln und testen können. Das war eine ziemlich coole Sache. Da kann Andreas aber auch noch was zu sagen, weil auch für den war das glaube ich ein neuer Einstieg.

Ja, genau. Also für mich war das eigentlich alles Komplettem, weil sowohl Java als auch Bimbos und bin tatsächlich erstaunlich schnell reingegangen. Das hat mich auch ein bisschen überrascht. Sobald man sich einmal an die Annotationen gewöhnt hat, ist man eigentlich sofort dran.

Genau das ist ja auch das Kernziel des Spring Boot Frameworks. Vielleicht kennt der ein oder andere Zuhörer ist noch nicht so oder kann auch nicht genau was damit anfangen. Deshalb würde ich kurz sagen, dass es sich um einen Quell offenes Framework für die Java Plattform handelt, welches meist genutzt wird, um eben Webanwendung zu implementieren, Microservices zu implementieren. Und das Ziel dieses Frameworks ist es eben möglichst schnell komplett Laufwege Anwendung erzeugen zu können, weil die default Einstellung der Konfiguration im Grunde sinnvoll sind.

Das ist der Anspruch, den dieses Projekt hat. Und wie das so ist z.B. beim Schachner im Menace to learn alive to Master, so ist das auch ein bisschen bei Spring Boot gestartet ist man sehr schnell, kann dann aber die Anwendung nach und nach um weitere Komponenten erweitern und eine sehr komplexe Anwendung bauen, was er ja auch gemacht hat.

Auf die genauen Inhalte müssen wir ja jetzt gar nicht eingehen, aber die Anwendung sollte als System von mehreren kleinen Microservices ineinander greifen. Wir brauchten unter anderem einen einfach zu nutzen. Das Web frommt und wir brauchten den eigentlichen Controller dahinter. Wir brauchten eine Datenbank Anbindung. Wir mussten die Möglichkeit haben, Daten im lokalen Dateisystem zu paar sistieren und und und. Das waren viele einzelne Komponenten, die wir dann entsprechend damit strukturieren konnten. Und das hat dem Ganzen wirklich einen hervorragenden Rahmen gegeben, wo man dann die Arbeit auch de facto gut aufteilen konnte, um eben das Ganze schön gekapselt zu haben.

Das hatte auch ganz viele Aspekte von der Pull-Faktor App, über die wir ja schon mal zusammen gesprochen haben, wie wir das dann Gebaute nachher auch die PEUT haben.

Andreas War das für dich? Hattest du das Gefühl, dass man es gut aufteilen kann und dass du dann so einzelne Häppchen abarbeiten konntest?

Ja, das ging eigentlich Duterte als ich zu dem Projekt dazugekommenen, was aber nur zwei Wochen war, nachdem Oliver auch damit angefangen hat, war quasi schon ein bisschen ein Grundgerüst da und werden dann aber recht schnell gemerkt. Wir brauchen jetzt noch zusätzliche Rest API Endpunkte von quasi zusätzliche Microservices. Und da hat es mich überrascht, wie einfach es war, da dann zusätzliche Sachen zu schreiben. Dann hat man einfach einen zusätzlichen Controller hochgefahren und dem Endpunkte gegeben und die konnten unabhängig voneinander dann bearbeiten.

Das hat einfach sofort funktioniert.

Das Gute ist halt bei dem Spring Framework und Spring Boot ist ja letztlich nur eine Geschmacksrichtung des großen vollumfänglichen Spring Frameworks, dass man diese Inversion of Control eben nutzen kann. Also Andreas hat es eben schon angesprochen per Annotation. Also Edin Denkakt oder Auto wiederholt sich dann die einzelnen Komponenten in die Klasse durch den Container oder durch das Framework Injektor lassen kann. Das deutsche Wort wäre glaub ich verdrahten lassen kann und dann eben diese Komponente vollumfänglich zu nutzen. Habt ihr das so Komponenten Weise aufgeteilt?

Die Arbeit oder jeder hat so ein bisschen Überblick über den gesamten Code gehabt.

Das werden glaub ich beide einen ganz guten Überblick über alles. Aber gut, wenn man zu zweit arbeitet, dann teilt man sich schon ein bisschen die Arbeit auf und Alianza ein bisschen mehr Erfahrung mit Docker Containern schon an denen, die. Deswegen hat er sich da mehr darum gekümmert und ein bisschen mehr um die Rest API selber, dann würde ich auch genau so unterschreiben und es war wirklich praktisch, dass man die ganzen Dependency es, die man ansonsten berücksichtigen müsste, dass man diese ganzen Weg gekapselt module dann sich einfach über dieses Auto via O-Ring direkter reinholen kann.

Da kann man vielleicht später nochmal kurz drüber sprechen, aber so angeteasert. Das hat es für uns dann eben auch super gemacht, das ganze mit Unit Test Abdeckung nachher zu versehen. Also diese modularer Bauweise, die hat uns da das Leben in vielerlei Hinsicht vereinfacht.

D. h. ihr habt dann wirklich Komponente für Komponente g Unit testet im Rahmen der Zeit, die wir zur Verfügung hatten.

Ja, also die war von Anfang an begrenzt. Das waren die letzten paar Wochen im Projekt Scope. Und wir haben mit den Kern Komponenten, die für den Betrieb nötig waren, entsprechend angefangen und haben entsprechend dann doch noch ein sehr akzeptables Level an Test Abdeckung für die ganze Applikation geschafft. Am Ende ja. Und das haben wir genauso gemacht.

Er war auch ein bisschen überrascht, dass wir dann doch noch so eine hohe Testa Abdeckung hingekriegt haben, weil dadurch das ganze zeitlich limitiert war. Haben wir jetzt nicht Testpiloten Development von Anfang an gemacht, da vor allem auch vieles zum Anfang noch nicht klar war, wie es am Ende aussehen würde, aber zumindest Järvi alle gesagt hat. Die Kernidee Teile der App und mit der nachträglich ziemlich einfach noch mit Tests versehen.

Das heißt, die Anwendung wurde zuerst entwickelt. Ich glaube, das kann man sagen. Es handelte sich um eine Brücke, einen Exporteur und einen Importeur von zwei verschiedenen Systemen, der einfach Daten transformiert hat zwischen diesen Systemen. So, und da waren wahrscheinlich die Schnittstellen nicht ganz klar und es hat sich erst im Verlaufe des Projektes herausgestellt und dann am Ende, als die Schnittstellen klar waren und die schon bespielt werden konnten. Habt ihr das dann nochmal getestet? Richtig. Also das Ganze war, wenn man es drastisch formuliert, wirklich als One-Shot Anwendung konzipiert.

Man hätte das natürlich dadurch, dass sowohl das Quelle als auch das Zielsystem weitverbreitet sind in der Branche, in der der aktuelle Kunde da unterwegs ist. Aber die Systeme waren jeweils so spezifiziert und an die Bedürfnisse des Kunden angepasst, dass es viel mehr Aufwand gewesen wäre, das deutlich generischer zu machen, um es als Produkt dann auszuarbeiten, sodass wir da wirklich eine maßgeschneiderte, schnell entwickelte Lösung gebaut haben.

K Perfekt. Jetzt habt ihr diese Anwendung gebaut. Wenn ich das richtig verstanden habe, Oliver, du hast dich so ein bisschen um die Pakete gekümmert. Docker Den Betrieb oder die DevOps Komponente. Andreas Du hast vielleicht etwas mehr an der Anwendungs Logik gearbeitet. Hattet ihr das Gefühl, dass euch springender Gut unterstützt, also dass ihr euch wirklich auf eure Kernthemen konzentrieren könnt Infrastruktur oder Anwendungs Logik? Oder hattet ihr oft das Gefühl oh ich schreib hier Boiler Pleite Code um die x te Datenbank Verbindung aufzumachen oder sowas?

Das muss doch einfacher gehen.

Er sei ein bisschen hatte ich schon den Eindruck, dass man ein bisschen Boiler Plaid Code schreibt. Gleichzeitig hatte ich aber auch den Eindruck, dass es weniger ist als meine Java sonst machen müsste. Da ich wohl noch nicht so Java Erfahrung hatte, war mir bewusst, dass ich da mehr bei der Palette Code schreiben muss, als z.B. ein Payton war. Das hat sich dadurch ein bisschen in Grenzen gehalten.

Hast du ein Beispiel für Boiler Plaid er gut alle Geta an CETA hat man einen Partner z.B. einfach nicht. In Ada kann man vieles umgehen in der Stelle.

Für mich hats massiv Code gespart. Du hast das Stichwort Datenbank Anbindung gerade genannt. Da ist durch JPY zu den technischen Feinheiten kannst du vielleicht gleich noch kurz etwas sagen ist uns extrem viel Arbeit abgenommen worden. Also da bringt Spring Boot von Hause aus die Möglichkeit mit, das sehr elegant zu nutzen, in dem nicht nur einfach die Gredenko sieals und die Konnektivität Informationen zu einer Datenbank übergeben werden, sondern man hat auch über vordefinierte Funktionen hat man die Möglichkeit, die Tabellen selber direkt anzulegen.

Also die Schemata. Das wird alles von Springflut über sehr viele einzelne Komponenten ermöglicht, ohne viel Aufwand an der Datenbank selber betreiben zu müssen. Das ist wirklich schön gemacht.

Ja, das stimmt. Also ein sehr komplexes Datenbank Schema, wie wir dann letztendlich doch eigentlich hatten, halte ich glaube ich hier. Wenn ich die hätte selber schreiben müssen ich in der Zeit hinbekommen. Auf jeden Fall.

Vor allem wenn man noch die SQL Schnittstelle selber in irgendeiner Form hätte bauen oder mit kleine SQL Code hätte bedienen müssen. Und da nimmt einem JPC dann eben schon extrem viel Arbeit ab. Und das hat dann auch def abseitig viel gespart, weil man einfach die Datenbank zur Verfügung gestellt hat, die Konfiguration in JPL mit ein paar Zeilen schnell gemacht hat und dann lief das. Das muss man einfach dazusagen. Das war wirklich einfach die JPL. Hier steht ja für die java persistent api die eben genau.

Für. Daten bank. anbindungen. Da ist. Oder persistenz. Schicht anbindungen da ist. Und das schöne hier ist. Dass man im grunde. Das es gerade gesagt. Diese tabellen relationen. Oder das datenbank schema. Das kann man einmal anlegen. Und jpl kümmert sich dann darum. Je nach dem ob du eine postgresql datenbank hast. Maisie. Soldaten. Bank. Oracle. Datenbank. Den. Richtigen exkl. Dialekt nenne ich es mal zu generieren, so dass das konkrete Backend dann eben unterstützt wird.

Und das macht natürlich auf Migration sehr einfacher. Der eine Kunde setzt die Datenbank Technologie ein, der andere Kunde setzt die Datenbank Technologie ein. Da möchte man kein Wenn du Login haben, sondern die JPL benutzt, läuft es überall oder auf allen Datenbank Plattform, die eben JPY Unterstützung erfahren, was die meisten sein dürfen.

Ja, das Thema Parketts hierum hast du eben angesprochen. Hass hat für mich auch nochmal leicht gemacht. Das war dann die Zusammenarbeit von Spring bzw. Spring gut und eben Maven als Paket Manager dies mir extrem leicht gemacht hat. Die Anwendung dann einfacher dem Docker Container zu betreiben, also sowohl schon für Entwicklungs Zwecke wirklich jeder auf seinem Entwickler Laptop was auch praktisch war war. In Docker waren wir dann eben auch völlig unabhängig davon, weil ich habe es offene Meek gemacht Andreas glaube ich auf einem Linux System.

Das lief dann alles sofort und auch der Roll outs beim Kunden war dadurch viel einfacher, weil der Ebene Container Umgebung zur Verfügung gestellt hat und wir dann nur noch da rein diplomen mussten und dann eben mit dessen, der vom Team geklärt wurde, wie dann der Betrieb abläuft. Aber dadurch, dass wir eben die Pakete hierum über Maven und Spring buht dann eben hatten und das ganze schon im Docker Container betriebsbereit zur Verfügung stellen konnten. Sehr einfach war das ein Kinderspiel und schnell gemacht.

Das war echt toll. Da habt ihr direkt eine Stärke von Spring Boot voll ausgespielt in Kombination mit Docker, weil ich sag euch das früher war das nicht so, dass man eine Java Anwendung direkt ausführen konnte oder es war ganz ungewöhnlich, sondern es gab einen sogenannten Application Server an Tomcat aus dem freien Bereich oder auch verschiedene proprietäre Produkte. Von RedHat hieß es z.B. J. Bors und das war ein sehr schwergewichtige Server, die also teilweise mehrere Minuten benötigt haben um zu starten.

Und da wurde dann die Anwendung alzu war fail oder eher fail wurde die Anwendung rein die bloed und rein geladen und die wurde dann auf diesem Server ausgeführt. Das ist natürlich heute in der kybernetisch Umgebung Microservices Umgebung ist das überhaupt nicht praktikabel, dass man da einen Server hat, der sehr viele Ressourcen braucht und der mehrere Minuten zum Starten braucht, sondern da möchte man eine kleine ausführbare Code Einheit haben, die ihre dedizierte Aufgabe übernimmt. Und da bietet sich natürlich das selbst laufende Spring Boot Programm an oder die selbst laufende Applikation ist es ja ein derFall was man direkt starten kann.

Wir haben in dem Zusammenhang genau das bekommen, nämlich ein Zerfall, was schon alle Dependency es enthielt. Man musste da keine Libraries mehr installieren und gar nichts. Man konnte mit einem minimalistischen Docker Image anfangen. Es musste nur Java installiert sein. Dann hat man das ja ausgeführt. Wenn man wollte noch ein paar Laufzeit Parameter mitgegeben und dann lief die Anwendung und die ethical schon eben diese Webserver Komponente. Zum Beispiel wenn ich mich erinnere an meiner Anfangszeit in dem Projekt, wo ich noch nicht so vertraut war.

Damit hab ich noch einen extra Docker Container hochgefahren, wo ich in Engine X Webserver drin betrieben habe, damit ich diese Rest API überhaupt irgendwie ansprechen konnte. Und irgendwann haben wir dann verstanden, dass Springflut das schon von Hause aus mitbringt. Aber da hat Andreas viel mehr mitarbeitet als ich.

Ja, da kam dann aber nochmal die zweite Erkenntnis. Also erstmal wie obligat gesagt hat, des Rest Framework selber. Aber man habe dann festgestellt, dass es ja wirklich war, seinen kompletten Webserver der auf Heilberufe mitliefert. Wir hatten dann nämlich doch nochmal eine Endings dazu, die Plots, um einfach statisch ein paar Fails für das Frontend können und das fand ein selber und dann feststellte Wir können das einfach direkt staatlich mit einbinden. Wir nennen einfach einen Ordner Public und dann passiert alles automatisch.

Das war dann nochmal so ein Aha-Erlebnis.

Das ist diese Opinio Nahtod Konfiguration. Also bring but leg dir schon so die Fold Ordner an oder bzw. die kannst du anlegen, wo dann Settings drin liegen können für die Anwendung oder eben statische HTML Falz, wo man sich dann nicht weiter kümmern muss, wenn man sich an diese die Fold Konfiguration hält. Man kann auch alles konfigurieren, aber das Ziel von Spring Boot ist es zu sagen Hammer, wir geben dir einen vernünftigen Grundstock auf dem kannst du aufsetzen und du kannst alles konfigurieren.

Aber so wie wir es dir liefern, ist es erst einmal in Ordnung für die meisten Anwendungen. Also könnt ihr bestätigen Spring Boot hat euch fÃr eure Entwicklung doch ordentlich unter die Arme gegriffen. Ihr seid schnell zu Rande gekommen, habt wenig kämpfen müssen. Leute, die um die Millennium Wende Java entwickelt haben, die kennen noch, wie schwerfällig das alles war. Habt euch gut in der STANDARD Konfiguration zurecht gefunden und wenn ihr Zusatz Komponenten eingebaut habt. Ich weiß jetzt nicht ob ihr den Spring Logger benutzt habt oder wahrscheinlich die Spring Datenbank Anbindung und so, dann war das wahrscheinlich mit 20.

Mal googeln. Bildung ist natürlich hier die Website, die sofort auf ploppt, war das relativ schnell eingebunden. Ja, würde ich genau so unterschreiben. Es war zunächst mal intuitiv ziemlich viel verständlich, muss ich sagen. Nun muss ich dazu gestehen, dass ich zumindest Java schon mal vorher gemacht hatte und auch Maven vorher schon mal gesehen hatte. Das hat mir die Grundlage ein bisschen bereitet, aber nachdem ich dann in die einzelnen Sachen besser reingekommen war, lief das sehr schnell.

Die Lernkurve war sehr steil und auch einfachste Internet-Recherche. Meistens kann man eben bei Bildung raus, hat da schon geholfen, weils eben auch so viel genutzt wird und so viele Leute sich damit beschäftigen und damit arbeiten.

Für mich war da die Lernkurve noch ein bisschen Tayler, weil ich hatte tatsächlich vorher noch keine einzige Zeile Java Code geschrieben. Aber selbst damit war das ohne Probleme machen. Also mit den Web Ressourcen kann man dann schnell zu Rande Andreas. Gibt es denn in der Python Welt ein mit Spring Boot vergleichbares Framework? Also was ähnliche Features anbietet oder was die vielleicht immer wieder aufgefallen ist, dass du gedacht hast oh stimmt, das ist so wie bei Falcon oder so.. Also mir geht es ganz häufig so Wenn ich mich in einer Welt relativ gut auskenne und dann mich in neue Themen einarbeitet, dann stelle ich fest Ah, okay.

Die NPD ist eine neue Form von Maven oder Gretl oder dass man quasi diese queer Referenzen herstellen kann.

Ich würde sagen, es gibt nicht so ein monolithischer Ding, was es alles kann. Ein bisschen. Also es gibt gute Respawn Frameworks, dem Rass ähnlich komfortabel auch eine Rest API aufziehen kann. Aber dann muss man halt nochmal einen Webserver dazu machen, was man zwar auch leicht geht, aber es halt erst ein anderes Projekt. Dependency Injection ist nochmal komplett anders. Man braucht es einmal in Payton nicht ganz so viel, da man in der Laufzeit natürlich viel austauschen kann.

Dynamisch auch, aber wenn man es wirklich vollständig benutzen will, dann muss man zu anderen Paketen gehen. Also es gibt nichts, was das alles miteinander verbindet und einem von Anfang an was funktionierendes gibt. Man muss das ein bisschen zusammensuchen, mehr und auch Entscheidungen treffen, welches man dann von mehreren Möglichkeiten wählt. Swing gibt’s ja auch Alternativen.

Genau, aber Spring Boot muss man schon sagen. Ich will nicht vom de facto STANDARD sprechen, aber das ist für Berat, also Rapid Application Development in der Java Welt so über die letzten Jahre ist das ein sehr, sehr großer Player geworden und man startet meistens damit, dass ganz viele große Applikationen, die man kennt, bestehen ja heutzutage aus vielen, vielen kleinen Microservices. Und diese Microservices, die die Arbeit im Hintergrund verrichten, die sind sehr oft mit Springflut geschrieben.

Welche Features von Spring Boot habt ihr denn verwendet? Also wir haben eben schon über ETT Auto Wired gesprochen. Andreas hatte die Notationen erwähnt. Das ist natürlich das Ding, oder? Diese Inversion of Control ist das Konzept, mit dem Spring damals bekannt wurde, Anfang der 2000er Jahre, dass man eben nicht mehr New Klassisch schreibt und damit eine harte Kopplung hat, sondern man sich über ET Auto Wired z.B. einen Logger in Jack tat, eine Datenbank in Jack That oder ein Transaction Manager in Jack That und dieser Transaktion Manager ist quasi entkoppelt davon, solang der ein gewisses Interface implementiert.

Bleiben wir mal beim Logger ist es egal, ob das ein Festplatten Logger ist, ein Screen Logger, ein Netzwerk Logger oder ein Logger auf einem ganz anderen Medium. Ein na Logger, der einfach nur alle Log Zeilen wegschmeißt oder ein Rauchzeichen lagert. Zur Not. Das Konzept ist ja ganz zentral und ich denke, das hat euch auch relativ früh. Habt ihr das bemerkt?

Ja also die Cernko Komponente für uns war, würde ich jetzt für mich sagen das Auto, wir O-Ring, dass man eben nicht jedes mal neue Instanzen von Klassen erzeugen muss, sondern wirklich diese Benes hat. Und wir haben die auch meistens eben als Singleton benutzt. Das war wirklich etwas, wo wir uns dann auch sukzessive beim Design der Anwendungen Gedanken drum gemacht haben. Also wir haben dann wirklich versucht, wo wir eigentlich zuerst intuitiv gesagt hätten Okay, wir brauchen mehrere Instanzen davon von der gleichen Klasse, dann haben wir trotzdem versucht, unser Design Pattern so umzubauen, auch gedanklich, dass wir eben diese Singleton Auto Viri Funktionalität benutzen können.

Und es hat uns halt auch beim Testing dann begleitet. Entsprechend ja eben das Logging. Andreas Was kann ich mir, wie haben wir das gemacht? Haben wir das von Spring genutzt?

Das Logging ist es auch per Annotation. Das war der SL vor J. Logger lassen hab der Franz Spring Boot selber ist oder?

Meistens sind das externe Libraries, die du einfach in Jackets. Beim Logging kippt es mehrere Standards. Es gibt Lock vor J, dann in CV. JJ Logger. Da gibt’s noch zwei, drei andere. Ich benutze den, der in der Anwendung schon drin ist, weil ich da kaum Unterschiede feststelle oder zumindest mit allen leben kann.

Sagen wir so. Was mir noch einfällt, das ist relativ gegen Ende gekommen, als es darum ging, die Anwendung beim Kunden in den Container Cluster. Zwar Masons zu Diplomen ging es darum, wie wir Health Checks unserer Anwendung im Betrieb machen können. Und weil das vom Dev OPs Team des Kunden angefragt wurde, wie man sicherstellen kann, dass die Anwendung auch vernünftig läuft und ich meine, da hättest bring uns die Funktionalität intrinsisch zur Verfügung gestellt. No Matrix Ja, genau, dass wir da nicht noch selber Health Brookes verschreiben mussten mit dedizierten Endpunkten in der API.

Genau. Wenn ihr das Micro Service Profil benutzt habt, haben wir glaube ich Letz endlich nämlich nicht.

Aber wir haben dann letztendlich die eigenen Endpunkte geschrieben gehabt und dann festgestellt, dass es bringt uns eigentlich frei Haus geliefert hätte. Aber da war es in dem Fall schon zu spät. Das lag dann eher daran, dass wir uns nicht genug damit auskannten. Okay, gut.

Aber das heißt im Grunde jetzt wisst ihr, dass es das gibt. Beim nächsten Service könnte man sich diese STANDARD Matrix also hier RAM verbraucht CPU Jukic, Disk Space könnte man sich auch sparen, sondern einfach die vordefinierten nutzen und die dann eben entsprechend erweitern. Wenn man das braucht.

Ja, was Oleh mir auch gesagt hat. Wir hatten dann ganz viele Klassen mit Autoritären, was am Ende darauf hinausgelaufen, dass wir ganz viele einzelne Klassen hatten, die quasi ein Objekt aus der einen Umgebung der neuen Umgebung übersetzen konnte. Und all diese Übersetzer waren dann letztendlich Singleton Wins, die dann an einer entsprechenden Stelle, wo sie benötigt wurden, einfach nur initiiert worden.

Genauso macht man es auch auch. Ich nehme an, als sie dann die einzelnen Komponenten getestet habt, dann injektor dir dann einfach Mock Objekte statt der realen Instanzen um dann die Kernfunktion einer Klasse zu testen. Richtig, genau so haben wir es dann gemacht.

Genau das war immer der Punkt. Wir haben versucht, das, was wir als Bian eben dann Jack Thot haben, vorher getestet zu haben, um es dann eben an einer anderen Stelle als fertigen Mock benutzen zu können.

Habt ihr bei Projektstart ich glaube es gab schon im Template Oleh Wanne. Ihr habt nicht den Spring Finisher Leisure, also auf Startpunkt Spring dort AIO gibt es den, den habt ihr nicht benutzen müssen, oder?

Nee, tatsächlich nicht. Da hatte ein Kollege schon was vorbereitet, um so eine grobe Projekt Struktur auch mal in Form von Place holder Klassen angelegt und eine grobe Funktionalität war auch schon gegeben. Also ich glaube man hat die Möglichkeit eine Liste zu migrieren oder Objekte einzulesen aus einem Testfall. Und es gab schon eine Anbindung an eine Postkarte oder Mail SQL Datenbank. Genau das war so unser Startpunkt zu dem Zeitpunkt und entsprechend gab es dann eben auch schon ein POM Fall mit dem ganzen Maven Setup A okay war.

Es gibt auch Startpunkt Spring Punkt Видео gibt es diesen Spring in leiser und da kann man dann sagen ich möchte eine Springflut Anwendung schreiben mit Datenbank Zugriff mit Maven oder Greendale Build System und man klickt so ein paar Sachen zusammen und am Ende fällt ein Zipfel raus, was quasi so die Basis Anwendung mit den getroffenen Einstellungen schon enthält. Quasi dieses schlachte schnell und kümmert sich um die Anwendungs Logik auf die Spitze getrieben. Jetzt habt ihr beide ja intelligent Diaa benutzt. Für das Projekt hat euch die Idee gut unterstützt.

Bei Spring Boot Anwendungen ist der Support dafür reif.

Der Support der war super. Tatsächlich. So war von den Socken. Wie einfach es doch ist, damit all die Sachen, die man sonst sehr manuell nachschauen muss in Variablennamen merken und dann ins Java natürlicher nach ner typisierte Sprache, d. h. das kommt noch dazu. All das. Da nimmt es einem ziemlich viel Arbeit ab.

Und auch die Kenntnis der Fidi über die Projekt Struktur. Also was kann ich überhaupt per Auto via O-Ring einbinden? Also was hab ich zur Verfügung? Oder wenn ich jetzt gerade nochmal an das Pom fail zurückdenke. Wenn ich da versuche in Versions takk von etwas einzubinden, was in der Form so nicht existiert, werde ich darauf hingewiesen oder dass ich das dann erst runterladen muss, damit es zur Verfügung steht. Für mich jetzt lokal all solche Sachen, um die man sich ansonsten zu einem späteren Zeitpunkt Gedanken machen müsste, um dann wieder zurückzugehen, um es zu fixen.

Das war schon klasse und natürlich die Möglichkeit, selbst in Module reinspringen zu können, die man nicht selber geschrieben hat, sondern die aus externen Libraries stammen und im Zweifelsfall dann eben de kompilierte Code vor sich zu haben. Was aber immer noch besser ist, als nicht zu wissen, was passiert.

Ja, das stimmt. Du hast Andreas hat eben auch gesagt die Gather und Zeta. Das stimmt, dass man die schreiben muss, das ist schon. Da entsteht diese riesen Text Tapete. Ich mache mal mit ALD einfügen generiere ich die einfach und habt ihr dann für alle Properties. Deshalb stört mich das gar nicht so sehr. Obwohl das eigentlich natürlich schöner geht, hat Andreas vollkommen recht. Was ich bei der Springflut Unterstützung ganz klasse finde ist Du kriegst ja dieses Blättchen, dieses Ahornblatt oder so wird dann angezeigt und dann siehst du die einzelnen Pins, dann kannst du bei den Autor via Pins kannst du so dadurch springen oder er schlägt dir dann schon die Methoden der Pins vor, wenn du da unten arbeitest.

Meistens läuft es da so hinaus. Du was hat deine Klasse, die die Anwendungs Logik enthält und du? Historiker Klassen, die dir halt zuarbeiten, also z.B. Du hast deine Anwendungs Logik und hast ein Database Worker, der Objekte aus der Datenbank holt, Objekte in die Datenbank speichert usw.. Kannst du die dann sehr einfach in deine aktuelle Klasse rein? Metten?

Ja, die Funktionalität hab ich zumindest auch hin und wieder mal benutzt. Was mir noch als Randnotiz positiv im Gedächtnis geblieben ist, ist die Tatsache, dass sehr intuitive Nomenklatur vorgeschlagen wird von der Idee. Also wenn ich das schreibe oder was haben möchte an möglicherweise vordefinierten Strukturen innerhalb meiner Klasse, dann ist die Nomenklatur entsprechend schon an das angepasst, was die tun soll. In dem Zusammenhang wies für mich jetzt gerade notwendig ist, auch wenn dann das schon mal sehr lange Methoden Namen bei rauskommen.

Aber es ist sehr gut. Human Redtube möchte ich mal sagen, was die Idee da einem vorschlägt. Also sie unterstützt da auch schon den menschlich intuitiven Zugang sehr.

Habt ihr eigentlich? Fällt mir gerade ein, bei Convention over Configuration habt ihr auch ein eigenes Banner erzeugt vor einer Anwendung.

Ja, ich hab das sogar in zwei erzeigt.

Wäre ja, ich hab zwischendurch mal gewechselt. Das ist richtig. Am Anfang habe ich ein Corporate Identity ähnliches Banner aus Asti Artzt da hinzugefügt. Genau Asgard Generatoren gibt’s ja genug online frei verfügbar und danach hab ich mir ein Zitat aus einem Musikstück, was ich sehr schätze da eingebaut, was in den Zusammenhang von dieser ganzen Worker Struktur ganz gut reinpasst. Richtig, das war so ein bisschen Selbstverwirklichung, muss ich zugeben. Aber ja. Haben wir gemacht.

Vielleicht für unsere Zuhörer. Kurz. Es gibt eine Band TX t, die kann man auch auf einem standardisierten Pfad ablegen. Und wenn die Anwendung gestartet wird, wird automatisch diese Textdatei quasi ins Lock Fail übertragen. Also normalerweise steht an Spring Boot Version 5.1 Delete, aber man kann das halt mit seiner eigenen SII Banner Punkt txt überschreiben. Was immer ganz interessant ist, was die Leute sich da ausdenken, weil das so ein Freitagnachmittag Task ist. Habt ihr denn auch die einzelnen Methoden dokumentieren müssen oder viel Dokumentation schreiben müssen?

Hat euch das bringt Boot irgendwie unterstützt?

Also da gibt es ja Bild Targets Chewie Java Doc die Dokumentation extrahieren. Da gibt es auch so Spring Boot Plug-Ins das ist alles ein bisschen schöner aussieht. Da purzelt dann diese Java STANDARD Dokumentation raus. Ich weiß nicht, ob das in dem Projekt gefordert war.

Das war nicht in Förderturm manuell dokumentiert, was zu dokumentieren war. Aber zwischendurch hatte ich mir tatsächlich auch diese automatischen Tools angeschaut. Die sind teils sehr umfangreich im Sinne von, dass sie natürlich automatisch alles dokumentieren, was in dem Fall einfach mehr war, als wir brauchten. Dann hätte man sich da dann nur die Teile rausziehen müssen, die man braucht. Von daher war es quasi. Es hat einem zu viel schon gegeben, mehr als von den Verbrauchter.

Zumindest war das mein Eindruck, was aber definitiv am Projekt Scope lag. Das war einfach nicht immer Anforderungsprofil der Aufgabe enthalten. Da ging es mehr um eine Übersicht Dokumentation und weniger in die Tiefe einzelner Methoden rein Dokumentation zu schreiben nach dem Festlegen vorgelegten Schema, sodass wir dann da eher eine Markdown Read Me geschrieben haben, die auch eher kurz ausgefallen ist und auf die Punkte eingegangen ist, die wirklich nötig waren. Deswegen konnten wir das Feature nicht nutzen. Sinnvoll.

Gab es denn bei dem Projekt irgendwie Fallstricke, die mit Spring Boot zusammenhängen, wo ihr sagen würdet Oh, wenn ich das nochmal machen würde, da hab ich viel Zeit gelassen, das würde ich anders machen. Also so Tipps, die im Grunde euch selber geben würdet, wenn ihr das Projekt nochmal durchführen würdet.

Ich weiß nicht, ob ich sie anders machen würde, aber auf jeden Fall Fallstricke, über die man wegkommen muss. Schon an seinem bisschen. Vor allem wann etwas ein Singleton Objekt ist und wann es kein Singleton Objekt mehr ist bzw. wenn du mal kein Singleton Objekt haben willst, musst du einfach ein bisschen mehr Arbeit machen oder muss überlegen ob du es wirklich nicht Singleton brauchst oder haben Singleton nicht auch ausreicht, weil einige Teile der Anwendung Wandern nachher ermutigt werdet. Da musste man dann ganz genau nachdenken, dass man da jetzt nicht dem Singleton irgendwie einen State verleiht, der dann von zwei setzt, sich gegenseitig überschreibt oder solche Dinge.

Da kann man perfekt wie Pattern einzelne Instanzen pro Thread Instance Ihren oder eben das ist ja fast schon dein generische Inversion of Control Anwendungs Design. Was du beschreibst.

Genau. Aber da fehlt ein bisschen die Zeit, dann auch für irgendwann. Aber ich würde sagen, dass das der wichtigste Punkt war, weil das einfach ein Konzept ist, was keiner von uns beiden zu dem Zeitpunkt wirklich angewandt hatte. Mal im Alltag, in der Programmierung und wenn man sich damit mal ein bisschen intensiver auseinandergesetzt hat, vielleicht auch auf einer theoretischen Ebene und an einfachen Beispielen angefangen, dann erleichtert das den Einstieg vor allem ins Design von so einer Anwendung, weil wenn man ständig wieder drei Schritte zurückgehen muss, um dann den Ansatz für eine Problemlösung doch nochmal komplett auf links zu drehen, weil man eben genau bei dieser Inversion of Control irgendwie das konzeptionell dann doch nicht richtig gemacht hat für den eigenen Anwendungsfall Gespartes schon.

Zeit, wenn man da einfach von vornherein das bei seinem Design Pattern berücksichtigt, als sie die Anwendung designt habt. Ich meine, wir haben eben schon kurz drüber gesprochen, habt ihr genug Beispiele für Spring gut Problem im Internet gefunden, also Bildung. Die Seite haben wir erwähnt und auch sonst bei Stack Overflow hattet ihr Immi Probleme für euern Fall was zu finden oder war das eigentlich immer gut? Wie würdet ihr die Dokumentation Situation einschätzen?

Ich würde sagen, Bildung war da sehr umfangreich. Es kam ein paar Mal vor, dass ich nach dem hin. Das reicht mir jetzt nicht nochmal einen halben Tag auf die Suche im Internet gegangen, nur um dann am Ende beim gleichen Bildung Artikel wieder zu landen und zu sehen. Okay, eigentlich stimmt es ja doch, was hier steht. Und wenn man es richtig liest und einen mit ein bisschen Abstand nochmal liest, dann steht da eigentlich alles drin.

Ich glaube, bei sehr spezifischen Problemen kommt es dann wie eigentlich immer ein bisschen aufwändiger werden zu recherchieren. So grundsätzlich war das Vorhandensein von Documentation ja schon gut ausgeprägt, aber ich erinnere mich, dass wir bei dem Thema Parallelisierung und dann eben Multi Reading unserer Anwendung doch die eine oder andere technische Hürde hatten, die ein bisschen schwieriger zu überwinden war, sowohl vom Design als auch von der technischen Umsetzung nachher, was dann auch ein bisschen mehr Recherche und Refactoring bei uns dann eben auch nötig gemacht hat.

Aber das sind dann schon sehr spezifisch die Themen der parallele Entwicklung oder?

Neben läufige Entwicklung ist natürlich immer noch ein Komplexität Stufe höher, einfach weil man eine ganze Menge bedenken muss, damit das auch funktioniert.

Ich hatte noch einen zweiten Fallstrick. Vielleicht hat mir eben am Anfang schon über das dpa gesprochen und wie Einfaches zu sagen gemacht hat, die Datenbank aufzubauen. Man hat dann aber am Ende schon gemerkt, wenn man relativ komplexe Abhängigkeiten mit mehreren von Civey, Strands und auch Manitoba Bennie Relationships. Irgendwann kommt man dann halt auch da ans Ende dieses Modells und kommt dann halt an Stellen, wo es dann noch mal her sich herausstellt. Okay, wenn ich das jetzt aber von der Seite aufziehe, funktioniert es perfekt und von der anderen Seite generiert es mir dann halt ganz ineffizienten ASCII Code.

Da muss man dann halt ein bisschen aufpassen, wenn man da angelangt ist.

Also einfach ein bisschen Augen offenhalten und vielleicht nicht nur eine Doku Stelle im Internet aufsuchen, sondern 2 3, um dann eben das für sich passende da rauszusuchen.

Genau da braucht ein bisschen mehr Recherche und muss sagen ein bisschen auch selber mehr ausprobieren, was dann da der beste Ansatzes würde.

Dir den Spring Boot als Plattform weiter empfehlen oder nochmal verwenden, wenn ihr eine weitere Java Anwendung in sagen wir mal im Kybernetisch Cluster betreiben wollen würdet oder auch einfach so auf dem Server betreiben wollen würdet.

Auf jeden Fall. Also ich würd mit nichts anderem anfangen wollen in Java.

Ich denke auch, dass sich das als Blaupause und Grundlage für, ja als die Fall regelrecht für Java Anwendungsentwicklung nehmen würde, weil die meisten Anforderungen aus Umgebungen kommen, wo man das eben gut umsetzen kann. Ich meine missis in den letzten Jahren nichts untergekommen, wo man jetzt auf einen klassischen ein Maschienen Server oder einen großen Mainframe irgendwas hätte entwickeln müssen, sondern man kommt eben immer eigentlich gerade wenn es Java sein soll in diese Microservices Richtung bzw. kann seine Anwendung zum Lösen eines Problems so Design, dass sie auch sinnvoll so umzusetzen ist.

Und dann ist Spring Boot wirklich ein Top Tool würde ich jetzt sagen. Und das ist doch glaube ich für den Einstieg gut. Also wenn man sagt, man kann bisschen programmieren, man kann objektorientierte programmieren, dann steigt man in Java ein, dann kann man mit Spring Boot auch sehr zufriedenstellend schnell ein Ergebnis erzielen, was wirklich Produktions reif. Innerhalb kurzer Zeit ist das eine tolle Sache.

Da kommt glaube ich dieses Opinio Native was du meintest Magix gut durch es. Es hat halt an vielen Stellen einfach sinnvoller die Falz und außer wenn du weißt, dass das unbedingt anders haben willst, ist halt anders. Aber der Default ist erstmal sinnvoll.

Ja genau. Also diese Opinio native Settings spielen eine Rolle. Deshalb läuft die Anwendung sofort, weil man im Grunde alles hat, was eine Anwendung benötigt. Der Webserver oder der Tomcat in dem Fall ist eingebaut, Matrix sind eingebaut, Health Checks sind eingebaut. Externe Konfiguration, also das Laden von Settings aus Properties. Falls wenn man zum Beispiel einen Dart Mac anbinden möchte und da ein Username Passwort und Connection String hinterlegen muss, ist dabei. Also ja, es funktioniert direkt und man kann dann anpassen, was man braucht.

Ich fand euer Beispiel sehr schön, weil ihr eigentlich ein Micros Service der Daten Transformationen hauptsächlich Macht implementiert habe, dann aber gesehen hat. Oh wir müssen noch irgendwie eine Web Komponente nachrüsten, weil wir statische Dateien aus liefern möchten oder Web Dateien ausliefern möchten. Ist das wirklich für eine Web Oberfläche gedacht gewesen, als wo jemand auf diesen Service springt und im Browser etwas machen kann? Oder war das einfach nur um Dateien auszulagern, die für diese Transformation notwendig sind?

Das war tatsächlich dann eine Oberfläche. Einfach weil sonst der Zustand der App ein bisschen schwierig zu monitoren waren. Brauchten wir da etwas, um den Überblick der dem Garzón in dem Fall zu behalten? Einfach weil ja da mehrere Zehntausend. Datenpunkte migriert werden mussten und das durch verschiedene Snakes durch. Erstmal exportiert werden musste, im neuen System importiert. Nebenbei noch Sachen hochgeladen werden mussten und da den Überblick zu behalten. Damals hat man ja im Frontend für gebastelt. Okay.

Und das Frontend ist nur für euch gewesen. Oder guckt der Kunde das auch an, wenn er diese Software einsetzt?

Das war jetzt in dem Fall für uns mehr als die Person, die dann die eigentliche Migration macht. Was in dem Fall ein Kollege von uns ist. Also nicht ganz für uns selber, aber der Kunde benutzt es in dem Fall nicht.

Er könnte es aber benutzen, wenn er wollte. Wenn die Anwendung in unserem Fall, auf dem wir entwickelt haben und er unser Benchmark Punkt war Björn ist gerade gesagt, ein paar 10 000 Datenpunkte, um die es ging, da war die Laufzeit für den kompletten Migrations Prozess im Bereich von Stunden. Das ist was, was man theoretisch morgens starten. Und wenn man es Büro verlässt, ist die Anwendung fertig betreiben kann.

Nicht nur theoretisch, sondern praktisch, ja sogar richtig.

Das wird sich dann hoffentlich bald zeigen. Aber es gab auch den Use Case. Ein bisschen mehr in der Zukunft, dass wir über mehrere 100 000 Datenpunkte vergleichbare Einzel Größe reden. Und dann würde die Anwendung halt schon deutlich länger laufen und man möchte vielleicht aktives Monitoring davon haben. Und das wäre eben darüber möglich gewesen, dass man dann eben mal reinschaut, wie es gerade der Stand der Dinge.

Und insbesondere hat dieses Webforen dann letztendlich nichts anderes getan, als gewisse Endpunkte unserer App anzusprechen. Und mit diesen Endpunkten hätte man dann auch ein beliebiges anderes Monitoring aufziehen können.

Na okay, ater sind die nachgerüstet von Matrix, die ihr eingebaut hat.

Unter anderem genau Azawad. Einige Standards, Sachen wie ihr Herzschlag und Memory Konsumption. Aber dann halt auch einfach wie viele sind schon prozessiert?

Wie viele sind in den unterschiedlichen Stages der Migration solche Sachen? Den letzten Fallstrick hatte ich noch als beiten Entwickler. Man muss sich an die Annotationen gewöhnen, dass sie einfach was ganz anderes sind als Payton Annotationen. Wenn man damit dem momentanen Modell sich einmal umgedacht hat, dann funktioniert es. Also das ist halt wirklich nur Annotation. Sind also zusätzliche Informationen, die dann irgendwie interpretiert wird, nicht Code, der ausgeführt wird.

Die Annotationen gibt es auch in neueren Pfeifen Versionen, zum Beispiel bei den Data Classes und ich hatte das so verstanden, dass die was ähnliches machen wie auch in der Java Welt oder ich hab sie so benutzt.

Sie sehen ähnlich aus, aber letztendlich sind sie nichts anderes als Haja oder Functions. Also die Funktionen als Argumente nehmen und dir deine modifizierte Funktion zurückgeben. Während Java Annotationen ja eigentlich nur ein Hinweis an ein Paket sind, jetzt irgend eine Magie zu verführen, aber nicht an den Annotation selber gekoppelt ist. Klar, man kann Annotation auch selber schreiben, aber es ist schon so, dass die Annotation so eine Art Auszeichnung sind, um die nachfolgende Funktion oder so eben zu Parameter visieren oder das nachfolgende Objekt genau innehabe.

Das eigentlich paar Interesieren passiert in Java soweit ich es verstanden hab, ja nochmal einfach anders. Also irgendetwas anderes nimmt dir Annotation und macht dann etwas damit Sphären in Python. Es ist die Annotation selber, die etwas macht.

Genau das Spring Framework werte die Annotationen aus und sagt Ach guck mal, hier ist ein Auto Wired, da muss ich ja diese Biene reinstecken, die ich hier initialisiert hab. Also das kann man vielleicht noch sagen, das Spring Framework geht hin, wenn die Anwendung gestartet wird, guckt das alle Bins also also eine Java Klassen hier als Service definiert habt oder als Controller definiert habt, guckt es an, instanziiert diese Klassen und dann erst guckt es in die einzelnen Klassen rein.

Wo steht dein Auto Wired und stöpseln jetzt diese initialisiert Klassen eben zusammen, damit die Anwendung loslaufen kann? Das passiert sozusagen alles im Vorfeld von dem Framework selber. Wenn ihr Fragen habt oder Feedback, sendet uns gerne eine E-Mail an Podcast Skill bei Tee. Wir freuen uns immer über Bewertungen und wenn ihr den Podcast an Freunde und Kollegen weiterempfehlen, die sich für ähnliche Themen interessieren. Wenn ihr aktuell im IT-Bereich auf Jobsuche seid, schaut gerne auf das G.H. Die Slash Job Seite vorbei.

Weitere spannende Technologien Themen findet ihr auch im Skill Bait Blog. Oli Andreas, ich danke euch ganz herzlich, dass ihr heute Abend meine Gäste wart.

Danke Maurice. Es war mir eine Freude. Ich wünsche euch beiden noch einen schönen Abend. Danke dir auch.

Maurice KnoppSkillbyte Podcast #45: Das Spring Boot Framework
Mehr

Skillbyte Podcast #42: IT-Aufgaben richtig outsourcen (Design, Entwicklung, Support)

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: IT-Aufgaben richtig outsourcen (Design, Entwicklung, Support)

// Inhalt //
01:14 – Definition: IT-Outsourcing
03:06 – Typische IT-Outsourcing Aufgaben
03:54 – Vorteile von IT-Outsourcing
04:26 – Warum ist IT-Outsourcing relevant? – Erfahrungsberichte aus der Praxis
10:23 – Saubere Kommunikation ist der Schlüssel für erfolgreiches Outsourcing
14:30 – Vorgehen für erfolgreiches IT-Outsourcing
15:17 – IT-Outsourcing Schnittstelle schwierig zu besetzen
16:18 – Erfahrungsberichte & Vorgehen für erfolgreiches Outsourcing
22:30 – Systembetrieb erfolgreich outsourcen
28:11 – Welche Plattformen gibt es?
30:09 – IT-Outsourcing Fails
37:09 – IT-Outsourcing Success Stories
41:06 – IT-Outsourcing is here to stay

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #42: IT-Aufgaben richtig outsourcen (Design, Entwicklung, Support)
Mehr

Skillbyte Podcast #25: Kubernetes: Flexibles und leistungsfähiges Rechenzentrum für Unternehmen

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Kubernetes: Flexibles und leistungsfähiges Rechenzentrum für Unternehmen

// Inhalt //
01:07 – Kubernetes: Aus welchen Komponenten besteht es? Was leistet es?
06:24 – On-Premise und in der Cloud
07:26 – Yaml Beschreibung für Applikation Zielzustand
09:07 – Services, Secrets, Ingress, Namespaces, Loadbalancer,… Wie hängt das zusammen?
13:43 – Namespaces
15:18 – Kubernetes Softwarepakete mit HELM
18:05 – Kubernetes steigert Geschwindigkeit und verkürzt Innovationszyklen
25:32 – Security Checks automatisieren
27:24 – Monitoring durch Health Checks
28:11 – Entwickler übernehmen Verantwortung für Infrastruktur
30:09 – Cloud Native Softwareentwicklung
35:11 – Werkzeuge entwickeln sich schnell

DevOps Folge: https://soundcloud.com/skillbyte/skillbyte-podcast-2-devops

Was ist die Twelve-Factor App?: https://www.dev-insider.de/was-ist-die-twelve-factor-app-a-894702/

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Was man nicht mit Geschwindigkeit Du kannst vieles ausprobieren und anhand des Feedbacks dann weitermachen, das heißt, es macht auch ein Businessmodell, macht es plötzlich Dinge möglich, die vorher nicht möglich war?

Herzlich willkommen zum skillbyte Podcast Episode Nummer 25 Kybernetische, flexibles und leistungsfähiges Rechenzentrum für Unternehmen abonniert unseren Kanal für mehr spannende Themen aus dem Technologie Umfeld. Wenn er eine Frage habt, schickt uns gerne eine E-Mail an Podcast. Wir freuen uns auch immer über Bewertungen des Podcasts oder Anregungen an die gleiche E-Mail-Adresse senden.

Ich bin heute hier wieder mit Masiar hier. Es freut mich, dich mal wieder zurück zu haben nach einigen ausschweifenden Suchen. Und wir sprechen heute über das Thema Kubernetes und welche Herausforderungen sich für die unternehmensalltag ergeben in Kombination mit kybernetische und natürlich auch, welche Vor und gegebenenfalls Nachteile sich um das Hauptthema Kubernetes ranken. Ich denke, wir sollten erst mal ein paar Begrifflichkeiten im Kubernetes Kontext einführen und besprechen, kurz sagen, was das ist für die Zuhörer, die noch nicht so viel Kubernetes Erfahrung haben und sich erst mal aufschlagen möchten.

Was ist Kubernetes überhaupt?

Kybernetische ist eine Orchestrierung, Plattform für Docker, Container. Jeder, der sich vielleicht mal mit Arisierungen und Containern beschäftigt hat, weiß, dass man die Container im Prinzip als Service für eine bestimmte Applikation baut. Services spielen hier eine Rolle. Jede eigenständige Applikation oder Micro Service wird in einen Container gepackt, und diese Container kommunizieren miteinander. Bei ein, zwei Containern ist das noch relativ einfach. Hier kann man entweder direkt mit dem Docker Command Interface starten und verbinden, wenn es mehr und komplexer wird.

Dann kann man z.B. Docker Composer nutzen. Aber Docker Combos ist mehr gedacht für lokale Entwicklungsumgebung, um schnell mal eine Umgebung zu starten. Verschiedene Dienste wie zum Beispiel Majas gelten als Frontend und ein, zwei Backend Container. Sobald es in Produktion geht, dann wird es schwieriger, das mit Docker, Combos oder auch selbst mit Swarm zu managen. Da braucht man ein etwas robustes System, und das sind dann halt Plattformen wie Kobanê oder meeses, Marathon oder Opernchef.

Die Docker Container, die rohen Docker Container benutzt man eher lokal zur Entwicklung, wenn man sich nicht sein lokales Entwicklungs System mit Dependance zu Mülln möchte, sondern schnell verschiedene Dienste nebeneinander installieren möchte und kybernetische ist sozusagen der Puppenspieler, der die Docker Container dann orchestriert.

Das ist ein schönes Wort. Puppenspieler? Genau, genau. Ja, es ist vielleicht nochmals im Hintergrund. Historisch gesehen war es früher so, dass man ein Server installiert hat, darauf Dienste installiert hat, und die Dienste hatten ihrerseits wiederum Abhängigkeiten, bestimmte Software, Bibliotheken oder andere Dienste. Und das war sehr flexibel, weil man z.B., wenn man zwei verschiedene Versionen nebeneinander installieren wollte, von beispielsweise Majas Cruel. Dann gab es halt die Probleme, dass die Abhängigkeiten nicht richtig stimmen und dass man sehr viel manueller Aufwand betreiben musste, um mehrere Versionen nebeneinander betreiben zu können, so es denn überhaupt möglich war.

Und mit Docker hat man eben diese ganzen Applikationen zusammen gepackt und fährt jetzt nebeneinander eben diese einzeln Container hoch, die alles mitbringen. Und somit ist auch der Betrieb von unterschiedlichen software-version einer Komponente kein Problem mehr. Also eine Flexibilisierung in der softer Schicht Kybernetik ist sozusagen. Ja, ich glaube, dass Altgriechisch für Steuermann. Google hat es ursprünglich entwickelt und dann unter einer offenen Lizenz gestellt. Der Steuermann steuert die Docker Container aus, je nachdem, welche Gesamtklang schafft man denn haben möchte.

Also ich glaube, technisch ist es so Kobanê. Es besteht aus einem Master und mehreren Worker Notes. Ich weiß nicht, ob es auch mehrere Master Notch geben kann.

Ja, natürlich. Wenn du in einer hoch verfügbaren Umgebung bist, dann brauchst auf jeden Fall mehrere Master. Da spielt das genutzte Protokoll eine Rolle, wie sich diese Master quasi miteinander synchronisieren. Das ist im Wesentlichen ist das basierend auf CD, quasi den Status des Clusters. Das ist die kritische Komponente und das benutztes Protokoll. Das heißt, für eine hoch verfügbare Umgebung braucht man eine ungerade Zahl an einem Master. Das heißt drei, fünf, sieben und so weiter.

Damit man immer beschlussfähig ist, sozusagen, wenn eine Maschine ausfällt.

Richtig, deshalb man Majority und Votings und so weiter zu tun. Deswegen habe ich bis jetzt fünf. War das Maximum, was ich erlebt habe. Kommt doch drauf an, wie schwer die Master runterlassen sind, wie viel sie zu arbeiten haben. Aber grundsätzlich kommt man mit drei, maximal fünf Marston aus in einer hoch verfügbaren Umgebung, dem Master.

Oder der Master unterscheidet sich nur dadurch von den Wolken, dass dort eben der Master. Dienst läuft, der Master Kybernetische Dienst läuft, dem gibt man sozusagen vor, ich hätte gerne folgende Umgebung mit folgenden Docker Containern. Und der sorgt dann dafür, dass auf den Worker Schnauz die entsprechende Last verteilt wird und diese soll Umgebung, die ziel. Umgebung sozusagen hochgefahren wird.

Combined ist an sich, besteht aus vielen Einzelkomponenten selbst, und Master besteht aus einem Server ETSI Knoten, wobei dieser Knoten nicht auf dem Master selber laufen muss, das dann auch ein eigenständiges Cluster sein. Dann haben wir den Ebikon Schola. Wir haben den Scajola. Das sind alles Komponenten, die den Master quasi ausmachen. Man kann es auch so konfigurieren, dass einzelne Wirk lots, also die Container, die auch auf dem Worker laufen, auch auf dem Mars läuft.

Aber grundsätzlich in der Umgebung verhindert man, dass das Workflows auf dem Master laufen, sondern das dem Master wirklich Matheaufgaben haben und nicht noch Workouts laufen haben.

Also den Master Nod muss man sich so vorstellen wie den Tower beim Flughafen, der sozusagen die Aufgaben die Landebahnen zuteilt, auf die einzelnen Flugzeuge kybernetische. Frei Das heißt, ich kann das in meinem eigenen Rechenzentrum einsetzen. Alle großen Cloud Provider bieten auch managed kybernetischen Umgebungen an, sodass man auch in einem Cloud Rechenzentrum direkt auf diese Kobanê Infrastruktur zugreifen kann. Und ich kann das auch verbinden. Ich könnte eine Cross und Tramitz Cloud kombiniertes Umgebung schaffen. Richtig?

Ja richtig, die Worker, wo die laufen, ob sie in der Cloud laufen, laufen, hybrid laufen. Das spielt für Kybernetische selber keine Rolle. Das ist abstrahiert das Netzwerk, solange die Dinger miteinander sich connector können. Diese Worker überall laufen können.

Das heißt, für Unternehmen, die jetzt viele Dienste in die Cloud migrieren, ist das eine sehr interessante Technologie. Einfach aus dem Grund, weil man ja auch so ein bisschen Hersteller unabhängig wird. Wenn alle Clouds diese Kubernetes Umgebungen anbieten und ich die auch am eigenen Rechenzentrum verwenden kann, dann bin ich mich ja nicht an proprietäre Dienste von AWS oder AJA oder der Google Cloud. Jetzt habe ich schon die Komponenten Master Notes Worker Notes. Haben die einzelnen Docker Container? Wie sag ich denn jetzt kybernetische, wie mein Ziel Zustand ist?

Da benutzt man doch die Jamel Beschreibung Sprache, um verschiedene Dokumente anzulegen, um Kobanê das zu sagen.

So und so möchte ich das genau. Der Workflow ist wie folgt Du beschreibst deine Wünsche, wie zum Beispiel, welche Applikationen, also welches Docker Image mit wie vielen Instanzen auf welchen Ports hören soll. All diese Dinge beschreibt in sogenannten Jamel Dateien und mit einem Kommandozeile tool genannt hatte also bzgl. sagst du Kobanê, dass er die Jamel Datei nehmen soll und aufs Cluster abspielen soll. Und das machst du dieser Kommandozeile. Die Kommandozeile Tool unterhält sich immer mit diesem Speicher, quasi.

Du kannst dein gegarte Lokal auf deinem Laptop haben und ein Cluster kann sonst irgendwo stehen. So lange dieser Episode auf dem Haus und auf dem Port erreichbar ist.

Das ist dann quasi verbunden Der Dienst von einem Laptop kommuniziert zu dem Master in der Cloud oder im Rechenzentrum.

Je nach Security ist auch durchaus denkbar, dass wir nur mal als Beispiel auf Amazon unterwegs bist oder in anderen Cloud Umgebungen. Ist es auch denkbar, dass du aus Angst oder Not, wo du quasi mit einem Laptop erst über s.a. Verbindung zu dem Kamphaus hast und von dort aus Bergkuppe dann die Befehle absetzt?

Ich glaube, Kube Cattle ist die Kurzform für Cube Control Kobanê. Sollten wir vielleicht sagen, in dieser jamil Beschreibung Sprache kann ich dann ja verschiedene. Ja, ich sag mal kubanisches Artefakte beschreiben. Also Secrets sind Ingress, die in verschiedenen Naim Spaces liegen. Laut Ballonfahrt kann ich beschreiben, was es damit auf sich. Vielleicht gehen wir einfach mal durch, was ein Service ist.

Kubernetes hat viele verschiedene sogenannte epü Objekte, und die Aromas ist Pott. Der ist sowas wie ein Container. Aber laut Spezifikation kann so ein Pott auch mehrere Container beinhalten. Grundsätzlich ist das Muster, dass man einen Container in einem totlaufen laufen lässt. Es sei denn, du hast spezielle use cases, wo du einen sogenannten Tschaika Container innerhalb des Ports laufen lässt, sodass mein Container hast plus einem Container. Das kann z.B. sowas sein. Win win lock Schipper, der locks des Containers auswertet und hin.

Und das möchtest du auch mal separat für sich beschreiben. Und die Pleuel, und das läuft oder kann zum Beispiel in einem Ort als zweiter Container mitlaufen. Also Pod ist quasi die kleinste Beschreibung dieser Einheit. Man sollte aber niemals mit einem. Direkt arbeiten, weil so bekommt IPI aus dem Osten bestimmten Reinsch. Was du auch konfigurieren kannst innerhalb von Kobanê, ist nur, wenn der Potz stirbt und davon. Das ist ein Paradigma, was man verstehen sollte. Man bewegt sich einem sehr volatilen Umfeld.

Das heißt, weder Amazon noch Google noch AJA garantieren, dass ein Bohrkerne zum Beispiel, den sie dir zuweisen, auch permanent läuft. Man muss dagegen designen und gewappnet sein, dass so ein Bordkanone einfach mal stirbt und ein anderer zur Verfügung gestellt wird. Davon muss man ausgehen, man darf nichts anderes voraussetzen. Und ein Pott, wenn er denn und das macht auch Kobanê werden, wenn ein Cannot ausgetauscht wird, dann kann er sehr transparent die Potz umziehen, offenen anderen funktionierenden Nod und du bekommst das noch nicht einmal mit, weil er das Routing, Traffiq und so weiter alles automatisch finde.

Ich manage nur, wenn so ein Pott woanders hochfährt. Bekommt er zum Beispiel eine neue I.G. Das ist laut Spezifikationen so, und dann kommt ein weiterer NPD-Fraktion Layer dazu. Service Ein Service ist quasi vorgeschaltet vor einem Ort und garantiert dir zum Beispiel eine bestehende IP-Adresse oder eine permanente IP-Adresse aus diesen Reinsch. Solange das epi Objekt des Services da ist, ist die IP auch fest, und du kann sich darauf verlassen, dass du zum Beispiel dein Backend Container oder was auch immer immer gegen diese IP laufen lassen kannst.

Und dann ist quasi erreichst Der Vorteil eines Servers ist es auch noch, dass du mehrere Instanzen des Potz hinter einem Service haben kannst, und der fungiert dann quasi auch als Pilot. Balance?

Okay, das heißt, ich darf niemals mit der FDP direkt sprechen, sondern mit dem Service, weil IPI Nummer ist nicht garantiert. Und wenn ich immer mit dem Service spreche, dann managed Cohn-Bendits die Kommunikation für mich. Ob es jetzt nur man kann sich eine Anwendung vorstellen, wo z.B. eine Such Komponente drin ist. Einfach eine Website Suche Such Komponente aufgerufen wird, dann würde ich mit dem Service Suche sprechen und nicht mit irgendeiner festen IP.

Und dann könnte dahinter ein Pod laufen, der diese Suche durchführt. Wenn gerade viele suchen. durchgeführt werden, könnten aber auch fünf Such Potts dahinter laufen und ich würde einfach mit dem Service sprechen und Kobanê? Es würde die Last automatisch balancierend zwischen die exakt potz die da hinten Dreierreihen. Okay.

Dieser Service ist unter der Haube quasi ein Managed für die. Das ist der sogenannte Proxy. Das heißt, wenn ich auf dem Bohrkernen unterwegs bin, mir die Prozesse angucke, dann Proxy finden, und das ist dieser Service Dienst, und der nutzt einfach IP T-Bills, um deine Pakete entsprechend richtig Suruç.

Das ist schon ziemlich low level. Also darum kümmert sich Cohn-Bendits. Absolut wichtig, glaube ich. Für unsere Zuhörer ist, dass man sagt Okay, deine einfällt. Micro Services dürfen nur mit dem Service sprechen und auf keinen Fall mit festen Tipis, weil die können sich ändern, die sind volatil. Und wenn man einfach auf diese Services Ebene geht, dann kümmert sich Kybernetische um den Rest.

Das Interessante ist, dass dieser Service quasi auch bei der Jamil beschrieben wird. ummehr mit Kube cattle, in den Kobanê die S-Klasse eingespielt wird, automatisch dafür sorgt, dass der Service Name nur in der Jamel festgelegt ist, quasi gleichzeitig der Host Name ist und von jedem Nod aufgerufen oder aufgelöst werden kann.

Das heißt, für die Anwendungsentwicklung selber wirkt dieser Service Name wahrscheinlich wie DNS Name exakt.

Genau das ist es ja, das ist ja auch ein Konzept.

Innerhalb von Kybernetische legt man einen Naim Space an, also der STANDARD namens BAW heißt, glaub ich, default, den man nicht benutzen sollte. Also man legt namens Bacons an für unterschiedliche Services, und innerhalb der Namens bases sehen sich die Services, oder die Ports können miteinander kommunizieren, und man kann dadurch eine höhere Sicherheit erreichen, dass man zum Beispiel Services, die nicht von außen erreichbar sein sollen, dann weg kapselt.

Die Nehmens Bacons ist erstmal ein organisatorisches Konstrukt. Kannst du zum Beispiel verwenden, um verschiedene Produkte, verschiedene Projekte, verschiedene Abteilungen in deinem Unternehmen abzubilden? Security technisch so eine Art Folder Werbung, wo die Sachen reingehört. Security Technisch muss man ein bisschen mehr machen, weil die standardmäßig die Ports aus den verschiedenen Namib. Sich gegenseitig erreichen und aufrufen können. Parke aber Security. Technisch gibt es halt Möglichkeiten, dass man diese hart abschottet, dass es übergreifend keine Kommunikation und so weiter möglich ist.

Okay, namens Spaces. Man kann es sich jetzt vorstellen In einem Rechenzentrum mit 100 Anwendungen würde man jeder Anwendung einen eigenen Namen Space zuweisen und die jeweiligen Ports, aus denen die Anwendungen dann besteht, genau die einzelnen Dienste. Die würden dann unterhalb des jeweiligen Namens Spaces laufen könnten.

Cross Application aber kommunizieren genau nach dem, was du halt in deinem Polleschs festlegt. Du kannst auch User einrichten, wo du sagst, der darf z.B. nur. Rechte auf diesen Namen Space. Jetzt hast du schon gesagt, dass man mit Cube Control oder Cube Kanzeln die einzelnen Befehle oder die Konfiguration von Kybernetische verändern kann. Also ich kann ein Service hinzufügen Ich kann ein POW hinzufügen. Ich kann diesen Schritt für Schritt, diesen Wunsch, Zustand herstellen. Aber was man ja eigentlich möchte, wenn man das kennt man ja, zum Beispiel aus dem Linux Umfeld oder MacOS Umfeld.

Man möchte ja eine Anwendung paktieren, was man ein Paket hat, was man ausliefert oder wie so eine ZIP-Datei, die im Prinzip alles enthält und die Anwendung dann innerhalb dieser Copernicus Umgebung entsprechend provisionsbasis und hochfährt. Da gibt es das Tool Helm ist, glaube ich, altgriechisch für Ruder. Und das ist ja der Kuper. Nettes Paket Manager.

Wir haben ja diese ganzen egy Objekte erwähnt. Weißt du, was du hast? Du hast Ingress und jede Menge mehr. Die kann ich natürlich alle einzeln mit Kube Karte platzieren und dieser Pakete manage ist einfach dafür. Da bin ich komplexere Applikationen, hab die mit mehreren Abhängigkeiten und so weiter quasi als Paket zusammen schnüren. Und dann mache ich einfach ein Helm install meine Applikation, und der sorgt dafür, dass alles Notwendige herangezogen wird und die Plaid wird.

Der Vorteil ist jetzt hab ich das Paket, das Helm Paket oder das Hemd. Schardt hab ich ja quasi auch diese Infrastruktur Ascot Paradigma erfüllt. Ich tippe nicht mehr mit Kube Kuddel irgendwelche Befehle und hinterher kann es keiner mehr nachvollziehen, was genau ich da gemacht habe, sondern mit Helm kann ich sagen Helm in Stahl und das Paket wird installiert oder Helm an in Stohl das Paket, dann wird es wieder installiert, und ich habe immer konsistenten nachverfolgt baren Zustand, den man dann auch entsprechend pensionieren kann, um verschiedene Releases ein und derselben Anwendung nach und nach aufzubauen und auszurollen.

Also Helm Ich hab ja immer so ein paar Beispiele aufgelistet. Was kann man mit Helm machen? Also die Anwendung paktieren, Abhängigkeiten definieren beispielsweise einen Micro Service, der vom Internet aus erreichbar sein soll. Der könnte dann noch ein Luftballon vorgeschaltet bekommen ein Kobanê, kybernetische Software, Luftballons, Suchdienste können. Williams Mountain, Persistent Williams Mountain war mal an der Datenbank. Denkt die, muss er die Dateien irgendwo ablegen und verschiedene Services enthalten für anwendungs Komponenten. Also wenn man Mikroskops hat, er auf die Datenbank zugreifen will, dann muss der Service sich bei der Datenbank irgendwie authentifizieren, damit User und Passwort.

Dafür würde man dann eben einen Service USA anlegen, diesen als Siegrid. Das ist auch ein Kobanê, das Objekt ablegen und das all dies gleichzeitig geschieht und der Micro Service mit der Datenbank kommunizieren kann. Das würde man dann auch anders mit aufnehmen und in einem Rutsch sozusagen mit ausrollen. Super. Ich glaube da haben einen guten Einblick gegeben, was Kybernetische alles leisten kann und wie es aufgebaut ist. Was sind denn die Herausforderungen für die Unternehmensseite, die heute was sind die Business Probleme, wo kybernetische helfen kann?

Im Wesentlichen geht es bei diesen Plattformen. Es muss nicht einmal kybernetiker sein. Natürlich sprechen wir jetzt in dieser Episode über Kybernetische. Aber grundsätzlich geht es um Geschwindigkeit. Das heißt, was habe ich als Business One von Geschwindigkeit? Ich kann schneller auf Marktgegebenheiten und Veränderungen reagieren. Ich verbrauche meine Ressourcen in Form von Zeit, Geld und Personal nicht, um ein System am Leben zu halten und Fehler zu fixen, sondern ich kann diese Ressourcen verwenden, um schneller neue Features zu bauen und schneller am Markt zu positionieren.

Schneller zu skalieren bin ich plötzlich durch eine Marketingaktion oder durch einen glücklichen Zufall? Viele, viele User auf meiner e-commerce-plattform habe, dann kann ich durch die Geschwindigkeit, was ich manifestiert, durch Automatisierung z.B. verschiedene Nod hochfahren, um diese Last abfangen zu können. Und diese Geschwindigkeit erreiche ich, wie gesagt, durch Automatisierung. Dafür aber, damit ich das automatisieren kann und Ressourcen sparen kann, brauch ich die Beschreibung meiner Plattform als Code. Das heißt als Jamel Manifeste, die dann getriggert durch verschiedene Gegebenheiten automatisch ablaufen können.

Die Vorteile, die die verschiedenen Cloud Platform mitbringen, nämlich dass ich ein Nod hochfahren kann und so weiter, das macht sich Kybernetische zu Nutze. Und ich kann durch Kombination von verschiedenen, was ich früher erreicht habe, durch Puppet und Chef, um gewisse Dinge zu automatisieren. Das ist alles in dieser Plattform Kybernetische. Die native Unterstützung der Cloud-Anbieter für Kybernetischen automatisiert, und das kann ich auf Knopfdruck quasi lostreten. Ich brauch kein Admin, der 24Stunden 24/7 auf irgendwas achtet und aufsteht.

Natürlich brauche ich das auch in irgendeiner Art und Weise, aber es ist nicht mehr wie früher, weil alles automatisiert ist.

Das heißt auch die Rechenzentrums Landschaft. Verändert sich also so wie ein klassisches Rechenzentrum, hat verschiedene Server und Spezial Appliances Slot Balance, die für einzelne Anwendungen beschafft wurden. Es gibt den zehn Jahre alten Server in der Ecke und den neuen Server für die Anwendung von letztem Jahr, sondern dadurch, dass Kobanê eben diese Standardisierung vorantreibt. Kann man eigentlich sagen ein TMS Rechenzentrum oder ein Cloud Rechenzentrum? Man packt einfach standardisierte Server zusammen, die günstig sind im Einkauf, wenn man einfach viele davon abnehmen kann, und weil sie millionenfach verkauft werden, und hält diesen Pool an Rechenkapazität vor.

Und jetzt kann man mit Kybernetische die einzelnen Anwendungen in dieses ja vorhandene Rechenzentrum die Plotin laut Ballonfahrer sind Software mäßig oder werden per Software umgesetzt. Man kann natürlich auch Hardware Luftballons hernehmen für richtig kritische Anwendungen, und ich kann Server tauschen. Ich kann Server, die vorhanden sind, nutzen, bis sie irgendwann. Ich sage mal Anführungszeichen kaputtgehen, weil wenn sie ausfallen, wird der Potro woanders gestartet, und meine Anwendung merkt es gar nicht so. Dieses Konzept der virtuellen Maschinen kann ich dann auch auf anwendungs Ebene fortführen und bin sehr flexibel, wann eine Anwendung auf einmal deutlich mehr Ressourcen benutzt.

Kann ich das sowohl im eigenen Rechenzentrum bieten, aber auch in die Cloud hinaus skalieren, wenn ich das brauche? Genau. Denn Geschwindigkeitsvorteil, den du ansprichst, der manifestiert sich ja insbesondere ein Kernfächer von kybernetiker ist ja das schnelle Deployment, das sich eine neue Version der Anwendung sozusagen ausspielen kann und erst nur auf 100 Prozent der Potz ausrollen kann, sodass jeder zehnte Benutzer die neue Version bekommt. Und wenn das fehlerfrei funktioniert, dann kann ich nach und nach diese neue Version dann für alle Potz ausrollen.

Also ich bin da super flexibel. Ich glaube auch Security mäßig, aber da bist du der Experte. Lassen sich die Dienste sehr gut voneinander abschirmen, die, die gar nicht mit dem Internet kommunizieren sollen. Aber auch wenn ich Anforderungen habe, das die Dienste z.B. innerhalb der Cloud oder des eigenen Rechenzentrums verschlüsselt miteinander kommunizieren sollen, dann kann ich eine Sidka Komponente benutzen. Die nennt sich istso damit Dienste die legacy Dienste, die nie dafür gemacht wurden z.B. verschlüsselt zu kommunizieren über diesen Proxy dann auf einmal doch verschlüsselt miteinander sprechen und gar nichts davon wissen.

Aber auch, dass neuere Dienste eben direkt verschlüsselt miteinander kommunizieren können.

Die Einsatzgebiete sind riesig. Also wenn man im Umfeld von Kubernetes von Automatisierung spricht, dann ist das eine konsistente und allumfassende Automatisierung. Wir haben zum Beispiel gesagt, dass EPI ein Objekt ist, das Deployment. Du kannst das Deployment so konfigurieren, dass zum Beispiel, wenn man eine neue Version einer Software live stellt, das im Hintergrund erstmal. Ich sage mal Nehmen wir an, du hast drei Instanzen E-Commerce verlaufen, und es ist eine neue Version. Und jetzt hast du verschiedene Möglichkeiten, die Deployment durchzuführen, die eine ist.

Das nennt sich Blue Green Deployment. Bedeutet, das du gleichzeitig drei weitere Instanzen hochfährt? Kybernetische für dich die neue Software. Die neue Version und anhand von definierter hält checks check er, ob die Version quasi oder die Instanz gestartet ist. Wenn alle drei Instanzen das sind, dann Switch quasi um auf diese neue Version und die alten Ports wieder runter. So mag das sinnvoll oder nicht sinnvoll sein. Man muss auch Bedenken bedenken Wenn man in der Cloud umfällt, ist das nicht immer von drei Instanzen, sondern kann durchaus auch 30 Instanzen sein und 30 Instanzen parallel hochfahren.

Bedeutet doppelte Ressourcen. Dann plötzlich braucht. Das kann ich wiederum fein justieren. Aber es gibt zum Beispiel auch ein anderes Deployment Paradigma.

Ich kann sagen, was du angesprochen, dass das sogenannte Canary Deployment, wo ich eine gewisse Prozentzahl nur weiterleiten darf, was ich neue Features schnell ausprobieren und ohne die Mehrzahl der User damit zu konfrontieren, sondern erstmal nur zehn Prozent oder zwei Prozent und sehe, wie das funktioniert. Tauchen Fehler auf? Wie reagieren die User? Und wenn ich sicher bin, dass das funktioniert, kann ich dann entweder mehr Prozent oder 100 Prozent um Unruhe. All das wird möglich. Ganz plötzlich.

Experimentieren, was früher nicht so einfach war, das meine ich mit Geschwindigkeit. Du kannst vieles ausprobieren und anhand des Feedbacks dann weitermachen. Das heißt, es macht auch für dein Businessmodell macht, dass plötzlich Dinge möglich, die vorher nicht möglich waren. Zum Thema Sécurité Du kannst also zum. Neben diesem kybernetische Paradigma gibt’s natürlich das nach wie vor das klassisches Continuous Integration und Continuous Deployment, was du quasi auch völlig automatisieren kannst. Man kann es so weit automatisieren, dass du sagst, ein Code kommt, in einem durchschimmert.

Control System nimmt sich den Code getriggert durch den Code mit. Baut das Platters in eine Kesting oder Staging Umgebung wartet. Thema Quality Gate wartet, bis jemand getestet hat und irgendwo gesagt hat Passt zum Beispiel mit einem Ulrik Fest und einem Mörz und sagt dann alles klar, ist quasi genehmigt und führt dann selbstständig in der Produktion aus. Man kann diese komplette Strecke automatisieren, sogar selbst Sécurité. Stichwort Check ups, wo du den kompletten Security Check, angefangen von einer statischen Analyse, sprich hast du vielleicht schon Bax oder Security relevante Dinge im Code eingebaut.

Da gibt es Libris, für die du, die du einbinden, Cabs, jeden Code checken und zum Beispiel gegen Datenbanken im Internet checken, ob deine Leibgericht bestimmte, weil ich haben kann, das ordnenden Bild abbrechen bis hin zu dem dynamischen Applikationen. Wenn es die Leuth ist, kann es zum. Da gibt es von sowas. Das ist eine Organisation, die sich um das Thema kümmert, wo du zum Beispiel die 100 meist durchgeführten Hex automatisch auf deine Applikation durchführen kann.

Also großzieht scripting, Shakes, Scuol Injection, Jabs und so weiter. Du siehst also, wo die Reise hingeht. All das, wofür man Tage und Wochen gebraucht hat. Früher kannst du jetzt quasi in einer Pipeline komplett weg automatisiert verstehen.

Dadurch springt natürlich die Qualität der Anwendung nach oben. Exakt. Man hat einmal diesen Integrations Aufwand, aber dann nutzt man quasi diese sich auch wahrscheinlich selbst automatisieren Libraries. Wenn neue CVS oder Security Lücken auftauchen, sind sie direkt da drin und man kann automatisiert die ganze Anwendung gegen diese neue Lücke testen lassen, sogar bis hin zu Compliance-Regeln.

Da gibt es auch Tools, wo du sagen kann, das und das und das sind meine. Meine Compliance-Regeln wie beispielsweise ganz einfach, benutze nicht das Original. Im Falle von Java, weil es Probleme hat und das Tool merkt Aha, verletzt und bricht ein Bild ab. Und Reporter? Und da gibt es richtig mächtige Tools. Würde diese ganzen Campanile Compliance-Regeln hinterlegen kannst.

Einen weiteren Vorteil das hast du schon mal anklingen lassen, ist natürlich das Monitoring durch Checks. Also ich habe jetzt Kybernetische ein Ziel stand vorgegeben und sagen So und so soll meine Anwendung aussehen. Und im Kybernetische prüft ja jetzt in regelmäßigen Abständen, ob jeder Posth gesund ist. Und wenn ein Pod nicht reagiert, dann kann man halt konfigurieren ok, bitte sofort einen neuen hochfahren, oder wenn ein die CPU Last auf einem Port eine gewisse Marke überschreitet, dann werden zusätzliche Potz hochgefahren.

Durch diesen Autos Krailling Mechanismus das vereinfacht ja auch das Monitoring der Anwendungen ganz erheblich. Das ist das, was ich eben sagte. Man kann die Hardware im Grunde viel länger nutzen, zumal wenn sie ausfällt, ist es nicht so schlimm. Combined merkt das sofort und fährt dann neuen Ports hoch. In dieser Multi Service Umgebung, was ich auch bemerkt habe, ist und das ist jetzt ein ganz deutlicher Paradigmenwechsel. Die Entwickler dadurch, dass die Infrastruktur auch durch Code beschrieben wird.

Das ist ja dieses DVB-S Paradigma, wo wir ja auch eine ganz eigene Podcast Episode zugemacht haben. Denke ich auch in der Beschreibung. Die Entwickler sind auch immer mehr verantwortlich für die Infrastruktur und die eigentlichen Admins. Früher war das ja oft so oder? In den PMS Rechenzentrum ist es oft so, dass die Entwickler bei den Admins etwas bestellen. Ein User, ein Server, eine Ressource, eine harddisk irgendwie. Und die Admins liefern die irgendwann. Jetzt musste der Developer im Grunde kann in seinem Manifest sagen Okay, ich brauche eine Disk mit 10 Gigabit, und die ist persistent und so weiter und ist quasi selber dafür verantwortlich.

Kobanê, das so zu Konfigurieren des Kabinetts prüft, das die Disk nicht voll läuft, sie entsprechend vergrößert wird und so weiter. Falls die Admins entlastet und die Developer müssten die IT-Infrastruktur verstehen, was laut Ballonfahrer. Wie funktioniert IPI Mask Reading? Was ist Nath? Diese ganzen Fachtermini, die mit Netzwerk Aufbau im Grunde genommen zusammenhängen, und bekommen diese Aufgabe zusätzlich.

Thema Das Du als Entwickler auch das spielt Richtung Geschwindigkeit. Früher, wenn du irgendwas gebraucht hast, dann hast du als Entwickler immer mit einem Admin Kontakt aufnehmen müssen. So viel Platz. Ich brauch neuen Server. Ich brauch dieses jenes und das kannst du jetzt selber geben. Du diese Jamel Dateien schreibst selber haben, und zwar innerhalb von Sekunden.

Man muss natürlich verstehen was man tut. Das verstehen, aber das ist halt der Paradigmenwechsel. Und das ist halt genau dieses Niveau, was die Unternehmen sich aufbauen müssen, ihre Entwickler entsprechend Schulwissen. Das ist halt die Herausforderung im Moment. Viele Entwicklungen, Entwicklungen stehen der Herausforderungen für die Unternehmensseite.

Um wirklich alle Vorteile von Kobanê ausnutzen zu können, muss man die Software ja etwas anders. Als das ich sage mal bis vor ein paar Jahren der Fall war das Stichwort wäre z.B. diese Klout native Anwendungen. Es ist auch möglich, alte Monolithen in kybernetische zu betreiben. Das ist nicht so flexibel, weil bei einem Monolithen wenn da der Pod ausfällt, hast du trotzdem diese Ausfallzeit bis der neue Pod gestartetes Plus. Die Anwendung muss so entwickelt sein, dass sie das auch dann handeln kann, wenn sie ausfällt.

Und viele ältere Monolithen wissen eben nichts von Kybernetische und können damit nicht entsprechend umgehen. Wie muss man Software entwickeln? Diese feingliedrige Software, die parallel laufen kann, wo Ausfälle einzelner Komponenten nicht zum System Ausfall führen, sondern einfach kompensiert werden können von Kobanê? Und wie erreicht man das?

Die größte Herausforderung ist jetzt mal von der Größe der Applikation Vor und Nachteile einer Schw, eines schwergewichtigen Monolithen und einzelner Miko. Mal davon abgesehen, weil das ist im Prinzip ein eigenes Thema für sich. Aber grundsätzlich, wenn man Software machen möchte, ist das wichtigste Thema steht. Es gibt die Summer Factor App, das beschreibt, das ist im Prinzip ein Best practices für Software, um Cloud laufen zu können.

Ich kann jedem empfehlen, sich diese App, Spezifikationen oder Beschreibungen mal anzugucken, weil das beschreibt eigentlich sehr genau eine Applikation gestrickt sein muss, um Kourtney laufen zu können. Zwei Themen aus diesen Faktoren ist einmal Stabs. Das heißt, man darf nicht voraussetzen, dass die Applikation den Status, wenn man aus dem Java Umfeld kommt, jemand JCC und Session auf dem Server der Applikation eine Session hält, weil, wie gesagt, immer sein kann, dass die Applikation von jetzt auf gleich woanders hingezogen wird.

Und dann ist der Status futsch. Man denke an Shopping Card oder was auch immer sauber gehalten wird. Das heißt, ich darf keine Sessions in der Applikation halten.

Es muss alles präsentiert werden in Datenbanken.

Im Grunde genommen direkt, ja, oder? Es gibt doch andere Möglichkeiten. Du kannst zum Beispiel einen radix haben, radix Cluster, quasi eine Datenbank, wo die Session außerhalb deiner Applikation gehalten wird. Und schnell, weil wenn so eine Session abtaucht oder Applikation ungezogen wird, dann hast du halt deine Session Memory. Da gibt es Lösungen für eine zweite Faktor. Aus diesen Faktoren ist das Du Konfiguration nicht in die Applikation legst, sondern immer von außen reingepasst, sodass quasi ein Container und eine Applikation völlig unabhängig von der Umgebung laufen kann.

Lokal State oder Produktion und Umgebung? Spezifische Konfigurationen oder Parameter kommen von außen als Umgebungen variable. Das sind, so Cloud, Faktoren. Wie gesagt, ich würde mir diese Apps mal durchlesen und strikt befolgen, weil das ist das, was ich für Applikationen in der Cloud.

Das ist auf jeden Fall ein heißer Tipp. Und da wird wahrscheinlich auch beschrieben, wie man mit Anwendungen die Anwendung komplett Container frisiert, wie man Micro Services aufbaut, wie man die Zugriffe untereinander regelt.

Also nicht in der Tiefe, sondern es ist so eine Art Manifest und beschreibt so eine Art Birth, wie diese Dinge sein müssen, damit das funktionieren kann. Da geht es um das Thema Abhängigkeiten, Konfiguration, Prozesse und so weiter. Das muss man sich einfach mal durchlesen. Das ist wirklich extrem nützlich.

Das heißt? Bölts Salvo ist ein schönes Stichwort Cloud Native Anwendungen. Das kann man, glaube ich, generell sagen. Besitzende hohe Testmarkt, weil sie ja tendenziell aus sehr kleinen Komponenten bestehen. Und das eignet sich natürlich auch, um so kleine inkrementelle zu bauen für Bowling Releases. Um die Anwendung, kleinstädtische weiterzuentwickeln, dann eben auch zielgenau zu skalieren. Man muss ja vorstellen, wenn man den Staat jetzt nicht mehr in der Anwendung hält, sondern in einem Memory Story radix oder in einer Datenbank.

Dann ist es ja auch möglich, mit parallelen Prozessen und parallelen Zugriffen darauf zu schreiben und zu lesen. Man muss ein bisschen synchronisieren, dass nicht zwei Services gleichzeitig beispielsweise einen Warenkorb schreiben. Aber das ist ja schon ein Paradigmenwechsel. Wenn man denen dann vollzogen hat, bekommt man eben die ganze, die ganzen Benefiz von Cohn-Bendits ganz genau, und man kann eine Anwendung sehr, sehr flexibel einsetzen. Also wenn man mal an eine Webanwendung denkt, wo die Webserver vielleicht in Deutschland erst einmal gehostet werden, und man expandiert jetzt auf den nordamerikanischen Markt, dann könnte man ja einfach in Nordamerika in der Zone weitere Webserver hinzunehmen, müsste nichts anderes machen.

Und die Leute in Nordamerika haben direkt eine bessere Erfahrung, weil die Zugriffe einfach schneller erfolgen. Und funktioniert natürlich nicht nur mit Nordamerika, sondern weltweit und kann so nach und nach einzelne Gebiete hinzunehmen. Gibt es da noch Werkzeuge für die Entwicklung, oder? Planung, die du auf jeden Fall empfehlen würdest. Also Docker und geht nehme ich jetzt mal als gesetzt. an, aber so Spezialwerkzeug, die dir in der Vergangenheit gute Dienste geleistet haben.

Alles, was das ökosystem Kobanê angeht, da könntest du Tage und Wochen erzählen, weil da kommst du gar nicht zum Ende. Weil wir nur am Ende bist, gibt’s ein paar neue zugelangt.

Die Entwicklung ist sehr schnell. Es ist abartig. Ich hatte das Thema der Check ups erwähnt. Ja, das ist auch relativ neu. Dann gibt es schon das Thema gibt Tipps, wo du die komplette Laichzeit einer Software von Entwicklung bis hin zum Deployment komplett übergibt. Das heißt, selbst in die Kobanê setz gar keine Befehle mehr selber ab, oder? Sondern einfach mit Quests reichen, um diese Kette abzubilden. Der Vorteil ist, dass du alles dokumentiert hast. Das hast du siehst jederzeit.

Wann wurde die Leuth? Warum wurde die Leuth? Du kannst die Kommentarfunktion in Gips nutzen.

Plus die Geschwindigkeit plus die Geschwindigkeit. Also du hast das Feature entwickelt, gemurrt, getestet, und es ist sofort. Zehn Minuten später ist es in der Anwendung und kann verwendet werden.

Ja, auch die Kollaboration. Du kannst ja auch quasi Kommentare hinzufügen. Du kannst es ja mal Teams oder Slack einbinden, was wiederum das Wort Stops ins Spiel bringt, wo du quasi mit slack Befehlen diese Karte weiterspinnen kannst. Also Thema ist komplette Agilität. Nein, das sind die Werkzeuge, die du hast nutzt, um es Software abzubilden, ohne jetzt direkt konfrontiert zu sein mit Kobanê. In all diesen low level Komponenten haben, weil da halt ein paar andere Layer dazwischen sind, die irgendwas steuern.

Es geht total schnell. Du musst echt am Ball bleiben, damit du gucken kann. Was passt zu meinem Kunden am besten? Welches Setup hatte aktuell? Das ist mitunter sehr anstrengend, aber macht auch sehr viel Spaß, weil sehr viel Bewegung drin ist.

Das Deployment aus dem Chat heraus zu starten oder ob ich da jetzt noch mitmachen muss, das ist ja fast schon akademischer Natur. Aber ich glaube, das Wichtige ist einfach, dass die Zeit, die vergeht, von einer Feature Entwicklung, also feature to market, wenn man so möchte, dass die möglichst kurz ist, dass man auch dann wieder lernt. Man hat dieses Feature eben entwickelt. Die Kunden nutzen es, die Nutzer nutzen es, und man bekommt Feedback.

Ah, okay, das ist es gelungen. Das und das ist vielleicht noch nicht optimal, dass man die Entwicklung der Anwendung in die richtige Richtung sehr schnell vorantreiben kann und eben dieses Builds Development sag ich mal betreiben kann. Also genau an den Kundenbedürfnissen ausgerichtet.

Vielleicht müssen wir mal das Thema ökosystem von Kybernetische, also welche Tools und neueste Entwicklungen? Das kann man dann eine eigene Episode daraus machen.

Das können wir gerne planen. Vielen Dank für die Session. Gerne. Wenn unsere Zuhörer Fragen haben zu dem interessanten Thema, können Sie uns gerne eine E-Mail senden. An Podcast abonniert unseren Podcast und lassen uns gerne eine Bewertung da und schaut auch auf Skill slash Blog vorbei. Wenn Ihr weitere spannende Technologie Themen lesen möchtet. Masiar Ich bedanke mich ganz herzlich bei dir.

Maurice KnoppSkillbyte Podcast #25: Kubernetes: Flexibles und leistungsfähiges Rechenzentrum für Unternehmen
Mehr

Skillbyte Podcast #23: Individualsoftware zügig und kostengünstig entwickeln

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Individualsoftware zügig und kostengünstig entwickeln

// Inhalt //
00:36 – Intro Markus Roth von expeso.de
01:25 – Beispiele für die Digitalisierung von Unternehmen
03:50 – Strategische und technische Themen
06:15 – Das Dreieck des Projektmanagements – Zeit, Kosten, Funktionalität
08:36 – Wie funktioniert Agilität?
14:45 – Product Owner ist die zentrale Schnittstelle
18:04 – Wie sollte der Kunde ein neues Projekt mit Erfolgskurs aufsetzen?
22:27 – Zusammenfassung: Vorteile des Agilen Vorgehens
25:32 – Kurzfristige und regelmäßige Software-Lieferung steigert Nutzerakzeptanz
26:27 – CI/CD als Toolunterstützung für zügige Softwarelieferung
30:10 – Zusammenfassung: Agile Entwicklung für Individualsoftware
31:00 – AHA Effekte aus realen Projekten
35:54 – Kontakt zu expeso

Informationen zu expeso finden Sie unter https://www.expeso.de

Das Whitepaper „6 Schritte für Ihren Projekterfolg“ finden Sie hier https://www.expeso.de/service

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #23: Individualsoftware zügig und kostengünstig entwickeln
Mehr

Skillbyte Podcast #22: Digitale Transformation ist eins der Härtesten

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Digitale Transformation ist eins der Härtesten

// Inhalt //
01:00 – Definition von digitaler Transformation
02:46 – „Sofortness“
03:28 – Daten, Konnektivität, Rechenleistung
05:28 – Digitaler Reifegrad eines Unternehmens
08:11 – Verschiebung: Kunden wollen Nutzen statt Produkt
09:55 – Vorhandene Prozesse digitalisieren und neue Digitalprozesse anbieten
14:20 – Digitale Transformation für den Mittelstand
16:43 – Digitale Chance: Konzentration auf Kundennutzen
17:13 – Herausforderungen der digitalen Transformation sind Chefsache
21:14 – Keine Angst vor neuer Technologie
25:27 – Wie kann Skillbyte bei den Herausforderungen unterstützen?
27:23 – Skillbyte hilft bei agiler Softwareentwicklung, CI/CD
29:30 – Skillbyte hilft bei DevOps, DevSecOps, Skalierung
35:04 – Skillbyte hilft bei Big Data, ETL, Dashboards, Reporting, Prediction
37:39 – Digitalisierung als Chance begreifen!

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Herzlich willkommen zur aktuellen Podcast Episode Nr. 22 Digitale Transformation ist eines der härtesten. Ich bin heute hier wieder mit unserem Stammgast. Masa Hallo Maria! Hi, wenn unsere Zuhörer Fragen haben, können Sie gerne eine E-Mail schicken. Podcast. Wenn euch unser Podcast gefällt, freuen wir uns über ein Abo oder über eine Bewertung. Vielen vielen Dank im Voraus. Heute wird es sehr, sehr spannend. Denn digitale Transformation ist natürlich ein Thema, was derzeit in aller Munde ist, also schon länger digitale Transformation.

Das ist der Oberbegriff, was in der deutschen Wirtschaft herumgeistert.

Genau. Und heute wollen wir darüber sprechen. Also wollen wir dieses buzzword ein bisschen herunterbrechen und auseinander nehmen und schauen. Warum ist das so ein großes Problem? Warum tun sich Unternehmen schwer damit? Was sind die Herausforderungen? Warum ist es überhaupt wichtig, dass sich Unternehmen damit beschäftigen? Ich glaube, es ist ganz, ganz wichtig. Ich denke, das können wir ganz gut herausstellen. Ich würde gerne beginnen mit einer Definition, die ich von der Wikipedia ausgeliehen haben und natürlich immer eine neutrale Quelle, einfach um nochmal das Framework einzuführen.

Worüber sprechen wir, wenn wir über digitale Transformation sprechen? Als die digitale Transformation wird auch als digitaler Wandel bezeichnet, bezeichnet einen fortlaufenden, in digitalen Technologien begründeten Veränderungsprozessen, der in wirtschaftlicher Hinsicht speziell Unternehmen betrifft. Im engeren Sinne wird als digitale Transformation häufig durch die digitalen Technologien oder darauf beruhenden Kunden Erwartungen ausgelöste Veränderungsprozess innerhalb eines Unternehmens bezeichnet. Also auch hier ganz zentral Die Unternehmen verändern sich, aber auch die Kunden. Erwartungen desto jünger, desto mehr, würde ich sagen, desto jünger die Kunden, desto stärker treiben die Kunden Erwartungen.

Die digitale Transformation voran.

Was mir an der Definition nicht gefällt, ist, dass von digitalen Technologien die Rede ist. Ja, natürlich. Digitale Transformation betrifft natürlich digitale Technologien. Aber meines Erachtens ist das viel mehr als das. In so einem Unternehmen gibt es Personen, wirkende Menschen, wirkende Personen. Es gibt Prozesse, und es gibt die Technologie und natürlich den Kunden. Das heißt, im Unternehmen müssen all diese drei Entitäten miteinander entsprechend harmonieren und interagieren, damit so eine Transformation überhaupt stattfinden kann.

Es ist nicht nur die reine Technologie, es ist nicht nur ein Tool, oder ich führe ein Technologie Prozess neu ein und schon bin ich dabei, sondern es betrifft viel, viel mehr.

Ich würde auch sagen, die digitale Transformation ist sehr, sehr stark, auch eine Meinzer Sache. Ein Freund von mir hat das so schön formuliert.

Er sagte Für mich ist die digitale Transformation, ganz vereinfacht ausgedrückt, die sofort eines die sofortige Verfügbarkeit von Informationen, sei es jetzt Entertainment oder Information.

Oder ich möchte einen Prozess anstoßen. Ich möchte meiner Versicherung ein Dokument hochladen. Ich möchte jetzt eine Antwort auf meine Frage. Ich möchte in meiner Reise buchen. Ich möchte jetzt dieses Lied hören. Ich möchte jetzt genau diesen Film schauen. Das Bedürfnis entsteht und kann sofort befriedigt werden. Das ist einer der Haupttreiber der digitalen Transformation.

Sehr, sehr Kulturbegriff. Sofort, wenn man vielleicht irgendwie so ein bisschen abstrakter, eine Ebene drüber zieht. Warum findet überhaupt eine digitale Transformation statt oder sollte oder was hat das in Gang gesetzt? Es ist in meinen Augen einmal die Menge der Daten, die zur Verfügung steht, über viele, viele verschiedene Channels hinweg, sei es jetzt Web, sei es mobil, sei es Booty, sei es über Kunden. Telefone im Call-Center da entstehen überall Daten. In einer sehr hohen Geschwindigkeit ist das eine, das andere ist die Konnektivität all dieser Komponenten und die massive.

Die dritte Komponente ist für mich die Massive Processing Power, die zur Verfügung steht, um all das auszuwerten, auszuwerten, um auf gewisse Dinge oder Marktgeschehen zu reagieren. Das heißt, diese Datensammelei stu, um abzuschalten. Was will der Markt? Wie hat der Markt auf diesem jedes reagiert? Bei mir, beim Konkurrenten darauf, schnell reagieren zu können, sei es von den Entscheidungsprozessen her, sei es von der Technologie, eher sei es von allgemeinen Prozessen, die in so einem Unternehmen laufen.

Diese drei so auszulegen, dass sie schnell reagieren kann. Das macht es für mich insgesamt aus. Was sind die drei Komponenten?

Nochmal sagen Sie nochmal nacheinander? Ja, die eine Komponente ist, dass Daten global zur Verfügung stehen über verschiedene Channels. Es werden sehr an sehr vielen Kontaktpunkte Daten generiert. Das zweite ist die Konnektivität, dass man viele dieser Channels miteinander verbinden kann, um so Korrelationen herzustellen. Die massive Rechenpower quasi auf haben wir zur Verfügung stehen. Damit erreiche ich im Saids mit diesen drei Komponenten oder generieren um mag es schnell mitzubekommen und darauf reagieren zu können. Um darauf reagieren zu können, muss ich natürlich den digitalen Wandel in meinem Unternehmen vollzogen haben.

Einmal nämlich meine Leute abgeholt haben. Geändert haben, die Prozesse umgestellt haben und natürlich die Technologie am Start haben.

Die drei Komponenten, die du benanntes, führen ja schon dazu zur Entwicklung gegebenenfalls neuer Geschäftsmodelle. Ich finde, es gibt es einen unterschiedlichen Reifegrad von digitalen Unternehmen, digital transformierten Unternehmen. Das kann man ganz gut erklären. Zum Beispiel? Nehmen wir mal ein Unternehmen wie die Bahn oder auch eine Airline. Und da sieht man okey, die gibt es seit vielen, vielen Jahren, und die digitalisieren sich. Angefangen, sich zu digitalisieren. OK. Man kann jetzt Tickets online kaufen.

Also früher bist du in den Shop gegangen, hast ein Ticket gekauft, heute kannst du die Tickets online kaufen. Das ist für mich der erste Schritt zur digitalen Transformation. Dass man einfach sagt, ein Prozess, den es bisher gibt, den verlagere ich ins Digitale, weil dann ist mein Ticketschalter 24 Stunden auf. Die Leute können das von jedem Fleck der Erde zu einem Ticketschalter kommen, müssen nicht anstehen und klicken sich quasi selber durch die Masken und bestellen ihr Ticket selber.

Das ist der erste Schritt, den ich sehe. Ein weiterer Schritt ist Wenn du wirklich aus diesen Daten, die ansprichst, selber wieder neue Geschäftsmodelle baust. Also wenn die Bahn zum Beispiel sagen würde Dein Zug fährt um viertel nach. Aber wir wissen, dass es um die Zeit immer so voll ist, immer fünf Minuten verspätet oder so was, dass Sie das quasi mit berücksichtigen würden. Das wäre so der nächste Schritt. Und der dritte Schritt oder die voll digitalen Unternehmen, das sind wirklich die Champions heute.

Das ist eigentlich total verrückt. Das vermitteln eigentlich nur noch z.B. Booking.com besitzt kein einziges Hotel, und die bringen einfach nur diese Nachfrage von Kunden und Hotels, bringen sie zusammen und stehen in der Mitte. Uber besitzt vermutlich besitzen ein paar Autos, aber wenige keine Taxis. Aber sie sind der größte Taxi Dienstleister. Airbnb besitzt keine Wohnungen, aber auch eine gewagte These vermieten wahrscheinlich mehr Wohnungen, wenn darüber abgewickelt als eine kleinere Stadt oder Ferrando nimmt. Die z.B. haben kein Restaurant und beschäftigen keinen Fahrer fest.

Aber die bringen halt Restaurants und die Leute, die gerne essen wollen, aber sich nicht aus dem Haus bewegen möchten, zusammen. Das ist für mich ein weiteres. Es ist so krass. Ich habe heute einen Unterbreche, habe heute erfahren, dass, liebe Ferrando, 30 Prozent von dem Umsatz kriegt, eine Pizza für sieben Euro bestellt kriegt, die zwei Euro zehn. Das finde ich unfassbar.

Ich dachte, dass es pro Bestellung gibts. So eine Fixkosten drauf kommen 30 Prozent.

Ich habe mich heute mit dem Restaurant unterhalten. Der Restaurantbesitzer bezahlt.

Ich dachte, der Endkunde bezahlt die Lieferung gewissermaßen.

Nein, bezahlte er, bezahlt der Restaurantbesitzer 30 Prozent. Aber das Verrückte ist Diese digitale Transformation führt auch dazu. Du siehst es schon. Die Wertschöpfung wird quasi an anderer Stelle abgegriffen. Das Essen muss irgendwie zum Mund, und je nach Themen, wo der Mund ist, muss es da hinkommen. Und das Essen zuzubereiten ist nur noch zwei Drittel, und das Essen auszuliefern ist dann schon ein Drittel der Wertschöpfung. Wenn man so möchte, ja, auch diese Abo-Modell, die heute, die es heute überall gibt, die würden ja gar nicht funktionieren.

Die mobile Apps für die e-roller, die hier rumstehen oder es gibt es, heißt das da für 20 Euro im Monat. Wenn du die App stellst, stellen sie dir ein Fahrrad hin. Wenn was kaputt ist, reparieren die das Fahrrad, und du hast quasi ein funktionsfähiges Fahrrad im Abo. Wenn du so möchtest. Ich merke das, wenn ich mit älteren Semestern spreche, die sagen Hey, ich will das Fahrrad besitzen. Und warum sollte ich ein Fahrrad mieten und Salzkonsum jetzt einen Monat irgendwo sind in einer anderen großen Stadt.

Und wo das angeboten wird, wäre das ja ein super System. Oder auch für Leute, die ihr Fahrrad sehr viel nutzen und sehr viel für die Reparatur kaufen. Klar ist das auch im System, was lobenswert ist, dass man quasi sagt Eigentlich das Fahrrad ist. Ich zahle für den Service, ein Fahrrad zu haben und nicht mehr für das physikalische Ding. Man zahlt für das Erlebnis oder für den Nutzen beim Streaming. Du kriegst keine CD mehr oder keine DVD mehr.

Aber du siehst in Filmen oder beim Carsharing Du bezahlst für den Nutzen, von A nach B zu kommen mit dem Auto und nicht für das Auto. Ja, ja, die Anforderungen der Kunden, seien es jetzt Endkunden und natürlich auch Businesskunden. Das verschiebt sich schon ganz erheblich. Und jetzt kommen wir zu dem Punkt Warum ist das für Unternehmen ein großes Problem? Die digitale Transformation dazu gesagt?

Das fand ich sehr wichtig. Deswegen will ich nun mal gern herausstellen, dass. Was du gesagt hast, ist, dass ich bestehende Prozesse in meinem Unternehmen digitalisieren. Das heißt, ich gucke mir an definieren oder oder identifiziere Prozesse, die von A nach B nach C D laufen und gucke. Was kann ich davon automatisieren? Digitalisieren, um es schneller zu machen und effektiver zu machen? Ein ganz einfaches Beispiel Ich muss Daten, die ich von einem Lieferanten bekomme, in mein System reingehen.

Kein Witz, ganz oft gesehen. Da steht ein Faxgerät, da kommt ein Fax rein. Dann nimmt sich irgendeiner das Fax, setzt sich einen Rechner und gibt die Daten in SAP ein. Gibt’s. Ganz aktuell habe ich sogar den Fall. Mein Vater ist jetzt in Pflege, und ich musste diese Pflege beantragen. Das sind fünf Parteien involviert. Das ist einmal die Krankenkasse, die Rehaklinik, der Hausarzt, der Pflegedienst. Und die müssen sich alle miteinander irgendwie austauschen.

Und alles offline, alles mehr oder weniger offline. Eine muss oder will oder kann nur das Ding per Post verschicken, der andere kann nur Fax, der andere kann das per E-Mail machen. Das ist furchtbar. Da gibt es so viele Reibungsverluste innerhalb dieses Prozesses. Du kriegst das terminlich nie hin, weil der eine muss das dem anderen kommunizieren. Dann ist mein Vater zu Hause. Da gibt’s die Geräte noch nicht, weil der andere das nur per Post verschicken muss.

Und, und, und. Man sieht da dran, wie ich sage, mal ganz, ganz, ganz einfache Mittel schon solche Abläufe voll digitalisiert und automatisiert werden können, um einfach effektiver und effizienter zu werden. Das ist das einender, das ich in meinem Unternehmen oder in so einem gesamtprozess mit Lieferanten und Kunden und so weiter Wege digitalisieren, automatisieren. Das andere ist ein Begriff. Muss ich dazu noch einführen, nämlich die Value Proposition, das heißt, das Werte versprechen?

Was du als Unternehmen dem Kunden gegenüber gibst, sei es jetzt zum Beispiel das Produkt oder eine Dienstleistung. Eine gewisse Eigenschaft hat eine gewisse Haltbarkeit. Wenn man grundsätzlich diese value proposition zu verbessern. Das ist erst einmal der erste Ansatz der digitalen Transformation. Indem ich, wenn ich zum Beispiel als Kunde Ja sage, mal so ein Pflegefall habt, dann kann ich das Werbeversprechen als Krankenversicherung erhöhen, indem ich solche Prozesse automatisieren.

Das heißt, es ist so witzig, ist doch günstiger für alle Seiten besser?

Ich habe fünf Mal von der Krankenversicherung den selben Antrag bekommen. Ich weiß nicht, wie der Prozess gelaufen ist. Wahrscheinlich tatsächlich einmal per E-Mail, einmal per Post und fünfmal. Ich habe eine Stunde gebraucht, um allein herauszufinden, dass diese fünf Anträge eigentlich alle die gleichen sind. Damit kannst du schon mal gegenüber dem Kunden. Das ist nur ein Beispiel, wenn du effizienter bist und schneller bist. Bei der eigenen Kosten senken und das Kunden Erlebnis verbessern?

Absolut. Das andere ist, wie du dein Werbeversprechen noch verbessern kannst, du neue Angebote schaffst, wie digital unterstützte. Nehmen wir als Beispiel Amazon. Wir haben am Anfang 94 angefangen mit dem Buchhandel, und zwar per Mail. Das heißt, du hast eine Mail geschrieben und hast gesagt Ich will das und das Buch. Und dann ging das ein paarmal hin und her per Mail. Und dann hast du ein Buch bekommen, als es losging, das mehr und mehr Menschen Browser adaptiert haben, benutzt haben.

Hat Amazon sich gedacht, das wäre doch cool, wenn wir diese Kette irgendwie verkürzen würden und nutzen jetzt den Browser damit für die Bestellungen online abgeben können und noch halten können. Und so eine Kommunikation über die Weboberfläche. Was im Prozess mega beschleunigt hat, mederer vereinfacht für beide Seiten. Als die Robotik stärker wurde und die Technologie besser wurde, hat Amazon einer der ersten, der seine Lager effizienter gestaltet hat, mit Robotern. Was Roboter liefern jetzt diese Ware zu dem Menschen, der da vorne steht und das verpackt.

Das ist durch und durch ein digitales Unternehmen. Der guckt sich an Welche Technologien sind Murchison und nutzt das, um einfach das kum Erlebnis dieses Superposition einfach zu ölen, zu verbessern für den Kunden.

Es geht ja noch weiter. Dann hat er gesagt Für das Weihnachtsgeschäft oder für Peace-Zeichen haben wir so viel Rechenkapazität übrig. Können wir wiederum anderen anbieten, eine einheitliche Schnittstelle darüber ziehen und daraus das A-WM?

Exakt genau so funktioniert das also für mich ein Musterbeispiel einer durch und durch digital nativen Firma?

Absolut. Aber hier geht es natürlich auch darum, dass wir Unternehmen in Deutschland vielleicht doch nicht so Großunternehmen zeigen wollen, wie sie auch selber die digitale Transformation gestalten können. Oftmals stehen ja auch gerade kleinere Unternehmen vor der Herausforderung. Die digitale Transformation erhöht ja erst einmal den Grad an Komplexität im Unternehmen, weil ich mit dieser Technik Sicht durchgehen muss, alle Prozesse beleuchten muss. In vielen Unternehmen sind Prozesse gar nicht dokumentiert, sondern die haben sich so eingebürgert. Ich brauche neue tech Experten.

Ich kann vielleicht nicht einschätzen. Sind Sie wirklich gut oder sind die nicht gut? Damit geht natürlich auch Kontrollverlust einher. Digitale Prozesse sind. Nicht mehr Wenn du kein Techniker bist, verstehen sie nicht mehr analoge Prozesse. Hast du halt in der Hand oder haben die Leute in der Hand und die sind einfach leichter verständlich. Dennoch, da bin ich ganz bei dir, gehe ich davon aus, dass es diese ganzen STANDARD Prozesse der Unternehmen, die nur Geld kosten.

Ich weiß nicht, wieviel Versicherungen generell billiger werden könnten, wenn man diese ganze Verwaltung runter dampft, auf die wirklich schwierigen Fälle und die ganzen Standart Fälle einfach mit Software abwickeln kann. Das ist ja heute auch schon. Es gibt Versicherungen, die Kasse monatlich ein und ausschalten zum so eine Reiseversicherung. Die buche ich nur, wenn ich eine Reise mache und schaltet einen Monat danach wieder aus.

Und das sind so einfach cool, dass man das machen kann.

Warum das so schwierig ist? In deutschen Unternehmen ist meines Erachtens, weil man noch sehr in Strukturen denken. Das heißt, du ziehst Strukturen in deinen Unternehmen ein mit Abteilungsleitern und Bereichsleiter, mit einer eigenen Profit, Lein, eigenen Reporting und so weiter und so fort. Das führt dazu, dass Silos entstehen und die vielleicht vielleicht ein Anführungsstrichen für sich effizient und effektiv arbeiten. Aber wir wissen nun alle, dass im Prinzip so ein Unternehmen nicht nur in Silos funktioniert, sondern kurz funktional sein muss, wo viele Menschen miteinander Abteilungs, Grenzen, arbeiten müssen, kommunizieren müssen.

Und da vergeht halt extrem viel Energie darauf, allein schon Entscheidungsprozesse. Wenn du im Entwickler-Team bist und irgendwas machen willst oder brauchen willst, dann musst du das nach oben kommunizieren. Dann von einem Teamleiter, dann geht so ein Abteilungsleiter vielleicht sogar irgendwo in den Vorstand, bis es wieder zurück kommuniziert ist all diese Wege, diese Entscheidungsfindungen, die funktionieren in einem digitalen Unternehmen nicht. Das heißt, du musst schnell Entscheidungen treffen.

Das zum einen und zum anderen glaube ich auch die Unternehmen. Das hängt mit der digitalen Transformation zusammen, ist aber nicht eine ausschließliche Folge. Davon müssen sich wieder mehr auf den Kundennutzen konzentrieren, weil dem Kunden nutzt das überhaupt nichts. Ob da fünf Abteilungen miteinander sprechen oder eine, das ist dem Kunden auch vollkommen egal. Er möchte seine Leistungen haben, das Herz der Geschäftskunden oder der Privatkunde. Er möchte einfach sein, seinen Job erledigt haben, und ich glaube, es ist Aufgabe der Unternehmensführung, eine große Herausforderung.

Jetzt haben mehr über die Probleme der digitalen Transformation gesprochen. Jetzt kommen wir mal zu den Herausforderungen für die Unternehmen. Ich glaube, die Aufgabe, die digitale Transformation voranzutreiben, ist ganz klar eine Aufgabe der Unternehmensführung. Schafft ein Unternehmen die digitale Transformation nicht, liegt das in der Verantwortung der Führung. Ganz klar für mich. Weil die Führung muss verstehen Okay, wir müssen uns wandeln. Sie müssen das tragen müssen. Meiner Ansicht nach funktionieren auch diese klassischen Hierarchiestufen nur noch bedingt, sondern sie müssen quasi lernen, Verantwortung abzugeben in einzelne Fachbereiche, die dann autark Entscheidungen treffen können, um eben schnell reagieren zu können.

Das haben mir auch manche mitbekommen, dass sie quasi Verantwortung für ein Projekt, für ein Produkt komplett abgeben. In Anführungsstrichen Startup Team Cross funktional besetzt ist und selber entscheiden kann, also schnell mit einem gewissen Budget ausgestattet ist. Und man sieht das schon mal hier und da, aber leider viel zu selten.

Dieses Abgeben von Verantwortung bedingt natürlich auch eine offene Fehlerkultur. Natürlich werden Fehler passieren, und natürlich ärgert sich der Vorstand darüber. Aber in der digitalen Welt ist es oftmals wichtiger, schnell zu sein, an Stelle fehlerfrei zu sein. Mir fällt jetzt ein großer amerikanischer Zahlungsdienstleister ein. Wenn er schon Jahre am Markt ist, dann überlegen sich die europäischen Banken Mensch, so was machen wir auch. Und wir haben auch schon drei Banken, die mitmachen. Also für mich als Digital Native ist völlig klar Das kann so nicht funktionieren.

Entweder müssen alle mitmachen, und das am besten auch schon schnell. Wenn der amerikanische Dienstleister sozusagen gerade auf ploppt oder du kannst es gleich sein lassen, dann hast du diesen Markt einfach verloren. Und dann Post oder gar nicht mehr anfangen. Wenn ein digitaler Player laufen ist und Erfolg hat. Und jetzt kommen die anderen auf die Idee Mensch, das mache ich auch. Dann ist der Drops gelutscht, weil durch diese Netzwerke Effekte in der digitalen Welt ist es unmöglich oder nur mit extremen Ressourceneinsatz möglich, diesen Weg gelaufenen schon einzuholen?

Das beste Beispiel ist WhatsApp auf dem Handy. Du könntest jetzt einen Messenger rausbringen, der doppelt so gut ist, schöner, schneller, bunter auf mehr Handys läuft. Den würde keiner mehr laden, weil das einfach verloren ist, weil es keinen Bedarf mehr gibt. Und der Bedarf wird von einer vorhandenen Lösung zu hundert Prozent erfüllt. Und damit bist du da raus. Also offenes Mainstadt? Offene Fehlerkultur ist ganz, ganz wichtig und meiner Ansicht nach die größte Herausforderung auch für den Vorstand oder für die Leitung eines Unternehmens.

Und es reicht nicht, einfach nur Coaches zu beauftragen.

Da spricht ja ich weiß frei. Die sagen Okay, wir machen alles agil, und damit wird das schon. Man muss sich wirklich als. Die harten, ehrlichen Unternehmer fragen stellen Können wir unsere Mitarbeiter schulen? Auf diese neue Denke können und wollen diese Menschen diesen Transformationsprozess gestalten. Es gibt, wenn man sich ehrlich fragt, auch Branchen. Da muss man mit Nein antworten. Da ist die Frage Was machen wir hier? Weil die digitale Transformation wird jedes Unternehmen betreffen, unabhängig davon, auch wenn man in der Industrie tätig ist und Werk Teile herstellt.

Das ist ganz klar, dass man davon betroffen sein wird. Und die Antwort ist Nein, wir schaffen das nicht mit diesen Menschen. Dann muss man auch daraus Konsequenzen ziehen. Auch das haben Unternehmen gemacht, dass sie sagen Okay, die Firmen Bereiche, die noch laufen, die verkaufen. Wir nehmen dieses Geld und investieren in digitale Unternehmen, um sozusagen über die, wenn man so will, über die Kreditkarte oder übers Bankkonto die digitale Transformation zu gestalten. Man verkauft die Unternehmensteile, die eben nicht sich nicht digitalisieren wollen oder wo man den Aufwand als zu groß vermutet, und beteiligt sich dann an Digital Unternehmen, also auch die Mitarbeiter mitnehmen.

Welche ängste haben die Mitarbeiter? Wie können wir diese abbauen und sich wirklich hart fragen Kriegt man das mit der Mannschaft hin? Ich glaube, das muss man, muss man sich eingestehen, wenn es so ist. Und wenn auch nicht so ist.

Dazu muss man sagen Was mich auch nur ein bisschen irritiert, ist grundsätzlich die Angst Schüren der Medien. Datenschützer Katastrophen heraufbeschwören, jede aufkommende Technologie erst einmal hinterfragen und schlecht reden und immer nur die Seite herausstellen. Was als Gefahr gesehen? Bestes Beispiel künstliche Intelligenz. Wir haben für die meisten Deutschen Dawid nicht den Vorteil, dass diese Technologie alles bewirken kann, egal, ob es mein Leben physikalisch, finanziell oder so verbessern kann. Was für ein Potenzial dahinter steckt? Darüber reden wir nicht.

Wir fangen sofort an mit den Bedenken und was das alles kaputt machen könnte. Oh Gott, ich habe mir einen normalen Deutschen. Künstliche Intelligenz würde sagen, ich habe Angst um meinen Job. Aber das Einzige, was hauptsächlich hörst, dass dein Job zerstört. Ja, das ist ein Aspekt. Aber könnte ich zehn andere Aspekte aufzeigen, wie es wieder neue Jobs schaffen, wie es dein Leben vereinfacht? So, und das ist jetzt ein Bumerang. Genauso wie mit dem Internet.

Das böse Internet. Und jeder ist eine böse Datenkrake. Wir müssen jetzt wie auf den Straßen überall Schilder hochhalten Achtung, Achtung, JavaScript! Achtung! Das ist schon fast absurd. Aber was das bewirkt, ist, dass es bei den Menschen subtil Angst heraufbeschwört vor diesen Technologien. Und wenn du all das, ohne zu hinterfragen, jahrelang praktiziert, dann darfst du dich nicht wundern. Wenn die Menschen Angst vor der Technologie haben, dann ist es schwierig, Menschen abzuholen, Mitarbeiter abzuholen, weil sie schon eine subjektive Meinung gebildet haben über die Zeit.

Genau das meinte ich mit Mitarbeiter mitnehmen. Es ist natürlich die Berichterstattung, und die Medienberichterstattung ist so, wie du sagst, dass man da sehr ängstlich, aber auch Politik Cumbia das Einzige.

Das Einzige, was uns zum Thema einfällt. Alle sind sich bewusst künstliche Intelligenz. Wir müssen da mehr tun. Wir müssen fördern bla, bla, bla, bla, bla. Die erste Amtshandlung ist doch tatsächlich ein Vorschlag. Wir müssen in alle Unternehmen einen Algorithmus Beauftragten installieren, so ähnlich wie der Datenschutzbeauftragte. Das ist in Absurdität gar nicht mehr zu überbieten.

Die deutsche Angst German Angst ist natürlich auch legendär. Ich glaube, das einzige, wo digitale Transformation wirklich ein Dämon ist, ist, wenn du Angst vor Veränderung hast. Es wird sich was verändern. Das ist jedem klar. Aber Veränderung Nummer ist das kann man gestalten, und das kann man zum Positiven und zum Negativen gestalten. Die KI ist ja nur ein Vehikel, wie ein Flugzeug ein Vehikel ist oder ein Auto ein Vehikel. Und viele Menschen fahren mit dem Auto zur Arbeit, und ein paar Verrückte fahren mit dem Auto, verletzten andere Menschen.

So und genau so ist das auch mit neuen Technologien. Die sind nicht per se gut oder per se schlecht, sondern es kommt darauf an, was man daraus macht. Ich meine jetzt, wir sitzen hier in der Mitte der Coruna, Pandemie, viele Leute, die überwiegend am Bildschirm arbeiten oder digitale Arbeitsplätze haben, die konnten normal weiterarbeiten. Man stelle sich nur mal vor, diese Pandemie hätte uns Mitte der 80er erreicht, wo das Internet noch überhaupt nicht ausgebaut war.

Das wäre einfach Hetze, die Volkswirtschaft komplett gestoppt.

Da wäre keiner zur Arbeit gegangen oder hätte keiner seine Arbeit erledigen können von zuhause, außer vielleicht mit dem Telefon. Aber das ist schon ein riesengroßes Glück, dass das Internet so gut ausgebaut ist. Zu der Zeit, wo das passiert war, definitiv. Und ich glaube, auch das ist ein absoluter Beschleuniger. Jetzt auch. Covert 19 hat so viel zur digitalen Transformation beigetragen, mit zehn Regierungen das nicht leisten können. Für mich als Technologie begeisterten. Ich kann das nicht so ganz nachvollziehen, wie man immer vor allem Angst hat.

Ich versuche immer Okay, das hat Risiken. Wenn man den Führerschein macht ja, natürlich hat ein großes Auto, was man bewegt, irgendwie Risiken, aber man lernt, damit umzugehen. Dann kann man eben auch damit sehr schöne Strecken fahren und Mobilität genießen. Aber man muss eben lernen, damit umzugehen. Und das ist auch ganz wichtig. Oder die Botschaft an die Menschen und draußen lernt und die Unternehmen lernt, damit umzugehen, und beschäftigt euch damit, weil die digitale Transformation wird euch früher oder später auf jeden Fall betreffen.

Egal, welches Geschäft ihr heute habt.

Vielleicht haben wir auch darauf ein, was die wirklich wichtigen Entscheidungen für Unternehmen sind, die von der digitalen Transformation stehen oder diese gerne aktiv gestalten wollen. Das ist ja ganz wichtig, um wie wir dabei helfen können. Wir haben ja schon mal so einen Prozess skizziert, wie wir Big Data Projekte durchführen. Um bei der digitalen Transformation ist es auch wichtig, dass man am Anfang erst einmal eine Bestandsaufnahme macht. Wo steht die Firma heute? Welche Prozesse sind überhaupt wertvoll und wer welche überhaupt nicht digitalisiert werden und schon rausfallen, weil man sie eigentlich nicht braucht?

Welche Prozesse sollen digitalisiert werden? Also hier. Die Strecke für zur Pflege wäre hier ein super Beispiel. Dafür Geld sparen können, wenn das einmal implementiert ist und der Service sogar noch besser würde für die Endkunden. Was wir als Gilbert machen ist, dass wir erst einmal eine Digitalisierung Landkarte erstellen und gucken. Wo sind denn deine Potenziale als Unternehmen und die mit den strategischen Zielen des Unternehmens? Im Prinzip übereinanderliegenden zu gucken. Was ist im ersten Schritt notwendig, um die digitale Transformation zu gestalten?

Und welche Technologien können wir verwenden, um dich dahin zu bringen? Das ist ganz wichtig. Digitale Transformation steht schon. Der Name sagt es schon, hat immer auch mit Technologien zu tun. Und wir konzentrieren uns am Anfang immer darauf, dass wir den Unternehmen erst einmal. Ich sage mal die einfachen Punkte zeigen, die schnell erreicht werden können. Auch dass man so ein Motivationsschub mitnehmen kann, um dann eben in weiteren Schritten dann die Ausbaustufe 2 und drei der Komponenten anzugehen.

Also wir gucken schon Welche digitalen Lösungen gibt es heute oder welche können wir entwickeln, um die aktuellen Unternehmensziele zu unterstützen? Und während dieser Brainstorming Session oder dieser Planung fallen oftmals auch Ideen für neue Geschäftsmodelle ab, die man dann erproben kann mit der WP Methode. Andreas von Valeo Salopp gesprochen Genau da geht es ja. Darum geht es ja darum zu prüfen. Hat das Perlet für die Kunden vielleicht, sagen wir, als Gilbert helfen können. Also einmal bei der Enterprise Softwareentwicklung.

Wir können gerne zeigen, wie man agile Lösungen entwickelt im eigenen Unternehmen also. Agil heißt für uns, dass man kurze Zyklus Zeiten hat und dabei das Unternehmen die volle Kostenkontrolle besitzt, quasi eine fortwährende Ost und Leistungskontrolle sehen kann, ob sich die digitalen Prozesse in die richtige Richtung entwickeln. Ein ganz zentraler Punkt ist das Aufsetzen von Pipelines, also Continuous Integration, Continuous Delivery. Da geht es darum, dass im Grunde die Artefakte oder die Software Komponenten, an denen die Entwickler bauen, dass sie jeden Tag ausgerollt werden können, an Borten Feature.

Man testet das Feature, und es kann. Die Zeit von Coding zu Produktions Release ist relativ gering. Was wir auch machen, ist Enterprise Softwareentwicklung, vorzugsweise mit Java und Micro Services, wo wir dann eben die in der Identifikationen Phase ausgeschriebenen Anforderungen umsetzen.

Genau. Wir konzentrieren uns auf den Technologiepark in der digitalen Transformation, können aber natürlich, weil wir das in mehreren Unternehmen schon gemacht und gesehen haben, sehr, sehr gut einschätzen, was die Schiedsstellen dazu sind, wie die Kommunikationsprozesse zu den Mitwirkenden sein müssen, wie die Entscheidungsprozesse sein müssen, also nicht nur die reine Technologie. Wir setzen sein Programmieren, sondern können dem Kunden gegenüber auch sehr gut kommunizieren, wie das bei einer digitalen Transformation auch die Technologie implementiert sein muss, kommuniziert werden muss, um zu den anderen Schnittstellen zu funktionieren.

Meistens ist es ja so, dass man es eingangs als ersten Grad bezeichnet, dass man im Prinzip vorhandene Prozesse digitalisiert, also eine Bestell schrecken. Dann zum Beispiel auf eine API Strecke, also eine Schnittstellen Strecke umbaut, das Thema automatisch Bestellungen auslösen können anhand gewisser Parameter, und dass man im Zuge dessen dann weitere Potenziale identifiziert. Dass man dann auch strategisch den Unternehmen unterstützt und sagt hier das und das und das sind Potenziale als Entscheidungs Vorschlag im Prinzip für den Vorstand, dass er schauen kann, ob das auch noch Projekte sind, die interessant sind und die strategisch zum Unternehmen passen.

Gerade im Bereich der Dobbs kann man Unternehmen ja sehr stark unterstützen, was die digitale Transformation angeht. Vielleicht möchtest du dazu etwas sagen.

Das Thema, was unten drunter schwingt, ist, wie du gesagt hast, sofort ein ganz einfaches Beispiel ein Konkurrent, ein Feature eingeführt, und das funktioniert super. Du brauchst das auch.

Wie lang will sie jetzt warten und diskutieren implementieren und die Pleuel bis zu dieses Feature am Start? Vielleicht bist du auch selber der Innovator und sagt Ich möchte verschiedene Interaktionsmöglichkeiten ausprobieren. Mit dem Kunden, um zu gucken und messen natürlich, was am besten funktioniert, um zu sagen Okay, wir schlagen jetzt diesen Weg weiter ein. Und das ist das, wobei es hilft. Das heißt, es nimmt hier in der gesamten Software-Entwicklung Sketche gefegt, dass die Entwickler Operations und die Infrastruktur schnell zu sein, wenn es sein muss, mehrmals am Tag in Produktion.

Eine änderung in der Webseite zu bringen, kennen die meisten, die diese digitale Transformation noch nicht haben, wenn sie Software bauen wollen oder lesen wollen. Selbst ins Web dauert das monatelang. Und wenn du etwas machst, dann machst du etwas anderes kaputt. Fürs neue Batz ein und, und, und, und. Das wollen wir mit der Woolfs Movement, mit den Tools und Prozesse auch. Da geht es nicht nur um Technologie, sondern auch um ein Meint.

Es geht auch um Daten getriebenes Handeln. Ich messe, wie oft ich am Tag die Pleuel vielleicht eingeführt habe, um mich dann verbessern zu können. Das heißt, dieser ganze Zyklus geschieht auch innerhalb des Webs für sich allein, um den Prozess kontinuierlich zu verbessern und Software immer schneller und Qualitätssicherung an Bord zu kriegen. Da gibt es neue Bewegungen wie Check ups. Oft ist es so, dass du, wenn du entwickelst, dann hast du noch die Security Abteilungen, die ein Strich durch die Rechnung macht.

Die verlangen dann Stadtmodell. Wie wollen, wie compliance-abteilung sagen Wir müssen aufpassen, dass da keine Third Party Lizenzen verletzt werden? Beispiel Lycée von Oracle oder bestimmte Compliance-Regeln Policies eingehalten werden. Das ist alles, was diesen Zyklus behindert. Und das führt Tools ein Voodoo. Stichwort Policy Code.

Dass du quasi diese Firmenpolitik genauso wie Infrastruktur Code als Code signiert hast und Tools automatisiert checken können, ob du Compliance bist. Das verhindert einmal Fehler, teure Fehler. Wenn du mal mit so einem Ding durchgeht, weil der Mensch vielleicht einen Fehler gemacht hat. Das macht ein Tool nicht, wenn es automatisiert ist und man dementsprechend gefüttert hat. Da wird jetzt immer mehr automatisiert, um so einfach Geschwindigkeit aufzunehmen. Und es ist ganz einfach der, der das macht, der ist schneller.

Werde es nicht mal langsamer und geht die Gefahr ein, irgendwann obsolet zu werden, weil die anderen an ihnen vorbeiziehen?

Das eine ist Geschwindigkeit beim Ausrollen neuer Funktionen, das andere ist natürlich auch Geschwindigkeit in der Skalierung selber. Also wenn eine Anwendung dann gefordert wird. Ich sehe das bei unseren Kunden. Die starten ein Service oder auf einer Webseite integriert. Dann funktioniert es ganz gut aus dem Datenblatt. Ich spreche jetzt mal und dann sag mal okay, wir möchten das in allen unseren Webseiten drin haben, haben aber dann pro Monat 4 Milliarden Requests. Von heute auf morgen explodieren die Zugriffszahlen, und das kriegt man natürlich auch hin mit dieser DVB-S Entwicklungsmodell, das man auch sagt.

Okay, die Infrastruktur beschreiben wir heute als Code und das läuft im eigenen Rechenzentrum oder in der Cloud. In der Cloud können wir dann raus skalieren. Heute machen wir es auf zwei Servern, übermorgen machen wir es dann auf 200, ohne was zu bestellen. Sehr schnell. Vielleicht funktioniert die Anwendung auch nicht. Dann melden wir die 200 Server wieder ab und können dann weitermachen. Mir kann dann aber sehr schnell verloben und sehr schnell neue, werthaltige Geschäftsführer des Unternehmens finden.

Das, was wir eingangs gesagt haben Geschwindigkeit, ist oftmals wichtiger als fehlerfreiheit, um eben natürlich auch in Grenzen. Wenn man eine Steuerung fürs Atomkraftwerks sollte man vielleicht dann doch anders priorisieren. Aber gerade im Bereich Web muss man einfach schauen, dass man schnell neue Dinge ausprobieren kann.

Ich will hier mal ein Beispiel nennen, was ich anfangs sagte dass dieses Silo, Denken und Kommunikation mit dazugehört. Ich habe mal einen Kunden gehabt im konsumgüterbereich, der mit vielen filial, da die Marketingabteilung eine Werbung geplant und geschaltet, wo plötzlich dann natürlich über Nacht die Zugriffszahlen, genau wie eben gesagt, in die Höhe geschnellt sind. Dementsprechend der Schopp nicht mehr funktioniert hat. Das heißt, man hat irgendwie künstlich Service selber eingeführt. In einem Unternehmen, das die digitale Transformation durchmacht, gilt es, diese Kommunikationswege so zu vereinfachen, so agil zu gestalten, dass man voneinander weiß und dann zum Beispiel für die Skalierung sorgen, für die automatische Skalierung mit Autos gelingt oder was auch immer.

Wozu das dann führt, wenn man das nicht macht, sieht man halt.

Das Unternehmen ist gewissermaßen Opfer seines eigenen Erfolgs geworden. Ich kann auch aus dem Nähkästchen erzählen. Das war nicht mein Projekt. Aber ein befreundeter Berater hat mir mal erzählt Eine Bank wollte ein Online-Konten beworben, zur Prime Time während eines Bocks Kampfes. Da sind auch die Call-Center, und die Webseite dieser Bank war überlastet, weil so viele Leute sich dann anmelden wollten. Und das war der beste Tag für die Konkurrenz, die dann alle verstehen. Oh ja, bei A kann ich das jetzt nicht abschließen.

Aber B hat doch auch ein Online-Konten. Und genau da ist der Schuss. Nach hinten losgegangen. Okay, das war jetzt Softwareentwicklung und warum ist das wichtig? Du hast ja schon die Datentypen angesprochen. Wir bei unserer Big Data Abteilung gehen so vor. Wir brauchen eine eigene podcaster Episode, wo wir genau zeigen, wie der Prozess ist. Aber ich fasse ihn hier noch mal kurz zusammen. Dass wir anfangs eine Daten Anamnese machen bei den Unternehmen, die Unterstützung im Bereich digitaler Transformation anfragen, dass wir sagen Welche Daten hat das Unternehmen, welche Möglichkeiten ergeben sich aus diesen Daten?

Dass wir neue Daten, Produkte, proben. Das haben wir ja auch letztes Jahr schon mal für den Kunden gemacht. Ich glaube, einen Monat oder zwei Monate haben wir ausprobiert, ob das so funktioniert, wie wir uns das vorstellen. Und dass man dann sehr schnell sagt Okay, die Daten sind hinreichend. Man kann das neue Produkt bauen, oder man muss noch hier und da mehr Daten einsammeln oder die vorhandenen Daten bereinigen, um dann die gewünschte Leistung herauszubekommen.

Das ist natürlich sehr charmant, dass man da sehr schnell einsteigen kann. Oftmals ist es auch so, dass unsere Kunden möchten, dass wir die Daten mittlerweile in Echtzeit bereitstellen oder in Echtzeit ein sammeln, damit die Software Komponenten in Echtzeit Entscheidungen treffen können und letztlich damit auch die Unternehmen in Echtzeit Entscheidungen treffen können. Und wir hatten jetzt eine Anfrage Anfang des Jahres, wo es darum ging, Daten Markt zu konzipieren. Also, wenn du dich daran erinnerst, aber ein großes Unternehmen, was von vielen, vielen Kunden Verbraucherinformation sammelt und eben diese Informationen in anonymisierter Form dann wiederum weiteren Geschäftskunden bereitstellen möchte und im Grunde mit diesen Daten handelt, zum datenblöcke wird.

Großes Potenzial liegt auch an der Vereinheitlichung von Daten Strecken innerhalb der Unternehmen, sodass man mal dokumentiert Welche Daten habt ihr eigentlich und was geht wohin und was kommt von b&o? dashboards und Reports stehen auch einmal ganz vorne, gerade damit die Unternehmensführung oder das Controlling weiß. Wo steht die Firma gerade? Es gibt oft regulatorische Anforderungen von Börsen gelisteten Unternehmen, die quasi zu jedem Zeitpunkt sagen müssen, wie viel, wie viel Geld es in der Kasse. Sag ich mal vereinfacht Um welche Verbindlichkeiten haben wir sie im Prime STANDARD richten können?

Immer mehr. In der jüngsten Vergangenheit werden Produktion Modelle angepackt. Wann fällt welche Maschine aus? Welche Kunden werden vermutlich kündigen? Welche Reichweiten haben wir mit diesen und jenen Kampagnen? Voraussichtlich nehmen wir die Kampagne so und so gestalten. Welche demografischen Daten füllen die Nutzer, die diese Kampagne vermutlich konsumieren werden, sodass man quasi im Vorfeld schon so eine Art Erfolgs Abschätzung macht? Bei all diesen Punkten unterstützen wir natürlich gerne, um den Unternehmen zu helfen und sie nach vorne zu bringen.

Also Angst haben muss niemand. Man muss sich nur vor der digitalen Transformation Angst haben, muss niemand zu dem Punkt stehen eine Chance? Auf jeden Fall. Man muss sich eben nur mit dieser Thematik beschäftigen und auch den Mut haben zu sagen Hey, wir gehen das an. Wir gestalten das aktiv. Lidl hat jetzt die Schwarz-Gruppe. Muss man sagen. Die Familie hinter Lidl hat jetzt vor einer Woche bekannt gegeben, dass Sie ein eigenes Klout Angebot aus dem Boden stampfen möchten.

Ich bin gespannt, wie sich das entwickelt. Meiner Ansicht nach 15 Jahre zu spät, aber beste. Die werden auch nicht dumm sein und werden sich genau überlegt haben, was sie tun. Sie haben eine Menge Innovationskraft und Finanzkraft, um da was auf die Beine zu stellen. Da bin ich ganz gespannt. Hast du noch einen Punkt? Eine wirklich wichtige Entscheidung, der sich ein Unternehmen stellen muss, welches über digitale Transformation nachdenkt.

Was wir machen können. Ich finde, das Thema lässt sich noch ein bisschen länger diskutieren. Und was hältst du davon, wenn wir so eine Serie mit vielleicht noch zwei oder drei weiteren Podcast machen, um dieses Thema dann die nächsten, vielleicht etwas praktischen Tipps, wie man, wenn man diese Dinge angehen kann, sehr gerne.

Wenn man mal cool, wenn unsere Zuhörer Fragen haben oder Feedback. Können Sie uns gerne eine E-Mail schreiben? An Podcast bei T. Wir freuen uns, wenn ihr den Podcast abonniert oder eine externe Bewertung da lasst und für weitere Technologien Themen. Schaut gerne auf www. Skill bei slash blog vorbei. Wunderbar.

Ich wünsche dir noch einen schönen Abend, dein gewöhnlich gut, du auch.

Maurice KnoppSkillbyte Podcast #22: Digitale Transformation ist eins der Härtesten
Mehr

Skillbyte Podcast #18: Warum sind IT Projekte so teuer?!

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Warum sind IT Projekte so teuer?!

// Inhalt //
00:36 – Was sind die Kostentreiber in IT Projekten?
01:07 – Problem: Wasserfall bei unklarer Route
04:54 – Problem: Kein klares Zielbild
07:47 – Verbesserungsvorschlag: Klares Zielbild – Was leistet die ideale Zielsoftware?
08:22 – Problem: Entwickler dürfen beliebige Technologien einsetzen
10:27 – Verbesserungsvorschlag: Systemarchitekt gibt Architektur vor, geringere Komplexität
12:21 – Verbesserungsvorschlag: strenge Sprint Zielkontrolle und offene Fehlerkultur
13:15 – Problem: Projekte werden mit Zieltermin statt Ziel-Funktionsumfang begonnen
14:07 – Verbesserungsvorschlag: nur wirklich wichtige Kernfunktionen festlegen
14:38 – Problem: Agile Movement
16:47 – Verbesserungsvorschlag: offene Sprint Reviews & Verantwortungsübernahme
17:25 – Verbesserungsvorschlag: Übertrage klare Verantwortungen!
18:54 – Problem: unklare Kommunikation
19:16 – Problem: Alle Konflikte im Team vermeiden wollen
20:40 – Problem u. Lösung: Die Fachseite muss ansprechbar sein
22:15 – Probleme im technischen Bereich
23:21 – Verbesserungsvorschlag: Neue Technologien und Projekte erst nach Rücksprache nutzen
24:26 – Problem: Integration von Altsystemen
26:24 – Unsere Faustregeln für erfolgreiche IT Projekte
31:14 – Faustregeln für Aufwandsschätzung

Wir empfehlen zu dem Thema auch die Podcast Episode #9: Bull’s Eye Software Development – Einfach und fokussiert auf Unternehmensziele
https://soundcloud.com/skillbyte/podcast-9-bulls-eye-software-development-einfach-und-fokussiert-auf-unternehmensziele

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Herzlich willkommen zum skillbyte Podcast Nummer 18. Warum sind IT-Projekte so teuer? Ich freue mich herzlich, die Zuhörer willkommen zu heißen. Vor der heutigen Ausgabe. Ich bin heute wieder mit Masala. Hallo Masa!

Hi, wenn euch der Podcast gefällt, abonniert ihn gerne oder lasst uns einen Daumen hoch oder ein leichter, wenn ihr Zuhörer Fragen habt, schreibt uns eine E-Mail an Podcast. Elbseite beginnen in der nächsten Episode darauf ein, und wir freuen uns immer über Bewertungen, positive Bewertungen und auch negative Bewertungen. Oder mit konstruktiver Kritik. Damit wir wissen, was wir besser machen können. Was sind die Kostentreiber in Projekten? Soll uns heute beschäftigen. Ich bin mir ganz sicher, dass wir beide dazu einiges zu sagen haben.

Oh ja, oh ja.

Ein leibliches Thema, das aber auch unsere Zielgruppe interessiert, um herauszufinden, wo das Geld hingeht oder warum IT-Projekte wir jetzt nicht sagen, wie Bauprojekte ja doch relativ oft das Budget überschreiten und deutlich überschreiten und auch den Zeitplan deutlich überschreiten. Wenn es um die Fertigstellung geht was glaubst du, ist denn Nr.1 Grund? Ich habe eine Theorie, aber ich würde sie gerne von dir zuerst hören.

Also Nr. 1 Grundwort Projekte, die teuer sind? Ja, genau. Klassischerweise wurden Projekte erstellt im Sinne eines Wasserfalls Modells.

Das heißt, man hat sehr lange bevor das Projekt überhaupt los war. Ich spreche von Projekten.

Genau um die geht es auch heute sehr lange, sich eingeschlossen. Ich sage mal Stellen, Fachabteilungen, Kämmerlein hat sehr viel die Prozesse durchgesprochen und was man genau will und wie das alles aussehen soll. Und dann ging es darum Okay, das muss das jemand erstellen. Und dafür braucht man Grays Wollen wissen, was uns das kostet. Damit ich ein paar kaufmännische Zahlen drüber legen kann. Was bringt uns das? Und so weiter und so fort. Und dieses Pflichtenheft hat aber sehr schwierig, diesen zu formulieren, weil man sehr genau eigentlich schon im Vorfeld wissen musste, was man genau braucht.

Also die Glaskugel. Man muss in die Zukunft schauen, in die Glaskugel schauen, genau, genau das.

Ich habe öfters ein solchen Pflichtenheft mitgewirkt, und das war immer ein riesen Akt, sehr schwierig zu erstellen, und am Ende hat es auch nichts gebracht. Dann hat eine Firma einen Preis abgegeben, die diese Ausschreibung bekommen hat. Natürlich haben Sie Ihrem entsprechend prozentualen Aufschlag drauf geschlagen. Sicherheit oder Risiko? Marge Und das Problem ist, dass, wenn es dann mit der Entwicklung losgeht und man irgendwann ein Ergebnis präsentiert bekommt oder vielleicht Meilensteine präsentiert bekommt, dann stellt man fest Welche Prozesse im Unternehmen sind wirklich sehr komplex?

Und man durchschaut nicht alles sofort oder kann alles manifestieren. Und man bekommt dann erst mit, wenn man diesen Aufschlag hat, damit interagiert, dass man das ein oder andere doch anders gerne gehabt hätte, oder? Es hat die Entwicklung so lange gedauert, dass der Prozess sich geändert hat. Aber die Firma hatte ja schon Preis dafür abgegeben. Man sagt, dass das diese Wasserfall Modelle immer zu 80 prozent Autoteilen und ordos Budget war. Mit gutem Grund.

Das heißt, erst bei der Umsetzung hat man dann Fragestellungen aufgeworfen, oder die sind dann entstanden, die man im Grunde nicht abgestellt hat, weil man dann erst festgestellt, dass es so und so und ganz, ganz genau gab.

Es ist auch immer ein Konfliktpunkt zwischen Dienstleister und dem Auftraggeber. Was ist jetzt eine änderung? Und können wir das noch rein nehmen? Und dann hat sich das wieder nach hinten verschoben. Von der Zeit wurde immer teurer, und deswegen sind oder waren IT-Projekte teuer und sind aus dem Ruder gelaufen.

Beide Seiten sind unglücklich. Der Anbieter versucht, dem Kunden alles auszureden, damit er ja keine Mehrarbeit leisten muss, nach dem originalen Vorkasse zu bleiben oder Budgets bleiben. Und der Kunde möchte natürlich so viel wie möglich an änderungen unterbringen, ohne das Budget zu erhöhen. Dann hat man diesen Konflikt ein bisschen länger ausgeruht.

Da sprechen wir ja jetzt in der nächsten Stunde ein bisschen drüber. Aber das hab ich jetzt gebraucht, um dir zu antworten und zu sagen, warum die Projekte teuer werden. Ich glaube, weil man im Vorfeld nicht weiß, was man will, und deswegen ändert sich das permanent. Dinge kommen dazu, Dinge fallen weg. Deswegen wird es teuer.

Du hast jetzt auch organisatorische Fallstricke angesprochen, weil häufig. Ich habe das ein bisschen für mich aufgeteilt. Meiner Ansicht nach gibt es organisatorische Gründe für Budget, überschreitungen und technische Gründe. Und ich glaube auch, dass die organisatorischen mit Abstand einen größeren Anteil am Budget überschreitung haben. Aus vielerlei Gründen. Jedes IT-Projekt ist ja ein Stück weit, oder was man dann umsetzt, ist ja ein Stück weit ein individual Projekt, weil sonst kaufe ich eine standardlösung installiert und bin fertig.

Und bei individual Lösungen, das ist wie das muss man sich vorstellen, wie wenn der Architekt ein Haus plant und. Das ist immer genau dann auf den USGS zugeschnitten und auch beim Hausbau. Jeder, der mal ein Haus gebaut hat, der weiß, dass da ganz schön viele Eventualitäten dazukommen können, und der Preis, der auf dem ersten Angebot steht, ganz, ganz selten der Preis ist, den man letztlich auch bezahlt. Ich bin immer verblüfft, weil bei der Architektur verstehen, dass die Leute sofort.

Aber bei der Software, weil das so etwas Abstraktes ist, kommen die Leute oft auf die Idee. Ich sage mal Kurz vor Fertigstellung wollen sie noch ein Stockwerk mehr und den Balkon auf die andere Seite versetzt haben.

Gute Metapher. Und wundern sich dann, warum das warum die Projektkosten explodieren. Bei einem Hausbau ist völlig klar, dass ich so eine weitreichende änderungen, die ich durch schaue oder die ich ja sehen kann, anfassen kann. Warum auf einmal, da die Kosten aus mir laufen? Also ich würde sagen, das ist schon angesprochen der Nr.1 Grund, warum IT-Projekte teurer werden, ist erstens eine ungenaue ziel. Beschreibung und mehrere unterschiedliche Vorstellungen der Stakeholder. Die sagen das Gleiche. Aber der eine meint das, der andere meint das ja.

Es muss ein System gebaut werden, was unser altes System ablöst. Der einer sieht nur seinen Prozess. Der zweite Mensch im Projektteam sieht zwar andere Prozesse von der, die das als System leistet, von denen der erste gar nichts weiß. Dann wird aus so einer wabernden Vorstellung wird ganz, ganz schnell, weil es schnell gehen muss, ein IT-Projekt aus dem Boden gestampft in Folge 9 oder Episode 9. Das Gebiet podcaster mal drüber gesprochen, kein Business Value Software Development gemacht, sondern es wird nicht geguckt.

Was sind denn die Prozesse, die werthaltig sind? Was ist wirklich das, was unser Unternehmen voranbringt oder unsere Prozesse vorwärts bringt, womit wir Geld verdienen, sondern da wird so eine Wünsch dir was Kiste aufgemacht. Und um alle zu befriedigen, darf jeder da sein Wunsch Zettelchen einwerfen, und du hast einen riesigen Wust, aber keine oder seltene, genaue ziel. Beschreibung, dann ist das Ziel für die Entwickler, und für die Konzeption ist einfach nicht klar. Also eine ganz genau ziel.

Beschreibung. Was müssen wir machen? Und was soll das fertige System leisten? Auch meinetwegen auf einem abstrakten Niveau. Das ist extrem wichtig, meiner Meinung nach ein bisschen verschlimmert. Noch wird das Ganze durch dieses agile Paradigma. Ja, wir legen erst mal los. Wir müssen uns jetzt gar keine Gedanken machen, sondern wir fangen an zu entwickeln. Und unterwegs treffen wir das dann noch so.. Ja, das ist richtig, wenn man ein Ziel Bild hat und das unterwegs nachschärfen.

Aber ich kann nicht anfangen, ein Softwareprodukte zu bauen oder ein Haus zu bauen, was als Gartenlaube gedacht ist, und dann unterwegs auf Bürogebäude umschwenken oder so. Ohne das die Kosten völlig aus dem Ruder laufen. Auch hier Software ist abstrakta ist das nicht so sichtbar. Bei der Baustelle würde das jeder sofort verstehen. Und also ganz klar. Problem Nummer eins Ungenaue Beschreibung, würde ich sagen. Aber wir wollen ja nicht nur schimpfen, sondern auch Tipps zur Verbesserung geben.

Meiner Ansicht nach lohnt es sich auch, wenn man agil unterwegs ist, sich im Vorhinein Gedanken zu machen und viele Gedanken darauf zu verwenden. Wie sieht denn die ideale ziel. Software aus? Welche Funktionen übernimmt sie? Welche Daten verarbeitet sie? Wie ist der grobe Fluss der Daten durch das System? Meiner Ansicht nach lohnt sich jede Planung Stunde, die man vorher investiert, 20 fach hinten raus, weil man einfach viele Sachen, die man nicht braucht, komplett weglassen kann und eine genaue Planung dahinter hilft, viel unnützen Code eben nicht zu schreiben, weil man von vornherein da klar ist, dass ein Thema aufgrund dieser Problematiken, die wir am Anfang besprochen haben, ist ja überhaupt das Agile und Scrum entstanden.

Da ist es irgendwie der nächste Pferdefuß. Was ich jetzt sage, mal in Entwicklungsteam so der agilen entwicklungsteams so mitbekomme, ist das ein bisschen vergleichbar mit dem Föderalismus. Was wir, was wir in Deutschland haben? Man versucht irgendwie, alle Entwickler in so eine Rolle zu zwingen oder gewisse Freiheiten oder gewisse maximale Freiheiten zu geben. Und das müssen einfach IT-Leiter und deutsche Unternehmen verstehen. Das Entwickler Spiel Kinder Entwickler spielen gerne mit modernen Technologien. Sie wollen mit modernen Technologien spielen, damit sie etwas dazulernen, damit sie wie das auf ihrem Zivi gut macht.

Entwickler werden mich jetzt wahrscheinlich hassen, aber das ist halt eine gewisse Technik.

Spielerei kann man ja niemand abstreiten. Das man macht ja jeder Mensch auch.

Ich denke ja genauso absolut in Ordnung, aber es muss zielgerichtet sein, es muss zielgerichtet sein.

Und aus Unternehmer Sicht muss man da halt ein bisschen vorsichtiger damit umgehen, was dann passiert ist. Und das ist jetzt nicht Theorie, sondern tagtäglich in vielen Projekten, so dass ein unheimlicher Wildwuchs von Technologien in einem Projekt entsteht, weil jeder mit irgendwas experimentieren will, das in Produktion wandert Entwickler übermorgen oder der Externe, was auch immer in einem Jahr wieder weg ist. So wächst das System um Frameworks und Leichen, die nicht dokumentiere. Und dann hast du ein Wildwuchs, dessen du nicht mehr Herr wirst.

Worauf ich hinaus will, ist Komplexität. Das ist so etwas wie System, Entropie. Und je höher die Entropie ist, umso mehr Chaos entsteht. Das ist eins zu eins widerspiegelt auf die Software-Entwicklung. Welt Du wirst der Komplexität nicht mehr Herr, und du kannst Entwickler nicht gleichberechtigt nun sagen So euch mal eine schöne Welt aus, setzt alles ein, was ihr möchtet. Meines Erachtens ist meine persönliche Meinung. Brauchst du immer. Das gab es früher immer Architekten in Projekten, der erfahren.

war, viele Projekte gemacht hat und die Architektur ein bisschen vorgegeben hat, ein bisschen darauf geachtet hat, was ein scheinbar umsetzen, was ein Wir setzen, was ein bisschen darauf geachtet hat, die Komplexität niedrig zu halten, manage skalierbar zu halten. Und wenn du das mal gemeinschaftlich in die Hände von vielen gibst, dann passiert genau das, was im Föderalismus passiert. Jeder kocht sein eigenes Süppchen, und jeder hat mitzureden. Und dann entsteht Chaos.

Das kann ich mir meines Erachtens im Unternehmens Context nicht erlauben, da es zu Recht die IT-Mitarbeiter, das sind auch irgendwo Wissenschaftler. Und wenn man Wissenschaftler da hat jeder so ein Bild vor Augen einfach in ihrem Labor einsperrt und sagt Macht irgendwas, da passieren viele Dinge. Aber gegebenenfalls gerät das Ziel aus den Augen. Genau. Also auch hier Ziel, Fokussierung. Und ich bin auch absolut dafür, dass es im. Oft sagt man in Scrum Teams Alle sind gleichberechtigt.

Ich denke auch, dass die erfahrenen Mitglieder auf jeden Fall so ein Drahtgitter Modell für die Architektur vorgeben sollten. Das hat einfach den Hintergrund, dass man a kennt sich damit aus jahrelanger Erfahrung und b ist das auch wieder so eine ziel. Fokussierung, eben nicht jedes Framework mitzunehmen und sich einfach an Standards zu orientieren, weil die Entwickler denken Ui, hier gibt’s ja neue Technologie, das kann ich benutzen, und das macht mir vielleicht etwas einfacher. Was Sie aber nicht sehen, ist der Maintenance auch dran?

Jemand, der vielleicht nach mir kommt, der muss sich auch damit beschäftigen, der muss das lesen. Er muss verstehen, was ich da gemacht habe und so weiter und so fort. Und das zieht halt dann einen ganzen Rattenschwanz nach sich. Und ich würde auch sein. Komplexität ist auf jeden Fall ein Feind für Projekte, Laufzeiten, was auch wieder damit zu tun hat. Genaue Ziele, Beschreibung auch architektonisch, technisch. Eine genaue Beschreibung ist auf jeden Fall Wert voll.

Wir wollen ja immer sagen, was man noch besser machen kann, und nicht uns einfach nur beschweren, sondern auch Input geben. Für die Zuhörer. Wie kann man das machen? Ich bin auch ganz knallhart dafür, dass man, wenn man Sprints macht, dass man danach eine strenge, ziel. Kontrolle hat, also wirklich sagt. Wie viel hat jemand geschafft? Klare Kommunikation. Ist das ausreichend? Kann man das besser machen? Auch unpopuläre Ansagen machen, um zu sagen Okay, das Framework kann man benutzt.

Das hat sich nicht als werthaltig herausgestellt. Wir probieren jetzt was anderes Probleme, Verbesserungspotenzial, offen ansprechen, aber dann dem Team auch helfen, diese Probleme lösen zu können. Also entweder durch Weiterbildung in einer bestimmten Technologie, durch modernere Hardware oder durch Ansprechpartner, die sich dann um das Problem kümmern und dann eben auch die Verbesserungen im nächsten Sprint, übernächsten Sprint und so weiter dann eben zu prüfen. Ich glaube, das hilft schon mir dann noch. Ich muss nochmal auf dieses Ziel Bildteil, diese ungenau ziel.

Beschreibung und das glaube ich, kennt jetzt jeder IT-Berater oder auch die Entwickler. Projekte werden oftmals gestartet mit der Frage Wann können wir live gehen? Die erste Frage ist Wann ist das fertig? Sozusagen. Anstatt zu fragen Welche Funktionen brauchen wir denn? Und das ist meiner Ansicht nach auch ein großer Problem. Punkt, dass man sagt Wann ist es denn fertig? Das kann ich auch verstehen aus busens Sicht. Aber jetzt muss man sich mal vorstellen, wenn man ein Haus kaufen will, und man geht zum zu so einem Immobilienberater, und der sagt Alles klar.

Wunderbar, dass Sie ein Haus kaufen wollen. Setzen Sie sich. Was sind denn Ihre Fragen? Die erste Frage wäre Wann kann ich einziehen? Na, dann wird auch der Berater sagen Ja, Moment, soll ein Haus sein oder eine Wohnung? Wo soll Design? Wie viel Budget haben Sie? Wollen Sie einen Garten? Wollen Sie eine Garage und so weiter und so fort? Und genau das muss man auch bei einem Software Projekt machen, das man erstmal fragt Was sind denn die wirklich wichtigen Funktionen?

Das mdep sozusagen mit dem Produkt, was erfüllt sein muss, um dann zu gucken, wenn man diesen funktions Korb hat. Okey, wie lange brauchen wir denn dafür? Und nochmal Wenn man diesen funktions Korb hat, wenn man glaubt, was alles wichtig ist, wirklich bei jedem Ding nochmal nachfragen? Ist das wirklich wirklich wirklich wirklich wichtig für die erste Version?

Oder können wir das hinterher auch machen? Können wir das hinterher machen, also wirklich den kleinen inkrementelle dann vorgehen? Das halte ich auch noch für ganz, ganz wichtig.

Passt zu dem, was noch gesagt, dass er, was auch immer, sehr witzig ist, wenn dieses Thema stramm und agil, warum man das macht, damit Projekte nicht mehr schief gehen. Unternehmen meinen, wenn Sie eine Firma anstellen, die Scrum einführt, ist das Thema gegessen.

Das Thema Nr.1 Verspätungen oder Projekt Fernzug gibt es nicht mehr. Wird ja verkauft das Agilität oder Egil oder digitale Transformation was wird die Lösung aller Probleme? Die ist dann meinen Vorstände. Na ja, gut, dann beauftrage ich halt so eine Firma, die bei mir agil einführt. Und dann finden ganz tolle Workshops und Spiele und Spaß um dieses Thema statt. Das Wichtigste Meinen Augen ist das Management oberster Ebene, aber auch in mittlerer Ebene das Thema verinnerlicht. Was das bedeutet, dass Meincke dahinter verstehe?

Ich habe ich noch kein Projekt erlebt, wo man zwar gesagt hat Ja, wir fahren. Wir fahren jetzt agil, machen agil, alles total super. Und was kostet das denn? Und dann fangen Sie an, diese Story von dieser Komplexität Abschätzungen plötzlich in Montale umzurechnen, weil diese beiden Welten sind dann noch da, sowohl die alte, und das wird dann versucht. Das ist total witzig.

Das ist auch schwierig, weil die anderen natürlich alte Business Welt oder die andere Business Welt, die ist natürlich total Termin getrieben. Wann ist sie fertig? Wann kann ich, was ich mache? Die werden ja von ihren Kunden auch wieder gefragt. Und wenn der Kunde sagt Ja, wenn wir 300 Story Points abgearbeitet haben, drängt sich natürlich die Frage auf Was heißt das jetzt? Dieser Wechsel, dieser Mentalitätswechsel hin zu Komplexität? Begg Von Zeit ist natürlich auch schwierig, aber deshalb halte ich es nochmal.

Ich stelle es noch mal raus für ganz wichtig, dass man sich mit der Kern notwendigen Funktionalität beschäftigt und sagt Okay, das machen wir erstmal und haben das innerhalb von nicht mein Gropp kann man es ja schon abschätzen 2 3 Monaten realisiert. Und die ganzen Sonderfunktionen? Die bauen wir dann danach dran. Und dann kann man jede Woche oder alle zwei Wochen je nach Spendende kann man den Fortschritt sozusagen dann eben kundtun, dass es auch noch eine Verbesserungsmöglichkeiten, die ich jedem empfehle, sind offene springend Reviews mit kurzem Projekt Intro, das man nach einem Sprint.

Die Entwickler, die Projektmanager, stellen vor, was in diesem Sprint erarbeitet wurde. Dass diese Runden offen sind. Im Grunde kann da jeder aus dem Unternehmen hinkommen, der möchte oder von Kundenseite auch der möchte. Dadurch entsteht so eine Art Verantwortlichkeit des Teams gegenüber der geleisteten Arbeit, und ich halte das für sehr, sehr wichtig. Verantwortlichkeit ist sehr, sehr wichtig. Und die Entwickler stellen kurz vor, woran sie gearbeitet haben, welche Fortschritte sie erzielt haben, und stehen danach auch für Rückfragen zur Verfügung.

Aber das zwingt die Entwickler, Verantwortung für die eigenen Module zu übernehmen. Unklare Verantwortlichkeiten ist auch ein ganz, ganz großer Killer und Kostentreiber. Du kennst das wahrscheinlich auch riesige Meeting runden, um alle abzuholen mir im Betrieb. Paar Wochen später fällt eine Komponente aus, und es ist völlig unklar Wer kümmert sich jetzt darum nicht? Wessen Fehler ist das? Sondern wer kümmert sich darum, dass das jetzt behoben wird? A Und das ist vor allen Dingen nicht wieder Auftritt.

B Der Monitor bestimmte Größen, ob das speicherplatzes Server, auslastungen, Netzwerkkarte ausgefallen und so weiter. Gibt es eine Checkliste für die Inbetriebnahme von Komponenten? Diesen übergang von Entwicklung zu verantwortlichem Betrieb, gerade wenn man schon Prozesse darauf ab gebildet werden, die dann produktiv sind, dass wirklich Leute zu benennen oder Teams zu benennen, die sich dann organisieren müssen. Das ist super wichtig. Bei sehr oft ist es so Eine Komponente fällt aus, irgendwie wird das. Dann wieder wird der Patient wieder beatmet und wird wieder an den Start gebracht.

Und danach laufen wieder alle zu ihrem Platz. Und die Aufregung im Hühnerstall legt sich wieder. Aber es ist nicht klar definiert. Wer ist denn jetzt verantwortlich, wenn das nächste Mal passiert? Und welche Größe kann ich monitoren, damit ich im Idealfall vorher schon weiß, dass es wieder sich andeutet und es gar nicht erst passiert? Das finde ich ganz wichtig und würde ich auch als Verbesserung anführen, Verantwortlichkeit den Entwicklern zu übertragen oder auch dem Team, was für den Betrieb verantwortlich ist.

Ein weiterer Punkt ist die unklare Kommunikation innerhalb von Projekt. Anforderungen, also Verstecken hinter Abkürzungen, werden nicht erklärt, alte Prozesse werden nicht hinterfragt. Halte ich auch für ein Riesending, wenn man jeden Prozess Formalin digitalisiert, mal hinterfragt Brauche ich den überhaupt noch? Oder macht er in der Form Sinn? Es zahlt auch wieder auf dieses klare Ziel ein. Kann ich auch sehr, sehr viel Aufwand sparen. Dann habe ich noch einen Punkt. Das ist mir aufgefallen, dass es da unterschiedliche Befindlichkeiten in Unternehmen gibt.

Und zwar gibt es Projektmanager, die scheuen den Konflikt nicht. Für die ist wirklich der Output wichtig. Also ist das Modul fertig. Ist es nicht fertig? Es gibt Probleme. OK. Dann bitte guckt, dass das gelöst wird. Und ok, du möchtest Technologie benutzen. Ich gebe aber Technologie BE vor, benutze Technologie BE, weil ich das vorgegeben habe. Das ist erstmal ein bisschen brutal, aber es gibt auch Struktur. Andere Projektmanager wiederum, die wollen diesen Konflikt gar nicht.

Die sind eher defensiv und sagen Nein, machst du das, wenn du das für richtig hältst, und ihr seid die Techniker, und ihr müsst das entscheiden. Und dadurch wird halt diese komplette Verantwortung. Von der Software Austellung wird quasi auf die Entwickler abgeladen. Ist ja bequem. Meiner Ansicht nach kann das nicht funktionieren, weil du dann wieder diese Insellösungen schaffst und jeder in seinem eigenen Saft schmort. Anstelle von Gemeinschaftsgefühl entsteht das allein einer Komponente Arbeiten. Man muss schon gewisse Richtlinien einhalten und Rahmenbedingungen einhalten, damit die Einzelkomponenten zusammen auch funktionieren können.

Da erwarte ich von einem Projektmanager, dass er auch in Konflikt gehen kann und sagen kann Nein, das muss jetzt, muss jetzt zusammen funktionieren, und dann müsst ihr halt müsst euch die Sache nochmal angucken. Wenn das jetzt noch nicht funktioniert und das ist deine Verantwortlichkeit für dieses Modul dafür zu sorgen, dass das funktioniert. Also bitte, setzt das jetzt auch um?

Apropos Projektmanager Wenn man heutzutage werden ja fast alle Projekte nur noch agil und so gemacht. Also Thema, Projektmanager und Zuständigkeiten. Und die Methodik sieht ja vor, dass du ein Produkt oder hast, der quasi von der Fachabteilung oder Kundenseite gestellt wird. Und der steht Rede und Antwort für all die Fragen, die man als Entwickler so hat bezüglich Anforderungen, bezüglich Vorgehensweise. Und auch das hab ich des öfteren erlebt, dass eigentlich auch so einer gar nicht richtig benannt ist, im Unternehmen oder im Tagesgeschäft so eingefangen ist, dass er den Sache nicht hinterherkommen.

Das habe ich schon ganz oft erlebt. Dass Entwickler sich da darüber beschweren, dass diese Zuständigkeit oder die Ernsthaftigkeit dieser Rolle nicht gegeben ist, weil diese Person, dieser Projektmanager, der hat wahrscheinlich schon drei Projekte für das Neue noch obendrauf.

Und jetzt muss er auf so vielen verschiedenen Hochzeiten tanzen, dass er im Grunde nur noch die die Bälle weg schlagen kann, ohne da wirklich tief einzutauchen. Okay, also die nicht Verfügbarkeit der fachleiter würde ich ja, aber genau das wäre ja jetzt auch gar nicht so schlimm, wenn wiederum das Ziel Bild klar beschrieben wäre.

Und oft ist es ja so, dass sich das Ziel dann eben entwickelt während der Umsetzung. Und dann muss natürlich die fachleiter verfügbar sein oder der Ansprechpartner verfügbar sein. Es geht ja nicht beides. Ich kann nicht bei der ziel. Beschreibung sparen und dann noch unterwegs bei der Kommunikation sparen, sondern ein tot., heißt es. So schön muss man sterben. Das waren ja jetzt sehr, sehr viele organisatorische Punkte, die wir angesprochen haben und wo wir auch Verbesserungsmöglichkeiten aufgezeigt haben.

Was siehst du denn im technischen Bereich? Wirklich harte technische Probleme, die dazu führen können, dass Projekte teurer werden oder dass Projekt Laufzeit stark ansteigt, hatte ich schon am Anfang so?

Das ist für mich Thema Nummer eins ist Komplexität. Dieses Mal agile Vorgehen ohne Architekt, das Dinge tut und irgendwo von der Bundeswehr ist. Das gehört zwar irgendwo zu Fehlerkultur dazu, dass man agil lernt. Aber wenn man eine Position im Projekt besetzen würde durch einen erfahrenen Architekten, könnte man sich halt viel Zeit, ärGer und Kosten ersparen.

Und der wäre dann auch verantwortlich. Man würde verantworten müssen, auf Hygiene achtet und all diese Dinge, dass das Projekt in gewissen Bahnen frei laufen kann, also nicht einschränkend von oben vorgehen, wie es früher gewesen ist, wo, bis Festnahmen und variabel nahm, alles vorgegeben wurde? Das ist Quatsch. Aber die Schranken dafür setzen, innerhalb derer ich mich frei bewegen.

Das sind die Fronten. Technologien, das ist die Gentechnologie, die zum Festen genaus. Und ja, auch wenn unter oder während des Projektes eine neuere Version rauskommt, benutzen wir erst mal die alte weiter, weil wir wissen, dass die stabil ist. Und das Upgrade auf die neue Version ist dann sozusagen ein Teilprojekt, wenn wir das wollen. Aber sonst benutzen halt erst mal die Alte weiter und machen das dann danach. Hohe Komplexität. Ich sehe das genau wie Du ist auf jeden Fall ein Killer.

Auch der Wechsel von Technologien während der Laufzeit halte ich für einen Killer wahrscheinlich. Im Frontend lässt sich das je nach Projekt Laufzeit gar nicht immer vermeiden. Aber dass man innerhalb eines Projektes Teilprojekte hat, wo man grundlegende Sachen umstellt und dann alle wieder sich neu eindecken müssen. Zumindest ich finde das ziemlich anstrengend, weil du du entwickelst, so eine Karte von einer Software Anwendung in deinem Kopf. Und wenn das andauernd umgestoßen wird und du dich komplett wieder neu einarbeiten musst, das es irgendwann blickt keiner mehr durch.

Und dann gibt sich auch keiner mehr Mühe, weil jeder weiß, wo in drei Monaten sowieso wieder alles anders aus. Von daher verliere ich jetzt. Hier gebe ich mir gar nicht so viel Mühe mehr, um das ordentlich zu machen. Ein weiterer technischer Fallstrick? Das weiß ich gar nicht. Ob das nicht doch vielleicht eher organisatorischer Natur ist, ist die Integration von Systemen. Da geht es häufig darum, dass alle Systeme noch angebunden werden müssen oder Daten migriert werden müssen.

Und das ist meiner Erfahrung nach auch nimmt das sehr, sehr viel Zeit in Anspruch, dass man das alte System dann irgendwie so beatmen, dass man die Daten in den neuen Topf dann eben mit übertragen kann. Das ist auch ein Punkt, lässt sich nicht immer verhindern. Aber das alte System ist meist schlecht dokumentiert, und es wird auch nicht immer. Und Leute, was es damit auf sich hat und wie das genau funktioniert, sodass man da viel trial and error hat.

Und was zieht es natürlich in die Länge, wenn man herumprobieren muss. Auch hier wieder würde ich sehen, um die Technologie oder um die Komplexität beherrschbar zu halten. Möglichst wenig erst einmal umsetzen, aber dann generell die Komponenten erweiterbar gestalten. Durch diese Micro Service Architekturen haben wir jetzt den Vorteil, dass wir diese harte Verdrahtung oft nicht mehr so extrem haben, wie das früher der Fall war. Aber auch hier und das kommt eigentlich diesem modularen Entwicklungs Ansatz schon entgegen, das man dann nach und nach weitere Komponenten nachrüsten kann oder Komponenten mit mehr Funktionen ausstatten kann, um dynamisch diese Software Landschaft hochzuziehen.

Früher hat man Software entwickelt wie ein Weihnachtsgeschenk. Man hat sich was gewünscht, dann hat man ja gewartet. Mal kam irgendjemand, der hat das Paket ausgepackt und Tadao da ist. Es ist dann wie das Geschenk der Tante.

Das kann gut sein, das muss nicht gut sein. Genau, oder? Heute ist es mehr so, dass Software entwickelt wird wie so eine Pflanze man Pflanzensamen in den Topf gießt, Wasser drauf, und die wächst so langsam nach oben. Und wenn sie krumm wächst, dann kann man auch die Pflanze an so einen Stab binden, sodass sie wieder in die richtige Richtung wächst. Nach einem Jahr hat man dann auch eine große Blume, die man aber quasi kontinuierlich begleitet hat und die Wachs Richtung beeinflusst hat.

Jetzt muss man sich einfach gewöhnen, dass es so ist. Hast du welche Faustregeln für IT-Projekte, um es besser zu machen? Also, wenn du ein Projekt aufsetzt, hast jetzt auch schon oft gemacht. Was sind die Fragen, die du dir stellst, um zu sagen Okay, ich möchte jetzt. Ich möchte auf gar keinen Fall, dass es ausufert. Sondern es soll natürlich ein erfolgreiches Projekt werden.

Ich versuche mich immer, dass das Projekt immer aus Sicht aus der Brille des Kunden zu sehen. Das. Ich würde gerne immer das Business verstehen oder den Newski hinter den einzelnen Features und eigentlich der gesamten Software. Wenn es mal Domänen, fremde oder fremde Projekte für mich sind, wo ich keine Erfahrung habe, lese ich mich sogar in diese Thematik hinein, damit ich einfach das Würdigen verstehe. Die Kunden oder die Projektleiter oder wie auch immer, die sprechen halt in ihrem Jargon.

Und das heißt Kommunikation oder Missverständnisse sind eigentlich auch ein riesen Faktor, warum Dinge in die falsche Richtung laufen. Deswegen nehme ich mir auch Zeit. Und in ersten Workshops versuche ich, das eigentlich auch sehr erfolgreich rüberzubringen, das ich mir erst mal Zeit nehmen möchte. Das Business natürlich nicht in voller Komplexität, aber ich sage mal, die Grundbegriffe und Grundbesitzes regeln und die Dynamik dieses Geschäftsmodells verstehen will. Bevor ich anfange, in irgendwas in Richtung Technik zu sprechen, weil ich will was Fundiertes haben.

Ich will das, weil gerade am Anfang, wenn du das ist wie Mathe, wenn du die Basics nicht verstehst, dann wird es hinterher immer schlimmer und immer schwieriger. Und so ist das in einem Projekt, auch wenn du dir angewöhnt, die gleiche Sprache wie der Kunde zu sprechen, das Projekt aus seinen Augen zu sehen und ernsthaft versucht, das Problem zu verstehen. Dann werden wir ganz andere Lösungen einfallen und am besten beraten und entsprechend auch am besten das Projekt Setup machen.

Du kannst daraus dann ableiten Wo haben wir Schwächen, wo aber Stärken? Was brauche ich für Rollen? Was muss ich besetzen? Aber ich versuche immer, alles zu umgehen, wo es heißt So, jetzt machen. Da ist das agile Team, legt einfach los und beachtlich inzwischen ein bisschen drauf und notfalls auch grüne Projekte nicht an. Wenn ich merke, das Verständnis ist nicht da, und da fangen irgendwie zwölf man wild auf, irgendwas rum zu prügeln oder verlieren sich ein Spielchen und Maskottchen, Schneiderei fürs Team oder Team Name?

So ein Quatsch. Das sind für mich keine ernsthaften Projekte, und da nehme ich mich auch raus.

Da ist das Projekt im Grunde schon von Beginn an verloren.

Was heißt verloren? Wenn die lang genug Geld rein schmeißen, wird es mit Sicherheit irgendwann irgendwas Vorzeigbares haben. Aber irgendwann geht es auch dem Kunden dann auch die Augen auf, wo man? Warum gibt es dann noch nichts? Und man Warum ist es so teuer wie jetzt? Vectoring? Wie? Und irgendwann fragen Sie sich Was stimmt da nicht? Und ich möchte halt nicht Teil eines solchen Teams sein. Für mich ist Softwareentwicklung immer noch eine Ingenieurskunst. Ich gehe das mal aus meiner Sicht sehr professionell an, und ich möchte irgendwas lösen und keinen Wellness-Urlaub für Entwickler durchmachen.

Das wäre dann so eine Art Du sprichst direkt auf eine Faustregel an, die ich für mich formuliert habe. Ist das die Frage? Habe ich die richtigen Leute, um dieses Projekt durchzuführen? Haben Sie schon mal ähnliche Projekte erfolgreich durchgeführt? Das ist ganz, ganz wichtig. Gerade kleinere Kunden, die orientieren sich bei Anforderungen dann oft an Silicon Valley Unternehmen und sagen Ja, bei Facebook geht das doch auch so und so, bei Google geht das doch auch so. Aber die.

Dass wir hier Multi Milliarden Dollar Unternehmen haben, die nur aus Software-Entwicklern der höchsten Güteklasse wenn ich das so sagen darf bestehen und die das natürlich einfach machen können. Und das ist vielleicht nicht bei jedem anderen Unternehmen der Fall. Da muss man sich fragen Habe ich die richtige Mannschaft, um sowas auch stemmen zu können? Dann auch eine Frage, die ich den Kunden jetzt nicht so direkt stelle ins Gesicht stelle, weil sie nichts schockieren würde, aber die ich mir dann schon selber stelle, um die Sinnhaftigkeit eines Projektes abschätzen zu können, ist Lohnt sich das Projekt für diese Firma, für diesen Kunden, auch wenn es doppelt so teuer wäre.

Und wenn es doppelt so lange dauern würde, weil man dann die Antwort ja ist, dann weißt du, dass du einen Transformationsprozess mit begleitet, der für das Unternehmen im Grunde alternativlos ist. Und dann ist seitens vom Vorstand auch oft das Commitment da, dass man auch bei Widrigkeiten das Projekt fortführt und nicht das so nicht essenzielles Projekt ist. Was dann immer gefährdet ist, das finde ich immer ziemlich schade. So, bei den Projekten arbeite ich auch nicht so gerne mit, weil ich immer das Gefühl haben Siemens.

Warum mache ich das? Warum? Wenn das nicht wirklich wichtig ist, warum setze ich meine Arbeitskraft ein? Und noch eine Faustregel, die ich aber mehr für mich postuliert habe, aber die ganz oft ganz gut hinhaut, ist, dass ich Schätzungen von Entwicklern das kennst du bestimmt auch es gibt. Es gibt unterschiedliche Schätz Typen, es gibt den Entwickler Typ A. Alles kein Problem. Da kann man irgendein Problem skizzieren, der schätzt Na, das hab ich in einem halben Tag gelöst.

Nach einer Woche sitzt da immer noch dran, weil auf einmal sich da doch unabwendbar keimten ergeben haben. Und witzigerweise sitzt dieser Entwickler oft immer eine Woche an Problemen, die er von halben Tag abgeschätzt hat. Das sind diese überaus optimistischen Entwickler. Abschätzungen. Dann gibt es das aber auch in die andere Richtung. Oh, da muss ich eine Farbe ändern. Da muss ich den Button hin machen, und das dauert bestimmt drei Wochen, damit Sie dann nach zwei Tagen fertig haben und sich sozusagen auf die Schulter klopfen können, dass Sie das viel schneller umgesetzt haben.

Und dann Mittelweg zu finden, das ist eine Kunst. Sag ich wirklich, mein Glauben abschätzen ist so einfach, aber das ist wirklich eine Kunst. Ich habe mir angewöhnt, bei Ich sage mal einigermaßen so gemittelte Schätzungen immer noch den Faktor 30 Prozent drauf zu schlagen. Wenn jemand 100 Tage abgeschätzt hat, rechne ich mit 13 Tagen Faktor 1,3 und lande oft ganz im Mittel. Natürlich lande damit oft ganz guten Treffer. Also, es gibt natürlich Aufgaben, die dauern nur die Hälfte der Zeit.

Dann gibt es Aufgaben, die liegen etwas drüber. Und dann? Das passiert oft. Es gibt Aufgaben, an die keiner gedacht, und die brauchen auch nochmal Zeit. So stehen gar nicht auf dem Zettel. Die tauchen unterwegs auf und verschlingen auch ein bisschen Zeit. Und da ist dieser 30 Prozent Sicherheitspuffer dann oft sehr wertvoll, dass man den für diese Aufgaben verwenden kann. Sehr oft hat man in der Aktie mit absolut profanen Problemen zu tun. Die Architektur ist alles da, die Schnittstellen können kommunizieren, und das Ganze konzeptionell Schwierige ist abgearbeitet.

Und dann braucht man zwei Tage, um den richtigen Datenbank Treiber mit der Datenbank zu verknüpfen, weil irgendwie Error 436 fliegt und keiner weiß, warum. Und dafür brauchst du dann zwei Tage, um das herauszufinden, wie man dieses Problem löst. Und das schätzt natürlich keiner ab.

Also, ich habe mal in kein Projekt gesehen Zeitbudget für unvorhersehbare, verrückte Fehlermeldungen. Drei Tage müsste man eigentlich, müsste man eigentlich immer einplanen, weil das passiert überall. Aber habe ich bisher noch nicht gesehen. Ich weiß nicht, wie es dir da geht.

Nee, das stimmt. Wenn ich aber eine Abschätzungen abgebe, ist es meistens so, dass ich sage mal also ich mache mir ein Excel Datei, schreibe die ganzen Features rein und mache dann drei Spalten, eine Spalte und eins ist der Schnitt.

Dieser klassische Trichter, dieser Trichter genau. Und zum Schluss dann tatsächlich diese 30 Prozent drauf. Für Unvorhergesehenes.

Das ist, so STANDARD, die 30 Prozent drauf, vom Schnitt oder vom Schnitt. Also wenn ein Geschätzter fünf Tage ist, fünf Tage, zehn Tage zwischen siebeneinhalb und da dann nochmal 30 Prozent drauf.

Heißt Eigentlich musst du nur abschätzen, was es bestenfalls und was. Den Zeitaufwand für den besten und den schlechtesten Fall und alles andere ergibt sich dann rechnen? Nee, super. Also ich hoffe, wir haben unseren Zuhörern eindringlich vermitteln können, wie wir glauben, dass man IT-Projekte schneller, besser und vor allem günstiger über die Bühne bringen kann. Also ich möchte nochmal die klare Ziel Beschreibung hier ansprechen, die ich für ganz wichtig halte und die Verteilung von Verantwortlichkeiten. Und ich denke, es ist im Sinne von allen, also sowohl den Unternehmen, die Kosten sparen, den Projektleiters die weniger Runden drehen, und den Entwicklern, die weniger Code schreiben, der am Ende nicht verwendet wird oder schlimmstenfalls in der Mülltonne landet.

Wenn wir lernen, zielorientierter Software zu entwickeln, indem. Möchte ich auch noch einmal auf die Episode IX des SKL bei Podcasts hinweisen? Wulz Development Ich glaube, die ist auch super interessant, wenn man sich für das Thema zielgerichtete Entwicklung interessiert. Ja, ich möchte mich ganz herzlich bedanken für die Session heute. Es war wie immer ein Fest. Danke, liebe Zuhörer. Wenn euch der Podcast gefallen hat, schickt uns gerne Feedback an Podcasts, abonniert den Podcast oder lasst uns eine fünf Sterne Bewertung in ihr weitere Infos aus dem technischen åland von Sky haben möchtet.

Schaut gerne auf Skill bei Slash Blog vorbei. Ich wünsche noch einen schönen Tag. Danke gut, du auch.

Maurice KnoppSkillbyte Podcast #18: Warum sind IT Projekte so teuer?!
Mehr

Skillbyte Podcast #16: Werde immer besser!

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Werde immer besser!

// Inhalt //
01:26 – Verbesserungen sind überall
03:04 – Kontinuierliche Verbesserung hat eine lange Geschichte
04:09 – Viele kleine Verbesserungen statt des einen Quantensprungs
05:01 – Deutschland, traue dich Fehler zu machen…
06:40 – …oder fahre im Windschatten?!
07:00 – Beschleunigung und schnelle Iteration
08:04 – Sicherheit vs Geschwindigkeit
12:38 – Die Transformation von Nokia
13:33 – IT-Bereich: Scrum als iteratives Modell
14:10 – Das Pareto Prinzip
15:19 – „Beharrmoment“ vs Innovation bei Organisationen
16:19 – Innovation: Online Weinprobe
17:12 – Zusammenfassung: Kontinuierliche Verbesserung
17:45 – Tools für die persönliche Verbesserung
26:25 – Buchtipp: Atomic Habits
27:50 – Positives Mindset: der Stoiker
30:05 – Positives Mindset: Sieh Probleme als Herausforderungen
31:03 – Positives Mindset: Sport als Energielieferant
32:12 – Positives Mindset: Weiterbildung
32:55 – Positives Mindset: regelmäßige Reflexion
33:36 – Belohnungen und Motivation

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #16: Werde immer besser!
Mehr

Skillbyte Podcast #9: Bull’s Eye Software Development – Einfach und fokussiert auf Unternehmensziele

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Bull’s Eye Software Development – Einfach und fokussiert auf Unternehmensziele

// Inhalt //
1. Definition: Das Ziel von Software
2. Unternehmen kommunizieren Unternehmensziele von Software oft nicht klar.
3. Der Wert von SCRUM
4. Für Entwickler: Was bedeutet professionelle Softwareentwicklung?
5. Fazit: Bessere Kommunikation von Unternehmen & zielgerichtete Entwicklung

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #9: Bull’s Eye Software Development – Einfach und fokussiert auf Unternehmensziele
Mehr