Prototyping

Skillbyte Podcast #40: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt haben (Teil 2)

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

In diesem Podcast geht es um das Thema: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt (Teil 2)

// Inhalt //
01:27 – Masiar’s IT Katastrophengeschichte
02:29 – 6. Lektion: Verstehe zuerst das Problem, schreibe dann erst Code für die Lösung
08:18 – 7. Lektion: Frage um Hilfe wenn du nicht weiter kommst (ultimative Superkraft)
11:20 – 8. Lektion: Du wirst immer weiter lernen (müssen)
21:22 – 9. Lektion: Test driven development (TDD) ist ein Mythos
26:34 – 10. Lektion: Alles dauert länger als geplant. Lass dich nicht von willkürlichen Deadlines verrückt machen.

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Nein. Prozess. Prozess beim ersten Mal o. citta bibber und um Gottes Willen und die Welt geht unter. So, und dann machst du und tust du. Und dann bist am Wochenende da und nachts bis drei. Und hin und her. So wird es aber trotzdem später, weil irgendetwas passiert ist, wo du keinen Einfluss drauf hast oder merkst. So schlimm war das jetzt doch nicht, weil der der Druck gemacht hat. Der war dann auch entspannt. So, und wenn das ein paarmal passiert, dann zuck sogar wenn Merkel.

Herzlich Willkommen zu unserem Skill bald Podcast Episode Nr. 40 10 Lektionen, die wir in über vierzig Jahren Softwareentwicklung gelernt haben. Teil 2 Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld, wenn ihr die Entscheider oder die Fachkraft seid. Wenn ihr Hörer Fragen habt, sendet uns gerne eine E-Mail an Podcast als Skill bei D. Wir freuen uns immer über eine positive Bewertung und wenn ihr den Podcast an Freunde und Kollegen aus dem ähnlichen Arbeitsbereich weiter empfehlt ich bin heute hier wieder mit Mazur zum zweiten Teil.

Hallo Masiar, Hallo Maurice, du bist heute sehr Energized.

Ich bin heute total Energieriese. Ich hatte eine gute Woche und freue mich jetzt mit dir. Wirklich, wirklich. Weil die ersten 5 Lektionen sind schon super angekommen. Da hab ich viele Zuschriften bekommen per WhatsApp und freue mich jetzt mit dir. Lektion 6 bis 10 durchzusprechen voller Energie. Vorher allerdings möchte ich dich fragen Sind dir noch Katastrophen aus deinem Leben eingefallen?

Ganz im Ernst. Ich habe überlegt und überlegt, wie es wirklich nichts eingefallen. Allerdings muss ich sagen, jetzt letztens kam eine GERB für Gravity Kiwi so toll eingerichtet. Was dir berichtet, ob alles in Ordnung ist. Und da kam eine Falschmeldung und damit hat sich das Herz in die Hose gerutscht. Da hatte ich seit langem mal wieder Angst, weil ich unterwegs war und nix machen konnte. Aber es war eine Falschmeldung. Insofern war es wieder gut. Was stand in der Meldung, dass Gravity nicht verfügbar ist?

Also komplett offline? Ja, genau. Ah, okay. Ich dachte jetzt Datenbank kaputt. Hacker haben die Daten geklaut oder so irgendwas Relevantes.

Mir ist nichts passiert in der Richtung nichts passiert. Okay. Erst bauen und Fehlalarm.

Das ist bestimmt meine Aura, die sowieso alles abhält. Deine Aura möchte ich auch haben. Na gut, springen wir zur sechsten Lektion. Vielleicht fällt dir unterwegs noch eine Katastrophe auf, wenn wir durch die Lektionen gehen. Die sechste Lektion ist eine ganz wichtige. Und zwar verstehe zuerst das Problem und schreibe erst dann den Code für die Lösung. Das Problem hierbei ist es oft. Ich bin sicher, das hast du auch gesehen, dass wenn es um Softwareentwicklung geht, springen viele Leute sofort ins Coding.

Die haben die Anforderung gehört. Ach ja, ich weiß schon, was ich machen muss. Achja, da mache ich das so. Da braucht man hier in Cash und das und das und setzen sich sofort an die Tastatur und legen los. Neue Funktionen wenn, dann so iterativ, ganz schnell implementiert und laufend angepasst. Und man merkt erst nach einiger Zeit, dass man das Problem gar nicht korrekt verstanden oder vollumfänglich verstanden hat. Und dann fängt man nochmal von vorne an oder es kommt auf jeden Fall zu einem erheblichen Zeitverlust.

Ich bin sicher, das hast du auch schon gesehen.

Ja, absolut. Ich meine, ich hab mich selber schon mal dabei ertappt. Ich hab mir seit dem das war so in den Anfängen hab ich das so gemacht. Tatsächlich. Aber irgendwann hab ich mir angewöhnt, keine Sequenzer, Diagramme, Urmel, Diagramme und so weiter groß gemacht, sondern einfach auf ein Blatt Papier, so die Komponenten aufgemalt, die Beziehungen aufgemalt. Kann echt auf einem Blatt Papier sein, um einfach mein Kopf zu sortieren und dann steige ich habe auch schon gerne ein.

Mir liegt die Klassennamen auf oberster Ebene, verknüpfe sie, schreibe die ersten Tests Duala Test Driven und das funktioniert ganz gut.

Das ist so, bis ihn der Flow, denn ich habe genau das ist für mich ein ganz klarer Indikator, ob man es mit einem Junior Entwickler oder Senior Entwickler zu tun hat. Ein Senior Entwickler stellt erst einmal sehr viele Fragen und versucht das Problem genau zu verstehen oder die Anforderungen genau zu verstehen und ist halt erst Input fokussiert. Wie geht man das jetzt an? Also du hast es eben schon gesagt. In jungen Jahren geht der Tüftler mit einem durch und man möchte sofort einsteigen und loslegen.

Ich habe so zwei unterschiedliche Pattern, je nachdem ob es um Feature Entwicklung geht oder um Bugfix sing.. Fangen wir mal mit dem Einfacheren an. Das wäre das Bugfix sing.. Das Allerwichtigste beim Bugfix sing. ist, dass man erst einmal den Bug zuverlässig reproduzieren kann, weil erst dann sinnvolle Entwicklung eines Fixes möglich. Meiner Ansicht nach erst, wenn ich weiß, wenn ich hier klicke und da klicke und dann tritt der Fehler auf und das immer wieder machen kann. Erst dann kann ich ja quasi prüfen, ob meine Lösung das Problem wirklich löst.

Ein weiterer Hinweis und ich bin verblüfft, wie viele Leute das nicht machen ist, den Debugger zu verwenden, also wirklich Schritt für Schritt durch das Programm durch zu steppen und sich die Variablen anzugucken. Was passiert hier? Was passiert da gerade, wenn man das Programm selber nicht kennt oder es nicht selber entwickelt hat, dann wird es oft sehr einfach, da einen Fix zu entwickeln, weil man einfach genau sieht Ah, ok, an dieser Stelle muss etwas anderes passieren oder muss etwas weiteres passieren und das könnte man dann implementieren.

Einfach den die Bagger abklemmen und idealerweise wenn man den Bug dann gefixt hat, dann hinterher war man jetzt schon im Thema drin. Noch einen Testa zu schreiben, der prüft, dass der fix funktioniert und dass das Problem eben nicht nochmal auftritt. Das ist meiner Ansicht nach eine professionelle Möglichkeit ans Bugfix hing ranzugehen, um nicht direkt in den Code zu springen. Bei der Feature Entwicklung und da bist du wahrscheinlich bei mir ist es oft so, dass die Anforderungen gar nicht so klar sind.

Also das ist wirklich ganz ganz selten, dass der Projektleiter. Jeder auf einen zukommt und glasklar schon sagt Das soll so sein. Das soll so sein. Das soll so sein. Das soll so sein, sondern ja, wie hat man altes System? Und da lief das so und so und ich möchte das jetzt genau so haben. Nur hier und da, da muss etwas geändert werden. Also das tritt sehr häufig auf. Auch hier das Problem erst einmal voll umfassend verstehen.

Wenn schon Quote da ist. Also wenn z.B. das Feature eine Erweiterung darstellt, erst einmal diesen verstehen, dann ne Lösung Skizze erstellen, genau wie du sagst. Ich versuche mir immer die Eingabe und Ausgabe Daten erst einmal aufzuschreiben. Was geht rein, was soll rauskommen und dann eine Technologie Skizze zu machen. Und im Grunde ist für mich ein Computersystem in Daten Topf mit Code drumherum, also eine Daten Haltung die Transformationen auf diesen Daten durchführt. Und ich glaube, wenn man die Daten und die Transformations Schritte hinreichend genau beschrieben hat, dann wird das Problem mehr oder weniger klar und der Rest folgt fast automatisch.

Oder die Problemlösung folgt fast automatisch. Und bis man soweit ist, hat man sehr viel gelesen, aber noch keinen Code geschrieben oder sehr wenig Code geschrieben. Warum passiert das? Warum springt man sofort in den Code? All das einfacher ist, als sich Gedanken über das Problem zu machen. Das ist oft sehr schwierig. Man muss nachfragen, man hat es nicht genau verstanden. Man muss diese Zeichnung erstellen und direkt zu coden. Das möchte im Grunde jeder. Aber mit zunehmender Reife weiß man, dass das nicht unbedingt das zielführende Vorhaben ist.

Du bist auch motiviert, hast eine Idee im Kopf und setzt sich hin und willst das sofort machen. Also ich muss sagen, wenn ich tatsächlich eine Idee fest im Kopf habe, dann mach ich das auch schon mal hier und da setze ich mich hin und knallt die Klassen einfach rein. Das funktioniert auch ganz gut, aber ich glaube, das kannst du nur machen, wenn du gewissen Erfahrungsschatz mitbringst.

Erstens das und wenn das Problem hinreichend klein ist. Ja, definitiv. Also nicht bei super komplexen Funktionen oder wo sehr viele Transformationen gemacht werden müssen. Genau. Und dann ist es oft auch wichtig, das Problem korrekt zu erfassen oder das ist eigentlich das Wichtigste und dann das Problem zu lösen, anstatt irgendwie fancy mit Architektur Patterns technische Exzellenz zu zeigen. Das sehe ich auch relativ häufig. Dann werden dann einfache Sachen technisch exzellent gelöst, aber das Problem ist gar nicht so richtig verstanden worden.

Da gibt’s ein schönes Zitat und damit möchte ich die sechste Lektion abschließend von Abraham Lincoln Gib mir sechs Stunden einen Baum zu fällen und ich werde die ersten vier Stunden mit dem Schärfen der Axt verbringen.

Als Kind ist es echt schön. Ja, genau.

Ich kenne sogar so eine extreme Version. Da heißt es Gib mir fünf Stunden und 50 Minuten zum Schärfen der Axt, sodass man mit einem Hieb im Prinzip den Baum durchbekommt. Aber was heißt das hier? Ganz klar Desto genauer du das Problem verstehst, desto einfacher wird die Lösung hinterher. Nur man muss halt mehr Zeit mit der gedanklichen Beschäftigung mit dem Problem verbringen statt mit dem eigentlichen Coding. Deshalb ist das so schwierig zu befolgen. Die siebte Lektion ist für mich eine ultimative Superkraft.

Und zwar Frage um Hilfe. Wenn du nicht weiterkommst, wie machst du das?

Wenn ich nicht weiterkomme, muss ich sagen such ich tatsächlich im Internet. Stack Overflow ist definitiv eine Quelle, die mir sehr viel Tipps und Inspiration gibt, aber auch alle Menschen toll sehr Ego im Netz sind. Da werde ich für den speziellen Fall, wo ich nix finde, frage ich ja tatsächlich natürlich auch Kollegen.

Man verbeißt sich oft in Problem oder so geht’s mir manchmal. Du fängst an, alles ist ganz einfach. Dann kommen irgendwie Hindernisse, auf den gelangst du immer tiefer in diesen Kaninchenbau rein. Man probiert unterschiedliche Ansätze und wendet sehr viel Zeit auf. Also dann ist man richtig frustriert und fragt nach zwei Stunden vielleicht einen Kollegen. Und er sagt Ach ja, kenne ich schon. Du musst hier das und das machen. Boah, das hat mich damals drei Tage gekostet, das herauszufinden oder so, wo man so richtig schön per Facepalm dann denkt Oh Mann, da hätte ich mal vorher gefragt.

Das ist aber auch so eine Gratwanderung. Du kannst ja nicht wegen jeder Kleinigkeit den Kollegen fragen. Na weil, dann ist er auch irgendwann genervt. Manchmal, wenn du der Mensch bist, der sich am längsten mit einem Problem beschäftigt hat oder am längsten ein Projekt ist. Es ist einfach unwahrscheinlich, dass die andere weiterhelfen können. Natürlich Google Stack Overflow und alle Quellen benutzen, die man im Internet findet. Das ist das Naheliegendste. Aber hier soll es wirklich darum gehen, den Kollegen zu fragen oder die Kollegen Kolleginnen zu fragen, ob man weiterkommt.

Also ich mache das so, ich probier das erstmal eine halbe Stunde, sag ich mal. Wenn ich an ein Problem komme und wenn ich dann nicht weiterkomme, zwinge ich mich, aufzustehen und jemanden zu fragen oder eben patschert jemanden zu fragen. So um dann einerseits respektvoll mit der Zeit der Kollegen umzugehen, auf der anderen Seite aber auch nicht zu viel Zeit zu verständigen. Und das hat sich bei mir eigentlich als gutes Vorgehen herausgestellt. Aber du fragst nicht so viel, oder?

Nee, hat vielleicht auch ein bisschen mit Persönlichkeit zu tun. Ich versuche lieber selber zu lösen. Keine Ahnung, ist einfach so. Ich kann nicht sagen, warum. Aber ich will den Knoten selber irgendwie aufmachen.

Das hab ich auch, dieses Gefühl. Man hat schon so ein bisschen das Gefühl Ah, wenn ich frage.

Und das ist jetzt vielleicht eine einfache Sache, das geht so ein bisschen in die Berufsehre. Sitzt noch nicht mal irgendwie, aber so ich mache auch nicht gerne welche Superpower Grabbing oder sowas würde ich programmiere, möchte ich irgendwie allein sein. Ich hoffe, das versteht Cat irgendwie, oder ob das jemand nachvollziehen kann.

Ich glaube, das können sehr viele nachvollziehen. Bei mir ist das tendenziell auch so, aber ich hab ne Frustrationstoleranz, die sehr niedrig ist, wenn ich nicht in kurzer Zeit ausreichende Fortschritte mache. Also wenn ich das Gefühl habe, oh, mit jemandem zusammen komme ich schneller voran. Der Zweck heiligt die Mittel sozusagen. Dann setze ich mich auch zu zweit hin. Wenn ich das Gefühl hab, ich komme ja alleine weiter, dann hab ich auch kein Problem, das zu machen.

Aber ich glaube dennoch ab und an um Hilfe zu fragen. Kann einem sehr schnell sehr viel weiterbringen. Zumindest für das Team. Insgesamt ist es besser, als wenn jeder verbissen an seiner eigenen Lösung arbeitet. Die 8 Lektion. Hier geht es um Weiterbildung. Da haben wir ja auch schon in diversesten Episoden drüber gesprochen. Im IT-Sektor wirst du immer weiter lernen müssen. Das Technologie Umfeld ändert sich so schnell. Bestehende Technologien verlieren an Relevanz, neue kommen hinzu, die es noch gar nicht gab, die sehr schnell sehr prominent werden.

Und es wird gefordert, weil man ist ja Technologie Experte, dass man sehr schnell eine Einschätzung liefern kann. Was sind kurzlebige Trends und was sind wirklich längerfristige Entwicklung und was bedeuten diese für das eigene Umfeld? Im Grunde Welche Technologien muss ich lernen und welche kann ich einfach vorbeiziehen lassen? Wie machst du das? Hast du da bestimmte Kanäle, über die du dich informierst, abseits der üblichen wie Heise, Golem usw.?

So um Trends und so weiter mitzubekommen. Tatsächlich einfach im Internet. Heise Golem. Ich habe aber auch diese ich habe mal Subscription eins zu Cloud, Gusi und viele Yumi Kurse. Da schaue ich regelmäßig mal vorbei und gucke, was neue Kurse sind. Speziell ist es aber für die Bereiche Java oder DevOps. Wo ich unterwegs bin, suche ich gezielt danach. Und wenn mir irgendwas interessant erscheint oder mir ein Wort begegnet Technologie, von dem ich noch nicht gehört habe, dann gucke ich mal rein.

Dann suche ich danach explizit. Ich versuche halt immer so ein Level zu erreichen, wo ich verstehe, was das Tool macht. Will mir eins besonders interessant erscheinen, oder? Ich meine, das passt mir sehr gut den Kram. Dann mach ich auch schon mal so ein Tutorial mit, um einfach mitreden zu können, einfach zu wissen, was es ist, was man damit machen kann und so erweitere so nach und nach mein Tool. Schade. Oh dann, je nachdem ich das nächste Mal auf so ein Problem stoße, weiß ich Aha, da gab’s doch mal so ein Tool.

Okay, toss im Grunde diese Sternenkarte schon im Kopf. Und wenn ein neuer Stern auf ploppt, dann guckst du dir den kurz an und kannst ihn dann einordnen.

Ja, das halte ich auch für sehr wichtig. Ich finde, diese längerfristigen Entwicklungen oder diese großen Trends, die erkennt man relativ gut, weil sie auch mehrere Jahre bestehen. Also Cloud wäre z.B. ein Trend, Datenauswertung wäre ein großer Trend. Generell Megatrend ist natürlich Digitalisierung. Wobei tue ich mich schwer, das als Trend zu beschreiben, sondern das ist einfach eine weitere Entwicklungsstufe der Menschheit. Das möchte ich jetzt nicht als Trend verstanden sehen, sondern man kann technologisch einfach Prozesse effizienter abbilden, als man das manuell könnte.

Gerade jetzt mit Heimarbeit wird das offenbar an vielen Stellen, sodass das auf eine weitere Entwicklungsstufe ist. Aber es gibt auch Micro Trends, das sind z.B. Tools im Kobanê, das Umfeld oder im Container Umfeld, die man so ein bisschen im Auge behalten muss. Vielleicht hier als Tipp. Ich weiß nicht. Kennst du jeden Freitag auf dem Heise Newsticker diese Developer News in ein, zwei Sätzen? Du kannst mal auf Heise Slash Developer gehen, da kriegst du nur die für Developer relevanten Artikel angezeigt.

Ist für mich ein Super Life Hack und die ganzen Clickbait Artikel sind dann weg und da gibts es jeden Freitag so ein Digest, wo dann in zwei Sätzen immer dran steht. Das Tool ist und der und der Version entschieden. Das kann jetzt so und so.. Die Software hatte Sicherheitslücken, die wird nicht mehr gepflegt, die ist neu hinzugekommen. So und das sind immer 35 40 Einträge, wo man einfach weiß, was so abgeht. Dieses Symbolbild von dem Artikel ist immer das gleiche.

Daran erkennt man es dann sofort und man hat einfach einen schnellen Überblick. Viele Tools sagen einem auch nichts. Also wenn das sieht so aus dem Automotive Bereich kommt oder irgendein Spezialwerkzeug ist okay, dann hat einem das noch nicht berührt. Aber so hat man so einen Überblick. Und da guck ich dann rein. Wenn jetzt ein Tool schon zum dritten, vierten Mal Erwähnung findet, dann kann ich mir vorstellen Ah, okay, das scheint auf jeden Fall wichtig zu sein, oder?

Da wird häufiger drüber gesprochen, weil die Entwicklung da so rasant ist. Jede Woche eine neue Version ist ja dann schon eindeutig ein guter Tipp. Auf der anderen Seite, also wenn es schon gesagt. Im IT-Bereich wird man immer lernen müssen. Auf der anderen Seite finde ich auch desto mehr Erfahrung man hat, desto weniger Schrecken ein. Diese neuen Technologien, weil man immer wieder feststellt So wirklich, wirklich Neues. Das kommt vor. Aber es ist nicht so häufig, sondern oft erscheinen neue Frameworks oder Libraries.

Und die sind nur ein Aufguss einer bekannten Technologie aus einem anderen Kontext. Und alles war irgendwie schon mal da. Deshalb bin ich dazu übergegangen, mir eher die Konzepte anzuschauen Welches Konzept steckt denn hinter der Blockchain oder einem Paket Manager oder Haskell? Wenn du SQL kannst, da kannst du alle Datenbanken und nicht nur eine bestimmte. Wenn du weißt, wie ein Paket Manager funktioniert, dann kannst mit N.P. Umgehen, mit Maven, mit Neef, geht mit APC, mit Pacman Kapern und wie sie alle heißen.

Und wenn dann jetzt der nächste dazukommt, dann weiß man AOC, dass im Paket Manager DeWitt irgendwie so funktionieren. Ich weiß, was im Paket Manager macht und das ist dann der Achte im Bunde. So ungefähr auch Protokolle. Also ganz früher gab’s den Remote Procedure Call, der ist sogar noch vor meiner Zeit, den kennst du wahrscheinlich noch. Dann kam die Scope Schnittstelle. Heute sind wir bei Rest APIs angekommen. Wer weiß was danach kommt. Hier Proto Buffer oder so.

Bei Frameworks genauso Tools kommen auch andauernd neue hinzu. Na da gibt’s natürlich so mega Tools wie Git. Also Code Warning ist glaube ich schon in den letzten 15 Jahren extrem gepusht worden, wo früher die Leute ihre Dateien irgendwo gesichert haben. Es war ganz grausam und zwischen den einzelnen Ökosystemen, also dort net Java node Python you name it. Wenn irgendwo ein cooles Feature auf ploppt ist meiner Erfahrung wird das sehr oft geklaut.

Sehr gut. Ist ja normal. Ja, ich finde das auch gut. Das ist ja die Schönheit. Ein Open Source. Wenn einer was rausgefunden hat, können alle profitieren. Also wie schließen wir mit dieser Lektion ab oder was ist unser Empfehlung? Ich würde sagen, man muss nicht alles im Detail verstehen, aber man sollte halt die Konzepte verstehen und diese Themen einordnen können. So wie du das eingangs im Prinzip gesagt hast. Du hast diese Sternenkarte und kannst neue Sterne schnell platzieren.

Du versuchst halt zu abstrahieren, soweit wie möglich.

Was ist für dich eine Technologie der letzten Jahre, wo du gedacht hast Okay, das ist ein Megatrend? Mein Gott, da muss ich wirklich viel lernen.

Das ist das Thema Cluster Orchestrierung. Docker Dieses ganze Gebilde. Das war für mich völlig klar, dass ich meine, damals waren mehrere so am Start da visus Marathon, kybernetisch, die waren alle gleich auf. Und interessanterweise, das hab ich auch schon bei einem anderen Podcast erwähnt. Ich hab mich am Anfang komplett gegen diese Docker Technologie gewehrt, als die Kollegen das angesprochen haben. So ein bisschen erklärt hab. Ich fand das halt mega abstrakt. Ich hab das alles gar nicht verstanden wie Leya und wie.

Ich kann da nicht reinschreiben was soll der Scheiß. Nach und nach je mehr die das gemacht und eingeführt haben, umso mehr hab ich verstanden. Mein Gott und dann hat es irgendwann Klick gemacht. Hat euch boah wie geil darunter. War mir klar, das willst du lernen. Ja, da hab ich mich rein gekniet. Das war vor fünf Jahren. Und dieses Universum expandiert wie das richtige Universum, wie es permanent neue Tools erfindet sich neu. Da kommt K3 is leichtgewichtige Scobel net das, was du quasi auf dem Raspberry laufen lassen kannst.

Das explodiert quasi diese Technologie. Und ich liebe es aber auch so dran zu bleiben. Kugel und auch Madhya. Das ist super und find ich klasse. Also diese Technologie war für mich so zu all dem was die letzten Jahre passiert ist mit ein Gamechanger der Wahnsinn.

Nachdem du dich zuerst gewährt hast, wusste ich gar nicht. Hast du gedacht, das ist so kleinteilig?

Und was braucht man mehr als VMS oder genau was bringt da auch so außer jetzt eine riesen Lernkurve? Muss das jetzt sein? Sah ich so halt als Spielerei der Admins an und eigentlich war diese Erfahrung ganz gut, weil wir ich jetzt quasi bei einem Kunden bin. Und du hast meinetwegen so einen alteingesessenen Unix Systemadministrator, der diesem Konzept entsprechend auch nicht aufgeschlossen gegenüber ist. Dann kann ich das super nachvollziehen und weiß dann, wie ich den anderen führen kann. Was so?

Weil du diese Entwicklung selber mitgemacht hast, kannst du sozusagen auf der empathischen Schiene sagen. Ich weiß, die Bedenken hatte ich auch. Aber sieh mal folgendes Ja, da kommen mehrere Sachen zusammen. Mit Docker hattest du so eine erste Abstraktionsebene und Docker alleine bringt ja nicht so viel. Aber in dieser Kombination mit dieser Cluster Technologie und diesem Paradigmenwechsel dieser da wir eine Episode gemacht dieser 12 Faktoren für Cloud Native Apps kannst du ja Anwendungen komplett anders bauen, die dann eben wirklich weltweit skalieren.

Also du kannst mit den großen Gagfah Unternehmen mithalten, vom technischen Standpunkt aus, wenn du diese Software nach diesen Paradigmen entwickelst und diese Gaffer unternehmen haben die sie ja entwickelt. Das ist nicht nur Technologie, sondern auch so ein Mindset plus auch diese Cloud. Denke da kommt alles zusammen. Und das ist eine größere Blase oder ein eigenes Universum, was man nicht so isoliert betrachten kann. Und für dich? Du hast ja mal gesagt, dass du auch früher viel IT Administration gemacht hast.

Also Netzwerk Administration, Linux Administration nehme ich mal an..

Die SEMA Administration oder so Backoffice wirklich, oder?

Ich war Third Level Support einmal und zum zweiten haben wir mit einem anderen Kollegen via Mail und Unix Systeme. Administriert mit send Mail. Ja, das waren noch Zeiten. Okay, da war noch nichts Container visiert. Äh, nicht so wirklich.

Ich kann mich genau erinnern, wo der Kollege ankam mit 20 Disketten und Material. Guck mal, Linux hier, Ledoux da. Das war also damals das Linux System. Putzer und Linux kam gerade erst auf und VM, wer will ich nie faxen? Wir sagte hier Guck mal die Virtualisierung von VM. Wer und wie ich da Disketten reingeschoben hab und damit rumgespielt hab. Und da waren wir auch. Glaube, da könnte was draus werden und diese war so Vollbild geworden ist.

Das stimmt. Also dieses Feld wandelt sich weiter und wie im Universum. Es gibt schnelle Sterne, es gibt langsame Sterne, große Sonnen, die nicht mehr weggehen. Und das kommt in der IT auf jeden Fall mit. Man muss sich weiterbilden in allen 40 Jahren oder in all der Zeit. Dann die neunte Lektion. Ich weiß nicht, ob es schmerzhaft ist oder lustig. Test Griffen Die Welt abmahnt ist ein Mythos, heißt die Lektion. Und was ich damit meine ist Testserver Development, dass man zuerst die Tests schreibt und dann anhand der bestehenden Test da rein die Funktion implementiert.

Das hab ich schon so oft gehört. Bei Kunden und in der Theorie macht das auch Sinn, dass man sich zunächst über alle Grenzfälle einer Anwendung Gedanken macht und das Verhalten genau bestimmt. Und wie soll es denn sein? Wie soll sie sich verhalten, dass man anschließend alle diese Annahmen in Unit oder Integrations Test niederschreibt und dann im Prinzip die Komponente selbst entwickelt und nur noch die Komponente so minimal entwickeln muss, dass alle Tests grün sind, also alle Tests erfolgreich durchlaufen werden.

Und dann hat man sozusagen die minimale Lösung, die alle Tests erfüllt. Das habe ich in der Praxis noch bei keinem Projekt gesehen, wo das wirklich funktioniert hat. Ich freue mich schon über die Zuschriften.

Gerne melden, wenn es bei euch in der Firma funktioniert oder wenn ihr ein Projekt kennt, wo es funktioniert hat. Aber ich habe es einfach noch nicht erlebt. Und ich glaube, das Problem besteht darin, dass die Anforderungen für ein neues Feature oder für eine neue Anwendung oft nicht so messerscharf spezifiziert werden können, dass sich daraus Tests direkt ableiten können. Ist da deine Erfahrung?

Ja, Test am Anfang hat man immer gemeint. Also ganz ehrlich, ich gehörte auch dazu. Tests machen die Sache nur teurer, weil du ungefähr ein Drittel deiner Zeit damit verbringen musst. Wenn du Test Rival entwickelst. Aber je mehr ich in komplexeren Projekten eingestiegen bin, um so mehr ist mir bewusst geworden, wie wichtig doch Tests sind. Und inzwischen gibt’s ja Tests irgendwie. White Box Testing, Blackbox Testing, Tschiche Test Varianten und jedes für sich macht Sinn.

Ja, je mehr, desto besser. Weil so hältst du deine Software wandelbaren, gewitzte, gewisse Sicherheit da auch Änderungen zu machen. Und du hast einfach keine Chance, manuell irgendetwas zu testen, wenn du in irgendeiner Ecke rumschrauben.

Ich glaube, da spielen mehrere Faktoren eine Rolle. Und zum einen verändert sich Software heute schneller als früher, weil sich die Geschäfts Anforderungen schneller ändern. Man ist gewöhnt. Ah, ich muss die Software nur ändern und dann ist die neue Funktion da drin und das funktioniert sofort. So, das ist bis in die Vorstandsetage hoch Geblubber. Und deshalb ist die Erwartung. Ich kann die Software schnell ändern, dann können wir das abfangen gestiegen. Also die Zeiträume bis hin zur Implementierung sind halt kürzer.

Wenn die Zeiträume kürzer sind, heißt das aber auch Development to Market ist kürzer. Und wenn du jetzt keine Tests hast, dann ist das so, als wenn du in schneller Folge beim Domino Day die Dominosteine aufstellen willst und umgeben bist von anderen Dominostein. Die Gefahr, dass du da irgendetwas anderes um stößt, ist gerade in komplexen Systemen riesig. Das heißt, die meisten Projekte, so kenne ich das, verwenden schon automatisierte Tests, meistens Unit Tests für einzelne Funktions Komponenten, die dann von der CCD Pipeline, also Git Lab, Bruna, Maven Tests usw.

angestoßen werden und Schlüssel Komponenten testen. Die IBAN sieht die richtig aus? Stimmen, die Datums Konvertierungen usw. und sofort. Aber eben nicht alles abdecken. Auch RPI Tests gibt es mehr und mehr, die einfach die Funktionsweise von Schnittstellen testen. Aber niemand hat 100 prozent und im Falle des Falles unter Zeitdruck fallen die Tests halt einfach runter. So, das ist meine Erfahrung und definitiv. Das sieht ja auch erstmal niemand.

Also du hast 100 Funktionen, 99 davon sind getestet, eines ungetestet. Jetzt machst du noch 10 Funktionen, noch 10 Funktionen ohne Tests, sodass nur so graduell wird das immer schlimmer. Aber das ist wie Carius. Erst einmal sieht man es nicht. Und irgendwann wird es dann offenbar. Und ich will nicht sagen, dann ist es zu spät. Aber dann muss man es dann doch behandeln. Ich glaube, ein guter Kompromiss ist hier die Kernfunktion, also kritische Sachen, wenn es um Transaktionen geht von Benutzerdaten, also datenschutzrechtlich relevanten Inhalten oder Zahlungsarten.

Das ist super wichtig, dass man das alles ab testet.

Es gibt dabei in jeder Anwendung auch unkritische Bereiche, da muss man sich ganz so genau nehmen. Unit Tests zumindest Völklein Komponenten halte ich für wichtig. Ja, und auf Front in Tests gibt es mehr und mehr und auch desto länger die Software besteht, desto mehr lohnen sich Tests. Gerade wenn viel verändert werden soll, hast du noch einen Tipp, wie man vielleicht dieses Tests Problem besser lösen kann? Also wie machst du das? Wie teilst du dir die Zeit ein für Tests?

Machst du Tests oder nur wenn es gefordert ist? Oder bestehst du darauf?

Nee, also so rigoros oder stringent bin ich nicht. Wenn ich meine, dass eine Interaktion zwischen Komponenten oder einer Komponente selber für mich in gewissem Komplexitätsgrad übersteigt, wo ich meine Oh, wenn es hier eine Änderung gebe, dann könnte es zu Problemen führen. Oder wäre das schön, wenn die anderen Komponenten das das bastel ich mir so im Kopf zusammen. Und wenn das einen gewissen Sprechrolle übersteigt, dann mach ich die Tests auch nicht für jede Klasse und jede Methode, sondern wirklich da, wo ich der Meinung bin, das könnte schwierig werden.

Später für die Worker oder Helper oder Converter oder sowas. Eben genau die sehr oft aufgerufen werden und die so eine Kernfunktion dann bewerkstelligen. Ja, sehe ich auch so. Haben wir schon einen gleitenden Übergang zur zehnten und letzten Lektion. Und davon können alle die Mitarbeiter und IT-Fachkräfte und Projektleiter ein Liedchen singen. Die zehnte Lektion heißt Alles dauert länger als geplant. Lass dich nicht von willkürlichen Deadlines verrückt machen. Das geht eher in Richtung Entwickler. Alles dauert länger als geplant. Wäre vielleicht die richtige Überschrift hier.

Was ist das Problem? Das Problem ist bei Kreativ Arbeit und nichts anderes ist ja die Erstellung von Programmcode. Im Grunde genommen ist ja nicht so, dass man da Mathematik rechnet, sondern eher kreativ sich eine Lösung überlegt und die dann runter codiert oder eine Formsprache bringt. Bei kreativer Arbeit ist es schwierig eine realistische Zeit Abschätzung abzugeben, gerade wenn die Anforderungen nicht klar sind. Zudem gibt es eine Vielzahl von Zeitfresser. Das erlebe ich immer wieder, die niemand auf dem Schirm hat.

Neue Bugs kündigen sich nicht an. Man kriegt einen problematischen Mertz Request von jemand anderem zugewiesen und brauch dafür 2 3 Stunden länger als gedacht. Mitten im Projekt gibt es Bibliothek, Updates oder Sicherheitslücken, die nicht warten können. Diese Bibliothek Updates ziehen Schnittstellen Änderungen nach, die man sofort machen muss. Was sonst funktioniert es nicht mehr? Irgendetwas funktioniert nicht wie beschrieben, kommt auch relativ häufig vor. Ein Kollege muss eingearbeitet werden, ein Kollege fällt aus. Es gibt viele Meetings.

Die Firma hat eine Restrukturierungen. Es wird kommuniziert, was jetzt alles restrukturiert wird und so weiter und so fort.

Und das taucht in keiner Zeit Abschätzung auf. Also ich habe noch bei keiner Sheets Runde gehört. Ja, also eigentlich würde ich sagen, ich brauch Tag, aber wenn wir restrukturiert werden unterwegs sollte ich vielleicht mal 2 Tage einplanen, weil beweiß. Dann bin ich ein Tag mit Meetings zugeschüttet oder so. Ich hatte jetzt letztens eine das hat mich nicht selber betroffen, aber eine Mitarbeiterin, die für ein Promo Video der Firma einen Tag quasi zur Verfügung stehen sollte. So was wird natürlich auch vorher nicht abgeschätzt.

Also was bedeutet das? Es dauert immer länger als du denkst. Sogar wenn du weißt, dass es länger dauert als du denkst. Wie gehst du damit um? Weil da wird ja manchmal schon relativ starker Druck gemacht. Extrem entspannt.

Also da drüber bin ich echt hinaus, um mir Druck machen zu lassen von Projektmanagerin oder Product Owner. Bei den Schätzungen gehe ich so vor, dass ich so eine Excel Liste mache und wir die jeweiligen Features Zeile für Zeile aufschreibe. Und dann mach ich eine Abschätzung für den Best Case, eine Abschätzung für den Worst Case dmit dort den Schnitt und addiere darauf nochmal 30 prozent für Unvorhergesehenes. So und so eine Schätzung gebe ich dann ab. Und wenn es dann länger dauert?

Ich versuche dann halt immer so ein bisschen zu dokumentieren, wenn was dazwischen kommt, was nicht auf dem Schirm war. Einfach um nachher, wenn einer fragt bis eine Liste raus und kann sagen Ja, das und jenes, welches ich habe keine Information bekommen nicht gebraucht habe oder der Kollege Z. Als Ansprechpartner war drei Wochen krank, ohne Vertreter, Regelung und und und, um einfach so ein bisschen sicher zu sein. Ansonsten kann ich es sagen. Wenn es dann noch länger dauert, dann ist es halt so.

Also du hast dieses Lass dich nicht von willkürlichen Deadlines verrückt machen völlig verinnerlicht.

War das bei dir immer so oder ist das ein Prozess?

Nein. Prozess. Prozess beim ersten Mal oh citta bibber und um Gottes Willen. Und die Welt geht unter. So und dann machst du und tust du. Dann bist am Wochenende da und nachts bis drei. Und hin und her wird’s aber trotzdem später, weil irgendwas passiert ist, wo du keinen Einfluss drauf hast oder Bergsee. So schlimm war das jetzt doch nicht, weil der der Druck gemacht hat. Der war dann auch entspannt. So wird das ein paarmal passiert da ja auch.

Was will man machen? Also zuckte du noch mit den ATL dieses Druck machen?

Ich sag mal ein bisschen Druck machen, okay. Aber dieses starke Druck machen? Es ist ja nicht so, dass du am Fließband stehst und jeden Tag in acht Stunden acht Autos Ponti hast. Und wenn du da zehn Stunden stehst, montiert du zehn Autos. Du denkst ja nicht schneller, weil du unter Druck geraten bist. Also. Ich weiß nicht. Bei mir funktioniert das nicht. Ich werde dann eher geblockt oder so. Wenn ich weiß Oh du Dexia, die schneller.

Ja, das ist ja sozusagen die Denke, da trödelt jemand, die mach ich jetzt.

Beine Nee, das kommt so aus der Industrialisierung und den setze ich unter Druck.

Und dann konzentriert er sich besser oder bleibt eher an der Sache dran. Das funktioniert bei Creativ Arbeit ja nicht. Also wenn ich einem Künstler sage mach schneller! Dann wirft er den Farbeimer gegen die Staffelei und dann kann er auch nicht sagen Ich bin fertig. Also vielleicht kann er das sagen, aber dann ist das Kunstwerk nicht gut. Und das sieht man leider auch mancher Software an, dass sie unter großem Zeitdruck entstanden ist.

Ich habe aber auch das Gefühl, Entwickler schätzen tendenziell zu positiv. Ich weiß nicht wieder.

Deine Erfahrung ist das kann ich so nicht sagen. Weiß ich das? Ich würde weder sagen positiv noch mal ist es klar mehr positiv, mal negativ heckt und ein bisschen damit zusammen, wie viel erfahrener oder unerfahrener Kollegen du im Team hast. Also eine generelle Tendenz kann ich glaube ich nicht sehen.

Ich hatte schon mal den Fall, dass Projektmanager bei Schätzungen gedrängt haben und sagen Nee, das ist zuviel, das muss schneller gehen und selber dann die Schätzung visieren oder beeinflussen.

Das auf jeden Fall halte ich für sehr gefährlich, es sei denn, der Projektmanager sagt vorher ganz offen Du, wir müssen unter diesem und jenem Level bleiben, um das Projekt genehmigt zu bekommen. Wenn das dann einmal läuft, dann wird es keiner mehr stoppen, wenn es länger dauert. Das hatte ich auch schon. Dass das so offen kommuniziert wurde, ist natürlich auch grenzwertig, aber das passiert manchmal. Aber klar, wenn das Projekt einmal läuft und man hat es schon 60 Prozent geschafft, dann wird es vielleicht der oberen Etage schwerer fallen zu sagen Na, wir stoppen das jetzt, weil das Budgets aufgebraucht, lass die letzten 20 Prozent weg.

Macht jetzt nochmal 20 Prozent und dann ist out.

Ich habe einmal erlebt, wo ein Produkt oder ein Kollegen so gedrängt hat, wird er das jetzt so so schätzt oder nicht fertig wird, dann gibt’s als mit dem Bonus nix.

Also wenn er es schätzt oder wenn es nicht fertig bekommt in der Zeit nicht oder so grob geschätzt.

Und dann sagte er Ja, es dauert halt so lange oder sagt sie Nee, auf keinen Fall. Dann gibt es wieder Modus. Nix gibt’s alles.

Ich hoffe, sie meint es nicht ernst. Doch ich war dabei.

Wenn’s nur auf die Schätzung ankommt, dann wird immer alles ganz schnell geschätzt.

Echt so, die Softwareentwicklung? Ja, manchmal ist es schon verrückt, meiner Erfahrung nach. Man kann sehr zuverlässige Schätzungen abgeben. Allerdings nur für sehr kleine Projekte oder sehr kleine abgegrenzte Probleme. Wenn die eingesetzten Werkzeuge und der Anwendungsfall sehr genau bekannt ist und man sicher gehen kann, dass man nicht von extern gestört wird. Das sind dann aber kleine Projekte und da weiß ich nicht. Die finden in den Firmen nicht so häufig statt. Meiner Erfahrung nach Bara sind dann nicht so wichtige Themen.

Ist denn in deiner Erfahrung mal ein Projekt vor der veranschlagten Zeit fertig geworden?

Ja doch, auf jeden Fall auch schon erlebt.

Ist zwar extrem selten gewesen, aber da gibt’s definitiv bei SKL bei Tamir einfallende, wo wir supergut im Zeitplan lagen. Oh, das war mega. Aber ansonsten. Ich muss mal überlegen. Na gut, auf der anderen Seite wir sind eine Consulting Firma und wir werden meistens angerufen, wenn in Excel schon eine rote Zelle erscheint.

Ja also diese Feuerwehr Geschichten gibt’s natürlich auch der Druck entsprechend groß ist.

Ja, das waren die 10 Lektionen. Unglaublich. Ich bin auf die nächsten 40 Jahre gespannt oder?

Ich hoffe nicht. Da mache ich so eine Abschluss Folge zur Verrenkung. Dann was ich gelernt habe, wenn unsere Zuhörer Fragen haben zu der aktuellen Episode oder auch so können Sie uns eine E-Mail an Podcasts Gilbert D.

Senden. Wir freuen uns immer über Bewertungen oder wenn ihr den Podcast abonniert. Empfehlt den Podcast auch an eure Freunde und Kollegen weiter und schaut auf der Skill bei D. Slash Jobs Seite vorbei. Weitere spannende Technologie Artikel findet ihr Weißgerber D im Blog Masa Es war wie immer ein pures Vergnügen mit ihr zu sprechen. Danke Rorys, dann wünsche dir noch einen schönen Abend.

Maurice KnoppSkillbyte Podcast #40: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt haben (Teil 2)
Mehr

Skillbyte Podcast #28: Cloud als Strategie, nicht als Technologie!

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

In diesem Podcast geht es um das Thema: Cloud als Strategie, nicht als Technologie!

// Inhalt //
01:20 – Intro Maurice Kemmann von Cloud-Mates.de
02:22 – Kosten von Cloudlösungen
03:09 – Möglichkeiten der Cloud-Migration
14:18 – Herausforderungen für Kunden bei der Cloud Migration
18:11 – Positive und negative Beispiele für Cloud Strategien aus echten Projekten
23:46 – Keine Angst vor Releases!
25:28 – Die Applikation als Basis für die Strategie / Cloud hat eine Lernkurve
27:29 – Retain und Retire inkl. Beispielen zum Datenschutz
34:26 – Prozesse, Betrieb und Monitoring
41:23 – Ausblick für zukünftige Cloud Strategien

Cloud Mates: https://www.cloud-mates.de/

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Wir haben bei einem Kunden, der auch noch aktuell in der Betreuung ist. Da kamen wir an, und die waren überzeugt Ja. Cloud Das ist das Meine, das wollen wir machen, da wollen wir hin. Aber es ist noch keine Strategie entwickelt worden. Wir sagen ja ganz klar Strategie, da hinzugehen. Ich glaube, da war eher mehr die Technik, das Interessante. Und von daher ist wenig Fokus darauf. Und wie bei allen Projekten, und da kann man jetzt in die allgemeine Projektsteuerung gehen, wenn ich keinen Fokus hab.

Wenn ich mir keine Ziele setze, wenn das eher so schwammig ist. Das geht schief. Herzlich willkommen zu unserer Podcast Episode Nr. 28 Cloud als Strategie, nicht als Technologie abonniert unseren Podcast. Wenn Ihr mehr spannende Themen aus dem Technologie Umfeld hören, möchtet ihr eine höhere Frage habt. Wir freuen uns immer sehr über eure Fragen, schreibt uns eine E-Mail an Podcasts D. Lasst uns eine positive Bewertung da und empfehlen weiter, wenn er euch gefällt. Das ist ganz, ganz wichtig für uns.

Ich freue mich ganz besonders auf meinen Studiogast, der ebenfalls Maurice heißt. Maurice Kemmann von Cloud Mates. Hallo Maurice, hallo schönen Abend.

Ich freue mich sehr auf dieses Gespräch, weil mit ihr habe ich ja wirklich ein Veteran in der Rechenzentrums. Planung, Durchführung im Betrieb heute hier mit ganz, ganz viel Erfahrung.

Ja, das kommt daher in 2000, angefangen mit Rechenzentren und ähnlichem. Uns darüber ja 16 Jahre, 17 Jahre bewegt. Dann halt später auch nochmal. Allerdings dann noch mehr. Also 13 Rechenzentren betreut und dabei so meinen Ausstieg gefunden. Und neuerdings sage ich Rechenzentrum adé zumindest im physischen Sinne und widme mich in den Clouds dieser Welt und vor allen Dingen aber dabei, das ja auch in einem Rechenzentrum betrieben wird.

Das ist ja ganz klar, das Cloud auch Rechenzentrum ist. Nur eben nicht das eigene dennauch.

Es ist kein Henson mehr, und ich muss keine Server mehr bestellen. Ich schreib ein bisschen Kohle und hab dann plötzlich eine VM oder sowas ist schon schon interessante Entwicklung. Ich sage mal generell auch von der ganzen Automatisierung her, ich hätte das gerne früher in meinen eigenen Rechenzentren gehabt. Aber naja, wir waren halt immer etwas kleiner als jetzt eine aways oder eine Microsoft oder Google.

Ich glaube, das gilt für die meisten Rechenzentrums Betreiber. Du hast ja dann direkten Einblick. Wie ist das denn von den Kosten für dich als Betreiber oder auch für die Endkunden, für die ihr ja Anwendungen oder Server gehostet habt, wird zu sagen Das ist überhaupt keine Frage, die Cloud ist immer günstiger, oder muss man da abwägen?

Also wenn man auf die Kosten schaut, da muss man schon sehr differenziert reinschauen. Okay, ich sag mal, wenn ich jetzt sehr weit bin, auf dem Weg in die Cloud zu gehen, so sehr alle Technologien alles, was es nutze, habe ich ein sehr großes Einsparungspotenzial. Aber letzten Endes ist das ja nicht die Welt, in der wir uns bewegen. Außerdem sind es Dadaab. Wir machen alles direkt für die Cloud. Wenn ich ein eigenes Rechenzentrum habe oder irgendwo was in Kolonisation hat, dann sieht die Welt natürlich ein bisschen anders aus.

Da ist nicht alles direkt klar.

Das heißt, eure Kunden sind sowieso so unterwegs, dass sie ein Rechenzentrum haben und neue Services neue Cloud Services nach und nach dazunehmen? Genau.

Also eigentlich sind es tatsächlich Migrations Kunden, die schon Vorteile sehen, für sich Benefiz herausgearbeitet haben, aber eigentlich nicht so genau wissen Wo fangen wir jetzt an, weil einfach das Thema auch sehr vielschichtig ist. Ich sage mal Ich persönlich bin jetzt mehr in der Arbeitswelt. Aber A-WM bietet 170, 180 Services an noch nicht aufsetzen kann. Da den überblick zu behalten, ist nicht so ganz einfach. Und den idealen Weg zu finden, ist auch nicht einfach ein Prozess.

Und das ist so der Bereich, in dem wir uns dann tummeln, wo wir dann reinkommen, wo wir unterstützen, unterstützen und diese Migration letztendlich mit den Kunden angehen. Was uns auch so ein bisschen zu dem Thema des heutigen Gesprächs führt. Weil wir ja gesagt haben, es ist eine Strategie weniger Technologie. Es ist natürlich auch eine Technologie.

Aber für den Kunden, den Endkunden in die Cloud gehen will, ist es eher eine strategische Entscheidung, weil es eben nicht nur um Outsourcing von Server Hardware geht, sondern viel mehr durch dieses Service Netzwerk, was ja um die einzelnen Cloud Komponenten entsteht.

Genau den größten Fehler, den man eigentlich machen kann, ist, dass man versucht ein klassisches Rechenzentrum eins zu eins abzubilden. Das ist die klassische Lyft. Entschlüpft, sagt man da neudeutsch zu. Und ja, das heißt, ich habe da eine VM, und ich habe Server. Bildet das genau so mit dem gleichen Aspekts auch wieder in der Cloud ab, und da muss man sagen Oder komme ich wieder zurück auf die Kosten? Das ist in aller Regel teurer, weil ich ja in der Cloud so Vorteile habe wie Pay as you go.

Also ich zahl das, was ich nutze. Aber im Rechenzentrum hab ich ja immer so eine 24 Stunden Nutzung auf die ganzen Specks nicht reserviert. Habe möchte das eins zu eins in der Cloud mache. Dann wird es einfach teurer, weil dafür, das ist nicht der Sinn hinter den klassischen klar.

Ja, das hab ich bei der Anwendungsentwicklung auch schon bemerkt, dass man im Grunde, das sie dieses Paradigma etwas verschiebt. Früher hat man gesagt Okay, die Datenbank ist eh da. Da kann man Abfragen machen ohne Ende. Und jetzt ist es schon so, dass man überlegt Wie mache ich deine Such Query? Oder schwanke ich sozusagen fünf Sekunden an Daten, macht dann einen Badge und schiebt das einmal durch? Statt 5000 Query mache ich dann eine. Anwendungen, die viel Datendurchsatz haben, kann es schon ein Unterschied machen für den Betrieb?

Genau. Es ist halt ein leichtes Umdenken. Es ist ja nicht so, dass ein technisch versierter Entwickler oder Administrator das alles komplett neue Geschichten sind. Aber wenn ich mich halt auch auf klauer stürze, dann hab ich einfach gewisse Möglichkeiten und Optimierungsmöglichkeiten. Und die nutzt man aber nicht nur bei Datenbanken. Das geht ja wirklich in alle Bereiche.

Also nochmal als Cloud maatz hilft Kunden und begleitet Kunden auch Henson bei dem Weg aus dem eigenen Rechenzentrum in die Cloud. Plus der Erstellung der Strategie. Was für Cloud Services machen denn in deinem Rechenzentrums so anwendungs zu Sinn? Und wie kannst du die optimal einsetzen? Genau.

Wir haben so eine Framework. Man kann es doch einfach ein Beratungs Ansatz nennen, wie wir halt vorgehen. Wir schauen uns natürlich erst mal an Was haben wir da für den Kunden? Was hat er an T. Das brechen wir halt runter. In aller Regel durchaus auf Applikationen, um zu schauen Okay. Was setzt dir ein? Wir versuchen, den Applications Runa ausfindig zu machen. Also hat die Hoheit über die Applikation Wer kann uns am meisten erzählen, um erst einmal zu sehen Okay, wie wird sie genutzt?

Welche Lernprozesse werden unterstützt? überhAUPT Welche Prozesse im Unternehmen werden durch die Software unterstützt? Welche Risiken existieren auch, wenn ich eine Applikation überfuhr? Als Beispiel, wenn ich ein Bin ich sehr Vertriebsleute ich bin, dann habe ich häufig ein crm-system, das sehr wichtig ist für meinen ganzen Vertrieb. Da sind alle Informationen drin, und hier hätte man sicherlich ein hohes Risiko bei einer Migration, wenn es denn schief gehen würde. Und das wird halt entsprechend beurteilt, wird festgehalten und auf Grund des Consulting im Vorfeld haben, wird dann letztendlich ein Plan entwickelt, wie man da vorgehen kann.

Das heißt, die Herausforderungen für eure Kunden sind an dieser Stelle ganz klar. Kritische Anwendungen dürfen während der Migration nicht ausfallen.

Genau, oder es muss ein sehr geringer Ausfall sein, also ein Gering. Man hat immer einen Ausfall, also spätestens dann, wenn ich halt umschalten von der bestehenden Applikation auf die neue Halts in der Cloud Umgebung. Aber sowas kann man natürlich gering halten. Man macht es entweder nachts oder am Wochenende, sodass man auch noch immer ein bisschen Zeit habe. Das Schöne ist aber dadurch, dass eine Migration ist, können wir den Hogg, eigentlich den Plouffe of Konzept, parallel zur bestehenden Umgebung aufbauen, und somit lässt sich das eigentlich ausgiebig testen.

Und wenn die Kunden dann einmal die Anwendungen in die Cloud verlagert haben, dann kann man ja mehrere Umgebungen hochfahren. Und ab dann sind die Deployment relativ einfach nachvollziehbar oder durchführbar. Ohne Ausfall?

Genau. Wir versuchen natürlich immer So sehen, ja können wir Sie hier wirklich automatisch wieder wie Staaten? Welche Abhängigkeiten sind dahinter? Das ist immer Teil der Planung und der Analyse. Wir haben letztendlich vom Ansatz her es wurde immer Six Artz genannt, also die 6, wonach so ein bisschen wie die Applikationen und Hosts eingeteilt werden. Das eine ist ein Request, dass es diesen Lyft in Shift Ich mache erst mal eine Eins zu eins übertragung. Das machen wir nicht besonders gerne, weil der Quick Win eigentlich nicht sehr hoch ist.

Also im Zweifelsfall habe ich vielleicht sogar noch höhere Kosten. Macht dann Sinn, wenn man einer eine Applikation oder eine Architektur erst mal kennenlernen muss und viele andere Systeme aber durchaus schon umziehen können, um dann alles umzuziehen. Da macht man halt ein Haus, aber es ist nicht der optimale Fall. Dann gibt es das, die Plattform an der Stelle, das sehr häufig bei Datenbanken stattfindet. Wir hatten eben schon mal das Thema Datenbank. Ich habe zum Beispiel ich sage jetzt mal meine Microsoft Scuol Datenbank, ich Aufsätze.

Ich musste mir da weiß nicht Enterprise Lizenz holen, aus welchen Gründen auch immer. Sie ist aber wenig belastet. Das ist ein Paradebeispiel dafür, dass ich dann zum Beispiel erst auf Aerts Datenbank Service umstellte, wo ich halt nicht mehr eine VM Map oder physischen Server, auf der die Datenbank mit der kompletten Lizenz, sondern ich hatte eine Datenbank Service und zahle per Transaktion. Und leider ist es häufig so, dass unsere Kunden nicht wissen, wieviel Transaktionen pro Sekunde oder so machen.

Da finden wir im Zweifelsfall für sie raus. Das ist dann in der Datenbank. Scuol wird über Scuol gemanagt, also steht auch da drin. Hat man eine Datenbank admin vor Ort, dann weiß er das. Und dann kann man schon mal entscheiden Ist das zum Beispiel eine Möglichkeit der Umstellung? Dafür gibts dann auch Migrations Tools. Sowas lässt sich sehr sehr gut machen und das ist etwas, was ich so als Cloud verstehe. Pay as you go. Ich zahl so viele Transaktionen wie ich habe.

Aber muss man natürlich schauen als Softwareentwickler. Wenn man dorthin geht, dann achtet man natürlich drauf, dass eine eine Suche oder das Abrufen von Daten einfach nicht so kostenintensiv ist.

Sprich Ich hab jetzt nicht so viele verschiedene Abfragen dahinter, um zu einem Ergebnis zu kommen oder das man crasht, das man wiederkehrende Abfragen crasht für einen gewissen Zeitraum das Genner mit zum Kiewel just z.B.. Und nicht jedes Mal die Datenbank abfragt. Genau das war schon bei hochbelasteten Datenbanken, vor allen Dingen bei größeren Firmen ist das auf jeden Fall zu empfehlen.

Ganz klar Per Datenbank ist ein eigener Themenkomplex Wahl. Es gibt ja, du hast es angesprochen Dorsts in einem Rechenzentrum hast du den Server mit der installierten Datenbank plus Lizenz vor oder hältst du vor meinetwegen auch mehrere Datenbanken. Und in der Cloud hast du jetzt unterschiedliche Möglichkeiten. Entweder du fährst da auf einer VM diese Software hoch. Lift ein Schiff, das ist sozusagen die einfachste Form. Aber da profitiert man am wenigsten von. Oder man nimmt so ein Scuol Service, der ja von den Cloud Providern schon angeboten wird.

Also wo man im Grunde eine global, also weltweit verteilte Datenbank erhält, die dann Scuol API davor hat, die man einfach ansprechen kann. Und man bezahlt pro Transaktion sehr, sehr wenig und die Volumina sind auch sehr groß. Das muss man dann gucken, wie sich das lohnt oder wie die Kosten sind. Und dann hast du nichts mehr zu tun mit Software Maintenance, also Updates installieren, das Betriebssystem aktuell zu halten, die Datenbank Software aktuell zu halten, mehr Speicherplatz irgendwann hinzuzufügen, weil die Datenbank wächst.

Einfach Es kostet zwar mehr Geld, aber man muss. Es muss keiner mehr rausfahren, um die Festplatte zu vergrößern, die die Datenbank zu stoppen, die Festplatte vergrößern, die Datenbank wieder zu starten und auf der vergrößerten Festplatte die Anwendung fortführen zu lassen, sondern das geht alles dynamisch. Man bezahlt einfach nur für den genutzten Speicherplatz für die Transaktionen und muss sich im Grunde nicht um die Wartung der Datenbank kümmern.

Genau das fällt tatsächlich fast komplett weg. Wir bieten hier über das reine Umstellen natürlich auch noch so Managed Services an, auch Datenbank Services reinfallen. Das ist immer dann die Frage, ob der Kunde einen eigenen DBA hat. Brauchen Sie das nicht zu machen? Der kann diese Aufgaben locker übernehmen. Aber die Erfahrung zeigt, dass selbst in relativ großen Firmen ist das Datenbanken Know how relativ gering, weil es vorher auch getanzt war. Oder man hat halt einfach gesagt Naja, gut, was sollen wir da schon großartig machen, sodass Parameter wie hydrazin oder sowas nicht beobachtet werden.

Wenn man das haben möchte, dann können wir das auch für Kunden übernehmen, das man einfach sagen kann. Bada. So stelle ich fest, ob die Software auch optimal arbeitet. Das ist zwar schön, dass ich eine Datenbank habe, die fast beliebig skaliert. Aber es entbindet natürlich nicht davon, vernünftige Software darauf zu entwickeln. Und absolut, da können wir natürlich noch unterstützen, was von den 6er gesprochen.

Ich glaube, drei hattest du schon genannt, aber es war das letzte Mal. Die Plattform hat diese Transformation in eine neue Plattform. Es gibt jetzt das Repertoire. Das ist letztendlich auch ein anderes lizenzmodell, also dass man einfach sagt, das passt auch zur Plattform. Bei einer Datenbank, welche Datenbank Lizenz vorhatte und jetzt offen, da hat man Service wie vielleicht auch das lizenzmodell. Letztendlich ja. Ich hab nämlich mit Lizenzen gar nichts mehr am Hut und muss nun nicht mehr alle paar Jahre erneuern und Support und sonstiges dazu holen.

Hat natürlich auch mal leichte Architektur änderungen, aber das betrachtet man halt auch nochmal. Das kann durchaus auch sein, dass es einfach das typische Beispiel auch immer mal wieder die originale Datenbank Oracle um ein anderes Produkt zu nennen. Meine lizensierung fällt auf, weil die auf Jahres basieren und jetzt die ich vor der Entscheidung Soll ich etwas Neues kaufen oder ändert? Irgendwie hat man diese Möglichkeiten natürlich auch in der Cloud. Das gleiche Geld mit fast allen Elitz oder wichtigen Dezenz Anbietern muss man aber gegebenenfalls einfach überprüfen.

Also es funktioniert nicht mit allem. Das ist nicht so die Lösung für alles. Aber da helfen wir natürlich.

Jetzt haben wir viel über Datenbanken gesprochen. Wer sind denn eure Kunden und was haben die für Herausforderungen? Gibt es da so? Muss da, wo du sagen kannst Ja, das ist ein schwerer Brocken für die meisten Kunden? Oder ist es hochgradig individuell?

Sowohl als auch individuell. Natürlich, weil alle Kunden haben unterschiedliche Schwerpunkte. Auch was risiko-management und so weiter angeht. Aber letztendlich Datenbank ist immer cih für die Anwendung. Aber die größte Herausforderung sind natürlich tatsächlich Anwendungen, die so gar nicht in die Cloud passen. Die, sagen wir mal, eher altbacken sind erp-systeme, die teilweise. Ich übertreibe mal gern ein bisschen noch mit dos Lückenfüller rüberkommen. Du hast es natürlich teilweise schwierig.

An der Stelle gibt es das Image ist auf aways gar nicht. Ich muss ehrlich sagen Prinzipiell würden wir das wahrscheinlich hinkriegen. Ich weiß es aber tatsächlich.

Auch für die an diese Kunden ist gedacht, wie das mit Security aussieht. Das mag ich mir gar nicht auszumalen.

Es wird auch weniger an der Stelle. Aber das sind so diese klassischen Kunden für ein Refektorium, das heißt neue Architektur. Ich such mir eine neue Plattform des software-plattform, denn, würde man sagen Pass auf, entweder man sucht. Ein Produkt am Markt, das existent ist, was unseren und seinen Belangen da hinreichendes, ist auch für die Cloud. Ich sag mal, aktuellere Produkte werden fast alle in Richtung Cloud entwickelt. Muss man ja nicht sagen, oder? Aber das ist natürlich dann der Idealfall.

Ich habe eine selbst entwickelte Software und suche mir halt eine Softwareschmiede meines Vertrauens, die mir das direkt laut Radi umsetzen. Das ist natürlich dann der höchste Benefit. Es gibt sehr, sehr gute Programmierer, schmieden dazu. Aber das hängt natürlich immer Kosten-Nutzen-Verhältnis in West. Also ich investiere natürlich dann wieder für die nächsten Jahre. Das muss dann gerade passen. Aber Factoring Ansatz ist der natürlich, der den höchsten Nutzwert eigentlich bringt, weil ich eine veraltete Architektur in aller Regel habe und die in eine komplett neue überführen und dort natürlich aus allen Vorteilen dann letztendlich profitieren kann.

Teichert Jetzt gedacht, das ist fast bei, wenn man hoffnungslos veraltete Software hat. Wie? Man muss eine Service Lösung nehmen, also eine Software as a Service Lösung, und dann irgendwie schauen, dass man die Daten da rein importiert bekommt, weil diesen Rückstand sehr schwer, dann aufzuholen.

Da geht es dann los mit der individuellen Betrachtung. Das kann sehr unterschiedlich sein. Auch ich sage mal eben Banken Umfeld trifft man häufig noch auf Termühlen Emulation im Frontend, komischerweise aber dann in einem Fensterchen mittlerweile drin sind und und, und, und und. Im Backend ist zwar auch häufig auf mainframe basieren, aber dennoch schon neuere Architektur zu finden. Das hat dann aber ich weiß nicht irgendwelche Cross Kompatibilität, die gehalten werden müssen. Da bin ich da manchmal auch überfragt.

Bankkunden Wer noch nicht überführt, muss ich auch der Ehrlichkeit sagen. Ich kenne halt nur, weil wir früher viel mit Banken Kunden zu tun hatten. Da gilt es dann zu überlegen Wie geht man vor? Aber hier mehr schriftlich vorgehen, denn so eine Entwicklung ist ja auch ein Prozess. Die sind dann eher ein, zwei Jahre, je nach Größe und Inhalt der Software. Das muss man sich halt wirklich genau angucken. Aber der Nutzwert ist tatsächlich der aus meiner Sicht höchste und ist natürlich ein optimaler Weg, den zu gehen, weil man es dann state of the art anfangen.

Das halte ich so raus. Eure Kunden sind Mittelständler, aber auch Großunternehmen in allen Lagen der Technik. So kann sein, dass sie 20 Jahre alte Technik haben. Es kann sein, dass sie relativ modern unterwegs sind.

Genau das ist wirklich ganz breitgefächert. Macht eigentlich auch den Spaß aus, weil man natürlich alles nur Nullen und Einsen, aber immer neu zusammengesetzt und dadurch natürlich interessanter, immer neue Herausforderungen. Die Kunst ist es natürlich, aus Kundensicht den besten Weg zu finden, was natürlich auch immer Kostenfaktor und so weiter.

Hast du ein Beispiel für ein Projekt, was du einfach mal ohne den kundennamen zu nennen, was besonders gut funktioniert hat? Oder vielleicht doch etwas, was nicht besonders gut funktioniert hat? Das ist ja auch immer ganz interessant für unsere Zuhörer, das man zeigt ok. Das hat überhaupt nicht geklappt. Wenn ihr in so einer Situation seid, überlegt nochmal, ob das richtige Weg ist und holt euch vorher Hilfe. Und ja, natürlich auch positive Beispiele, dass man sagt Okay, in deren Constellation lohnt sich das auf jeden Fall.

Und man hat sehr, sehr wenig Widerstände zu überwinden, vielleicht etwas Positives und ein negatives Beispiel.

Ich fange mal mit einem negativen an, weil sich daraus durchaus positive Ansätze zumindest definieren lassen. Wir haben bei einem Kunden, der auch noch aktuell in der Betreuung ist. Da kamen wir an und waren überzeugt Ja, Cloud, das ist das Meine, das wollen wir machen, das wollen wir hin. Aber es ist noch keine Strategie entwickelt worden. Wir sagen ja ganz klar Strategie, da hinzugehen. Ich glaube, da war eher mehr die Technik, das Interessante.

Und von daher ist wenig Fokus darauf. Und wie bei allen Projekten, und da kann man jetzt in die allgemeine Projektsteuerung gehen, wenn ich keinen Fokus hab, wenn ich mir keine Ziele setze. Wenn das eher so schwammig ist. Das geht schief, und hier sind wir aber auch uns an, weil wir am Anfang dachten Gut, ja, weil man vorgehen. Man will jetzt erst mal was kennenlernen, und dann gehts weiter. Aber vielleicht auch Coruna bedingt.

Ist das jetzt so ein bisschen aus dem Fokus geraten und ist jetzt so eine never ending story? Hier wird man nochmal neuen Anlauf brauchen, einen Plan aufstellen und einfach mal so sagen Okay, wie ist das? Fangen wir doch mal mit Applikationen an. Gerade wenn ich es kennenlernen will. Wie funktioniert? Klar? Welche Möglichkeiten sind da Applikationen mit wenig Risiko dabei, die ich parallel gut aufziehen kann? Und dann kann die IT-Abteilung des Kunden so wie wir. Man kann sich annähern, findet den Weg und findet halt auch die Rezepte, wie wir die Umsetzung machen wollen, die Migrationen machen wollen, sondern das ist so der negative Aspekt, der aber eigentlich wieder ganz klar vor Augen führt.

Bitte bleib bei diesen Frameworks, wie wir sie auch vorgeben.

Also Fokus und Fokus auf ein Projekt haben. Und auch ich sag mal ehrgeizige Ziele sich vornehmen und dann noch bei der Stange bleiben. Das ist ein ganz wichtiges Voraussetzung für ein erfolgreiches Projekt.

Definitiv. Da entgegen haben wir einen anderen Kunden. Die beiden kann man ganz gut vergleichen, weil erste Berührungspunkte mit der Cloud. Mittelständische Unternehmen, in Deutschland ansässig und hier? Um? Ja, anfangs um die Lösung für Back up Szenarien notfalls Szenarien unternehmen. Und die hatte man erstmal ein klares Ziel definiert, hat gesagt Okay, die anderen Dinge, die finden wir sexy. Aber mit dem wollen wir uns jetzt noch nicht beschäftigen. Wir haben jetzt ein Primärziel, und das haben wir dann umgesetzt.

Auch sehr, sehr schnell. Tatsächlich konnten wir denn den Plouffe auf Konzert machen. Da haben wir ihn dann innerhalb weniger Tage direkt in eine produktive Umgebung überführt und konnten eigentlich so den Kunden sofort zufriedenstellen. Und er sagt Ja, und so wollen wir weiter vorgehen. Wir möchten jetzt gerne, dass das Ablösen, wir neue Dinge identifiziert. Und das wandert jetzt auch in die Cloud. Und da hat einer meines Erachtens schon sehr viel Projekt Erfahrung einfach gehabt, sodass er eigentlich unsere Dinge direkt mit aufgenommen hat und auch so vorgeht.

Und für uns ist das Interessante Ja, wir wachsen mit dem Kunden. Und wir verstehen ihn immer mehr und können auch die Applikationen, die dahinter sind, besser verstehen und somit auch vielleicht Risiken aus unserer Sicht einschätzen. Es gibt auch immer Applikationen. Wo ich den Kunden empfehle, würde ich nicht machen. Also, wenn ich zum Beispiel nicht bereit, denn eine alte Software abzulösen, und wenn ich schlechte Bandbreiten habe, sind zig Faktoren erreichbar. Und noch weiß nicht eine funktionierende Abteilung.

Alles ist gut. Dann würde ich auch sagen Passt auf, dass es. Dieses partielle Bausteinen würde ich jetzt nicht überführen, zumindest jetzt noch nicht.

Never change running system.

Mehr ja. Erst wenn die Zeit gekommen ist, wenn man sagt Ja, ich will die Software jetzt ablösen, dann würde man natürlich wieder auf die neuen Technologien. Aber solange das System Apple Running ist und es keine weiteren Quicken oder Winds gibt, also Kosteneinsparung, Effizienzsteigerungen, was auch immer, dann muss man natürlich auch davon abraten. Und hier war es ganz einfach ein Kunde Mittelschiff, sehr bodenständig. Ich nenne sie immer Schnittchen, Kunden, weil da gibt’s mal Mittagessen, gibt’s immer Schnittchen drauf, und das meine ich auch gar nicht negativ.

Ich finde das. Die wissen genau, was sie wollen und sehen wollen und dass das sehr positiv verlaufen. Muss man sagen, da sagst du was.

Ich hab auch das Gefühl, dass beim mittelständischen Unternehmen der Fokus sehr hoch ist oder tendenziell höher ist, weil ich weiß nicht, weil die einfach mehr darauf angewiesen sind, dass ihre Kerne Prozesse funktionieren müssen, damit sie Geld verdienen und sie nicht so viel eher weiche Ziele haben, sondern meistens ist es ja ein Unternehmen, das genau um einen Zweck gebaut ist. Und alles, was nicht diesem Zweck dient, wird irgendwie rausgeschmissen. Und von daher ist immer sehr schnell klar, in welche Richtung es gehen muss.

Genau so kann ich so unterschreiben, wobei man immer noch eine Sache beobachten muss. Das ist die IT-Abteilung. Das ist immer schön, wenn der Chef oder so sagt Ja, das hört sich gut an, das wollen wir machen. Aber es ist ja eine ganze, ist eine Strategie. Und Strategie muss getragen werden von den Leuten, die sie hinterher auch umsetzen. Das ist dann in aller Regel ja die Abteilung, und die müssen natürlich auch mitziehen. Und wenn man hier neugierig ist, wenn man auch Spaß hat an Technik?

Adam begeistert auch klar und einfach die Automatisierung Unmöglichkeiten. Ich habe die Reporting Monitor. Ich habe so viele Daten nicht auswerten kann, wenn ich mir denn vernünftige kpis schaffe. Also, ich habe wirklich jede Menge Benefiz, aber das macht doch wirklich Spaß.

Das ist auch so eine, merke ich manchmal. Es gibt zum manche Hürden bei meinen Z. Gerade was Fury ließ es angeht, dass man sagt Ja, dann fährst du die Umgebung zweimal hoch und schalte ist um. Da brauchst du keine Angst mehr, families zu haben, und wenn das nicht klappt, nimmst du das alte Image. Das ist ne abschottet und fest, das hat wieder hoch. Und damit Kybernetische ist das ja noch dynamischer. Aber definitiv, dass man wirklich da.

Das freut mich immer ganz besonders, dass man dann diese Aha-Effekt sieht, wenn die Leute das es erst mal machen. Früher hatten wir ein Release alle drei Monate, weil dann mussten alle nachts in die Firma, oder die Leute mussten nachts in die Firma, und alle haben gebetet und sich bei ihren Familien abgemeldet für zwei Tage. Und dann wurde mit Biegen und Brechen das neue Relais ausgespielt. Und jetzt kann du einfach so machen und haßten viel geringeres Risiko, weil du zurückrollen kannst.

Wenn du merkst, das neue Feature braucht mehr CPU Power, kannst du dich einfach hinzu buchen, und man ist halt einfach flexibler.

Wo du es auch anspreche, sobald ich mich mit Thematiken die micro Service ist und so weiter beschäftige, was natürlich meistens bei diesem Refektorium Einsatz kommt. Ich mache etwas neu und ich gehe direkt in diese Welt. Taugt da wirklich ein A? Ich kann hier ganz modular abdecken. Ich muss nicht mehr dieses Jahres Mammut Update machen, wie du geschrieben hast. Alle gehen mit Essen und Trinken für zwei Tage ins Exil und in die Firmen. Quarantäne? Genau.

Ich war einfach Meine einzelne Micro Service tauscht die aus, die kommunizieren nur noch über Schnittstellen. Sie hatten einen hohen Grad von Testmarkt an einer Stelle, und alles wird doch deutlich entspannter oder planbarer und planbarer, was natürlich auch zur Entspannung beiträgt.

Was ich bei dir super finde, ist Du gehst von konkreten Nutzungs Szenarien aus oder von der Applikation. Und schaust Was kann die Cloud mir bieten im Bezug auf diese Applikation? Du schaust sie die Applikationen an, und du gehst nicht von diesem Cloud Hype aus. Also ganz oft in der Werbe, Literatur oder im Internet. Tanja Wie du gesagt hast. Cloud hat 170 Services, und Server lässt und man braucht sich um nichts mehr kümmern. Ja, ja, das ist schon wahr.

Aber man erkauft sich dadurch. Das sind sozusagen die positiven Sachen. Aber man erkauft sich dadurch andere Paradigmen, nach denen man entwickeln muss, die man erst mal lernen muss. Das Thema Stat ist bei Cloud net Anwendungen ganz anders. Da muss man das behandeln als mit Prammers Anwendungen und auch Parallelisierung von Entwicklung, was ja schon immer eine Herausforderung war. Also dass mehrere Freds parallel sich nicht in die Quere kommen und die Anwendung quasi horizontal skaliert. Da muss die Anwendung darauf vorbereitet sein.

Und das ist auch nicht trivial, so eine Architektur aufzusetzen. Und das ist sozusagen der Preis. Der Preis, den man bei einer Cloud Anwendung hat? Definitiv. Das ist nicht immer notwendig. Deswegen auch meine ganz klare Aussage Es ist eine Strategie. Die Services und die konkreten Dinge, das sind die Technologien, die man einsetzen kann, die man nutzen kann. Aber es ist eine Strategie, und wir sagen halt ja. Die Strategie kann durchaus auch beinhalten Ich gehe nicht zu 100 Prozent in die Cloud, sondern nur zu 70 Prozent, was auch immer.

Aber man legt sich da fest, zumindest für einen gewissen Zeitstrahl. Und ich sage man Darüber hinaus wird sowieso wieder was Neues entwickeln. Oder die ganzen Cloud-Anbieter sind so effektiv dabei neue Services erschaffen. In drei Jahren gibts vielleicht wieder doppelt so viel. Und vielleicht trifft dann etwas, was ich machen will, dann besser. Dann ist da ein Service. Ich jetzt zurzeit noch nicht oder unzureichend habe. Und deswegen ist das auch durchaus ein langwieriger Prozess, der immer immer wieder hinterfragt werden muss.

Ich bin nicht sicher, ob du schon alle 6 er gesprochen hast. Ich glaube ihr, wir haben noch zwei übrig. Wobei den einen haben wir ja schon so angeschnitten. Das sind Applikationen, die tatsächlich nicht im migriert werden können. Aus diversen Gründen sei es, dass man Applikationen auch so lang betreiben will, bis sie End of Life ist, und erst dann sich Gedanken macht, dass das Risiko der Migration ist zu hoch. Oder es gibt halt auch ganz einfach politische Compliance.

Wie auch immer Gründe, wo man sagt Nein, die sollen weiter hier und in unserem Rechenzentrum oder bei unserem Rechenzentrum stehen. Und ich sage Je größer eine Umgebung ist, eine IT-Landschaft, desto mehr hat man auch durchaus Applikationen, die darunter fallen. Mackensen Nützliches ist und was sehr häufig vergessen wird, das ist Retailer. Das heisst nicht oder kaum genutzte Applikationen, die einfach weggeschafft werden. Was ist das? Gibts sowas überhaupt? Natürlich, weil fast jeder hat in seinem Rechenzentrum plötzlich VMware oder einen anderen hypervisor laufen.

Schafft sich VMs ohne Ende? Und ja, dann wird halt noch ein Server hin zugestellt, wenn er nicht reicht. Und hier ein bisschen stolz, weil in Anführungszeichen. Kostja nichts. Es wird ja immer nur der Preis für eine Hardware oder für Festplatten gesehen. Wird ja weniger. Ich sag mal, das ganze Operations dahinter gesehen. Und wenn ich dann aber VMs habe, dieser ganze Park ist gewachsen, und ich nutze dann aber nichts davon. Und ich rede ja durchaus von 30 Prozent und manchmal mehr an Ressourcen, die nicht regelmäßig genutzt werden.

Dann Retailer zum Einsatz, und hier haben wir häufig auch ein Quick Win. Also einfach sagen, was? Man könnte ja einfach ausstellen. Wir finden keinen, der dafür verantwortlich ist, weil die läuft seit Jahren. Aber der eingerichtet ist nicht mehr da. Keiner kümmert sich drum. Es werden nur noch abdeckte gepflegt. Aber seit 18 Monaten hat sich niemand eingeloggt. Aber man hat tatsächlich diesen Fall, und da sagen wir ganz einfach abschalten. Das Risiko ist gering.

Und wenn, dann schreit einer. Aber dadurch ist das Risiko gering, dass es das nicht, und das ist durchaus ein Einsparungspotenzial. Und es ist auch einer der ersten ersten, die wir tatsächlich versuchen zu rauszufinden, weil alles, was ich retailer, muss ich nicht erst migrieren, weil das gehört natürlich auch dazu, jetzt nicht in unnötigen Olver zu schaffen.

Also erst mal den Papierkorb rausbringen, sozusagen, um dann zu sehen, was übrig bleibt.

Das ist aber ein klassisches Thema, was Virtualisierung angeht. Das sind meistens dann VMs und gerade auch in größeren Unternehmen, die ja Richtlinien haben. Die kennen dann nur drei Grössen von VM sag ich jetzt mal, die haben je die große, die mittlere und die kleine. Schaut man sich das mal statistisch an, irgendwie kaum kleiner dabei. Fast alles ist mittel und gross, weil irgendein Software-Hersteller mal gesagt hat Ja, wir brauchen aber mindestens so viel und so unser Programm.

Und Deutsch? Und ja, aber dann halt wirklich nicht mehr genutzt, sondern ist relativ viel IT Ressource da reingesteckt. Das ist wirklich einer der häufigsten Punkte in den Eitan, die nicht so gepflegt werden. Es gibt auch die anderen Beispiele. Wo eine Abteilung. Hinterher ist auch Ich sage mal Lebenszyklen für die VMs festlegt. Aber wenn ich es sehr positiv ausdrücken würde, hält sich das ungefähr die Waage. Aus dem Bauch heraus würde ich sagen, dass wir mehr irritieren, als dass da ordentlich gepflegt wird.

Das ist, glaube ich, nicht zu unterschätzen. Auch da fällt mir noch etwas ein. Denn ich habe bei einem aktuellen Kunden das Problem, dass er Daten in die Cloud migrieren möchte, aber er selber mit seinen Endkunden einen Vertrag hat. Steht das kein nicht EU Mitarbeiter diese Daten je anguckt? So, jetzt leite ich Daten in die Cloud und jetzt theoretisch der Cloud Provider oder plant dies zu tun. Der Cloud Provider könnte ja jetzt darauf zugreifen. Kann er nicht in jedem Fall.

Je nachdem, ob ich das verschlüsseln oder wie ich das verschlüsseln. Aber das ist natürlich auch ein Thema, das man sagt Ja, im Moment. Ich kann nicht einfach alles in die Cloud laden, weil der Cloud Provider mehr unter anderem nicht garantieren kann, dass nur EU-Bürger auf diese Daten Zugriff haben.

Genau das ist ein typisches Compliance Thema, was auch je nach Unternehmen relativ hoch aufgänge ist. Auch zu Recht. Da bin ich auch ein absoluter Befürworter, das zu durchleuchten. Man muss halt sehen, erst einmal. Generell kann man erst mal sagen So häufig ist gefordert Das muss auf europäischen oder auf deutschen Server liegen. Das kann ich einschränken. Also ich kann sagen meine, ich benutze nur Server in Frankfurt oder nutze Server in Europa. Das kann ich natürlich schon machen.

Ich kann die Festplatten verschlüsseln, ich kann alles Mögliche verschlüsseln. Ich kann mir Key Management Server buchen, aber das muss man klar sagen, je nach Schutz Bedarf, Feststellung. Auf meine Daten all diese Infrastrukturen kommen ja von dem Cloud Provider Provider sitzt in Amerika und ich sag mal, wenn man Böses denkt, kann man natürlich sagen Na gut, er hat immer eine Backdoor oder er hat die Festplatte verschlüsselt.

Aber der Schlüssel liegt ja auch irgendwo bei dem Provider. Genau, aber letztendlich das Einfachste für ihn wäre. Ich habe halt einfach sowieso den Super Master Ki, und das ist meine meine Backdoor an der Stelle. Da muss man sehr differenziert reingehen. Also, da komme ich so ein bisschen aus der Alten Welt, wo ich mich halt auch sehr viel mit alten grundschutz um IT-Sicherheit Compliance beschäftigt habe. Man macht ja tatsächlich schutzbedürftig Feststellung, wonach man guckt Was hab ich für Daten?

Wo liegen diese Daten? Also z.B. ich bleibe beim Beispiel. Abends hab ich zum Beispiel Account Daten, die liegen durchaus auch in den USA. Das lässt sich nicht verhindern. Das ist halt so eingestellt, wenn ich eine Datenbank in Deutschland suche. Da hat man Service oder eine Weinbuch. Da hat man die Daten liegen natürlich auf europäischen Server. Aber spätestens also Mitarbeiter hat nicht. Erst einmal hat kein Interesse daran, auf die Daten zuzugehen. Aber gerade in der Datenbank rufe ich mir eine Datenbank admin oder an Spezialisten von AVM.

Habe ich keinen Einfluss da drauf? Zumindest im ersten Schritt nicht. Woher der kommt? Die werden natürlich immer aus meiner Zeitzone holen. Es wird in aller Regel europäisch sein, aber hier sind sicherlich Dinge zu betrachten. Da muss man dann ja, das ist die differenzierte Betrachtung. Und wenn es da Zweifel gibt, dann würden wir auch eher sagen Pass auf, Meedia Das Risiko nicht. Man kann es natürlich auch umgehen, aber da muss Hellwege Software mitspielen. Nämlich nämlich eigene Verschlüsselung, Auslösung und Topliga.

Das ich sage jetzt mal das triviales Beispiel wäre jetzt eine Datei Server oder Server. Ich lebt halt nur genug Budget verschlüsselte Dateien ab. Die Schlüssel liegen hier bei mir in Deutschland. Dann ist es mit vertretbarem Aufwand selbst auch für Geheimdienste nach besten Wissen und Gewissen nicht möglich, darauf zuzugreifen. Und da hätte man Sicherheit. Aber man muss ja auch ehrlich sagen Welche Applikation schafft das durchgehend? Von daher ist hier ein kritischer Umgang damit. Ist auf jeden Fall auch von unserer Seite erwünscht, wird gefördert und sollte auf jeden Fall immer beibehalten werden.

Wie ist es denn, wenn die Anwendungen in die Cloud migriert sind und jetzt betrieben werden? Man hat ja sehr viele Möglichkeiten, eine Anwendung zu monitoren, entweder durch Shakes oder durch eingebaute ablösungen, einfach um die ganze Landschaft zu monitoren.

Unterstützt ja, dabei auch. Ja, das ist ein sehr wichtiger Aspekt, der häufig auch missverstanden. Zwar bieten die Provider jede Menge Services und so weiter an, und dann entsteht häufig der Eindruck Naja, das eigentliche Operations, der eigentliche Betrieb, läuft über den Cloud Weida oder wie auch immer, das ist tatsächlich nicht vollständig richtig. Also ich sage jetzt mal kleiner mittelständischer Betrieb fünf Arbeitsplätze, ruft bei KWS an und sagte Ich habe ein Problem, sagte er. Gut an, schmeiß mal hier ordentlich Geld ein, und dann schauen wir uns das ganze Thema mal an.

Bis das gelöst ist, haben hochrangige Spezialisten diesen supertoll. Aber der kennt den Kunden nicht, erkennt nichts von der Umgebung. Das heißt, die Wahrscheinlichkeit, dass er zielgerichtet schnell helfen kann, ist relativ gering. Da kommen wir natürlich ins Spiel. Wir richten zusammen mit den Kunden anhand seiner vorgegebenen kpis, oder? Wir vorschlagen Monitoring, ein Kontrolle und wir reagieren dann darauf. Das ist natürlich eine maschinenteilen aus Weggucken oder ein Service fällt aus. Wir gucken das dann wieder an, Staat kommt aber halt auch so Dinge aus der Datenbank sind schlechte Werte.

Wir gucken mal, woran es liegen könnte. Wir haben im Netz komisches Verhalten. Irgendwas ist hier langsam. Dann fällt das halt auf. Darum kümmern wir uns ihre Pforten natürlich auch. Wir sind also unsere Welt des Operations, des Betriebs. Hat sich schon etwas verändert? Wir müssen noch mehr Reportern, eigentlich, aber wir haben auch mehr Daten. Die Reporter können also deutlich mehr, als wir teilweise früher hatten, und können dem Kunden halt auf der Basis kennenlernen und können auf der Basis Vorschläge machen und optimieren.

Der Betrieb, die überführung in einen Betrieb, ist heute sehr, sehr wichtig für uns. Aber das kennen wir als Firma gar nicht anders. Das haben wir früher mit eigenen Rechenzentren genauso gemacht. Die Arbeit mit der IT-Abteilung des Kunden zusammen beschert Responsibility. Guck mal, wer ist für was zuständig? Und danach wird das aufgetrennt. Und das funktioniert eigentlich sehr, sehr gut und insbesondere, wenn sich das mal eingespielt hat. Das ist auch ein Prozess, der braucht von wenigen Tagen bis in einem Jahr von einer Größe ab, denn den ganzen Umgebung.

Da stimmt sich das ein, und ich glaube, am Ende des Tages hat man dann schon sehr, sehr guten an der Stelle. Genau.

Also in der Cloud. Ist es generell so, dass Hardware fehlt? Ja, sollten nicht mehr auftreten. Aber natürlich kann es immer noch in der Anwendung selber Probleme geben, auf die dann reagiert werden muss. Also Beispiel Irgendwas ist nicht richtig gesichert, und statt eines ein Megabit profil Bildes lädt irgendjemand 50 Megabit hoch oder so was dann zu einem Problem wird an anderen Stelle?

Ja, es gibt auch so klassische Szenarien. Ich habe im Auto Stellingen eingerichtet. Das heißt, ich. Meine Webseite braucht sonst nur zwei Webservices, um redundant zu sein. Und jetzt hab ich auf dem Heise Ticker gerade heute News gepostet, und schon werde ich mit.

Geht die Post, Gena? Und dann geht plötzlich mein mein Auto hoch. Aber ich war damals vorsichtig und hab gesagt Der mehr als 100 Webserver werde ich nie brauchen, um die Anfragen so zu erfüllen. Und dann? Plötzlich wird es auch langsam. Na, dann kann man halt sagen Okay, wir erhöhen jetzt mal gerade die Anzahl. Solange das andauert, können wir im Nachgang nochmal besprechen, wer diese Vata mag. Richtig. Oder andersherum Wir machen den Prozess daraus, dass wir benachrichtigt werden, wenn ihr solche Mitteilungen hat, die potenziell interessant sein können, dass wir im Zweifelsfall auch durchaus mal manuell eingreifen.

Also durchaus auch noch der Fall? Ja, man macht ja eine Begrenzung des Ganzen, malt auch nicht über gewisse Kosten Grenzen zu kommen, was immer Sinn macht. Und dann sagt man Okay, ich hab jetzt aber eine große Veranstaltung, große Pressemitteilung, wie immer. Jetzt muss ich sicher gehen, dass da nichts schief geht. Da macht man es manuell für eine Zeitspanne, und dann stellt man es wieder zurück.

Also dieses semi Automatische würde ich fast als Ideallösung sehen, weil wenn du einfach sagst, du setzt die Autos galligen Gruppe hoch. Statt 100 Maschinen stelle ich es einfach auf hundert. Und wenn mal der Heise Artikel kommt, dann bin ich safe. Kann es immer noch sein, dass man so eine Art DDoS Attacke bekommt? Einfach unfassbar viele Anfragen auf ein Webdienst abgegeben werden und dann würde man ja das Geld bezahlen für diese 1000 Server und wenn man das einfach blind einstellen würde.

Also ich bin sowieso immer ein Freund davon, dass Automatisierung ist toll. Es erleichtert Unmengen, insbesondere heute bei Google, und man entwirft eine Plattform, schiebt sie raus. Oder doch nicht? Man wirft sie wieder weg. Also alles ist sehr easy, sehr schnell. Aber ich bin immer ein Freund davon, dass halt auch noch ein Mensch drauf guckt, bei der im Endeffekt besser entscheiden kann bei gewissen Szenarien. Was ist das jetzt? Gerade wenn etwas häufig Vorfeld greifen, auch Maschinen, löning ki, Algorithmen an anderer Stelle, die haben dann gelernt irgendwelche Relationen, Information, Relation.

Und dann? Dann kann ich darauf auch reagieren. Aber bei so spontanen, erstmalig auftretenden Fällen, wie auch immer da ist ein Mensch, denke ich, noch eine ganz gute Alternative.

Mir fällt ein Projekt von mir selber ein. Da hatte ich in mehreren Wochen Anwendungen entschlackt und hat dann ungefähr eine 30 prozentige Steigerung in der Arbeitsgeschwindigkeit erzielt. Es war eine interaktive Anwendung, das heißt, die Nutzer waren so zwei, 300 Leute gleichzeitig immer auf der Anbindung aktiv, haben halt gespürt, dass die Anwendung besser reagiert und das zügig ihres Arbeiten möglich ist. Und dann hab ich mal vor ein Nachrichten unternehmen, dann hab ich die neue Version abends online gestellt oder liest, und ich komme am nächsten Morgen rein ins Büro und gucke ok.

Wie sieht es denn aus? Sondern hab ich genau die gleiche alte Last wieder, als hätte ich diese Optimierung nie gemacht. Ich hab mich gefragt Also wirklich Einzelstunden? Wie kann es sein, den Fehler gesucht? Was ist das Problem? Und dann habe ich herausgefunden, dass genau an diesem Morgen ein Flugzeugabsturz stattgefunden hat. Und das statt 200! Auf einmal 5500 Leute gleichzeitig die Anwendung benutzt haben Ich habe das gleiche lãst profil hatte wie Vortags, wo die alte Software noch lief.

Was dann wiederum sehr gut war. Aber ich hab zuerst nicht verstanden, warum. Warum die Zahlen nicht deutlich besser sind oder die Performance deutlich besser ist.

Aber du hast für eine Firma gearbeitet, du kãnntest du es mit Eckdaten, dann hinter der Entscheidung. Daran könnte es liegen. Man das jetzt bei nem Dienstleister, der so gar keinen Bezug zu einem hat, der käme ja nicht da drauf, weil er gar nicht weiß, was man macht. Ich glaube, da war, was du als Mensch dann in dem Moment fast unbezahlbar.

Ich möchte einfach sagen Manchmal ist menschliche Intelligenz halt wichtig, um zu verstehen Warum ist der Effekt so, wie er ist? Und das hätte jetzt ein automatisiertes System nicht unter Umständen so erkennen können. Was glaubst du denn in Zukunft? Wohin geht die Reise noch? Was sagt eine Glaskugel?

Kann ich ja sagen. Ich fang einfach mal in der Vergangenheit an, wo ich gesagt, habe ich viele sehr skeptisch gegenüber. Klar, die ersten klar, Anfänge. Was aber daran lag, dass vieles noch im Unklaren war. Es war ein gewisser Hype. Für viele war allerdings Cloud mehr Storage Anbieter. Da konnte ich meine Bilder hochladen und meine Dateien. Viel mehr war da nicht. Wenn ich mir anschaue, wie schnell sich hier eine neue IT-Landschaft entwickelt hat und wie gut ist, funktioniert bei durchaus Kritik würdigen Aspekten.

Aber, muss ich ganz ehrlich sagen, glaube ich schon, dass es jetzt ein halbmayr ist. Man sieht, es ist ein Geschäftsmodell. Es entstehen immer mehr Firmen, so wie wir auch in diesem Umfeld. Ich glaube, es ist noch ein längerer Prozess, bis hohe Prozentsätze der Wortlauts gewandert sind. Aber es wird passieren. Man wird sehr, sehr viele Birkenholz. Wird man in die Cloud wandern? Das klassische kleine Rechenzentrum wird aussterben. In meinen Augen aus.

Es hat eine Nische, in der Claudia mich jetzt nicht tätig sind. Es wird es immer noch etwas geben. Aber das sind dann wirklich reine Nischenanbieter.

Oder man braucht Kerth Spezial Anforderungen, besonders viele GPUs, die in der Cloud halt teuer sind, weil sie mich massenweise eingekauft werden. Und wenn ich sie 24 Stunden am Tag brauche, lohnt sich das einfach wieder die Sachen selber zu kaufen.

Genau das sind natürlich so Punkte, aber das meine ich auch so mit einer Nische. Aber was die beiden Wortlauts angeht im Markt ist. Ich denke, da geht der Trend absolut hin. Das wird immer mehr kommen. Die Software geht über die Applikation, wie wir ja auch schon heute viel gesprochen haben. Und die Applikation ist heute schon schwierig, individual Entwickler zu finden, die noch so Oldschool entwickeln. Sicherlich, aber ich habe mit großen Software-Hersteller gesprochen, alle mindestens 1000, 200, 300 Mitarbeiter, Softwareentwickler.

Und da wird kein Oldschool mehr entwickelt. Die machen alles nur noch Clouds und von daher ist es gar nicht so eine große Glaskugel. Das ist einfach auf der Zeitachse die Glaskugel. Wie schnell passiert ist. Also ich denke nicht, dass das von heute auf morgen geht, ist halt ein Prozess. Aber es wird passieren, was ich auch beobachte.

Bei unseren Kunden ist das. Man tastet sich manchmal ran an die neuen Anwendungen werden in so eine kubanisches Umgebung zum Beispiel. Und da ist es ja dann wiederum ein sehr kleiner Schritt zu sagen Okay. Diese Copernicus Umgebung läuft bei mir im Rechenzentrum oder läuft in der Cloud A oder B oder C. Gerade wenn man noch nicht weiß, welcher Anbieter macht das Rennen? Wobei ich glaube, das kann man schon ein bisschen antizipieren, dass da zwei ganz besonders hervor stechen werden die nächsten Jahre, oder ist jedenfalls mein Tipp.

Es wird so sein, und man muss sich einfach mal die gängigen Marktanalysen anschauen. Es ist schon sehr erstaunlich der Unterschied zwischen Platz 1 und Platz 2 noch erstaunlicher ist, wenn man reingeschaut. Unterschied zwischen 2 und 3, denn plötzlich ist mit Google am Platz drei. Und ich sage mal Ich weiß nicht, was für ein Bild du von Google hast, aber für mich so ein absoluter tech Riese. Aber die spielen da halt nur den dritten Platz und müssen aufpassen, dass Chinesen wie Alibaba oder Soda nicht aufholen, weil die drängen jetzt auch in den europäischen Markt, und die sind ja auch sehr teuer.

Aber die Big Player bieten schon hervorragende Services an, insbesondere für die Welt, die du gerade beschrieben hast. Und hier kann ich dann als Entwickler oder auch als Kunde sagen Pass auf, ich schaue mir einfach am Ende des Tages an, wenn alles servas ist. Soweit nicht leicht migrieren kann. Wo hab ich meine besten Kosten nutzen? Structure an der Stelle, und dann kommt da auch mehr Konkurrenzkampf noch in Markt. Im Moment ist noch nicht so viel Konkurrenzkampf im Markt, teilt sich gut auf.

Aber ich glaube, in Zukunft wird es da mehr Konkurrenzkampf geben. Und das wird im Zweifelsfall in niedrigeren Preisen oder durchsichtige und Preismodell gipfeln als mein absolut subjektiver Eindruck.

Der Cloud Provider ist Technologieführer dafür preislich etwas teurer. Wer aways? Ganz klar. Wobei man da ja auch deutliche Rabatte bekommt, wenn man gewisse Ressourcen fest für ein Jahr bucht oder gar für drei Jahre bucht. Ich glaube, dann gibts 60 Prozent Rabatt. hws waren die ersten, die profitieren. Das haben auch meiner Ansicht nach das. Angebot und die Profitierenden nach wie vor von auf dem zweiten Platz im absoluten Sauseschritt. In den letzten ein, zwei Jahren hat Microsoft aufgeholt.

Ich glaube, das kommt durch die. Microsoft ist in den Firmen groß, die mittleren und kleinen Firmen natürlich schon super präsent durch die Office Lösungen, durch die Windows Lösung. Und da ist dieses Cloud Ding ein cheek Punkt mehr im Vertrag. Haben Sie da schon guten Kontakt zu den Unternehmen und an dritter Stelle Google? Ich finde die Google Cloud ziemlich gut, muss ich sagen. Ich habe auch schon mit der gearbeitet. Aber ich glaube, Google ist ein Teck Konzern, der supergut Technologie macht.

Aber ich glaube Marketing mäßig zumindest im Cloud Bereich. Da ist nicht so viel Platz. Dort sind auf der einen Seite den Technologieführer, auf der anderen Seite den mit den Unternehmenskunden. So, wer bleibt da noch? Der Cloud macht?

Das ist meiner Ansicht nach die blöde dritte Position von Google, das sie nicht so richtig klar positioniert sind. Und diese Oracle, IBM Cloud eben. Mir ist noch niemand über den Weg gelaufen, der die wirklich produktiv einsetzt. Ich denke, das sind die haben ihre Daseinsberechtigung in irgendwelchen Nischen oder vielleicht in anderen Märkten. Könnte mir vorstellen, dass im Mittleren Osten Nahen Osten das Orakel noch ganz stark ist, aber auch nicht da sind, glaube ich, eher ueberall, wo ich diese klassischen hybride Ansätze habe.

Oder wenn ich mit IBM ein absoluter Technoide ist, mit Unmengen an Angeboten, und das ich in Bestandskunden dann noch ein bisschen Cloud lief. Also ungefähr so okey wird auch weiter wohl existieren, aber nicht Weltmarkt relevant sein. Oracle hat halt ein wesentliches Produkt, bietet ein bisschen was drumherum. Aber ich glaube, er hat auch ein bisschen ein Imageproblem. Aber das muss jeder für sich entscheiden. Und tatsächlich Um wieder an den Anfang zu springen, versuchen es mit weit über 40 Prozent absolut Marktführer, weil sie am längsten am Markt sind, die meisten Services haben und sich halt auch nichts verbauen.

Also ich kann von komplett Microsoft Umgebung bis hin zu komplett Unix oder was auch immer. Ich kann alles entsprechend umsetzen. Asea empfinde ich, ohne dass ich jetzt ein echter Experte bin, als sehr stark. Sind auch stark im Wachstum. Und genau wie du sagst es die Unternehmenskunden die reine Microsoft Umgebung haben, die keine Hybrid oder sonstigen Technologien verwenden, was ihr kleiner eine Firma ist, also kleiner mittlerer Mittelstand durchaus der Fall sein kann. Ich sage mal so schon aus dem Bauch heraus würde ich da wahrscheinlich eher in diese Richtung gehen.

Aber man muss sagen, viele Kunden haben dann doch noch hier bisschen, da etwas. Und wenn man dann einfach sieht Okay, ich will halt wirklich Cloud Ansatz wählen. Ich will diese Strategie ganz konsequent verfolgen. Und ich versuche dann eher, klassische Mittel abzulösen durch Service. Dann landet bei Aretz, weil die Menge an Service ist. Die Innovation, die dahintersteht. Das, muss man wirklich sagen, ist momentan noch out. Und da wird selbst Microsoft noch etwas brauchen, um da in diese Richtung zu kommen.

Aber wie gesagt, es gibt immer überraschungen. Das sind alles sehr große Konzerne, und ich fände es ja auch spannend, wenn da noch mal irgendwelche überraschungen eintreten.

Auf jeden Fall. Für den Endkunden kann es ja nur positiv sein, entweder durch den Preis oder durch die Innovation, die er dann nutzen kann.

Genau. Der Endkunde wird der Sieger sein. Definitiv. Wenn unsere Zuhörer Fragen haben oder Feedback zu der aktuellen Folge hat, können Sie uns gerne eine E-Mail an Podcast senden. Bitte bewertet diese Podcast Episode und lasst uns einen Kommentar dafür. Weitere spannende Technologie Themen schaut gerne auf Skill bei Slash Blog vorbei Bries. Ich bedanke mich ganz ganz herzlich bei dir.

Ich danke dir Maurice.

Maurice KnoppSkillbyte Podcast #28: Cloud als Strategie, nicht als Technologie!
Mehr

Skillbyte Podcast #27: Erfolgreiche (Tech-) Produkte bauen – so geht’s!

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

In diesem Podcast geht es um das Thema: Erfolgreiche (Tech-) Produkte bauen – so geht’s!

// Inhalt //
04:47 – Das Mindset für die erfolgreiche Produktentwicklung
07:02 – Technik ist (leider) nicht alles
09:13 – Fehler wurden gemacht…
11:34 – Technologie ist nicht das größte Problem (wiedermal)
14:10 – Wie entstand das skillbyte Produkt GravityCV?
19:12 – Online und Offline Tools sind Produkte
20:02 – Vorgehen für erfolgreiche Produktentwicklung
21:52 – Der Business Model Canvas
25:06 – Der Unterschied zwischen Produkt und Hobby
26:34 – Fertig ist Fertig
29:04 – Weshalb scheitern Technologie-Projekte?
36:52 – Fuckup Nights – Lernen von Anderen

Der Business Model Canvas: https://canvanizer.com/downloads/business_model_canvas_poster.pdf

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Man sieht immer, wenn man erfolgreiche Produkte der Unternehmen sieht, berichten die Medien darüber. Dann hört und liest sich das alles so einfach schön und gut. Aber man hört ja gar nicht von den Millionen anderen, die irgendwie aufgeben und nicht funktionieren. Man kann sich nicht vorstellen, wie viel Arbeit hinter einem Produkt steckt.

Herzlich willkommen zur bei Podcast Episode Nr. 27 erfolgreiche Tech Produkte bauen. So geht’s abonniert unser Kanal für mehr spannende Themen aus dem Technologie Umfeld. Wenn ihr eine Frage habt, schreibt uns gerne eine E-Mail an Podcast und lasst uns eine Bewertung und ein Feedback. Darüber freuen wir uns immer sehr. Ich bin heute wieder mit meinem Stammgast Masiar.

Hallo Masiar, hallo ich, hallo du Evergreen Gast. Heute sprechen wir über Technologie Produkte. Ein super spannendes Thema. Ein absolutes Ja. Ich möchte auch sagen Hauptthema. Viele Publikationen drehen sich ja darum. Man müsste einfach nur eine Idee implementieren, und schon hätte man das Riesen ONLINE Business. Aber wie wir selber aus leidvoller Erfahrung wissen, ist das gar nicht so einfach.

Ja, das ist wohl richtig. Ist ein gewisser Wandel im Gang? Jeder Versuch, diese Mentalität zu bilden. Ich habe auch sehr viel. Ich will jetzt nicht sagen, dass ich Produkte bauen kann. Aber ich habe einfach viele Fehler gemacht, und da bin ich auch gleich ein bisschen was erzählen, was man anderen erspart bleibt.

Genau.

Was mich etwas stört, ist, das in der Literatur dieses Lean Start up Movement führt. Oder ist da federführend, das noch weiter zu pushen, das es so dargestellt wird? Es ist alles total einfach. Du brauchst nur eine Idee Setz dich hin, kote das runter, und schon läuft das Ganze. Und das ist ja beileibe nicht so ne.

Man sieht immer, wenn man erfolgreiche Produkte oder Unternehmen sieht, berichten die Medien darüber, dann hört und liest sich das alles so einfach und schön und gut. Aber man hört ja gar nicht von den Millionen anderen, die irgendwie aufgeben, die nicht funktionieren. Und man kann sich nicht vorstellen, wie viel Arbeit hinter einem Produkt steckt. Absolut.

Da muss man fast immer ein bisschen schmunzeln. Du hattest bestimmt auch schon Gespräche mit Freunden oder Bekannten, die sagen Ja, ich habe eine Idee, aber ich möchte nicht darüber sprechen, weil sonst nimmt sie mir niemand weg. Und dann ich die Idee und jemand anderes wird damit ganz reich. Daran erkennt man die Anfänger, würde ich sagen, weil die meisten Menschen Hammann job. Die meisten Menschen haben auch ein Leben, und es ist nicht so. Wenn jetzt jemand von einer Idee hört, dass man alles stehen und liegen lässt, sein Leben aufgibt und sagt Ja, genau das mache ich jetzt, um die Idee zu stehen und damit erfolgreich zu werden.

Ja, es wurden Ideen übernommen in der Vergangenheit, aber zu einem ganz anderen Zeitpunkt und auch mit einer ganz anderen Zielsetzung. Wenn man schon Unternehmen hat, meistens anzumalen.

Die Idee an sich betrãgt nicht mal 100 Prozent an einem erfolgreichen Produkt. Ich würde sogar einprozent nicht schwitzen. Deswegen ist so eine Idee Mal raushauen muss man gehen, aber es ist nicht so wild.

Oftmals sind die Ideen ja gar nicht so entscheidend. Ich meinen, bleiben wir mal bei WhatsApp ist, das die SMS irgendwann durch einen Messenger auf Datenbasis abgelöst wird und man nicht mehr pro SMS 20 Cent bezahlt. Die visionäre Energie, die dahinter steht, halte ich mal für überschaubar.

Also da ist schon klar, dass sowas kommen wird, genau wie Videochats. Aber die Frage ist ja Wer macht es von den ganzen Playern, die es da draußen gibt, eine Wer schafft das dann am Ende? Und das ist genau, wie du richtig sagst. Execution ist 99 Prozent des Weges. Aber trotzdem finde ich immer. Also egal, wie hanebüchen manche Ideen sind, finde ich es mal klasse, wenn Leute sagen, ich habe eine eigene Idee, und ich verfolge die jetzt neben meinem eigenen Job.

Ich probiere, das irgendwie aufzubauen. Ich habe diesen Traum, das ich von meinem Produkt leben kann, und es gibt auch viele Menschen, die das können. Wir erinnern uns an dieser Stelle, an die Geschichte von Tonfalls Fingers. Ich glaube, das ist unsere Episode Nummer 21, wo der Cris genau beschrieben hat, wie er das gemacht hat und seine Geschichte erzählt hat. Und es funktioniert auch wenn man lange genug dran bleibt und lernfähig ist, aus seinen Fehlern lernen kann und sich immer wieder neu herausfordert, dann klappt das auch irgendwann.

Die Schlüsselkompetenzen wird das Durchhaltevermögen sein.

Genau.

Sich kritisch hinterfragen liefere ich wert. Sind die Nutzer Nutzen, die mein Produkt benutzen, die es gerne? Empfehlen Sie es weiter? Bin ich da auf dem richtigen Weg? Muss ich was ändern? Auch oft ist es ja so, dass man stellt sich in seiner idealen Welt das Produkt vor und sagt A so müsste das sein. Aber wenn man es dann baut, dann stellt man fest Nee, die Nutzer brauchen eigentlich etwas ganz anderes oder ziehen den Wert an einer ganz anderen Stelle des Produktes heraus, als man das selber antizipiert hat.

Und da ist es dann wichtig, auf die Benutzer Bedürfnisse zu reagieren und sich selber hinten anzustellen oder seine eigene Leidenschaft hinten anzustellen und zu sagen OK. Scheinbar. Von den Nutzern lernen, wo der Wert herkommt und muss mich dann dort entsprechend anpassen. Also ganz wichtige Mainz Sache.

Das ist ja auch so, wenn ich mal diese erste Spannung und Freude und Enthusiasmus vorbei ist, wo es dann um Arbeiten geht und auch mal langweilige Dinge durchzuziehen, dann würde ich mich gar nicht von Preisbrecher einer, der braucht immer diesen neuen irgendwas geschafft zu haben, irgendwas gelöst zu haben. Und ich muss mich disziplinierend, dann auch mal dabei blame einbringen bis zum Ende. Weil ich auch ein Taki bin. Ich habe mal eine langweilige Technologie, weil ich das gemeistert haben, weil ich das gelöst haben.

Das ist für mich persönlich die Herausforderung, dranzubleiben.

Du meinst, dem abchecken syndromen von der Schippe zu springen, das man nichts sagt. Oh, das ist was Neues, das ist was Neues und das ist viel besser, sondern dass man sich wirklich einer Idee verschreibt und sagt Entweder werde ich damit erfolgreich, oder ich mache nie was anderes.

Und es ist noch nicht einmal wie das andere viel besser, sondern diese so nah, ein komplexes Problem zu haben und mit neuen Gedanken, neuen Herangehensweisen das zu lösen. Das ist, glaube ich, für mich der Kick. Ich habe mir deshalb so ein Programm nicht gelegen. Bin ich immer wieder quasi Erde, und da muss ich jetzt, wo ich bis zum Ende hin du sagst, ja das Problem lösen.

Du meinst wahrscheinlich das Problem technisch lösen? Definitiv. Technisch ja, aber zu einem Produkt. Ein Produkt ist ja nicht nur eine technische Lösung, sondern auch das Marketing drumherum. Man muss die Leute, die Nutzer finden. Die Nutzer müssen auch, müssen das Produkt entdecken, müssen es nutzen, müssen Feedback geben. Und diese kontinuierliche Verbesserung? Diese Maschine muss man erst ins Laufen bekommen. Das war für mich, muss ich wirklich sagen, auch als Techniker eine sehr, sehr harte Lektion, die ich im Laufe meines Lebens gelernt habe.

Dass ich dachte, die Technologie ist total wichtig, dass die 1A ist und dass es den neuesten Standart erfüllt. Und dann baust du eine Anwendung, die super top aussieht, die neuste Technologie verwendet, und keiner nutzt sie. Hab ich gestern noch von einem Freund, der aber einer beim großen Unternehmen arbeitet, gehört? Sie haben sich jetzt 2020 auf die Fahne geschrieben. Noch in einigen Bereichen wird noch MS-DOS verwendet, das das dann doch mal langsam abgelöst wird.

Also technisch ganz schlimme Dinge, aber die liefern halt Wert. Und das ist das am Ende des Tages, worauf es ankommt. Wenn eine Abrechnung auf Maestros Basis funktioniert, dann ist das ein Wert, und die Technologie ist da zweitrangig. Ob das DOS, Windows, Linux oder wie auch immer ist. Wenn die Firma ihre Abrechnung macht und das irgendwie funktioniert, ist das egal.

Hauptsache, die Abrechnung ist der Wert, dass die gemacht wird und nicht die Technologie, die da drunter steht. Das sieht man als Techniker natürlich oft mit einem traurigen Auge. Auch Software auf Geldautomaten ist oft sehr alt. Aber es funktioniert. Solange der Wert, den die Menschen von dieser Technologie erwarten, gegeben wird, ist alles andere zweitrangig. Erst einmal Das ist hart für mich zu verstehen oder zu akzeptieren.

Aber es ist einfach so, und das haben wir auch bei Chris Tent was Finger Beispiel gehört das immer, wenn er an ein Problem gestoßen ist, ein technologisches Problem gestoßen ist, hat er das gelöst und ist dann weiter vorgegangen. Er hat aber nicht sehr viel Zeit darauf verwendet, von Anfang an so eine Infrastruktur aufzubauen, dass man von vornherein alle möglichen technischen Probleme, die man vielleicht mal hat, von vornherein ausschließt. Aber du hast gesagt, du hast. Also, ich hab natürlich auch ein paar Produkte, die ich gebaut hab, die vielleicht nicht ganz so abgehoben haben, wie ich mir das vorgestellt habe.

Aber du sagst auch, dass einige Lektionen gelernt, vielleicht mal ein paar teilen.

Das darunter liegende Thema ist diese Technik Verliebtheit bei unserem ersten Produkt. Da haben wir an der Software gebaut und umgetan und ein Mutterschiff an Funktionalitäten. Mein Gott, was sage ich gleich doppelt so, und das war für so ein Aerzte brutal. Zum zweiten haben mein Partner und ich haben uns gegenseitig gepeitscht, was das für ein tolles Tool ist die Welt erobern und das gesunde Portion Größenwahn? So will ich mal sagen. Genau das haben wir gemerkt. Dann erst angefangen haben, mit Krankenhäusern zu sprechen.

Und alle haben gesagt Journey Moment brauchen wir. Das sind schon gut ausgelastet da, und das hat uns natürlich komplett runtergezogen. Es hat ja noch nicht lange gedauert, bis uns das so ist. Kann man auch. Weil es so schwierig war, dieses Land zu kommen und dann auch gemerkt hat Die Entwicklung war echt Piepenburg dagegen, sondern das Marketing, das Artnet. Da muss so meint Mitbringen nicht von einem Nein, nicht beeinflussen lassen. Die Erfahrung hat man da halt nicht.

Und deswegen mal das Produkt, wo wir sehr viel Schweiß und Geld reingesteckt haben, ist man eingestellt. Und deswegen kann ich diese Bewegung liegen, die bei Lottmann, dass man vorher Interviews führen soll. Vorher anrufen soll. Habt ihr das Problem? Ist das Problem. Und wenn es so ein Ding geben würde, Butzen und so weiter, haben wir dann halt erst gemerkt, als das Produkt schon war. Und dann haben Sie jetzt auch gedacht Mein Gott, hätten wir das doch gemacht.

Wie viel ärGer wie gut seid, hätten wir uns da gespart? Auf der anderen Seite haben wir natürlich durch diese Erfahrungen aber auch sehr viel an Weisheit in Anführungsstrichen gewonnen. Genau wie man es nicht mal als Tiki fängt man an, eine Lösung zu entwickeln, und entwickelt dann die Lösung immer weiter.

Das ist so der natürliche Weg. Vielleicht wäre es cleverer, oder? Ich bin ganz sicher, dass es cleverer ist. Du machst einfach eine Webseite, wo du drauf beschreibst, was das Produkt kann, und sammelt Interessenten. Also versuchst, Leads einzusammeln dafür und bewirbt diese Seite. Und Kux verstehen die Leute, was ich vorhabe? Wollen Sie das Produkt wieviel bezahlen, die für das Produkt nutzen? Nur gratis würden die auch ein Abo abschließen und, und, und.

Diese ganzen Geschäfts kritischen Fragen, die muss man im Grunde vorher stellen oder viele davon vorstellen. Und erst wenn da hinreichend Interesse ist, dann kann man sich in die Lösung begeben. Genau das ist ganz wichtig bei meinem Tool, was ich über dreieinhalb Jahre gebaut habe, dass dieses Online-Tool für Gemeinschafts Geschenke so ähnlich funktionierte wie Dudeln. Und da war es so, dass wir mit diesem Tool gestartet sind Abstimmung für Gemeinschafts, Geschenke. Das haben die Leute gar nicht so benutzt, sondern sie haben sich eher Geschenkideen gesucht.

Was verschenken denn die anderen? Da hat man so ein Blog da, wo wir Geschenkideen beschrieben haben. Der hat dann immer mehr Traffic gezogen, und irgendwann haben wir festgestellt Okay, das sind die Inhalte auf dem Blog, den die Leute eigentlich wollen. Dann müssen wir diese Inhalte halt besser verpacken oder vermarkten im Sinne von E-Books, im Sinne von später Print Büchern. Und das hat dann gut funktioniert. Man hat quasi aus einem Webstuhl ist dann eine Content Plattform geworden.

Da waren wir gottseidank so was schon so viel Erfahrung, dass wir gesagt haben Okay, wir müssen uns immer irgendwie an den Nutzern ausrichten und nicht hart unsere Idee durchdrücken, sondern einfach schauen. Wo kommt der Wert her für die Leute? Und so hat sich das dann entwickelt. Aber das ist auch eine Position am Mainzer Top-Position, die meiner Ansicht nach sehr wichtig ist, dass man die einem dieses dieser Glaube okey. Ich weiß nichts. Ich muss den Nutzer beobachten Wie nutzt der das Produkt?

Wo kriegt er den Wert her? Was ist ihm wichtig? Welche Probleme hat er? Wie löst die Probleme? Wie kann ich ihm helfen, die Probleme zu lösen, dass man das ins Zentrum stellt? Und wirklich Es ist fast schon eine Floskel, Nutzer zentriert, sein Produkt weiterentwickelt. Aber da kommt es eben wirklich darauf an, dass man nicht sagt Ah, ich weiß, wie das alles funktioniert, und ich baue die perfekte Lösung, sondern was man mit zum Meinzer dran sagt.

Okay, ich mach mal etwas, was ich logisch finde, und beobachtet, wie die Leute damit umgehen, und muss das dann entsprechend anpassen. Genau das war auch ein weiter Weg und auch ein schmerzvoller Weg. Und da wurde auch viel entwickelt, was hinterher weggeschmissen wurde. Das stimmt. Bei Gravity Kiwi das ist ja das Produkt für Kiwis, um Lebensläufe digital abzubilden. Da sollte etwas anders vorgegangen. Da gab es ja schon eine erste Version, mit der Idee evaluiert habt.

Und da habt ihr jetzt ja schon auch super viel gelernt und das eben weiter ausgebaut.

Geht es aber schon länger. Ich habe mit meinen Zivis als Freiberufler permanent Probleme. Das ging mir so auf den Nerv, dass ich dieses Tool so nebenher. Um auch mit neuer Technologie zu experimentieren, habe ich das nun selber programmiert. Ganz einfachen Version habe ich dann einfach mal leid. gestellt und mir nach ein paar Wochen man schon eingesammelt. Hat das dann von einem Programmierer quasi nachbauen lassen mit einer anderen Technologie, weil ich es funktioniert. Leute nutzen das. Anscheinend haben andere das gleiche Problem.

Ich hab das nachbauen lassen mit mehr Features, und das war ungefähr einem Dreivierteljahr leid. Und dann haben wir uns entschlossen Okay, mal größer aufziehen. Viele Leute tragen dies und jenes an und haben auch keine richtige Zeit, um Support zu bieten. Das war ja immerhin ein Hobby Projekt, immer noch. Und dann haben wir irgendwann gesagt So professionell auch diesmal richtig Ressourcen, ein Aufrichtung Marketing und bauen das jetzt mal richtig. Und anders dann auch da wieder mit einer ganz einfachen Version, mit dem Wissen, was woher in der Zeit gesammelt haben, in einer Version umgesetzten Jetzt aktuell quasi Leid und haben dann wirklich beim Design viel Zeit verwendet, um User zu befragen.

Wir haben tatsächlich mit Video User befragt und gleichzeitig aufgezeichnet und hat nun einen Fragenkatalog überlegt und haben gesagt Mach mal versucht, dich mal zu registrieren und gehe mal mit dem Tool, mal aufgezeichnet, wie er damit umgeht, was er Fragen stellt, wie er mit der Maus umgeht und was er Schluss, dann auch einen Fragenkatalog durchgearbeitet. Am Schluss war die Frage Würdest du dafür bezahlt und wie viel, wenn ja, wieviel würdest du bezahlen? Das haben wir dann mit 20 Leuten gemacht.

Entwickler, Projektmanager aus dieser Ecke, diverse Rollen. Auf Basis dessen haben wir das Tun dann quasi rund gemacht im September, in dieser neuen Version. Ich bin gespannt, wie du auch diese lernsituation.

Das ist ja jetzt schon das zweite Release. Habt ihr dann schon einmal auch sehr gründlich dann durchgeführt? Bei dem Tool ist es sehr wichtig, dass die Daten sicher abgespeichert werden und so weiter. Kann man nicht einen Schnellschuss wagen?

Exakt im Moment gerade Test durchgeführt. Wir müssen auch gerade weil die Kollegen sehr stark danach fragen Wie speichert Daten, wo speichert sie die Kunden? Du genau? Wenn da was passiert und das Ding dichtmachen, insofern der Schaden so groß ist, wo man ganz, ganz sichergehen, dass alles gut ist. Ein zweiter Runde von Hackern durch Checken und Verschlüsselungen, alles, was dazugehört. Es gibt Dinge, die kann man nicht so agil machen. Gerade wenn es so geht, muss man schon.

Insgesamt ist es natürlich sehr viel Aufwand. Das ist alles selbst finanziert. Ja, das ist schon seit Jahren mitschwang, und ich hatte jetzt noch im Grunde drei Zielgruppen.

Ihr habt einmal die Entscheider, die das sozusagen als eine Herauslösung benutzen können, um ihr Team zu verwalten oder zu schauen. Welche Skills hat denn mein Team? Wer kann zum Beispiel Französisch sprechen und besitzt die Skills für das neue Projekt? Gefragt ist Die IT-Fachkräfte habt ihr als Zielgruppe, die da ihr Profil einstellen, um ihre Skills zu zeigen, und die Personaler, die gegebenenfalls dann, wenn man es im Freiberufler Kontext einsetzt, diese Profile sichten und dann die entsprechend richtigen Kandidaten dann an die eigenen Kunden weiterleiten.

Die Personalvermittler keinen direkten Kunden sehen, sondern die bekommen von unseren Kunden die Unternehmen und Programmierer, Freiberufler, Designer keine Ahnung. Die schicken diese Links an die Vermittler, und die gucken sich das an oder downloaden. Aber das ist keine zahlende Kundschaft.

Bei uns sind aber auch Stakeholder, die sozusagen in Kontakt mit dem System kommen und das Nutzen bestmöglich nutzen. Damit Sie Ihre Arbeit machen können? Okay, jetzt haben wir schon so ein bisschen darüber gesprochen, jetzt nur ONLINE Tools als tag. Produkt bezeichnet. Es gibt natürlich aber auch interne Werkzeuge, sodass man Kommandozeile, Werkzeuge, Import, Export beschreibt, die im Unternehmen selbst Prozesse vereinfachen. So ein Video encoder. Wer zum Beispiel ein Produkt, was man intern einsetzen könnte, oder eine App zur Reisekosten Erfassung für Großunternehmen, die sie intern verwenden können, Branchenlösungen zur Abrechnungen für irgendwelche ärztekammern oder sowas.

Da gibt es viele Tools, die dann teilweise auch auf den arbeitsplatzrechner und fest installiert werden. Das wären ja auch Produkte, die nichts mit Web zu tun haben, aber die man durchaus entwickeln könnte. Wenn man auf diese Nische geht und das Produkt?

Wie würdest du denn empfehlen vorzugehen, wenn ich ein erfolgreiches Produkt bauen möchte?

Ich würde sofort mit Umfragen starten. Das heißt nicht überlegen, wie ich meine Idee validieren kann. Ein Beispiel ist Ich baue eine Landingpage und tu quasi so, als ob das Produkt schon bestünde. Das heißt seine App oder einfach eine Beschreibung, was auch immer muss mir einfallen lassen. Die Landing Page soll quasi beweisen, dass überhaupt User darauf kommen, dass unser Interesse haben. Bin ich zum Beispiel mit Bestellwert Heising arbeite oder Google. Dass ich überhaupt User darauf ziehen kann, dann würde ich einen Button einbauen, wie zum Beispiel Jetzt registrieren oder jetzt kaufen oder mehr Informationen, je nachdem, was ist.

Und dann würde ich auswerten, wie viele User die Seiten gekommen sind, klicken und würden. Man muss sich natürlich überlegen, weil er schon wissen will, was ich ihm dann gebe. Ehrlichkeit am besten. Ich sage Danke, dass du wolltest wie validieren. Gerade eine Idee. Und dafür, dass du jetzt quasi nicht sofort das Produkt haben kann. Nicht so, dass wir, wenn wir das Produkt bauen, auch einen besonderen Preis einräumen oder einen Gutschein, was auch immer.

Du würdest evaluieren. Auf der Seite steht ja das Leistungsversprechen dieses Werkzeuges, das, das sozusagen auf Interesse stößt und Leute sich da sogar eintragen. Genau oder sogar auf bei Klicken, um zu sagen Ja, das ist wertvoll, was du dir da überlegt hast. Und da würde ich gerne dran teilnehmen. Das würde ich auch so sagen. Was auch wichtig ist Es gibt diesen Businessmodell. Kern Was kann ich in einer Episode in den Scharnhorst verlinken? Das ist ein Plan mit einigen Feldern, wo man sich Gedanken macht generell zu dieser Idee, also noch vor der Landingpage.

Vielleicht, dass man sich überhaupt erst mal Gedanken macht Wie monetarisiert das Produkt? Welche Features muss es bringen? Welche Partner brauche ich, um das zu realisieren? Welche Advantage habe ich vielleicht, wenn ich ein Wir sind ein Thi Unternehmen unser Anführer Advantage, das für uns sehr gut mit Althaus kennen und da viele Möglichkeiten kennen, die vielleicht jemand, der nicht aus dem Gewerbe kommt, nicht so einfach nutzen kann? Vielleicht haben dafür andere Unternehmen ein Vertriebs Team, was schon da ist, was Produkte absetzen kann.

Dann wäre das deren Anfeuert. Vantage und die einzelnen Felder dieses Businessmodell kennen. Was sollte man ausfüllen, um sich Gedanken zu machen, wie die Idee überhaupt funktionieren kann? Kann. Ich muss, weil man wird auch immer überrascht von vielen Punkten.

Dieser Businessmodell soll ja quasi unter dem Schirm diese liegen, wo das alles Glaskugeln ist. Ich habe auch schon ein paar Seiten Zeug, natürlich ein bisschen den Markt zu analysieren. Aber gerade diese ganzen Zahlen, die man nicht aus dem Kreuz fünf-jahres-plan Dreijahresplan. Ich glaube, da ist schnellere Iteration und Nutzer.

Befragung und Beobachtung ist da wichtiger, als dass man wirklich sagt Jetzt mal angenommen, deine Website, deine Landingpage, da würden sich genug Leute registrieren, und man würde sagen Okay, ich mache einen ersten Test, dass man sich wirklich ein Feature heraussucht, das Feature und eine ganz Basic Version implementiert, die nur das eine kann, das schon ausliefert an Kunden. Das ist auch ganz wichtig, dass man gerade bei Webentwicklung, wenn es vielleicht nicht daten, kritisch ist, dass man sich traut, das Ding auch online zu stellen und benutzbar zu machen für Kunden, wenn es noch nicht perfekt ist.

Das ist, glaube ich, so eine Krankheit in Deutschland. Nein, und dann wird da noch geschraubt und hier noch geschraubt. Nein, das Ding muss raus, sobald der Kern leistungsversprechen funktioniert und es einigermaßen benutzbar ist. Man kann es ja noch gratis. Stark reduziert anbieten, dass jedem klar ist, dass es eine Testversion ist, aber dass man etwas hat, was also so schnell wie möglich in die virtuellen Hände der Nutzer bekommt, um zu gucken Wie gehen Sie damit um?

Das Lernen muss einfach im Zentrum stehen. Wie gehen Sie damit um? Funktioniert das so? Liefert es ein Wert für die Benutzer? Und diesen Zyklus, dass man den schnellstmöglich startet. Und dann lernt man so schnell haughey. Die Benutzer brauchen eigentlich das. Oder man bekommt sowieso Anfragen. Muss ich das so umbauen? Muss ich das so umbauen? Muss ich das so umbauen? Und dann gibt quasi der Benutzer ein Stück weit vor, wie der Prozess optimal für die Zielgruppe des Benutzers zu funktionieren hat, damit er möglichst ohne Reibungsverluste das Werkzeug nutzen kann.

Und der sogenannte Product Market Fit ist dann erreicht, wenn die Kunden sagen Ja, dieses Tool kostet X im Monat, und das ist auf jeden Fall wert. Dafür bekomme ich ja diese Leistung, und diese Leistung ist viel wichtiger als das Geld, was ich dafür bezahlen.

Das ist auch ganz, ganz wichtig. Das möchte ich noch mal betonen. Zahlen die Kunden für diese Lösungen? Ja, das hört sich jetzt so kapitalistisch an. Meine Philosophie ist die Ein echtes Produkt hat die Kraft oder liefert so viel Wert, dass es sich selber finanzieren kann und die eigene Weiterentwicklung dann auch wirklich finanzieren kann aus dem eigenen Cashflow. Wenn du etwas baust, was zwar genutzt wird, aber die Leute bezahlen nicht dafür, das ist ein Hobby. Das ist kein Produkt für ein Produkt, wird bezahlt und kann aus sich selber wachsen.

Alles, was ich sonst mache, Foren, die gratis betrieben werden, mit Tausenden von Mitgliedern. Hey, dieser Podcast zum Beispiel, der ist ja nicht monetarisiert. Das ist ein Hobby, das kein Produkt. Produkt wird es dann, wenn etwas beginnt, sich selber zu tragen, oder das Potenzial hat, sich selber zu tragen.

Das ist ein Hobby, das ist einfach meine Philosophie.

Und ich denke, das passiert auch, wenn du etwas schaffst, ein Produkt erschafft, was so viel Wert liefert oder was Leuten so wertvoll ist, dass sie einen bestimmten Betrag dafür bezahlen. Dann strömt diese Energie ja auch wieder in dem Produkt zu und gibt dir. Das Geld ist ja nur eine Energieform. Davon kann man niemanden beschäftigen, der das weiterentwickelt. Man kann es selber weiterentwickeln, kann Marketing machen, man kann Grafikdesign machen und als Geld sozusagen wieder in ein besseres Produkt um zurück umwandeln.

Und dann läuft dieser Kreislauf, und dieser Schneeball, der dann rollt, wird dann eben immer größer, oder das Produkt wird immer besser. Allerdings, und das möchte ich jetzt auch ein streuen, das es aber mehr so eine Kritik an Produkten generell. Vielleicht kennst du das auch? Ich habe manchmal das Gefühl, wenn ein Produkt zu gut funktioniert, dann wissen die Entwickler nicht, wann es fertig ist. Das ist auch ein ganz wichtiger Punkt. Irgendwann ist ein Produkt meiner Ansicht nach auch fertig.

Dann kann man es noch warten. Aber es ist ganz wichtig, ist dann nicht mit Tausenden Funktionen zu überfrachten. Und jetzt könnten verschiedene Softwarelösungen Pack Programme sind da ganz vorne. Die fangen an mit als Pack Programm. Irgendwann kann man Videos damit bearbeiten. Das ist für mich immer so ein Symbol zum Zeichen. Jetzt haben wir es wirklich übertrieben. Also Mediaplayer oder Pack Programme finde ich ganz schlimm das man auf einmal einhundert Funktionen da drin hat und keiner benutzt die oder oder Prömel nutzt die.

Meiner Ansicht nach wäre das dann wieder ein anderes Produkt, weil es dann eine andere Zielgruppe anspricht. Aber steht vielleicht auf einem anderen Blatt, wann ein Produkt fertig ist?

Ich meine, das ist natürlich schwierig. Klar. Aber auch Kunden und oder neue. Wiederum ein Produkt, das am Markt bleiben, am Kundennutzen bleiben. Für mich ist es schwierig zu sagen, weil ich es mir schwer nicht mehr weiter lieber.

Gravity, wie sich das auch nicht so, aber zum Beispiel PDF Reader ist für mich so ein Beispiel. So Man hat eine Software installiert, ein Programm installiert, um PDFs anzuschauen.

Das ist die Kernfunktionen, und irgendwann nimmt dieses Werkzeug so überhand, dass es wiederum ein Feature ist, wenn PDF Reader rauskommt. Denn nur PDFs anzeigen kann, der total klein ist 300 Kilobyte, so schnell ein PDF auf klickt und wieder zu klickt. Also unter Windows, dann Sumatra PDF wäre so eines, das man sagt Okay, jetzt ist das normale PDF Programm vom Hersteller so groß geworden, dass wieder ein Markt entsteht für Leute, die einfach nur die Dienstleistung PDF angucken haben wollen.

Und da biete ich jetzt wieder eine abgespeckte Lösung an, die nur die Dienstleistung anbietet. Weißt du das? Der Grund, warum das Produkt ursprünglich mal entstanden ist, so weit aus dem Fokus gerückt ist, dass es wieder ein Feature ist, nur genau diesen Punkt zu bedienen? So, und da wäre für mich so ein Punkt, wo ich sagen würde Jetzt haben wir das Rad zu weit gedreht. Was sind denn die häufigsten Gründe bei ablösungen oder bei Teck Produkten, wenn es nicht klappt?

Entweder bin ich nicht lang genug dran geblieben, zu schnell aufgegeben oder ich hab das vielleicht unterschätzt, was meine Arbeit ist und kann ich alleine nicht leisten. Also bin ich Programmierer, bin zum Beispiel kann ich das Marketing nicht selber machen? Ich bin und finde auch keine geeigneten Partner. Wenn ein Produkt dann erfolgreich werden soll, kann man das schon allein nicht mehr schaffen. So wie früher. Keine Ahnung. Einer hingesetzt hat und in drei Tagen programmiert und komplizierte Teams daran mehrere Jahre.

Ich will jetzt nicht sagen, dass die Entwicklung so weiter genauso kompliziert ist. Aber als Einzelkämpfer ist es schwierig. Man braucht jemanden, mit dem man sich austauschen kann, Sparringspartner, der vielleicht sogar einem anderen Gebiet unterwegs ist als man selbst. Das sind für mich die Gründe.

Das ist auch so ein verzerrtes Bild, das man wie bei meinen Krafft oder so dann denkt Oh, das hat jemand alleine programmiert. Aber man blendet aus, dass der irgendwie zehn Jahre vorher schon nur Spiele programmiert hat, also das auch sein 21. Versuch ist und das zufällig jetzt einer von Hunderttausenden Mal so ein Hit gelandet hat. Aber wenn man heute zuhause sitzt und darüber nachdenkt, ein erfolgreiches Produkt zu bauen, dann möchte ich ja nicht Lotto spielen und sagen Okay, die Wahrscheinlichkeit ist eins zu 100 000, dann lege ich mal los, sondern ich möchte ja.

Ich glaube ja, dass ich ein wichtiges Problem löse und möchte, dass möglichst smart angehen. Was natürlich auch zur Folge haben kann, dass man herausfindet, dass das Problem, was man selber glaubt, was wichtig ist, gelöst zu werden, gar nicht so wichtig ist. Das glaube ich. Ehrlich gesagt Ist denn Nummer 1 Grund, warum Produkte scheitern, dass Lösungen gebaut werden für Probleme, die zu wenige Menschen haben oder wo zu wenige Menschen bereit sind, dafür zu bezahlen?

Ja, da bin ich gespaltener Meinung. Jetzt wirds spannend. Also ich finde, man muss nicht immer ein Problem lösen, um erfolgreiches Produkt haben. Bestes Beispiel Apple und dem iPod. Was für ein Problem hatte man damals mit dem Walkman Cassette?

Langsam muss es ja nicht, dass es langsam mal Schnelleres gab. Das war damals halt Alltag. Es stand der Technik. Du hattest kein Problem, nur Musik gehört. Und auf einmal kam einer, der einfach ein besseres Produkt, also mehr Lieder und Songs speichern, schnell hin und her spulen konnte, nicht einfach ein Produkt, was es schon gab, verbessert oder mit dem Telefon genauso? Wir hatten kein Problem mit dem Telefon. Problem gelöst. Da ist es noch eher so, aber er hat einfach irgendwas erschaffen, das die Leute noch gar nicht wussten, dass das was ist.

Das würde ich faszinieren und ab dem Nichts ein Ding zu erschaffen, wo die Leute gar nicht wissen, was sie wollen, dass es auf jeden Fall die höchste Kunst.

Man darf natürlich nicht vergessen, dass bei Apple die smartes Leute arbeiten mit den größten Budgets, die man sich überhaupt vorstellen kann, und dass man da natürlich andere Möglichkeiten hat, als das vielleicht jetzt ein mittelständisches Unternehmen ganz klar hat. Aber das muss man auch sagen. Apple geht natürlich auch die großen Probleme an, einen Computer einfach zu bedienen. Die Musikindustrie zu revolutionieren, die Telefon Industrie einfach zu revolutionieren. Und das haben sie jedes Mal geschafft. Das muss man auch.

Muss man den Hut ziehen? Da ist es ja so, dass Sie im Markt auch erschaffen haben. Ja, da hast du recht. Das ist ganz große Kunst. Da gibt es nichts zum umzu Reden. Noch Gründe, warum es schwer wird für. Ich sag einfach mal Start ups oder so. Loprieno wäre die eigene Projekte. Bauen Sie direkt am Anfang alles wollen, was das eben mit zu früh aufgeben bezeichnet. Und es muss sicher sein, und das muss sexy sein.

Es muss gut aussehen, und es muss schnell sein, und es muss perfekt skalieren. Und das Marketing muss sitzen, das man einfach zu viel will und dann untergeht. Früh das Produkt ausliefern, wenn es etwas kann, und dann lernen mit dem Kunden. Das, glaube ich, ist der erfolgsversprechend weg, anstelle fünf Jahre im Kämmerlein das Produkt zu entwickeln. Und dann? Tadashi ist es, und niemand hat auf dich gewartet, so wie ihr das mit dieser Plattform hattet, von der du gesprochen, dass man an das Beispiel Summen denkt.

Anfang des Jahres dieser Video Spätdienst, die haben ja auch erst Sicherheit eingebaut, als es zum Problem wurde. Wenn man mal böse sagt Nein, im Moment, wo die halbe Welt das benutzt hat. Doch eine Priorität, aber auch die gibt es noch, die leben noch und das hat sie nicht umgebracht. Dass sie dann schnell, schnell die Sicherheit noch dran geschuftet haben.

Wie übrigens auch viele andere. Das ist auch kein Geheimnis. Wer die PayPal Geschichte kennt, der weiß, dass auch PayPal sehr viel Geld verloren hat. In den Anfangszeiten einfach durch, also durch Kreditkartenbetrug. Und die haben das einfach erstattet, bis irgendwann das Budget für Erstattungen von Kreditkartenbetrug so groß war, dass sie gesagt haben Da kann man jetzt auch eine Lösung für entwickeln, dass das gar nicht mehr passiert, weil wir glauben, dass das mittlerweile günstiger ist. Und die haben das sozusagen einfach übers Bankkonto entschieden.

Und einen Grund hast doch schon angesprochen, dass sich das Team nicht gut ergänzt. Also 100 Teck Könige? Das wird schwierig, sondern man muss ein bisschen. Also ich glaube, man muss sich schon gut verstehen, sonst macht das nicht so viel Spaß, und man kommt doch nicht so weit. Aber die Kompetenzen müssen sich gut ergänzen. Der eine ist ein bisschen zurückhaltender, dafür kontrollierter, etwas besser. Der andere ist Puschilin und setzt sich durch, guckt nicht so genau hin, aber der bringt halt auch die Sachen vorwärts, sodass man da alle Perspektiven ein bisschen bedenkt.

Um da nicht zu sehr auf die Füße zu fallen und auch Chancen nutzt, wenn sie da stehen und nicht zu verkopft, die an sich vorüberziehen lässt.

Und was passieren kann, ist, wie Gekehrten startet. Und dann, wenn das mal heiß und unproblematisch, dann geht sowas auch oft schief. Man streitet sich um, geht irgendwie auseinander. Deswegen hoch her, egal wie gut man sich versteht. Alles zu regeln. Einmal eine Woche einschliessen, alles schriftlich fixieren für den Fall der Fälle, damit kein böses Blut gibt, hat das bei Klarheit hat also vielleicht nicht genau ganz am Anfang.

Aber sobald das professionellere Züge annimmt, würde ich das auch so sehen. Und man jetzt gemeinschaftlich entscheidet da substanziell Zeit, Geld zu investieren. Dann auf jeden Fall. Wenn da noch andere Kulturen aufeinandertreffen. Du hast schon von Offshoring gesprochen. Ich habe auch meine eigenen Offshoring Erfahrungen. Nein, nicht immer. Nein, heißt ja nicht immer Ja, heißt so oder so. Zeitplanung, das als durchaus kreativ ausgelegt werden kann, das sind dann andere Herausforderungen, die man meistens selbst unterwegs klar werden.

Super. Vielen Dank mir.

Sehr, sehr gerne. Ja, mir auch wie immer. Auch wenn, wenn alte Erinnerungen und Wunden.

Es gibt eine Veranstaltungsreihe, ich weiß sie in Düsseldorf abgehalten wird. Ich bin mir nicht sicher, ob Sie auch in anderen Städten Deutschlands abgehalten werden, die sogenannten FA-Cup Neids, wo Unternehmer von ihren schlimmsten fals erzählen. Ich weiß nicht, ob es die schlimmsten sind oder von fals erzählen Fehlentscheidungen, die sie getroffen haben. Dinge, die gehörig daneben gegangen sind. Das ist ein großer Erfolg, weil gerade in Deutschland, öSTERREICH und der Schweiz spricht man ja nicht so gerne übers Scheitern.

In Amerika ist es okay, bisher hingefallen. Jetzt ist wichtig, aufzustehen und weiterzumachen. Da ist ist man schneller verbrannt. Deshalb spielt man hier mehr auf Sicherheit. Da ist das ein ganz erfrischendes Format, das man sich mal angucken kann. Ich glaube, es sind auch Videos davon online. Also einfach mal FA-Cup, Neids Düsseldorf bei YouTube suchen oder FA-Cup Neids generell suchen. Und da gibt es einige Videos dazu und auch Veranstaltungen. Wenn unsere Zuhörer Fragen haben oder Feedback zu der Podcast Episode, können Sie gerne ein E-Mail schicken an Podcast Gilbert.

Lass uns gerne eine Bewertung da und abonnieren sein Kanal. Weitere spannende Technologie Themen findet ihr auf skillbyte Slash Blog. Wir freuen uns immer über Kommentare. Ich wünsche noch einen schönen Abend bis zum nächsten Mal.

Maurice KnoppSkillbyte Podcast #27: Erfolgreiche (Tech-) Produkte bauen – so geht’s!
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 #14: Big Data und Machine Learning Projekte richtig angehen

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

In diesem Podcast geht es um das Thema: Big Data und Machine Learning Projekte richtig angehen

// Inhalt //
01:15 – Definition & Beispiele: Was ist ein Big Data Projekt?
01:59 – Ist das wirklich ein Big Data Projekt und erfüllt es 2 der 3Vs?
03:58 – Big Data Maturity Model für Technologie und Unternehmen
05:41 – Anamnese – Wo steht der Kunde heute?
07:26 – Agile Task Force für kleine Projekte statt Big Bang
08:51 – Big Data Projekte im Business Development
10:54 – Fokus durch Minimal Viable Product
13:54 – Kategorien von Big Data Projekten
17:54 – Big Data Beispielprojekt
20:27 – Warum die schelle Entwicklung eine Proof of Concept wichtig ist!
22:18 – Schritt 1: Welche aktuellen Big Data Technologien gibt es?
23:54 – Schritt 2: Wo steht der Kunde heute?
25:13 – Orchestrierung der richtigen Technologie Komponenten ist die Kunst
27:02 – Das CAP Theorem
29:14 – Datenhoheiten in der Organisation
30:20 – Schritt 3: Zielbild – Was möchte der Kunde erreichen?
31:35 – Schritt 4: Umsetzung / Proof of Concept
32:18 – Ideen-Backlog
33:17 – Continuous Improvement
37:42 – Beispiele für Big Data Projekte
40:00 – Große Daten, Kleine Daten

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

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #14: Big Data und Machine Learning Projekte richtig angehen
Mehr