In modernen Software-Landschaften werden die Fachlichkeiten mit Hilfe von DDD sauber voneinander abgegrenzt und als eigenständige Services umgesetzt.
Was muss in der Entwicklung eines solchen Services beachtet werden, um diese Eigenständigkeit zu gewährleisten und gleichzeitig sicherzustellen, dass alle Services gemeinsam als ein großes Ganzes funktionieren?
Service-Konsumenten sollen Schnittstellen nach Möglichkeit nutzen können, ohne Aufwand beim Anbieter der Schnittstelle zu verursachen. Das Ziel ist es, Features schnell und unabhängig umsetzen zu können.
In dem Vortrag wird vorgestellt, wie man eine hohe Nutzerzufriedenheit durch Consumer-Centric API Design und regelmäßige Produktiv-Deployments erzielt.
Möglich wird das durch ein sauberes API-Design, eine schlanke Microarchitektur und eine hohe Testautomatisierung. An praktischen Beispielen wird gezeigt, wie das erreicht werden kann.
Versteht man seine Anwendung als Kombination (fast) unabhängiger Services, so ergeben sich nicht nur für Entwicklung und Deployment neue Perspektiven.
Denn nicht nur die eigenen Services können internen oder externen Dritten zur Verfügung gestellt werden, sondern auch der umgekehrte Weg ist denkbar.
Eine entsprechend flexible Architektur vorausgesetzt, lässt sich die eigene Fachlichkeit durch 3rd Party Services sinnvoll und gewinnbringend ergänzen, ohne dabei das Rad neu erfinden zu müssen.
Besonders interessant scheint hier das Feld der künstlichen Intelligenz zu sein. Egal ob automatische Texerkennung, Retourenvorhersagen, Qualitätsicherung in der Produktion oder die Vorhersage von Terminen zur Maschinenwartung; die Möglichkeiten scheinen nahezu unbegrenzt.
Die Session zeigt, welche Möglichkeiten heute bereits Out-of-the-Box AI Services bieten und für welche Aufgaben man doch besser einen ML Experten mit ins Boot holen sollte.
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
Believing the analysts Serverless Computing will be the “next big thing”. Thanks to NoOps, writing a serverless function and bringing it to production is quite easy. And also combining some of them to build up a more complex system seems to be not too complicated at all. But what are suitable scenarios for Serverless Computing? When to favor serverless over other architectural approaches and when not? Are there any specific patterns to be aware of when applying serverless? How does the serverless paradigm influence the software lifecycle, e.g. testing and monitoring? A lot of open questions to be answered!
Wer Microservices implementiert, wird schnell feststellen, dass ihn viele Herausforderungen erwarten, die er bis dahin nicht gekannt hat. Resilience, Service Discovery, verteilte Autenfizierung, Tracing und Health Checks sind Themen, die man als Entwickler nicht jedes Mal neu erfinden möchte. Aber zum Glück gibt es da etwas von der Eclipse-Foundation – das MicroProfile. Eine Spezifikation, die mit ihren verschiedenen Implementierungen den technischen Herausforderungen von Microservices eindrucksvoll begegnet. Egal ob Health Check, Metrics, Fault Tolerance, JWT Propagation, Configuration, Tracing oder Open API, das MicroProfile hat die passenden APIs im Gepäck. Mit viel Code und wenig Slides wirft dieser Workshop einen Blick auf die jeweiligen APIs, zeigt sie im Praxiseinsatz und stellt Vorteile und Probleme vor.
Spendiert man jedem Microservice seine eigene Datenbank (Database-per-Service-Pattern), hat man irgendwann unweigerlich das Problem verteilter Businesstransaktionen. Die gute alte DB-Transaktion fällt per Definition aus dem Rennen. Lässt sich also aus fachlicher Sicht ganz auf Transaktionen verzichten? In vielen Fällen ist das durchaus möglich. Als Alternative zur Sicherstellung Service-übergreifender Datenkonsistenz bietet sich u. a. eine Realisierung auf Basis mehrerer lokaler technischer Transaktionen an, auch Saga-Pattern genannt. Die Session führt in die Theorie des Saga-Patterns ein und zeigt seine praktische Verwendung an verschiedenen Beispielen.
„Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer cloudspezifischer Architekturmuster? Im Rahmen des Workshops werden wir Schritt für Schritt eine bestehende Enterprise-Anwendung in die Cloud migrieren. Angefangen bei der Nutzung von Cloudinfrastruktur (IaaS) über die Anbindung von Cloudplattformkomponenten (PaaS) und Backend-Services (BaaS) bis hin zu Serverless Functions (FaaS) werden wir für die unterschiedlichen Anwendungsszenarien unserer Applikation passende Architekturansätze entwerfen und deren Vor- und Nachteile diskutieren. Natürlich sprechen wir dabei auch Themen wie Testing, Monitoring und automatisiertes Deployment an.
Mit dem Begriff „Microservice-Architektur“ wird der Architekturstil beschrieben, bei dem mehrere unabhängige Services eine Applikation bilden.
Aber in welchen Situationen ist die Wahl dieses Ansatzes sinnvoll? Welche Konsequenzen hat es, wenn ich mich dafür entscheide? Wie finde ich den richtigen Service-Schnitt? Und wie baue ich ein passendes Frontend dazu?
Der Vortrag gab einen guten Überblick über die Herausforderungen und deren Lösungsmöglichkeiten und beleuchtete dabei auch Themen wie Testing und Continuous Delivery.
In modernen Software-Landschaften werden die Fachlichkeiten mit Hilfe von DDD sauber voneinander abgegrenzt und als eigenständige Services umgesetzt.
Was muss in der Entwicklung eines solchen Services beachtet werden, um diese Eigenständigkeit zu gewährleisten und gleichzeitig sicherzustellen, dass alle Services gemeinsam als ein großes Ganzes funktionieren?
Service-Konsumenten sollen Schnittstellen nach Möglichkeit nutzen können, ohne Aufwand beim Anbieter der Schnittstelle zu verursachen. Das Ziel ist es, Features schnell und unabhängig umsetzen zu können.
In dem Vortrag wird vorgestellt, wie man eine hohe Nutzerzufriedenheit durch Consumer-Centric API Design und regelmäßige Produktiv-Deployments erzielt.
Möglich wird das durch ein sauberes API-Design, eine schlanke Microarchitektur und eine hohe Testautomatisierung. An praktischen Beispielen wird gezeigt, wie das erreicht werden kann.
Versteht man seine Anwendung als Kombination (fast) unabhängiger Services, so ergeben sich nicht nur für Entwicklung und Deployment neue Perspektiven.
Denn nicht nur die eigenen Services können internen oder externen Dritten zur Verfügung gestellt werden, sondern auch der umgekehrte Weg ist denkbar.
Eine entsprechend flexible Architektur vorausgesetzt, lässt sich die eigene Fachlichkeit durch 3rd Party Services sinnvoll und gewinnbringend ergänzen, ohne dabei das Rad neu erfinden zu müssen.
Besonders interessant scheint hier das Feld der künstlichen Intelligenz zu sein. Egal ob automatische Texerkennung, Retourenvorhersagen, Qualitätsicherung in der Produktion oder die Vorhersage von Terminen zur Maschinenwartung; die Möglichkeiten scheinen nahezu unbegrenzt.
Die Session zeigt, welche Möglichkeiten heute bereits Out-of-the-Box AI Services bieten und für welche Aufgaben man doch besser einen ML Experten mit ins Boot holen sollte.
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
Believing the analysts Serverless Computing will be the “next big thing”. Thanks to NoOps, writing a serverless function and bringing it to production is quite easy. And also combining some of them to build up a more complex system seems to be not too complicated at all. But what are suitable scenarios for Serverless Computing? When to favor serverless over other architectural approaches and when not? Are there any specific patterns to be aware of when applying serverless? How does the serverless paradigm influence the software lifecycle, e.g. testing and monitoring? A lot of open questions to be answered!
Wer Microservices implementiert, wird schnell feststellen, dass ihn viele Herausforderungen erwarten, die er bis dahin nicht gekannt hat. Resilience, Service Discovery, verteilte Autenfizierung, Tracing und Health Checks sind Themen, die man als Entwickler nicht jedes Mal neu erfinden möchte. Aber zum Glück gibt es da etwas von der Eclipse-Foundation – das MicroProfile. Eine Spezifikation, die mit ihren verschiedenen Implementierungen den technischen Herausforderungen von Microservices eindrucksvoll begegnet. Egal ob Health Check, Metrics, Fault Tolerance, JWT Propagation, Configuration, Tracing oder Open API, das MicroProfile hat die passenden APIs im Gepäck. Mit viel Code und wenig Slides wirft dieser Workshop einen Blick auf die jeweiligen APIs, zeigt sie im Praxiseinsatz und stellt Vorteile und Probleme vor.
Spendiert man jedem Microservice seine eigene Datenbank (Database-per-Service-Pattern), hat man irgendwann unweigerlich das Problem verteilter Businesstransaktionen. Die gute alte DB-Transaktion fällt per Definition aus dem Rennen. Lässt sich also aus fachlicher Sicht ganz auf Transaktionen verzichten? In vielen Fällen ist das durchaus möglich. Als Alternative zur Sicherstellung Service-übergreifender Datenkonsistenz bietet sich u. a. eine Realisierung auf Basis mehrerer lokaler technischer Transaktionen an, auch Saga-Pattern genannt. Die Session führt in die Theorie des Saga-Patterns ein und zeigt seine praktische Verwendung an verschiedenen Beispielen.
„Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer cloudspezifischer Architekturmuster? Im Rahmen des Workshops werden wir Schritt für Schritt eine bestehende Enterprise-Anwendung in die Cloud migrieren. Angefangen bei der Nutzung von Cloudinfrastruktur (IaaS) über die Anbindung von Cloudplattformkomponenten (PaaS) und Backend-Services (BaaS) bis hin zu Serverless Functions (FaaS) werden wir für die unterschiedlichen Anwendungsszenarien unserer Applikation passende Architekturansätze entwerfen und deren Vor- und Nachteile diskutieren. Natürlich sprechen wir dabei auch Themen wie Testing, Monitoring und automatisiertes Deployment an.
Mit dem Begriff „Microservice-Architektur“ wird der Architekturstil beschrieben, bei dem mehrere unabhängige Services eine Applikation bilden.
Aber in welchen Situationen ist die Wahl dieses Ansatzes sinnvoll? Welche Konsequenzen hat es, wenn ich mich dafür entscheide? Wie finde ich den richtigen Service-Schnitt? Und wie baue ich ein passendes Frontend dazu?
Der Vortrag gab einen guten Überblick über die Herausforderungen und deren Lösungsmöglichkeiten und beleuchtete dabei auch Themen wie Testing und Continuous Delivery.
Jeder Service für sich kann unabhängig deployed und skaliert werden.
Gerade Cloud Computing erleichtert in vielen Unternehmen die Verwaltung der IT-Infrastruktur. Weil die für die Software benötigte Plattformen so einfach anzumieten sind, werden Developer deshalb immer mehr in die Rolle des DevOps gedrängt -- die Software, die sie entwickeln, soll auch selbst betrieben werden -- You build it, you run it.
Doch diese Strukturierung ist nicht ganz kostenlos - Developer müssen dadurch immer mehr Verantwortung übernehmen. Um dieser Verantwortung gerecht zu werden, muss eine Schwachstelle ausgeschaltet werden: der Mensch. Im Talk gehe ich auf Prozesse der klassischen Softwareentwicklung ein und lege dar, wie diese in dem “You build it, you run it”-Modell verbessert werden.
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“OPEN KNOWLEDGE GmbH
„Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer Cloud-spezifischer Architekturmuster? Wie kann uns das Cloud Maturity Model dabei helfen? Und was steckt eigentlich hinter Akronymen wie IaaS, PaaS, BaaS, SaaS und FaaS?
Im Rahmen des Worskhops werde ich eine klassische Enterprise Anwendung Schritt für Schritt in die Cloud migrieren und dabei die verschiedenen Stufen / Reifegrade des Cloud Maturity Models durchlaufen. Angefangen bei "Lift & Shift" bis hin zu "Cloud Native" und "Cloud Voodoo – aka Serverless".
Der goldene Schnitt – Wie schneide ich Microservices richtig?OPEN KNOWLEDGE GmbH
Mit Microservices wird versucht, eine Anwendung in möglichst kleine, unabhängige Teile zu schneiden, die dann miteinander kommunizieren. Diese Idee bringt einige Vorteile mit sich. Wie bekommt man es aber hin, dass dabei die Fachlichkeit nicht zerpflückt wird und so der Blick für das große Ganze verloren geht? Wie schneide ich die Services richtig? Und worauf muss bei der Kommunikation der Services untereinander geachtet werden? Der Workshop zeigt, wie Domain-driven Design dabei helfen kann, diese Fragen sinnvoll zu beantworten, und was es sonst noch zu beachten gilt.
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“OPEN KNOWLEDGE GmbH
„Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer cloud-spezifischer Architekturmuster? Und was steckt eigentlich hinter Akronymen wie IaaS, PaaS, BaaS, SaaS und FaaS?
Im Rahmen der Session werden ich Schritt für Schritt eine bestehende Enterprise-Anwendung in die Cloud migrieren. Angefangen bei der Nutzung von Cloudinfrastruktur (IaaS) über die Anbindung von Cloudplattformkomponenten (PaaS) und Backend-Services (BaaS) bis hin zu Serverless Functions (FaaS) werden wir für die unterschiedlichen Anwendungsszenarien unserer Applikation passende Architekturansätze entwerfen und deren Vor- und Nachteile diskutieren. Natürlich sprechen wir dabei auch Themen wie Testing, Monitoring und automatisiertes Deployment an.
Die Matrix: Enterprise-Architekturen jenseits von MicroservicesOPEN KNOWLEDGE GmbH
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
Getreu dem Motto "choose Microservices for the benefits and not because your codebase is a mess." (Zitat: Simon Brown), beleuchtet die Session typische Problemstellungen aus großen Projekten und zeigt auf, für welche dieser Microservices eine Lösung darstellen und für welche eher nicht. Anhand verschiedener Real-Life-Anforderungen, werden alternative Architekturen als Lösungsansätze gezeigt und bewertet.
Da hat man einmal eine tolle Idee für eine Mobile-App und möchte sie so schnell wie möglich realisieren, und dann scheitert das Ganze am Ende am passenden Backend. Zu aufwendig und riskant die Anpassung des bestehenden Web-Backends, zu zeitintensiv und teuer die Entwicklung eines neuen Mobile-Backends. Von mangelnder Skalierung, Security und Co. ganz zu schweigen. Aber kein Grund zur Panik: Wo ein Wille ist, ist auch ein Weg. Die Session zeigt, wie bestehende Backends für Mobile-Apps „enabled“ und neue Backends on the fly via Cloud-Anbieter zur Verfügung gestellt werden können. SaaS, PaaS, BaaS und BFF heißen die Akronyme der Stunde. Was nimmt man wann? Auflösung folgt …
Eine Anwendung basierend auf Microservices mit Java zu entwickeln kann ja so schwer nicht sein. Schließlich gibt es Frameworks wie Spring Boot oder MicroProfile, die dem Entwickler das technologische Rahmengerüst vorgeben. Nur leider ist es damit nicht getan. Wie zum Beispiel sieht der optimale Service-Schnitt aus? Wie kommunizieren die Services untereinander, ohne dabei ihre Unabhängigkeit zu verlieren? Wie soll die Anwendung reagieren, wenn mal ein Service nicht so kann, wie er soll? Und wie bindet man seine Microservices an bestehende Infrastruktur wie Distributed Tracing, Monitoring oder Identity Provider an?
Was sich in der Theorie einfach anhört, bringt in der Praixis so manchen Stolperstein mit sich. Im Rahmen des Workshops werden wir daher gemeinsam eine kleine, auf Microservices basierende Anwendung bauen und zum „Fliegen“ bringen. Angefangen bei der Diskussion über den optimalen Service-Schnitt via Domain-driven Design, über die Integration der Services untereinander via unterschiedlicher Kommunikationspatterns inkl. eingebauter Fehlertoleranz bis hin zur Instrumentalisierung der Services zwecks Laufzeitanalyse und -optimierung, lassen wir dabei kaum ein Thema aus.
Am Ende steht eine Anwendung, die live gehen könnte – naja, fast.
Künstliche Intelligenz ist auf dem Vormarsch, ohne Zweifel. Egal ob Qualitätssicherung in der Produktion, Retourenmanagement im Online-Handel oder Customer-Support via Chatbot: KI eröffnet bisher noch nicht dagewesene Möglichkeiten, die eigenen Prozesse und Geschäftsmodelle deutlich zu verbessern - vorausgesetzt man verfügt über hinreichend viele und qualifizierte Daten.
Aber wie lässt sich KI in die eigene Software-Architektur integrieren? Wer befindet über das richtige Modell und den richtigen Algorithmus? Und wie wird über die hinreichende Quantität / Qualität von Daten entschieden? Die Rolle des KI-Architekten scheint geboren.
Die Session veranschaulicht die verschiedenen Herausforderungen, die sich durch das Einbinden von KI für die eigene Software-Entwicklung ergeben können und zeigt dafür passende, pragmatische Lösungsansätze auf.
Das ist doch alles nur Frontend - Wer braucht da schon Architektur?OPEN KNOWLEDGE GmbH
Single-Page-Applications -ursprünglich als kleines fancy Frontend gestartet- sind in den letzten Jahren zu großen, schwergewichtigen eigenen Applikationen angewachsen, die fehleranfällig, schwer wartbar und langsam in der Weiterentwicklung sind. Aber woran liegt das eigentlich? Im Frontend gibt es als Abstraktion zumeist nur das Konzept der Komponenten. Eine tiefergehende Analyse der benötigten Bausteine bleibt in der Regel aus. Im Backend hingegen, erfolgen solche Analysen seit Jahren.
Aber lassen sich die Backend-Architektur-Konzepte ohne weiteres für das Frontend übernehmen? Was sind die Herausforderungen, in denen sich moderne Frontends von klassischen Backends unterscheiden? Wo braucht man daher andere Lösungen? Neben der Problemanalyse gibt dieser Talk konkrete Bausteine an die Hand.
Das „Schwergewicht“ Java EE scheint nicht wirklich mit der Wunderwelt der Microservices und den damit einhergehenden Architekturpatterns zu harmonisieren. Dabei bringt der Java-Enterprise-Standard technologisch gesehen alles mit, was es zur Umsetzung von Microservices benötigt. Wo also liegt das Problem? In der Session werden wir Schritt für Schritt eine monolithische Java-EE-Anwendung „sezieren“ und uns den damit einhergehenden Herausforderungen der neu entstandenen, Microservice-basierten Architektur stellen. Aha-Effekte garantiert!
Jeder redet von Continuous Delivery, aber was macht eine gute Development-, Testing- und Delivery-Pipeline aus? Diese Session soll zeigen, welche Schritte nötig sind, um das Ziel Continuous Delivery zu erreichen. Neben Themen wie Update- und Roll-out-Strategie werden ebenso Crash Reports und Analytics-Möglichkeiten beleuchtet.
Die Zeiten einfacher Web-Anwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle, wie Web, Desktop, Mobile oder 3rd Party Clients, parallel bedienen zu müssen. Und das mit einer Architektur. Wie aber sieht eine passende Architektur aus? Welche neuen Herausforderungen ergeben sich durch die zusätzlichen Kanäle? Und welche Auswirkungen hat dies auf Aspekte wie Security, Schnittstellendesign oder das Datenmodell? In der Session „öffnen“ wir eine Web-Anwendung und stellen uns den Herausforderungen.
Oftmals wird "Multi-Channel" gleichgesetzt mit Responsive Design. Dies setzt allerdings voraus, dass jeder Channel mehr oder minder dieselben Use-Cases bedient. Ein echter Business-Mehrwert wird aber erst erreicht, wenn jeder Channel seine speziellen Eigenschaften ausspielt, was automatisch eine deutlich größere Flexibilität - auch auf Ebene der Architektur - verlangt. Genau hier setzt die Session an und zeigt, wie eine Architektur aufgebaut sein sollte, die deutlich mehr erlaubt als "nur" Responsive Design.
Eine Serverless Function zu schreiben ist denkbar einfach. Und auch die Kombinationen mehrerer FaaS zu einem komplexeren System ist kein Hexenwerk. Was aber, wenn die niedlichen kleinen Funktionen sich zur Laufzeit nicht so verhalten, wie gewünscht? Wie sieht das Monitoring der einzelnen Funktionen und des Systems als Ganzes aus? Und was ist mit Testen? Muss die Funktion dazu immer in der Cloud deployt werden oder kann man das produktive System auch lokal emulieren? Wie wichtig ist der Aspekt der Automatisierung und wie wird diese erreicht? Wie beeinflussen Cold- und Warm-Start das Laufzeitverhalten? Diesen und vielen anderen Herausforderungen wollen wir uns in der Session stellen – Aha-Effekte garantiert!
Die Zeiten einfacher Webanwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle wie Web, Desktop, Mobile oder 3rd-Party-Clients parallel bedienen zu müssen. Und das mit einer Architektur, die am besten auch noch zukünftigen, bisher noch nicht bekannten Anforderungen standhält. Wie aber sieht eine solche Architektur aus? Welche neuen Herausforderungen ergeben sich durch die Öffnung für zusätzliche Kanäle? Und welche Auswirkungen hat das alles auf Themenbereiche wie Security, Schnittstellendesign, Versionierung oder das Domänen- bzw. Datenmodell? Im Rahmen der Session „öffnen“ wir eine klassische monolithische Webanwendung und stellen uns den Herausforderungen.
CQRS (Command Query Responsibility Segregation) als Architektur-Pattern sieht vor, dass lesende (Queries) und schreibende Zugriffe (Commands) in getrennten Subsystemen auf unterschiedlichen Modellen realisiert werden. Während Commands meist asynchron und transaktional angestoßen werden, arbeiten Queries mit denormalisierten Views auf “eventual consistent” Daten. Ziel ist eine hoch skalierbare, hoch performante und sichere Plattform. Was sich zunächst einmal nach zusätzlichem Aufwand anhört, bringt in der Praxis eine Menge Vorteile mit sich. Die Session zeigt die wesentlichen Ideen von CQRS auf und demonstriert anhand eines praktischen Beispiels die Vorteile dieses Ansatzes im Kontext von Web APIs.
Microservices-basierte Architekturen auf der grünen Wiese zu starten mag ja noch vorstellbar sein. Was aber, wenn es – wie leider so häufig in der Praxis – einen bestehenden, historisch gewachsenen Monolithen gibt, der schon einmal bessere Tage gesehen hat? Wie kann ein möglicher Migrationspfad aussehen und mit welchen Stolperfallen muss dabei gerechnet werden? Im Rahmen des Workshops nehmen wir uns anhand eines konkreten Beispiels einen solchen Monolithen vor, überlegen, welche Services sich sinnvoll herauslösen lassen und welche Patterns dazu verwendet werden sollten. Natürlich ergeben sich durch die neue Architektur auch neue Herausforderungen, denen wir uns stellen müssen. Aber das kann uns natürlich nicht stoppen!
Die gute Nachricht vorweg: Einen einzelnen Microservice zu implementieren ist dank Bounded Context, loser Kopplung und klar definierter Kommunikationsschnittstellen denkbar einfach. Nur leider macht ein Frühling noch keinen Sommer und ein einzelner Microservice noch lange keine sinnvolle Anwendung aus! Um am Ende nicht im Chaos zu versinken, benötigt auch eine Microservices-basierte Anwendung eine Architektur und die Verwendung von Patterns. Wie zum Beispiel stellt man die Evolution von Schnittstellen sicher? Oder wie soll die UI eingebunden werden? Welche Aufgaben übernimmt ein API Gateway und wird es überhaupt benötigt? Sollten Microservices synchron oder asynchron kommunizieren? Oder gar beides? Fragen über Fragen, deren Klärung über Erfolg oder Misserfolg der eigenen Anwendung entscheiden kann. Der Workshop gibt einen Einblick in die verschiedenen Herausforderungen bei der Umsetzung einer Microservices-basierten Anwendung und diskutiert verschiedene Lösungsansätze, Patterns und Best Practices. Ein optimaler Einstieg in den Microservices-Summit.
Monolithische Mehrschichtarchitekturen scheinen ihre besten Tage hinter sich zu haben. Heute muss alles “micro”, „loosely coupled“ und „highly flexible“ sein. Ach ja, “resilient” nicht zu vergessen! Hört sich spannend an, aber was genau bedeutet das eigentlich für uns Entwickler/Architekten? Brauchen wir wirklich neue Architekturen? Und wenn ja, welche Herausforderungen ergeben sich dadurch? Mit welchen Patterns und Best Practices kann man diese Herausforderungen bewältigen? Und wie sieht überhaupt ein möglicher Migrationspfad aus, wenn man nicht das Glück hat, auf der grünen Wiese starten zu dürfen? Fragen über Fragen. Die zugehörigen Antworten auf dem Weg in eine leichtgewichtige(re) Zukunft gibt es in der Session.
"Microservices" stellen einen der meist diskutierten IT-Trends der letzten Monate dar. Doch wie designt man den perfekten Service? Oder anders gefragt, wie definiert man seine Grenzen? Als wichtiges Hilfsmittel auf dem Weg zum Erfolg dienen die Bounded Contexts aus Eric Evans Domain-Driven-Design-Ansatz sowie deren zugehörige Kommunikationsmuster.
Im Rahmen der Session wird an einem praktischen Beispiel ein bestehender Monolith seziert und in fachlich sinnvolle Microservices aufgeteilt - Diskussion inklusive.
Sie haben die Kunden, Ideen und Konzepte - wir setzen diese für Sie um
Wir verstehen uns als langfristigen Entwicklungspartner und als Experten für neue Medien und den damit verbundenen Produkten, wie Apps, webbasierten Datenbankapplikationen oder Cloud-Lösungen und stehen Ihnen unterstützend und beratend bei Ihren Projekten zur Seite.
Unser schlagkräftiges Team vereint alle Kompetenzbereiche die zur Entwicklung von Apps und Webapplikationen notwendig sind. Professionelles Projektmanagement und kurze Kommunikationswege ermöglichen eine Entwicklung nah am Kunden und dessen Anforderungen.
Lernen Sie uns und unsere Leistungen kennen, indem Sie direkt mit uns in Kontakt treten. Wir freuen uns auf Sie.
Jeder Service für sich kann unabhängig deployed und skaliert werden.
Gerade Cloud Computing erleichtert in vielen Unternehmen die Verwaltung der IT-Infrastruktur. Weil die für die Software benötigte Plattformen so einfach anzumieten sind, werden Developer deshalb immer mehr in die Rolle des DevOps gedrängt -- die Software, die sie entwickeln, soll auch selbst betrieben werden -- You build it, you run it.
Doch diese Strukturierung ist nicht ganz kostenlos - Developer müssen dadurch immer mehr Verantwortung übernehmen. Um dieser Verantwortung gerecht zu werden, muss eine Schwachstelle ausgeschaltet werden: der Mensch. Im Talk gehe ich auf Prozesse der klassischen Softwareentwicklung ein und lege dar, wie diese in dem “You build it, you run it”-Modell verbessert werden.
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“OPEN KNOWLEDGE GmbH
„Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer Cloud-spezifischer Architekturmuster? Wie kann uns das Cloud Maturity Model dabei helfen? Und was steckt eigentlich hinter Akronymen wie IaaS, PaaS, BaaS, SaaS und FaaS?
Im Rahmen des Worskhops werde ich eine klassische Enterprise Anwendung Schritt für Schritt in die Cloud migrieren und dabei die verschiedenen Stufen / Reifegrade des Cloud Maturity Models durchlaufen. Angefangen bei "Lift & Shift" bis hin zu "Cloud Native" und "Cloud Voodoo – aka Serverless".
Der goldene Schnitt – Wie schneide ich Microservices richtig?OPEN KNOWLEDGE GmbH
Mit Microservices wird versucht, eine Anwendung in möglichst kleine, unabhängige Teile zu schneiden, die dann miteinander kommunizieren. Diese Idee bringt einige Vorteile mit sich. Wie bekommt man es aber hin, dass dabei die Fachlichkeit nicht zerpflückt wird und so der Blick für das große Ganze verloren geht? Wie schneide ich die Services richtig? Und worauf muss bei der Kommunikation der Services untereinander geachtet werden? Der Workshop zeigt, wie Domain-driven Design dabei helfen kann, diese Fragen sinnvoll zu beantworten, und was es sonst noch zu beachten gilt.
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“OPEN KNOWLEDGE GmbH
„Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer cloud-spezifischer Architekturmuster? Und was steckt eigentlich hinter Akronymen wie IaaS, PaaS, BaaS, SaaS und FaaS?
Im Rahmen der Session werden ich Schritt für Schritt eine bestehende Enterprise-Anwendung in die Cloud migrieren. Angefangen bei der Nutzung von Cloudinfrastruktur (IaaS) über die Anbindung von Cloudplattformkomponenten (PaaS) und Backend-Services (BaaS) bis hin zu Serverless Functions (FaaS) werden wir für die unterschiedlichen Anwendungsszenarien unserer Applikation passende Architekturansätze entwerfen und deren Vor- und Nachteile diskutieren. Natürlich sprechen wir dabei auch Themen wie Testing, Monitoring und automatisiertes Deployment an.
Die Matrix: Enterprise-Architekturen jenseits von MicroservicesOPEN KNOWLEDGE GmbH
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
Getreu dem Motto "choose Microservices for the benefits and not because your codebase is a mess." (Zitat: Simon Brown), beleuchtet die Session typische Problemstellungen aus großen Projekten und zeigt auf, für welche dieser Microservices eine Lösung darstellen und für welche eher nicht. Anhand verschiedener Real-Life-Anforderungen, werden alternative Architekturen als Lösungsansätze gezeigt und bewertet.
Da hat man einmal eine tolle Idee für eine Mobile-App und möchte sie so schnell wie möglich realisieren, und dann scheitert das Ganze am Ende am passenden Backend. Zu aufwendig und riskant die Anpassung des bestehenden Web-Backends, zu zeitintensiv und teuer die Entwicklung eines neuen Mobile-Backends. Von mangelnder Skalierung, Security und Co. ganz zu schweigen. Aber kein Grund zur Panik: Wo ein Wille ist, ist auch ein Weg. Die Session zeigt, wie bestehende Backends für Mobile-Apps „enabled“ und neue Backends on the fly via Cloud-Anbieter zur Verfügung gestellt werden können. SaaS, PaaS, BaaS und BFF heißen die Akronyme der Stunde. Was nimmt man wann? Auflösung folgt …
Eine Anwendung basierend auf Microservices mit Java zu entwickeln kann ja so schwer nicht sein. Schließlich gibt es Frameworks wie Spring Boot oder MicroProfile, die dem Entwickler das technologische Rahmengerüst vorgeben. Nur leider ist es damit nicht getan. Wie zum Beispiel sieht der optimale Service-Schnitt aus? Wie kommunizieren die Services untereinander, ohne dabei ihre Unabhängigkeit zu verlieren? Wie soll die Anwendung reagieren, wenn mal ein Service nicht so kann, wie er soll? Und wie bindet man seine Microservices an bestehende Infrastruktur wie Distributed Tracing, Monitoring oder Identity Provider an?
Was sich in der Theorie einfach anhört, bringt in der Praixis so manchen Stolperstein mit sich. Im Rahmen des Workshops werden wir daher gemeinsam eine kleine, auf Microservices basierende Anwendung bauen und zum „Fliegen“ bringen. Angefangen bei der Diskussion über den optimalen Service-Schnitt via Domain-driven Design, über die Integration der Services untereinander via unterschiedlicher Kommunikationspatterns inkl. eingebauter Fehlertoleranz bis hin zur Instrumentalisierung der Services zwecks Laufzeitanalyse und -optimierung, lassen wir dabei kaum ein Thema aus.
Am Ende steht eine Anwendung, die live gehen könnte – naja, fast.
Künstliche Intelligenz ist auf dem Vormarsch, ohne Zweifel. Egal ob Qualitätssicherung in der Produktion, Retourenmanagement im Online-Handel oder Customer-Support via Chatbot: KI eröffnet bisher noch nicht dagewesene Möglichkeiten, die eigenen Prozesse und Geschäftsmodelle deutlich zu verbessern - vorausgesetzt man verfügt über hinreichend viele und qualifizierte Daten.
Aber wie lässt sich KI in die eigene Software-Architektur integrieren? Wer befindet über das richtige Modell und den richtigen Algorithmus? Und wie wird über die hinreichende Quantität / Qualität von Daten entschieden? Die Rolle des KI-Architekten scheint geboren.
Die Session veranschaulicht die verschiedenen Herausforderungen, die sich durch das Einbinden von KI für die eigene Software-Entwicklung ergeben können und zeigt dafür passende, pragmatische Lösungsansätze auf.
Das ist doch alles nur Frontend - Wer braucht da schon Architektur?OPEN KNOWLEDGE GmbH
Single-Page-Applications -ursprünglich als kleines fancy Frontend gestartet- sind in den letzten Jahren zu großen, schwergewichtigen eigenen Applikationen angewachsen, die fehleranfällig, schwer wartbar und langsam in der Weiterentwicklung sind. Aber woran liegt das eigentlich? Im Frontend gibt es als Abstraktion zumeist nur das Konzept der Komponenten. Eine tiefergehende Analyse der benötigten Bausteine bleibt in der Regel aus. Im Backend hingegen, erfolgen solche Analysen seit Jahren.
Aber lassen sich die Backend-Architektur-Konzepte ohne weiteres für das Frontend übernehmen? Was sind die Herausforderungen, in denen sich moderne Frontends von klassischen Backends unterscheiden? Wo braucht man daher andere Lösungen? Neben der Problemanalyse gibt dieser Talk konkrete Bausteine an die Hand.
Das „Schwergewicht“ Java EE scheint nicht wirklich mit der Wunderwelt der Microservices und den damit einhergehenden Architekturpatterns zu harmonisieren. Dabei bringt der Java-Enterprise-Standard technologisch gesehen alles mit, was es zur Umsetzung von Microservices benötigt. Wo also liegt das Problem? In der Session werden wir Schritt für Schritt eine monolithische Java-EE-Anwendung „sezieren“ und uns den damit einhergehenden Herausforderungen der neu entstandenen, Microservice-basierten Architektur stellen. Aha-Effekte garantiert!
Jeder redet von Continuous Delivery, aber was macht eine gute Development-, Testing- und Delivery-Pipeline aus? Diese Session soll zeigen, welche Schritte nötig sind, um das Ziel Continuous Delivery zu erreichen. Neben Themen wie Update- und Roll-out-Strategie werden ebenso Crash Reports und Analytics-Möglichkeiten beleuchtet.
Die Zeiten einfacher Web-Anwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle, wie Web, Desktop, Mobile oder 3rd Party Clients, parallel bedienen zu müssen. Und das mit einer Architektur. Wie aber sieht eine passende Architektur aus? Welche neuen Herausforderungen ergeben sich durch die zusätzlichen Kanäle? Und welche Auswirkungen hat dies auf Aspekte wie Security, Schnittstellendesign oder das Datenmodell? In der Session „öffnen“ wir eine Web-Anwendung und stellen uns den Herausforderungen.
Oftmals wird "Multi-Channel" gleichgesetzt mit Responsive Design. Dies setzt allerdings voraus, dass jeder Channel mehr oder minder dieselben Use-Cases bedient. Ein echter Business-Mehrwert wird aber erst erreicht, wenn jeder Channel seine speziellen Eigenschaften ausspielt, was automatisch eine deutlich größere Flexibilität - auch auf Ebene der Architektur - verlangt. Genau hier setzt die Session an und zeigt, wie eine Architektur aufgebaut sein sollte, die deutlich mehr erlaubt als "nur" Responsive Design.
Eine Serverless Function zu schreiben ist denkbar einfach. Und auch die Kombinationen mehrerer FaaS zu einem komplexeren System ist kein Hexenwerk. Was aber, wenn die niedlichen kleinen Funktionen sich zur Laufzeit nicht so verhalten, wie gewünscht? Wie sieht das Monitoring der einzelnen Funktionen und des Systems als Ganzes aus? Und was ist mit Testen? Muss die Funktion dazu immer in der Cloud deployt werden oder kann man das produktive System auch lokal emulieren? Wie wichtig ist der Aspekt der Automatisierung und wie wird diese erreicht? Wie beeinflussen Cold- und Warm-Start das Laufzeitverhalten? Diesen und vielen anderen Herausforderungen wollen wir uns in der Session stellen – Aha-Effekte garantiert!
Die Zeiten einfacher Webanwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle wie Web, Desktop, Mobile oder 3rd-Party-Clients parallel bedienen zu müssen. Und das mit einer Architektur, die am besten auch noch zukünftigen, bisher noch nicht bekannten Anforderungen standhält. Wie aber sieht eine solche Architektur aus? Welche neuen Herausforderungen ergeben sich durch die Öffnung für zusätzliche Kanäle? Und welche Auswirkungen hat das alles auf Themenbereiche wie Security, Schnittstellendesign, Versionierung oder das Domänen- bzw. Datenmodell? Im Rahmen der Session „öffnen“ wir eine klassische monolithische Webanwendung und stellen uns den Herausforderungen.
CQRS (Command Query Responsibility Segregation) als Architektur-Pattern sieht vor, dass lesende (Queries) und schreibende Zugriffe (Commands) in getrennten Subsystemen auf unterschiedlichen Modellen realisiert werden. Während Commands meist asynchron und transaktional angestoßen werden, arbeiten Queries mit denormalisierten Views auf “eventual consistent” Daten. Ziel ist eine hoch skalierbare, hoch performante und sichere Plattform. Was sich zunächst einmal nach zusätzlichem Aufwand anhört, bringt in der Praxis eine Menge Vorteile mit sich. Die Session zeigt die wesentlichen Ideen von CQRS auf und demonstriert anhand eines praktischen Beispiels die Vorteile dieses Ansatzes im Kontext von Web APIs.
Microservices-basierte Architekturen auf der grünen Wiese zu starten mag ja noch vorstellbar sein. Was aber, wenn es – wie leider so häufig in der Praxis – einen bestehenden, historisch gewachsenen Monolithen gibt, der schon einmal bessere Tage gesehen hat? Wie kann ein möglicher Migrationspfad aussehen und mit welchen Stolperfallen muss dabei gerechnet werden? Im Rahmen des Workshops nehmen wir uns anhand eines konkreten Beispiels einen solchen Monolithen vor, überlegen, welche Services sich sinnvoll herauslösen lassen und welche Patterns dazu verwendet werden sollten. Natürlich ergeben sich durch die neue Architektur auch neue Herausforderungen, denen wir uns stellen müssen. Aber das kann uns natürlich nicht stoppen!
Die gute Nachricht vorweg: Einen einzelnen Microservice zu implementieren ist dank Bounded Context, loser Kopplung und klar definierter Kommunikationsschnittstellen denkbar einfach. Nur leider macht ein Frühling noch keinen Sommer und ein einzelner Microservice noch lange keine sinnvolle Anwendung aus! Um am Ende nicht im Chaos zu versinken, benötigt auch eine Microservices-basierte Anwendung eine Architektur und die Verwendung von Patterns. Wie zum Beispiel stellt man die Evolution von Schnittstellen sicher? Oder wie soll die UI eingebunden werden? Welche Aufgaben übernimmt ein API Gateway und wird es überhaupt benötigt? Sollten Microservices synchron oder asynchron kommunizieren? Oder gar beides? Fragen über Fragen, deren Klärung über Erfolg oder Misserfolg der eigenen Anwendung entscheiden kann. Der Workshop gibt einen Einblick in die verschiedenen Herausforderungen bei der Umsetzung einer Microservices-basierten Anwendung und diskutiert verschiedene Lösungsansätze, Patterns und Best Practices. Ein optimaler Einstieg in den Microservices-Summit.
Monolithische Mehrschichtarchitekturen scheinen ihre besten Tage hinter sich zu haben. Heute muss alles “micro”, „loosely coupled“ und „highly flexible“ sein. Ach ja, “resilient” nicht zu vergessen! Hört sich spannend an, aber was genau bedeutet das eigentlich für uns Entwickler/Architekten? Brauchen wir wirklich neue Architekturen? Und wenn ja, welche Herausforderungen ergeben sich dadurch? Mit welchen Patterns und Best Practices kann man diese Herausforderungen bewältigen? Und wie sieht überhaupt ein möglicher Migrationspfad aus, wenn man nicht das Glück hat, auf der grünen Wiese starten zu dürfen? Fragen über Fragen. Die zugehörigen Antworten auf dem Weg in eine leichtgewichtige(re) Zukunft gibt es in der Session.
"Microservices" stellen einen der meist diskutierten IT-Trends der letzten Monate dar. Doch wie designt man den perfekten Service? Oder anders gefragt, wie definiert man seine Grenzen? Als wichtiges Hilfsmittel auf dem Weg zum Erfolg dienen die Bounded Contexts aus Eric Evans Domain-Driven-Design-Ansatz sowie deren zugehörige Kommunikationsmuster.
Im Rahmen der Session wird an einem praktischen Beispiel ein bestehender Monolith seziert und in fachlich sinnvolle Microservices aufgeteilt - Diskussion inklusive.
Sie haben die Kunden, Ideen und Konzepte - wir setzen diese für Sie um
Wir verstehen uns als langfristigen Entwicklungspartner und als Experten für neue Medien und den damit verbundenen Produkten, wie Apps, webbasierten Datenbankapplikationen oder Cloud-Lösungen und stehen Ihnen unterstützend und beratend bei Ihren Projekten zur Seite.
Unser schlagkräftiges Team vereint alle Kompetenzbereiche die zur Entwicklung von Apps und Webapplikationen notwendig sind. Professionelles Projektmanagement und kurze Kommunikationswege ermöglichen eine Entwicklung nah am Kunden und dessen Anforderungen.
Lernen Sie uns und unsere Leistungen kennen, indem Sie direkt mit uns in Kontakt treten. Wir freuen uns auf Sie.
Wie hoch sind die Kosten bei der Entwicklung einer App? Welche Kosten sind für welche Arten von Apps zu erwarten? Mit welchen Zusatzkosten muss man der App Entwicklung rechnen und wo treten sie auf?
Die Präsentation gibt Antworten auf diese Fragen - Kosten der App Entwicklung im Jahr 2015
7 UX-Trends, auf die Sie sich im Jahr 2018 freuen müssen, um die End nutzer Z...Dieter Ziegler
Die Nutzerer fahrung war 2017 zwei fello sein großes Thema; seies Schnittstellen von Produkten, Onboarding-Prozessen oder Inhalten, die durch verschiedene digitale Plattformen genutzt werden.
“Building Blocks für Mobile” offer standardized value added services and API’s as backend solutions for apps: Services like Push-Messaging, secure authentication, GPS-data publishing, App marketing, App Store marketing, App metrics and analytics, In-App purchase, GSM GPS-tracking, App retention services, OTA-services, payment processing are available as secure Cloud or Managed services.
In der aktuellen Ausgabe des kostenlosen eStrategy-Magazins liegt unser Themenschwerpunkt auf einem umfassenden Marktüberblick für Enterprise-Shopsysteme im B2B- und B2C-Umfeld. Ergänzt wird das Ganze wiederum durch eine Vielzahl informativer und spannender Artikel rund um die Themen eCommerce und Online-Marketing.
Das komplette Magazin mit allen Inhalten kann unter nachfolgendem Link kostenfrei herunter geladen werden: https://www.estrategy-magazin.de/aktuelle-ausgabe.html
Mobile Connectivity and Digital TransformationNamics
Am Mobile Business Forum in St. Gallen stellte Namics in einer Workshop-Session Best Practices und Lösungen für das Mobile Business vor.
Die Präsentation zeigt auf, welche neuen Verbindungen und Prozesse dank Mobile möglich sind und wie sie im Zusammenspiel Mehrwert für das eigene Unternehmen erbringen können.
Im Fokus des Workshops standen Wearables und die Apple Watch.
Im Workshop haben die Teilnehmer die Möglichkeit, gemeinsam mit uns an Watch-Prototypen zu arbeiten und können diese auf ihrer persönlichen Watch mit nach Hause nehmen.
Sitecore Experience Marketing – Gestaltung von aussergewöhnlichen Kundenerfah...Unic
Präsentation „Sitecore Experience Marketing – Gestaltung von aussergewöhnlichen Kundenerfahrungen “ von Stefan Steiner am Unic Fokus „Customer Experience“ vom 08.09.2015 in Zürich.
Eine kurze Frage: Integrieren Sie noch oder managen Sie bereits den Fluss Ihrer Unternehmensinformationen auf einer agilen Plattform?
So oder so: Wir zeigen Ihnen in unserem Webcast „Erfolgsfaktor Integrationsplattform - damit die Digitale Transformation gelingen kann“,
wie Sie ihr Ist-Situation verbessern und eine (noch) erfolgreiche Integration von Unternehmensanwendungen sicherstellen.
Erstellen einer erfolgreichen App in sechs SchrittenRakuten Aquafadas
Durch die Teilnahme an unserem nächsten Webinar erfahren Sie, wie Sie Ihre eigene mobile Unternehmensapp planen und entwickeln. Weiterhin lernen Sie alles über Launch und Wartung der App, wobei der Schwerpunkt auf Möglichkeiten liegt, Ihren Nutzern hochwertige Inhalte bereitzustellen.
In diesem Webinar erhalten Sie Informationen rund um:
- Monetarisierung von Apps
- Interne oder externe Entwicklung
- Einbeziehung der Nutzer
- Wartung und Inhaltspflege von Apps
- Aufkommende Technologien und Innovationen
"Failure is not an options" Slides from our IBM Connections Webinar Series. F...Beck et al. GmbH
in German! In this Webinar Series we focus on one of the most important social business collaboration platforms: IBM Connections. We talk about all relevant aspects of what it is necessary to run IBM Connections successfully and support social business.
As it addresses German speaking companies content is in German.
Einführung in die Mobile-Produktentwicklung: Konzeption, Design, Entwicklung,...Bokowsky + Laymann GmbH
Dieser Workshop richtet sich an Projektleiter und Entscheider, die erfolgreich Mobile-Apps und -Services an den Markt bringen wollen. Dabei richtet sich der Blick auf den gesamten Lebenszyklus - von Konzeption über Design, Entwicklung bis hin zur Vermarktung von Apps. Erfahrene Mobile-Experten geben dabei Einblicke in die wichtigsten Phasen der App-Entwicklung: die Erarbeitung eines schlüssigen und medienadäquaten Konzepts, die Definition der wesentlichen Anforderungen, die Bestimmung von Zielgruppen. Nicht zuletzt geht es um die Frage, welchen spezifischen Mehrwert die App bieten soll. Wir gehen in diesem Workshop alle Stationen der App-Entwicklung durch und beleuchten die spezifischen Besonderheiten im Vergleich zur klassischen Websiteproduktion, stellen unterstützende Tools vor und erklären technische Sachverhalte, die auch Nichtprogrammierer verstehen müssen, um sinnvolle Vorgaben zu machen und die richtigen Entscheidungen zu treffen. Die Stationen im Einzelnen:
(1) Strategie und Konzept
(2) Devices und Plattformen
(3) Usability und Design
(4) Team und Technik
(5) Programmierung und Testing
(6) Distribution und Promotion
(7) Erfolgskontrolle und Maintenance
Markus Bokowsky wird zusammen mit erfahrenen Spezialisten aus den einzelnen Bereichen die Teilnehmer durch den Prozess der App-Entwicklung führen und angereichert mit Beispielen aus der Praxis sowie etlichen Hands-on-Elementen ein umfassendes Bild aller Aspekte jenseits der eigentlichen Programmierung vermitteln.
Warum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AIOPEN KNOWLEDGE GmbH
Häufig stellt die Entwicklung einer ML-Lösung die Optimierung von Performanz-Metriken wie der "Accuracy" unter Verwendung sehr komplexer Modelle in den Fokus. Fälschlicherweise wird sich damit abgefunden, dass aufgrund der höheren Komplexität die Explainability, also die Frage nach dem "Warum verhält sich mein Modell so und nicht anders?" leiden muss. Die Folgen können schwerwiegend sein und reichen vom unwissentlich gelernten Bias aus tabellarischen Daten bis zu einer hohen Anfälligkeit gegenüber Adversarial-Attacks in Bilddaten des autonomen Fahrens.
Warum meiner Meinung nach die Explainability auch bei komplexen Modellen nicht leiden muss, möchte ich in diesem Vortrag verdeutlichen.
Hierfür werde ich verschiedene XAI-Methoden, wie z.B. die Permutation-Importance und LIME, anhand eines konkreten Anwendungsfalles vorstellen, bewerten und vergleichen. Mein Ziel ist es, für XAI zu sensibilisieren und euch einen Methoden-Kasten an die Hand zu geben, der dazu befähigt, den Blick in die Black-Box zu wagen.
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...OPEN KNOWLEDGE GmbH
Künstliche Intelligenz ist auf dem Vormarsch, ohne Zweifel. Egal ob Qualitätssicherung in der Produktion, Retourenmanagement im Online-Handel oder Customer-Support via Chatbot - KI eröffnet bisher noch nicht dagewesene Möglichkeiten, die eigenen Prozesse und Geschäftsmodelle deutlich zu verbessern. Vorausgesetzt man verfügt über gute Ideen und hinreichend viele und qualifizierte Daten. Aber wie genau kommt man zu diesen Ideen? Und wie lässt sich KI in die eigene Software-Architektur integrieren? Wer befindet über das richtige Modell und den richtigen Algorithmus? Und wie wird über die hinreichende Quantität / Qualität von Daten entschieden? Die Session veranschaulicht die verschiedenen Herausforderungen, die sich durch das Einbinden von KI für die eigene Softwareentwicklung ergeben können, und zeigt dafür passende, pragmatische Lösungsansätze auf.
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die CloudOPEN KNOWLEDGE GmbH
Cloud is the new normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer, cloudspezifischer Architekturmuster? Was unterscheidet dabei die verschiedenen As-a-Service-Varianten (IaaS, PaaS, BaaS und FaaS) voneinander und für welchen Anwendungsfall nimmt man was? Fragen über Fragen – aber keine Panik, der Talk liefert Antworten.
SPAGAT ZWISCHEN BIAS UND FAIRNESS
KI soll fair sein. Da sind wir uns alle einig. Entsprechend gilt es, eine „Voreingenommenheit“ der eigenen KI-Lösung zu vermeiden.
Leichter gesagt als getan, denn Bias kann sich an verschiedenen Stellen innerhalb des AI/ML-Lifecycles einschleichen – vom initialen Design bis hin zum produktiven Einsatz des Modells. Diese Stellen gilt es zu identifizieren und im Detail zu verstehen. Denn nicht jede Art von Voreingenommenheit ist automatisch auch böse bzw. unfair.
Die Session zeigt, wie potenzielles Auftreten von unerwünschtem Bias in der eigenen KI-Lösung aufgedeckt und vermieden werden kann.
FEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data ImputationOPEN KNOWLEDGE GmbH
Leider sind die in der Praxis zur Verfügung stehenden Daten für das Training von Modellen bei weitem nicht so gut und vollständig, wie in den Lehrbüchern. Was also tun? Unvollständige Datensätze ignorieren und damit die zum Training notwendigen Daten deutlich reduzieren? Oder die Lücken besser mit sinnvollen Näherungswerten auffüllen.
Die Session zeigt, ob und wann es sinnvoll ist, fehlende Datensätze aufzufüllen und demonstriert an Real-Life Szenarien verschiedene Verfahren zur sinnvollen Ergänzung fehlender Daten. Neben einfachen Verfahren wie Mean/Median, Random Sample, Mulitple Imputation oder der Interpolationen zeitbezogenen Werte werden auch ML-basierte Imputation-Verfahren wie Regression oder Classification sowie deren potenzielle Einsatzgebiete beleuchtet. Dass fehlende Datensätze im Training auch einen positiven Effekt auf die Qualität des resultierenden Modells haben können, wird ebenfalls gezeigt.
In der Vergangenheit mussten Log-Files von Produktiv-Systemen mühsam von Hand zusammengesucht und danach durchforstet werden. Mit dem Aufkommen von Microservices gibt es jedoch immer mehr Tools, die die Aggregation und das Durchsuchen von Log-Informationen automatisieren. Den Anfang hat der ELK-Stack gemacht. Verteilte Systeme liefern jedoch heutzutage viel mehr relevante und besser aufbereitete Informationen als in den Log-Files zu finden sind. In einigen Situationen sind die in den Log-Files gefundenen Informationen unzureichend oder müssen mühsam extrahiert werden. Aus diesem Grund ist es naheliegend, die benötigten Informationen direkt in einem geeigneten Format bereitzustellen. Heutige Standards wie OpenTelemetry ermöglichen es, Informationen in dem benötigten Format zu sammeln. Werden Log-Files dadurch überflüssig? Die Session regt einen Mindset-Change an, stellt die Herausforderungen vor, die mit den verschiedenen Toolings bewältigt werden können, und erklärt, unter welchen Voraussetzungen auf Logging komplett verzichtet werden kann.
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierter Enterprise-Computing-Lösungen geht. Das gilt zumindest immer dann, wenn die Anwendung als Monolith in einem Application-Server deployt werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so mit Hilfe von Nebenprojekten wie Eclipse MicroProfile den Anforderungen moderner Cloud-Native-Anwendungen gerecht zu werden. Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien, aka Serverless, eine gute Figur macht.
From Zero to still Zero: The most beautiful mistakes going into the cloud. OPEN KNOWLEDGE GmbH
"Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Passende Blaupausen dazu gibt es mehr als genug. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloud-Anbieter glauben machen wollen? Natürlich nicht. Diese Session zeigt anhand typischer Antipattern, wie der Weg in die Cloud garantiert im Desaster endet und wie man sich dagegen wappnen kann. Ähnlichkeiten zu existierenden Projekten sind rein zufällig – oder auch nicht.
API Expand Contract ist ein Pattern zur Weiterentwicklung von APIs. Aber was verbirgt sich hinter der Idee? Wie kann ich damit eine API weiterentwickeln, ohne dass Client und/oder Server im Wartungsaufwand alter Schnittstellen(-Versionen) ersticken?
In der Realität erweist sich Management von APIs und deren Versionen als gar nicht so einfach. Diese Session zeigt mögliche Wege und Alternativen, um der Versionierungshölle zu entkommen und dabei das oberste Gebot beim API-Design - nämlich „Don’t break the Client“ - jederzeit einzuhalten.
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & CoOPEN KNOWLEDGE GmbH
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierte Enterprise Computing Lösungen geht. Dies gilt zumindest immer dann, wenn die Anwendung als Monolithen in einem Application Server deployed werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so, mit Hilfe von Side-Projekten wie dem Eclipse MicroProfile, den Anforderungen moderner Cloud Native Anwendungen gerecht zu werden.
Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien aka Serverless, eine gute Figur macht.
Eine auf Microservices basierende Architektur umzusetzen, bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität - vollständig oder in Teilen - in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren? Dies sind nur einige von vielen Fragen, die im Rahmen der Session beantwortet werden. So viel vorab: Umdenken ist gefragt!
Nur wenn die Auftrennung der Fachlichkeit in verschiedenen Microservices auch konsequent bis hin zur Ebene der Datenhaltung vollzogen wird, kann die angestrebte Unabhängigkeit der Services zur Entwicklungs- und Laufzeit erreicht werden. Ohne diesen Schritt dagegen würde sich das Problem der starren Kopplung und der damit einhergehenden Abhängigkeiten einer monolithischen Architektur lediglich um eine Schicht nach unten, in die Datenbank, verlagern. Was aber bedeutet das konsequente Einhalten des Database-per-Service-Patterns und einer damit einhergehenden Verteilung der Datenhaltung in der Praxis? Die Session zeigt die wesentlichen Herausforderungen auf und liefert passende Lösungsansätze.
Machine Learning ist eine Art von Software-Entwicklung, bei der man nicht direkt Code schreibt, sondern ein Modell anhand von Daten trainiert. Das kann in Situationen von Vorteil sein, in denen man keinen passenden Code schreiben kann oder dieser extrem komplex werden würde. TensorFlow ist das bekannteste Framework im Bereich Neuronaler Netzwerke mit dem man solche Modell erzeugen und nutzen kann. TensorFlow.js (https://js.tensorflow.org/api/latest/) implementiert die volle API von TensorFlow mit JavaScript und erlaubt sowohl die Ausführung, als auch das Training von Neuronalen Netzwerken auf jeder GPU.
Im ersten Teil des Workshops werden wir ein Modell zur Bilderkennung in einer grafischen Webanwendung trainieren und in einer eigenen Anwendung zum Laufen bringen. Hier geht es um die Grundlagen von Machine Learning und den Teil der TensorFlow.js API zum Ausführen eines Modells.
Im zweiten Teil werden wir ein eigenes Modell mit der TensorFlow.js API trainieren und als Teil einer JS-Anwendung integrieren.
Es sind keine Vorkenntnisse nötig und zur Teilnahme wird lediglich eine beliebige IDE zur Entwicklung von JavaScript benötigt.
KI und insbesondere Deep Learning sind der Megatrend. Dank leistungsstarker Frameworks sind erste Schritte schnell gemacht. Leider stößt man aber genauso schnell auch wieder an (seine) Grenzen. Passt das genutzte Modell überhaupt zu meinem Problem? Wie sind die gewonnenen Ergebnisse zu bewerten? Kann durch geschickte Veränderung von Modell-Parametern das Ergebnis weiter verbessert werden? In der Session werden wir unser eigenes Neuronales Netz von Grund auf aufbauen und Schritt für Schritt verbessern. Aber keine Angst: „it’s not rocket science“!
Eine auf Microservices basierende Architektur umzusetzen, bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität - vollständig oder in Teilen - in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren? Dies sind nur einige von vielen Fragen, die im Rahmen der Session beantwortet werden. So viel vorab: Umdenken ist gefragt!
Java scheint mit seinem Memory- und Runtime-Overhead in Zeiten von Cloud-native und Serverless nicht wirklich gut für die Zukunft gerüstet. Erschwerend kommt hinzu, dass viele auf Java basierende Frameworks mit Annotation Scanning, Aufbau von Proxies und Caches das Start- und Speicherverhalten weiter negativ beeinflussen. Bedeutet das das Aus für Java in der Wunderwelt der Cloud? Mitnichten! Projekte wie Quarkus versuchen, Java in der Cloud zur Numero Uno werden zu lassen. Und das auf beeindruckende Art und Weise. Die Session zeigt anhand praktischer Beispiele, was heute bereits möglich ist.
Das Product Goal oder "Ohne Ziele laufen eben alle in die Richtung, die ihnen...OPEN KNOWLEDGE GmbH
Der Scrum Guide von 2020 führt das Konzept eines Product Goals ein, um das Scrum Team auf ein größeres, wertvolles Ziel auszurichten. Jeder Sprint sollte das Produkt näher an das übergeordnete Product Goal heranbringen. Aber wie erstelle ich überhaupt ein Product Goal? Was sind Merkmale von einem guten Produkt Goal? Und was ist der Unterschied zu einer Produkt Vision? Brauche ich eigentlich beides oder reicht eins von beiden? Auf diese und weitere Fragen gehe ich in meinem Vortrag ein.
Maschinen haben kein Gewissen. Oder etwa doch? Immer wieder hört man von Fällen, in denen eine KI scheinbar „unethische“ Entscheidungen fällt oder für politische Zwecke missbraucht wird. Angefangen bei genderspezifischer Benachteiligung, über die Generierung und gezielte Verbreitung von Fake-News und Deep-Fakes bis hin zu offenkundigem Rassismus durch eine KI existieren unzählige Beispiele. Was aber genau steckt dahinter und wie können wir uns dagegen verwehren? Die Session zeigt einige populäre Beispiele auf und beleuchtet deren Hintergründe.
Eine KI ist nur so gut wie ihr Modell und die Daten, auf denen dieses basiert. Dies führt immer wieder zu überraschenden, ja sogar erschreckenden Resultaten bei deren Einsatz. Dabei bildet die KI nicht selten lediglich unsere Realität ab und spiegelt somit die Grundwerte unserer Gesellschaft wider, wie populäre Beispiele zeigen. Die Session zeigt einige Beispiele, in denen eindeutig einzelne Gruppen der Bevölkerung benachteiligt wurden, und beleuchtet diese im Detail. Es wird aufgezeigt, wie wir alle durch Fake-News und Deep-Fakes manipuliert werden und welche Initiativen zum Schutz und zur Regulierung angedacht sind.
Die Welt rund um das Frontend befindet sich im ständigen Wandel. Die Leistung der Computer der Konsumentinnen und Konsumenten und auch deren Erwartungen an Software steigen. Während die Server von Webdiensten früher lediglich ein wenig HTML erzeugen mussten, liegt die Logik heutzutage deshalb immer mehr auf dem Client, um eine optimale User Experience sicherzustellen – und das bringt Herausforderungen mit.
Im Talk schauten wir uns einige Trends der Webentwicklung an und analysierten die Probleme, die durch das Aufrüsten der Browser durch Google und Co. gelöst werden.
3. ÜBER MICH
Wer bin ich - und wenn ja, wie viele?
• CIO New Technologies
• Enterprise & Mobile
• Autor, Speaker, Coach & Mentor
• Snowboard & MTB Enthusiast (a.k.a. “stets bemüht“)
Lars Röwekamp (a.k.a. @mobileLarson)
4. #WISSENTEILEN
APIs create new opportunities
APIs sind der Schlüssel zur Erschließung neuer
digitaler Kanäle.
APIs ermöglichen die interne/externe Bereitstellung
von Daten, die Anbindung mobiler Anwendungen
und das Generieren neuer Geschäftsmodell.
“
5. #WISSENTEILEN
It‘s all about Money
Expedia generiert $2 Milliarden jährlich
durch seine Affilliate Networks APIs.
$7 Milliarden der eBay Transaktionen
werden via APIs realisiert.
“
6. #WISSENTEILEN
DX is the new UX
Eine gut designte API ist für den Entwickler
genauso wichtig, wie eine Smart UI für den
Web User.
Eine API sollte intuitive zu verstehen, einfach
zu nutzen und in sich konsistent sein.
“
11. #WISSENTEILEN
define your
business
objectives
Step #1Business holistically lens
„Wie lässt sich die Bindung der Kunden zu meinem
Unternehmen verbessern/erhöhen?“
„Wie kann ich meine Partner dabei unterstützen
das Nutzenversprechen gegenüber den Kunden zu
verbessern/auzubauen?“
“Welche internen Prozesse können von dem
vereinfachten Datenzugriff partizipieren?“
“
12. #WISSENTEILEN
define your
business
objectives
Step #1APIs business objectivies
Definiere deine Business Objectives für die API.
Das WARUM deines API Programms.
Stelle sicher, dass diese Business Objectives
messbar sind, um so durch fortlaufende
Optimierung der API langfristigen Erfolg zu
garantieren.
“
13. #WISSENTEILEN
define your
business
objectives
Step #1Answer the WHY
Interner Datenzugriff und Agilität
Interne APIs sind nicht so „sexy“ wie Open APIs -
aber extrem wertvoll.
Verbesserte Kollaboration und Kommunikation kann
die Produktivität um 20-25% erhöhen.*
“
*(Source: by McKinsey)
14. #WISSENTEILEN
define your
business
objectives
Step #1Answer the WHY
B2B / Partner Connectivity
Bereits 2020 wird 40% des Umsatzes der IT
Industrie und 98% des Wachstums durch Dritte
getrieben werden.
“
(Source: Annahme der International Data Cooperation [IDC])
15. #WISSENTEILEN
define your
business
objectives
Step #1Answer the WHY
Mobile Initiativen
Bis 2020 werden Mobile Apps $189 Milliarden
Umsatz generieren ($88 Milliarden in 2016).
Just for the record: Mobile User stellen freiwillig
persönliche Daten via Apps zur Verfügung!
“
16. #WISSENTEILEN
define your
business
objectives
Step #1Answer the WHY
Monetarisierung digitaler Assets
Im digitalen Zeitalter geht der Wert digitaler Daten weit
über den internen Wert hinaus.
Daten sind zu einem Produkt geworden*, das via
APIs zur Verfügung gestellt werden kann.
“
*(65% der CEOs glauben daran, dass Digital Assets ihr Unternehmensergebnis in den kommenden 3 Jahren verbessern werden.)
18. #WISSENTEILEN
define your
business
model
Step #2I need a business model
Ein passendes Business Model ist extrem wichtig.
Das gewählte Business Modell entscheidet
darüber, ob und wie sich Entwickler auf die API
einlassen und wie sich damit Geld verdienen lässt.
“
19. #WISSENTEILEN
define your
business
model
Step #2I want you money
Entwickler zahlen
Entwickler zahlen für den Service. Typische Modelle:
“pay as you go“, „tiered“ oder „freemium“ (z.B.
Google Maps API - freemium).
“
20. #WISSENTEILEN
define your
business
model
Step #2You want some money?
Entwickler werden bezahlt
Du als API Provider animierst Entwickler Apps oder
Anwendungen auf Basis der eigenen API zu bauen.
Z.B. in Form von Umsatzbeteiligung (z.B.
Amazon‘s Affiliate Program).
“
21. #WISSENTEILEN
define your
business
model
Step #2Come in, it‘s free
Indirekte Monetarisierung
Bei einer indirekten Monetarisierung, dienen die APIs
als Mittelsmann zur Umsatzgenerierung. Die
Nutzung der API wird nicht direkt in Rechnung
gestellt, generiert aber indirekt Umsatz (z.B. eBay
API).
“
22. #WISSENTEILEN
define your
business
model
Step #2Come in, it‘s realy free
Free
Ein freies API Business Modell erlaubt Dritten die
Nutzung der APIs ohne jegliche Kosten. Die
Möglichkeit zur inidirekten Monetarisierung ergibt
sich durch die Generierung von Mehrwerten (z.B
Twitter und Facebook).
“
24. #WISSENTEILEN
design your
application
interface
Step #3API Design
Beim API Design geht es nicht darum, welche Form
von (Backend) Daten ich zur Verfügung stellen
möchte.
Frage an die potentiellen Nutzer: „Welche Aktionen
möchtest du mit Hilfe der API ausführen /
erreichen können?“
“
25. #WISSENTEILEN
design your
application
interface
Step #3Developer Experience
Designe die API in der Art, dass sie für ihre Zielgruppe
- die Entwickler - einfach und intuitive zu
verstehen, zu nutzen und zu testen ist.
Die wichtigste Frage, die es in dieser Phase zu klären
gilt, ist: „Für wen designe ich die API eigentlich?“
“
26. #WISSENTEILEN
design your
application
interface
Step #3API First
Denke an dieser Phase nicht an die Implementierung der
API. Fokussiere dich ausschließlich auf das Design einer
großartigen API User Experience!
Hole dir Feedback der potentiellen API User während
der Design Phase ein, z.B. via Mock Services.
“
27. #WISSENTEILEN
design your
application
interface
Step #3Iterate on your design
Einmal veröffentlicht wird jede Änderung an der API
direkte Auswirkungen auf die Nutzer haben und ggf
ihre Apps beeinträchtigen.
Gehe erst zur nächsten Phase des Lifecycles über,
wenn du wirklich zufrieden bist und glaubst, du hast das
richtige API Design gefunden.*
“
*API Change Management von Anfang an in das Design mit einbeziehen!
28. #WISSENTEILEN
design your
application
interface
Step #3API Design insides
Führe so früh wie möglich verbindliche API Design
Rules* ein und etabliere diese bei den API Entwicklern.
… später mehr in „Best practices & pitfalls“
“
* Erfinde das Rad nicht neu. Es gibt sehr gute Beispiel in der API Community..
30. #WISSENTEILEN
build and
deploy
your API
Step #4
Connect to the backend
Einmal desinged, muss die API gebaut und mit dem
Backend verbunden werden.
Simple Version: Proxy für existierenden Web Service
Real-Life Version: komplexe Integration / Orchestrierung
“
31. #WISSENTEILEN
build and
deploy
your API
Step #4
Complex integration
Platziere keinen „Custom Code“ innerhalb des
API Layers zur Integration, Orchestrierung oder
Transformation.
Nutze stattdessen „Fit-to-Purpose“ Lösung oder
verwende ein API Gateway, dass die gewünschten
Funktionalitäten von Haus aus liefert.
“
32. #WISSENTEILEN
build and
deploy
your API
Step #4
Policy management
Bevor eine API deployed werden kann, müssen
Policies zu deren Nutzung etabliert werden:
• Security / Authentication
• Rate Limiting / Throtteling
• Customer SLAs
• XML / JSON Threat Protection
“
33. #WISSENTEILEN
build and
deploy
your API
Step #4
Security
Ohne entsprechende Sicherheitsmechanismen sind
die API und die von ihre zur Verfügung gestellten
Daten angreifbar für unerlaubte Zugriffe.
Authentication: präferiere Tokens über Credentials
Authorization: bewillige spezielle Permission-Levels
“
35. #WISSENTEILEN
engage
developers
with your API
Step #5Engage developers
Das Einbinden von Entwicklern und der damit
verbundene erfolgreiche Aufbau einer Entwickler-
Community Ist wahrscheinlich der wichtigste
Erfolgsfaktor des eigenen API Programms.
“
36. #WISSENTEILEN
engage
developers
with your API
Step #5Provide easy access
Der Aufbau einer Entwickler Community beginnt
damit, ein Portal für Entwickler bereitzustellen, dass
ihnen ein „Entdecken“ der API ermöglicht.
Entwickler können die API so für ihre Use Cases und
Anwendungswelt evaluieren.
“
37. #WISSENTEILEN
engage
developers
with your API
Step #5
Self-Service Support Hub
Trust Signal
Communication Nexus
Documentation Database
DevRel Tool
Product und Implementation Showroom
API
API
API
…
Stakeholder
Stakeholder
Stakeholder
Stakeholder
…
What is a Dev Portal?
“
38. #WISSENTEILEN
engage
developers
with your API
Step #5
I have a question
„Was genau ist der Zweck der API?“
„Wie starte ich am besten mit der API?“
„Was muss ich bzgl. der API verstanden haben?“
„Wie erledige ich Aufgabe X mit Hilfe der API?“
„Wie komme ich an die Details der API ran “
„Wie nutze ich die API im Falle von Y?“
„Arbeitet überhaupt jemand mit der API?“
„An wen wende ich mich im Falle von Fragen/Problemen?“
„Wie erhalte ich Zugriff auf die API?“
„Kann ich mir die API leisten und ihr trauen?“
“
39. #WISSENTEILEN
engage
developers
with your API
Step #5
We have the answers*
Getting Started
Dokumentation
Code Beispiele
Interaktive Dokumentation
Error Codes und Responses
Forums
FAQs
API Status
“
*(ProgrammableWeb: nur 1% von 11,000 APIs bieten die gesamte Namdnreits)
40. #WISSENTEILEN
Step #5
Developers journey
“ #1: discover & research
#2: evaluate API features
#3: get started with dev
#4: dev/troubleshoot
#5: celebrate
#6: maintain
engage
developers
with your API
41. #WISSENTEILEN
Step #5
How do I get started?
“ engage
developers
with your API
Tutorials
Tutorials helfen den
Entwicklern dabei,
erfolgreich die ersten
Schritte mit der API
zu gehen
„Reading to learn to do“
Prinzip.
42. #WISSENTEILEN
Step #5
How do I get X done?
“ engage
developers
with your API
Guides
Guides erklären anhand
von Use Cases, Rezepten
oder Cookbooks, wie
konkrete Probleme und
Herausforderung zu lösen
sind.
43. #WISSENTEILEN
Step #5
Still working on it?
“ engage
developers
with your API
Blogs
Blogs können regelmäßig
(neue) Lösungen
kommunizieren und dabei
helfen neuen Content zu
verproben.
50. engage
developers
with your API
#WISSENTEILEN
Step #5
inspired by findings of
Peter Greenbaum
and Kata Nagygyörgy
Overview
What is the API about?
How does the API work?
Getting started
How can i start integrating?
Sample code
How can i start integrating?
Help & Support
Trust signal
Can I trust this API?
References
How can is start …?
Search function
Where can i find …?
Menu / in-links
Where can i find …?
The Landing Page
“
51. #WISSENTEILEN
engage
developers
with your API
Step #5From Dev to Dev
Promote deine API zielgruppengerecht und
glaubwürdig via Developer Evangelists.
Organisiere Hackathons*, um die Starthürde(n)
zu minimieren und interessierte Entwickler
zusammenzubringen.
“
*Salesforce Hackathon mit 1 Mio $ Preisgeld
52. #WISSENTEILEN
engage
developers
with your API
Step #5Eat your own dog food
Das Verständnis und die Akzeptanz für (d)eine API
beginnt in den eigenen Reihen.
Jeff Bezos: “Every application leveraging enterprise
data or services must go through an API – no back
doors are available.“
“
*Jeff Bezos, Amazon.com:
54. #WISSENTEILEN
manage and
monitor
your API
Step #6What‘s going on?
Sobald eine API zur Verfügung gestellt wird, wird auch
Managing und Monitoring notwendig, so dass …
… Fehler schnell identifiziert werden können
… potentielle Probleme antizipiert werden können
… Nutzung und Performanz gemessen werden können
“
55. #WISSENTEILEN
manage and
monitor
your API
Step #6
What to look at?
Operational Level Metrics als „Lebenszeichen“ der
API: z.B. API Status, Response Times, Up-/Downtimes.
Functional Level Metrics für einen tiefen Einblick in die
Verwendung der API als Basis zur Optimierung: z.B.
Consumption by Region / by Platform, Traffic by
Consumer, …
“
56. #WISSENTEILEN
manage and
monitor
your API
Step #6
Abstraction layer
Ein API Gateway erlaubt es der API Runtime sich
mit den Backend Services zu verbinden und dient
als Abstraction Layer.
Durch Nutzung von Caching und Routing Features,
können API Publisher hohe Verfügbarkeit und
schnelle Response-Zeiten garantieren.
“
58. #WISSENTEILEN
measure
the impact
of your API
Step #7Are we successful?
Deine API lebt und atmet als Teil deines Business;
und sollte daher permanent verbessert werden.
API Publisher sollten in regelmäßigen Abständen den
„Erfolg“ des eigenen API Programms kritisch
hinterfragen und ggf das Programm korrigieren.
“
59. #WISSENTEILEN
measure
the impact
of your API
Step #7Review the success
Wird das Programm angenommen, wie
erwartet / erhofft? Liefert das Programm den
erwarteten Umsatzzuwachs / Mehrwert?
Wenn nicht, ist es Zeit zu hinterfragen, was die API
liefert/bietet, wie sie designed ist, wie sie beworben
wird oder ob das Business Modell evtl nicht passt.
“
60. #WISSENTEILEN
measure
the impact
of your API
Step #7Goals and needs change
Ziele und Bedürfnisse ändern sich. Daher muss
permanent hinterfragt werden, ob die API nach wie
vor das liefert, was mein Business ausmacht!
“
63. #WISSENTEILEN
Golden Rules of API DESIGN (business)
#1: definiere deine Business Objectives
#2: designe für eine herausragende User Experience
#3: ermögliche einen einfachen Zugriff
#4: baue eine Community auf und pflege diese
“
64. #WISSENTEILEN
Golden Rules of DESIGN (tech)
#1: sei konsistent
#2: sei flexibel
#3: sei erweiterbar
#4: vermeide Versionierung
“
65. #WISSENTEILEN
Pro Tipp of the Day
„The web and it‘s standards are your friends.
Do not reinvent the wheel!“
“