In einer sich ständig verändernden Geschäftswelt ist Innovation ein Schlüssel zur Wettbewerbsfähigkeit. Unser Vortrag gewährt Einblicke in die laufende Einführung des Continuous Innovation Framework (COIN) bei KPS. Wir teilen wertvolle Praxiserfahrungen, vom Umgang mit Widerständen bis zur Schaffung einer agilen Innovationskultur. Entdecken Sie, wie COIN unsere Organisation transformiert und Innovationsbemühungen lenkt. Erfahren Sie mehr über bereits gescheiterte Ansätze, die Grundlagen des Continuous Innovation Framework und praktische Herausforderungen bei der Umsetzung. Ein Ausblick auf zukünftige Auswirkungen von Continuous Innovation bei KPS rundet den Vortrag ab und bietet wertvolle Erkenntnisse für die Umsetzung von Innovationsprozessen in anderen Unternehmen.

Zielpublikum: Innovatoren, Innovation Coaches, Manager, Entscheider, Architekten, Entwickler und alle, die gerne Innovationen in ihrem Unternehmen vorantreiben möchten
Voraussetzungen: Es gibt keine Voraussetzungen. Wissen über die Entwicklung von Geschäftsmodellen und Interesse für das Thema Innovation sind jedoch von Vorteil.
Schwierigkeitsgrad: Einsteiger

Es war eine schlimme Woche: Am Montag wurde die Rechtsabteilung aufgefordert, den Code unserer Anwendung vollständig zu veröffentlichen – eine eingesetzte Open-Source-Bibliothek zwingt uns dazu. Am Mittwoch musste ein neuer Release zurückgerollt werden, weil der fremde Autor sein offenes JavaScript-Modul überraschend funktionsuntüchtig gemacht hat. Freitag haben wir schließlich herausgefunden, dass der Rollout der neusten Version einer unserer Open-Source-Basislösungen wegen eines Sicherheitsproblems dringend wird. Leider haben wir das Paket stark erweitert – weshalb jeder Versionswechsel Wochen dauert und riskant ist. Wie konnte es so weit kommen? Und mehr noch: Welche Architekturentscheidungen verhindern so etwas?

Zielpublikum: Entwickler, Architekten, Projektpraktiker
Voraussetzungen: Interesse am risikoarmen Einsatz von Open Source
Schwierigkeitsgrad: Fortgeschritten

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/bernd.rederlechner

Kritische Fehler, die erst im Rahmen des Live-Betriebes öffentlich werden, stellen nicht zuletzt eine negative Werbung für ein Produkt und die beteiligten Unternehmen dar. Um dies zu verhindern, ist das Thema Qualitätssicherung in der modernen Produktentwicklung und -fertigung ein grundlegender und integraler Bestandteil. Nur durch eine hohe Testabdeckung und die zeitnahe Rückmeldung von Ergebnissen lässt sich die Qualität und Reife des Produkts ausreichend genau nachweisen und bestätigen. Die grundlegenden Parameter im Bereich Manufacturing & Industry haben sich nicht geändert: Die Entwicklung erfolgt hardwarenah und es kommen etablierte industrielle Standards und Entwicklungswerkzeuge zum Einsatz. Für die Entwicklung sind meist Ingenieure oder Naturwissenschaftler verantwortlich und es gibt definierte Vorgaben durch ein Qualitätsmanagement in der Entwicklung und Produktion. Doch der Anteil der Softwareentwicklung hat sich in den letzten Jahren stark erhöht. Das liegt zum Beispiel daran, dass sich der Anteil der Wertschöpfung der Produkte stark auf die Software bzw. softwarebasierende Services stützt. Außerdem ergeben sich durch die Vorgaben der Digitalisierung und Industrie 4.0 neue Anforderungen für Hardwareentwicklungsprojekte im industriellen Umfeld. Das bekannte Ebenenmodell der Automatisierungspyramide wird "aufgebrochen" und Technologien wie MQTT, REST oder OPC-UA greifen direkt Daten ab. Mit diesen Daten werden Use Cases wie IIoT, BI oder Künstliche Intelligenz mit Informationen versorgt.

Understanding what is happening in your cluster can be challenging. How can you quickly and easily tell if your cluster and apps are healthy, well utilized and running as expected? In this tutorial, we'll look at various aspects of Kubernetes observability, and present multiple OSS solutions from the CNCF landscape and beyond to achieve that. We will start with tools that simply query the Kubernetes API and deliver the output in an easy-to-understand UI (e.g. Skooner, k9s), go over sidecar-based and eBPF-based services meshes (e.g. Istio/Kiali, Cillium/Hubble UI) and end with application-side logging and monitoring (e.g. OpenTelemetry, fluentd, Jaeger, Grafana). Each level of observability demands a certain price in terms of configuration and runtime overhead. In turn the quality and depth of the information is different. The intended take-away is to get an understanding which type of tooling is the right one for a given purpose.

Target Audience: Developers, Architects
Prerequisites: None
Level: Basic

Die Architektur einer Anwendung ist wichtig, darüber gibt es wohl keine zwei Meinungen. Aber wer ist dafür zuständig? Ein eigener Softwarearchitekt? Dieses oft als altmodisch betrachtete Denken passt so gar nicht in die moderne agile Welt: Architektur ist Aufgabe des Teams! Ist das wirklich so? Aus seinem Berateralltag erzählt David viele spannende Beispiele und zeigt, dass die Antwort ein ganz klares "Jein" ist und wer wann genau welche Aufgabe übernehmen sollte.

Zielpublikum: Softwareentwickler, Architekten, Entscheider
Voraussetzungen: Basisverständnis der Softwareentwicklung
Schwierigkeitsgrad: Fortgeschritten