Unser Labor - Einrichtung der Entwicklungsumgebung

Was wir bisher zu dem Thema veröffentlicht haben finden Sie hier:

Teil 1 - Teil 2 - Teil 3 - Teil 4 -  Teil 5  zu Model Driven Transformation for Streaming Applications

In diesem Beitrag wird Ihnen die benötigte Entwicklungsumgebung, welche für dieses Projekt zusammengestellt wurde, vorgestellt.

Modellierung der Eingangs- und Ausgangs-Datenstrukturen sowie der Datentransformation

Was wir bisher zu dem Thema veröffentlicht haben finden Sie hier:

Teil 1 - Teil 2 - Teil 3 - Teil 4 zu Model Driven Transformation for Streaming Applications

In diesem Betrag beschäftigen wir uns mit der Struktur des innovator-Modells, aus dem die Datentransformationsregeln generiert werden sollen.

Event Driven Streaming Architektur

Was wir bisher zu dem Thema veröffentlicht haben finden Sie hier:

Teil 1 - Teil 2 - Teil 3 - zu Model Driven Transformation for Streaming Applications

In diesem aktuellen Beitrag beschreiben wir den technischen Rahmen für die Software-Entwicklung – die Software Architektur.

Die Challenge/Vision:

Für das erfolgreiche Design der Software Architektur sind neben den nicht-funktionalen Anforderungen unter anderem auch funktionale Anforderungen, wie das Datenaufkommen, die bestehenden oder zukünftigen Geschäftsprozesse, sowie der Systemkontext wichtige Architekturtreiber. Für die hier vorgestellte Software Architektur sind folgende funktionale Anforderungen definiert worden:

Apache Kafka – Funktionsweise, Doku, API

Was wir bisher zu dem Thema veröffentlicht haben finden Sie hier: Teil 1 und Teil 2

In diesem Betrag beschäftigen wir uns näher mit dem Stream Processing System Kafka.

Was ist Apache Kafka?

Apache Kafka - hat nichts mit Franz Kafkas „Der Prozess“ zu tun, sondern es handelt sich um eine der bekanntesten Streaming Plattformen auf dem Markt. Apache Kafka ist eine verteilte Streaming Plattform und der wohl bekannteste Vertreter der Kappa-Architektur. Kafka ist in der Lage nahezu in Echtzeit eine extrem hohe Anzahl von Daten bzw. Ereignisse in Form eines Datenstromes entgegenzunehmen, zu speichern, zu verarbeiten und bereitzustellen. Apache Kafka ist laut Confluent (https://www.confluent.io/) für zwei Einsatzszenarien am geeignetsten: zuverlässige Echtzeit-Streaming-Datenpipelines und reaktionsschnelle Echtzeit-Streaming-Anwendungen mit Datentransformation.

Fachliches Integrationsszenario und Lösungsansatz mit Kafka

Was wir bisher zu dem Thema veröffentlicht haben finden Sie hier.

In diesem Beitrag beschreiben wir die Gesamtarchitektur unseres Ansatzes auf oberster Ebene.

Die Challenge/Vision:

Aufgrund unserer Erfahrungen und Erkenntnisse bei der Arbeit mit verschiedenen Kunden haben wir als Anwendungsbeispiel zur praktischen Erprobung von Apache Kafka ein übliches Szenario aus der Unternehmenspraxis gewählt, nämlich die Datenübertragung von einem Quell-System (Producer) zu einem Ziel-System (Consumer), wobei die Daten bei ihrer Übertragung einer Transformation unterzogen werden sollen.

Die IT-Landschaft von heute muss sich immer wieder und dazu noch in immer kürzeren Zeitabschnitten an die wachsenden Datenmengen anpassen. Wir schreiben keine Nachrichten mehr, sondern übertragen Voice Messages, hören on Demand Musik über Streaming-Anbieter und schauen Video-On-Demand auf dem Fernseher und von unterwegs. Neue Fahrzeuge haben das Potential bei einem Unfall direkt Kontakt mit der Versicherung für Schadensmeldung aufzunehmen und selbst unser Kühlschrank könnte schon leer gewordene Lebensmittel selbständig nachbestellen. Zudem kommt hinzu, dass dieses Meer an Daten in „Echtzeit“ analysiert, verarbeitet und weitertransportiert werden muss.

Bei der Frage welche Software Architektur für diese Herausforderungen die Richtige ist bzw. welche Komponenten am besten in meine bestehende IT-Landschaft passen, stößt man heutzutage sehr schnell auf die Streaming Architektur und um es noch stärker einzugrenzen auf die Kappa Architektur mit ihrem populärsten Vertreter, der Streaming Plattform Apache Kafka.

Was ich nicht weiß, macht mich nicht heiß

Im Blog-Beitrag zu Innovator 14 und den Neuerungen im Bereich der Konfiguration haben wir uns mit der Möglichkeit beschäftigt, wie zusätzliche Stereotyp-Merkmale in nahezu jedem Profil zu einem Stereotyp hinzugefügt werden können.

Doch wie verhält es sich mit ungewünschten, nicht benötigten Eigenschaften (Labels, Spezifikationstexten (F3-Texte)), Verbindungsmöglichkeiten zwischen Modellelementen sowie die Möglichkeit, Elemente generell anlegen zu können? Oftmals ist das Ziel einer eigenen Modellierungsmethodik, die Modellierung zu vereinfachen und nur diejenigen Elemente mit spezifischen Eigenschaften dem Anwender zur Verfügung zu stellen, die tatsächlich im Kontext des Unternehmens bzw. des Projekts benötigt werden.

Bislang hatten Sie diesbezüglich wenige Möglichkeiten, ungewünschte Stereotypen bzw. deren Eigenschaften aus dem Modell zu entfernen. Sie konnten auch hier entweder nur die Konfiguration der Elemente in den definierenden Profilen anpassen (Stichwort: Updateproblematik bei der Verwendung von Migrationsprofilen – siehe Blog-Beitrag Innovator-Konfiguration leicht gemacht) oder sich wieder eigene Profile mitsamt allen benötigten Elementen anlegen (sehr aufwändig und nicht updatebar ohne manuelle Anpassungen).

Mit Innovator 14 gehört auch dies der Vergangenheit an!

Im ersten Blog-Beitrag zu Innovator 14 haben wir Ihnen einen ersten Überblick darüber gegeben, welche verbesserten Konfigurationsmöglichkeiten Sie mit dem neuesten Release haben:

• Stereotypeigenschaften in Erweiterungsprofilen definierbar
• Importierte Konfigurationsinhalte ignorieren
• Verweis auf anderes Element

Doch was genau lässt sich unter diesen Punkten verstehen? Was bedeutet es, Stereotypeigenschaften in Erweiterungsprofilen definieren zu können, ohne das Rad neu erfinden zu müssen?

Bis einschließlich Version 13.3 von Innovator waren grundlegende Änderungen eines Stereotyps (Hinzufügen bzw. Wegnehmen von Merkmalen) nur in dem Profil möglich, in dem der Stereotyp definiert ist.

Beispielweise wurde dem Stereotyp <<Anforderung>> ein Merkmal „Geheimhaltungsstufe“ hinzugefügt. Dieses Merkmal musste bisher im ROOT-PROFILE konfiguriert werden.

Abb. 1: Individuelle Merkmale zu Elementen hinzufügen

Innovator 14.0 steht in den Startlöchern und damit für Sie als Anwender die Chance, individuelle Anpassungen und Modellierungs-Methoden so einfach wie noch nie zuvor in den Innovator zu bekommen:

Stereotyp-Eigenschaften können ab sofort in jedem beliebigen Profil angelegt und gepflegt werden.

Bis dato mussten Sie dafür die standardmäßig vorhandenen Profile eines jeden Modells anpassen, liefen dabei aber Gefahr, bei einem Update des Modells (durch Einspielen von Migrationsprofilen) die gemachten Änderungen wieder zu verlieren.

Abb. 1: Warnhinsweis bei der Sperrung von MID-eigenen Profilen

Einführung

Das Interesse am Thema Digitale Transformation nahm laut GoogleTrends in den letzten 10 Jahren um das 9-fache zu. Die Digitale Transformation wird in zahlreichen Papers, Foren und Blogbeiträgen diskutiert. Der Aufklärungsbedarf scheint groß zu sein.

In diesem Artikel zeigen wir, ob und inwieweit Modellierung zum Erfolg der Digitalen Transformation beitragen kann.

Begriffsklärung

Als Digitale Transformation bezeichnet man technologische Veränderungen und Neuentwicklungen, die so weitreichend sind, dass sie Unternehmen, die ganze Gesellschaft und das Alltagsleben betreffen.

Konkret: auf Basis technologischer Möglichkeiten (Sensorik, soziale Netzwerke, Big Data, zunehmende Vernetzung etc.) werden völlig neue Produkte und Dienstleistungen erschaffen oder die bestehenden erheblich verändert. Ein Beispiel dafür sind die FinTechs (Online-Banken, PayPal, PayDirect, Klarna).

Digitale Transformation in der Praxis

Die Unternehmen müssen bei der Digitalen Transformation dranbleiben, sonst werden sie von der Konkurrenz abgehängt oder sogar von neuen, technisch fortschrittlicheren Marktteilnehmern überrollt.

Sinnvolle Fragen, die sich Unternehmen in Bezug auf die digitale Transformation stellen können, sind:

1. Wie kann ich erfolgreich neue Geschäftsprozesse in die bestehende Prozesslandschaft und IT-Architektur integrieren?
   
2. Welche Bereiche sind betroffen?
3. Welche Konsequenzen bringen diese Anpassungen auf Prozess- und IT-Architekturebene mit sich?