Freitag, 18. Oktober 2024

Was ein Cloud-Architekt ist und warum Ihre Firma womöglich einen braucht

Quelle: Wikipedia

In der heutigen digitalen Welt, in der Cloud-Technologien zunehmend den Kern von IT-Infrastrukturen bilden, wächst die Bedeutung des Cloud-Architekten stark. Doch was genau macht ein Cloud-Architekt, und warum könnte Ihre Firma von dieser Rolle profitieren? Um das zu verstehen, ist es wichtig, einen Blick auf die klassischen Architekturrollen zu werfen und zu analysieren, wie sich diese in der Cloud-Ära weiterentwickeln.


Die Rolle eines Cloud-Architekten: Eine Verschmelzung von Kompetenzen

Es gibt sie schon lange und es gibt etliche Modelle und Frameworks, welche IT- und allgemein Unternehmensarchitektur (oft auch im Deutschgen Englisch Enterprise Architectur genannt) beschreiben oder besser definieren, wie man solche definiert. Traditionell definiert bspw. das verbreitete TOGAF (The Open Group Architecture Framework) verschiedene Rollen im Bereich der Unternehmensarchitektur, darunter:

Enterprise Architect:
Verantwortlich für die Gesamtarchitektur eines Unternehmens, um sicherzustellen, dass IT und Geschäft im Einklang stehen.

Business Architect:
Fokussiert auf die Geschäftsprozesse und wie die IT diese unterstützen kann.

Data Architect:
Zuständig für die Datenarchitektur und -verwaltung innerhalb der Organisation.

Application Architect:
Beschäftigt sich mit der Architektur der Anwendungen im engeren Sinn und ihrer Integration.

Technology Architect:
Fokussiert auf die technische Infrastruktur, darunter Netzwerke, Server und Speicher etc. Manchmal auch breiter gefasst und ebenfalls zuständig für den Software-Technologie-Stack mit verwendeten Sprachen, Frameworks und Speichersystemen, insb. Datenbanken.

Andere (gängige) Modelle und Frameworks definieren häufig ähnliche oder vergleichbare Rollen.

Mit dem Aufstieg der Cloud-Technologien – von IaaS (Infrastructure as a Service) über PaaS (Platform as a Service) bis hin zu SaaS (Software as a Service) – verschmelzen die Grenzen zwischen diesen Rollen jedoch zunehmend. In der Cloud-Welt sind Plattformen, Daten und Anwendungen eng(er) miteinander verzahnt, was es immer schwieriger macht, diese Bereiche und Aufgaben- respektive Zuständigkeitsgebiete klar zu trennen.

Ein Cloud-Architekt vereint mehrere dieser klassischen Rollen. Dies ist besonders dann relevant, wenn ein Unternehmen den Grossteil seiner IT-Infrastruktur in die Cloud auslagert oder cloudbasierte Technologien intensiv nutzt.

Die Anforderungen an IT-Systeme und Architekturen haben sich mit der Cloud revolutioniert. Während früher die physische IT-Infrastruktur lange Lebenszyklen hatte, ändern sich cloudbasierte Technologien rasant. Die Halbwertszeit des Wissens ist dramatisch gesunken, und Firmen müssen auf flexible, skalierbare Lösungen und Organisationsformen setzen, um wettbewerbsfähig zu bleiben.

Ein Cloud-Architekt muss dabei nicht nur Technologien verstehen, sondern auch:
  • Prozesse kennen, um Vorschläge machen zu können wie diese mit (Cloud-) Technologie verbessert werden können.
  • Tools und Produkte für den Aufbau und das Management von Cloud-Infrastrukturen und Services kennen und verstehen.
  • Erfahrung im Programmieren haben um abschätzen zu können, was der Einsatz von Cloud native Komponenten in der eigenen Software bedeutet.
  • (Neue) Business-Needs verstehen und cloudbasierte Lösungen entwickeln, die diese effizient adressieren.
  • Rechtliche Rahmenbedingungen der Cloud-Nutzung (z. B. Datenschutz und Compliance allgemein) kennen und sicherstellen, dass die Infrastruktur und generell der Setup mit allen Produkten und Services diesen entspricht.

Cloud Foundation

Im Zusammenhang mit dem Weg in die Cloud und der Cloud-Architektur allgemein wird ein Begriff immer populärer: Cloud Foundation. Ein nicht ganz neuer und nicht ganz eindeutiger Begriff. Gemeint ist hier die Cloud Foundation wie sie bspw. von meshcloud in deren Cloud Foundation Community verstanden wird: https://cloudfoundation.org/understanding-cloud-foundation

Eine Cloud Foundation hat das Ziel, eine stabile Grundlage für den Betrieb von Cloud-Systemen zu schaffen. Sie umfasst klare Best Practices, Governance-Regeln und eine sogenannte Landing Zone – eine gesicherte, standardisierte Umgebung für Cloud-Workloads. Der Aufwand, um einen neuen "leeren" Cloud-Tenant für alle nicht funktionalen Anforderungen (sog. NFR) fit zu machen darf nicht unterschätzt werden. In einer Public Cloud ist fast alles möglich, aber vieles muss auch selber konfiguriert werden.

In der Cloud Foundation spielen Cloud-Architekten eine wichtige Rolle, indem sie die verschiedenen möglichen Elemente der Cloud-Infrastruktur evaluieren, orchestrieren und eine skalierbare, sichere Umgebung definieren.

Die von meshcloud erwähnten wichtigsten Rollen in einer Cloud Foundation: Enterprise Architects, Platform Engineers and Operators, Security & Governance Stakeholders greifen meiner Ansicht nach zu kurz.

Da gerade ein Enterprise Architekt, je nach Definition und Framework, als Rolle relevante Bereiche nicht abdeckt. Um eine ideale Landing Zone zu definieren, brauchen Sie auch einen Data Architect. Das scheint auf den ersten Blick vielleicht irritierend zu sein. Aber um die Cloud (wirtschaftlich) erfolgreich zu nutzen, müssen Sie die Daten (-Prozesse) mit der Cloud verbessern können. Dazu braucht es eine Land Zone, welche die Nutzung und Integration von den dafür geeigneten Werkzeugen und Services optimal - out of the box - ermöglicht. Um die diesbezüglichen Anforderungen an eine Landing Zone zu definieren brauchen Sie ein Zielbild der Daten-Architektur und damit schliesst sich der Kreis zur Rolle des Data Architekten.


Neue Skill-Kombinationen sind gefragt

Da die Cloud-Welt eine Verschmelzung vieler Disziplinen darstellt, reicht es nicht mehr aus, ein reiner Daten-, Technologie- oder Anwendungsarchitekt zu sein. Cloud-Architekten müssen eine neue Kombination von Fähigkeiten mitbringen. Sie müssen in der Lage sein, strategisch zu denken, tiefgehendes technisches Know-how zu haben und gleichzeitig die geschäftlichen Anforderungen zu verstehen.

Cloud-Architekten sind die Brücke zwischen IT und Business. Sie schaffen die technische Grundlage, die es Unternehmen ermöglicht, die Flexibilität und Skalierbarkeit der Cloud optimal zu nutzen. Dabei müssen sie sowohl mit dem Business wie auch mit der IT auf Augenhöhe kommunizieren können.


Fazit: Der Cloud-Architekt als Schlüssel zur modernen IT - Warum Ihre Firma einen Cloud-Architekten brauchen könnte
Die digitale Transformation und die Migration der Cloud stellen Unternehmen vor neue Herausforderungen. Ein Cloud-Architekt kann helfen diese zu bewältigen, indem er die Kompetenzen aus verschiedenen Architekturdisziplinen vereint und massgeschneiderte Cloud-Lösungen aufzeigt. Wenn Ihre Firma den grössten Teil ihrer IT-Infrastruktur aus der Cloud bezieht oder dies plant, könnte ein Cloud-Architekt der entscheidende Faktor für den Erfolg Ihrer IT-Strategie sein. Im Rahmen einer internen Cloud Foundation agiert er dabei natürlich nicht alleine, wie wir gesehen haben. Es braucht ein starkes "Cloud-Team", in welchem der Cloud-Architekt eine wichtige Rolle spielen kann.


Wie wird man Cloud-Architekt und haben wir einen Fachkräftemangel an Cloud-Architekten in der Schweiz?

Da ein Cloud-Architekt verschiedene Skills vereint, gibt es verschiedene Werdegänge, um ein guter Cloud-Architekt zu werden. Aus meiner Sicht ist es aber wichtig, dass ein Cloud-Architekt programmieren kann.

Er braucht Erfahrung in der Software-Entwicklung, da Cloud native Software in der Cloud (fast) immer mehr eine Kombination aus Diensten aus der Cloud und der eigenen Software ist. Ein Cloud-Architekt muss daher verstehen was es heisst, wenn man einzelne Funktionen einer Anwendung nicht selber implementiert und an der Stelle die Funktion mit einem Service abdeckt. Welche wiederum in die eigene Software integriert, getestet und betrieben werden muss. Er muss aber auch Programmieren können um die Ansätze von IaaS zu verstehen und abschätzen zu können, welches Tool für welchen Bereich von Infrastruktur, Deployment und Konfiguration für welches Use Cases sinnvoll ist.

Aktuell haben wir aus meiner Sicht einen theoretischen Fachkräftemangel an Cloud-Architekten. Theoretisch deshalb, weil viele Firmen noch nicht erkannt haben, dass sie vielleicht einen bräuchten. Den Soll-Bestand könnte aktuell wohl nicht abgedeckt werden. Schaut man sich die aktuellen Stellenausschreibungen an, hält sich die Nachfrage aber noch zurück. Um einem künftigen effektiven Mangel entgegen zu wirken ist es notwendig, dass man in der Schweiz (weiterhin) zu attraktiven Konditionen Programmieren kann. Wenn immer mehr Firmen die Programmier-Arbeit ins billige Ausland geben, fehlen hier künftig Fachkräfte, welche auf solchen Profilen aufbauen. Dann haben wir in Zukunft vermehrt PowerPoint-Architekten die wenig hilfreiche Folien pinseln ohne zu wissen, was sie wirklich tun. Gefragt ist breites und tiefes Know-how und Erfahrung, wie die nachfolgenden Anforderungen aus einem aktuellen Stelleninserat mit dem Title "Cloud Architekt" zeigen:

  • Hochschulabschluss in Informatik (FH, Uni, ETH) mit praktischem Know-How (>10 Jahre) im Systems- und Software-Engineering
  • Mehrjähriger Erfahrung bei der Konzeption und Umsetzung (Hands-On) der Cloud Migration zu einem der drei Hyperscaler
  • Mehrjährige Erfahrung als Architekt*in in komplexen Applikationsentwicklungs- und Infrastrukturprojekten unter anderem bei der Implementierung von serviceorientierten Architekturen
  • Mehrjährige Erfahrung mit Container- (Docker, Podman, Kubernetes, OpenShift,…) und Cloud- (Terraform, Pulumi, ObjectStore, FaaS, CloudEvents,...) Technologien sowie bei der Implementierung von eventbasierten Architekturen u.a. mit Data Streaming Plattformen wie Kafka
  • sicherer Umgang mit Tools wie Git, JIRA, Jenkins, Gitlab CI/CD
  • ausgezeichnete Plattformkenntnisse von Linux und Unix-Systemen
  • Plattformkenntnisse von Windows Systemen
Man könnte zum Schluss kommen, die Organisation hier sucht eine ganze IT-Abteilung, nicht nur eine Rolle/Funktion. Es geht auch weniger anspruchsvoll, wie dieses aktuelle Beispiel zeigt:

  • Erfahrung im Einsatz von Public Cloud Services wie Amazon AWS, Microsoft Azure und Google Cloud Platform
  • Implementierungs-Kenntnisse im modernem SW-Development Umfeld
  • Erfahrungen im Aufsetzen von Pipelines in einer modernen & sicheren CI/CD Landschaft
  • Zertifizierung(en) eines Public Cloud Providers oder für Softwarearchitektur (z.B. ISAQB / CPSA)
Den meisten Anforderungen ist gemeinsam, dass sie sowohl Software-Entwicklungskenntnisse inkl. CI/CD wie auch Infrastruktur-Kenntnisse verlangen. 

Es handelt sich um die erwähnte Verschmelzung von bisher meist getrennten Rollen und Funktionen.

Was ich nicht selten etwas vermisse ist der Business-Kontext. Um eine auf die Bedürfnisse des Business optimierte Lösung zu konzipieren muss ein Cloud-Architekt meines Erachtens auch in der Lage sein, Geschäftsanforderungen und Geschäftsprozesse zu verstehen.

Hinweis: Man findet synonym zu Cloud Architekt auch den Begriff Cloud Solution Architekt.

Haben Sie bereits eine Cloud Foundation und/oder einen Cloud (Solution) Architekten?

Mittwoch, 16. Oktober 2024

Back to the future - Wo die Google Cloud der Bank-IT heute helfen kann

Wir schreiben das Jahr 2015, als ich im September einen Artikel mit dem Titel: "Was sind die Anforderungen an die Banken-IT von Morgen?" veröffentlicht habe (Artikel). Wir blicken also 9 Jahre zurück. Die These war, dass man nur zwei Kategorien braucht, um alle Anforderungen an die Bank-IT von morgen zu kategorisieren:

Quelle: Ronny Fuchs, Artikel vom September 2015

Kosten reduzieren und Verkauf von Produkten und Dienstleistungen unterstützen. Im Nachhinein ist man bekanntlich immer schlauer. Für einmal würde ich den Artikel aber auch "back to the future" fast identisch schreiben. Die Themen sind meines Erachten alle nach wie vor vorhanden und relevant. Beim Thema Personal Finance Manager (PFM) gibt es wahrscheinlich eine kleine Adaption, weg vom Begriff hin zu den Funktionen. In anderen Worten: Von PFM spricht eigentlich niemand mehr, aber die Funktionen die unter diesem Begriff adressiert waren, sind nach wie vor aktuell, direkt ins jeweilige E-Banking integriert.

Da es bezüglich Themen und Herausforderungen eine gewisse Stabilität zu geben scheint, lohnt sich ein Blick mit der Cloud-Brille auf diese Themen. Wo kann die Google Cloud heute konkret helfen, Anforderungen zu erfüllen? "The new way to cloud" aus einer funktionalen Anforderungsperspektive. Damit sind wir definitiv zurück im Jahr 2024.

Der Fokus liegt dabei klar auf kurz- bis mittelfristig realisierbaren Umsetzungen. Ich gehe nicht davon aus, dass eine Bank in den nächsten 1-2 Jahren selber anfängt, eine komplette Bankensoftware Cloud native zu entwickeln. Dennoch hat eine Bank aus meiner Sicht gute Möglichkeiten, von auserwählten spezifischen Cloud-Lösungen zu profitieren.

Wenn man sich die Anforderungen anschaut liegt der Schluss nahe, dass die Google Cloud mit ihren einzigartigen Kapazitäten in der Poleposition für einzelne Anforderungen ist. Im vorliegenden Artikel möchte ich daher Inputs und Gedankenanstösse liefern, wie man der zukunftsfähigen Banken-IT mit den heutigen Möglichkeiten von Cloud-Services einen weiteren Schritt näher kommen kann. Doch jetzt der Reihe nach.

Die Themen:

Compliance

Das Thema ist nach wie vor aktuell:

Auszug aus Blog-Artikel 2015

Als horizontales Thema können verschiedene GCP-Produkt die Anforderungen und Zielsetzungen von Compliance unterstützen. Konkret zum Thema Bank-Compliance hat Google ein für Finanzinstitute exklusives Anti Money Laundering (AML) API: https://cloud.google.com/anti-money-laundering-ai?hl=en

Vielleicht eine Möglichkeit, das AML auf die nächste Stufe zu heben und besser in eine Microservice-Architektur zu integrieren?


Mobile Banking

Nicht mehr wegzudenken - oder?

Auszug aus Blog-Artikel 2015

Die Google Cloud selber bietet nicht direkt entsprechende App Client-Produkte an. Aber Google stellt mit Flutter und Angular entsprechende Technologien bereit, um (auch) Apps effizient zu entwickeln:



Personal Finance Manager (PFM)

Der Begriff ist etwas out, aber die Funktionen nach wie vor aktuell.

Auszug aus Blog-Artikel 2015

Hier bietet die Google Cloud ein breites Spektrum an Lösungsmöglichkeiten. Dies insbesondere in den Bereichen der Transaktionsklassifikation und des Vorschlagswesen. Automatische Transaktionsklassierung oder Fragestellungen wie: "Was nutzen vergleichbare Kunden für Produkte und Dienstleistungen" oder "Was bezahlen andere Kunden monatlich für das Mobile-Abo" etc. sind typische Themen des maschinellen Lernens. Dazu bietet Google Cloud mit Vertex AI und BigQuery vielversprechende Möglichkeiten:


Das Thema ist natürlich eng verwandt mit der Anforderung "Daten-Analyse", siehe weiter unten.


Self Service

Um echten Self Service anbieten zu können, müssen die internen Prozesse in Workflows automatisiert sein. Heute ist Self-Service bei Banken teilweise immer noch ein Potemkinsches Dorf wo die Mitarbeiter wie bei Optimus manuell die Fäden im Hintergrund ziehen:

Auszug aus Blog-Artikel 2015

Google Cloud kann hier etwas Abhilfe schaffen. Wenn auch durch AI Agents die kompletten Prozesse nicht vollständig abgedeckt werden können, wenn die dafür notwendigen technischen Schnittstellen fehlen, so können mit AI Agents doch partiell Self-Service-Angebote realisiert werden. Oder die E-Banking Hotline kann bspw. entlastet werden in dem AI Agents für Kunden direkt oder für Mitarbeiter Standardabklärungen vornehmen.




Customer Journey und Multi Channel

Customer Journey und Multi Channel haben aus meiner Sicht in letzter Zeit etwas an Fahrt verloren. Es gibt nicht viele Bank-Prozesse, wo der Kunde im Mobile starten, vor Ort am Schalter nahtlos einen nächsten Schritt ausführen und den Prozess dann bequem zu Hause am Computer abschliessen kann. Aber vielleicht ist auch schlicht die Nachfrage zu klein dafür. Bei der Customer Journey sieht es aus meiner Sicht über einen längeren Horizont vergleichbar aus. Oftmals fehlen der Bank jedoch Informationen oder sie haben diese nicht genügend gut verfügbar. So begleiten die Banken Kunden auf ihrer Reise, bspw. vom Hauskauf über das Wohnen, Vermieten und wieder Verkaufen nur partiell und in der Regel dann, wenn der Kunde selber auf die Bank zu geht:

Auszug Blog-Artikel 2015

Eine fertige Lösung hat die Google Cloud natürlich nicht. Dies müssen die Banken letztlich selber realisieren. Aber eine Customer Data Platform (CDP) könnte je nach konkreter Herausforderung vielleicht eine gute Grundlage für nächste Schritte schaffen. CDP ist eine Kombination von verschiedenen Produkten wie BigQuery/ML, Looker/Looker Studio und Analytics Hub. Im Themenbereich Customer Journey könnte eine CDP bspw. dabei helfen, Daten zusammenzuführen und eine personalisierte Kommunikation zu ermöglichen, basierend auf externen Informationen wie Google Trends oder Wetterdaten etc.


Big Data, Data-Analytics. Machine Learning

Wenn ich 2015 Machine Learning mit AI ersetzt hätte ... Gerade hoch aktuell. Sicher in gewissen Bereichen etwas "Hype", das soll aber nicht vom echten Potential ablenken.

Auszug Blog-Artikel 2015

Hier schöpft Google aus dem vollen. Es gibt fast unzählige Werkzeuge in diesem Themenbereich. Hier die aus meiner Sicht wichtigsten:



Produkt-Innovation

Echte Produktinnovation im Banking ist schwierig. Die eigentlichen Bankprodukte sind alle im Grunde recht alt. Es geht in der Regel mehr um die Einfachheit und den Zugang (bspw. für eine neue Kundengruppe, über einen neuen Kanal, zu einem neuen Instrument etc.), als um das Bankprodukt im finanzmathematischen oder rechtlichen Sinn. Eine Bank bietet neue die Möglichkeit, Bitcoins über das E-Banking zu kaufen und zu verwalten? Keine Bankproduktinnovation, einfach ein Zugang zu einer zusätzlichen Anlageklasse. Das "Münz" aus Kartentransaktionen wird in Aktien investiert? Einfachheit (ich muss es monatlich nicht selber ausrechnen und beauftragen) und vielleicht Zugang (kleine Beträge investieren können). Nicht zu vergessen natürlich die Preiskomponente. Nach einer Phase von hohen Kontoführungsgebühren, schon fast vor Jahrzehnten von der UBS eingeführt und dann Schritt für Schritt von anderen übernommen, geht der Trend aktuell wieder hin zu Kostenlos. Normale Zyklen:

Auszug Blog-Artikel 2015

Zugegeben schwierig, hier ein Cloud-Produkt zu finden, das unterstützen könnte. Aber es gibt sie. Vielleicht helfen Ihnen A/B-Tests herauszufinden, welche Anpassungen an Produkten die Kunden schätzen. Dadurch können Sie die Produkt-Innovation mindestens im funktionalen Bereich von Zugang und Einfachheit mit kleinen Schritten beschleunigen. Die nachfolgenden Quellen können als nützliche Inspiration dienen:





Banksteuerung

Nach wie vor unabdinglich für eine Bank:
Auszug Blog-Artikel 2015


Direkte Lösungen für die Bankensteuerung bietet die Google Cloud nicht. Und dennoch gibt es Werkzeuge, welche unterstützen können.




Stärken und Funktionen:

Prozess-Engine

Mehr und mehr Banken setzen Prozess-Werkzeuge ein. Bei der Durchgängigkeit und auch beim Thema einfaches Outsourcing von einzelnen Schritten besteht sicher noch Verbesserungspotential.

Auszug Blog-Artikel 2015

Google Cloud kann hier mit mehreren Werkzeugen unterstützten. Erwähnenswert sind sicher die beiden Produkte Cloud Composer und Dataflow.

Als managed Apache Airflow bietet es volle Flexibilität und eine grafische Darstellung der Prozesse. Geeignete vor allem für etwas länger dauernde Prozesse.

Als Apache Beam Executor bietet Dataflow eine hoch skalierbare performante Streaming-Plattform. Mit Apache Beam lassen sich auch zeitkritische Order-Prozesse effizient umsetzen.

Nicht immer hat man strukturierte Daten in einem Prozess. Nach wie vor gibt es mehr oder weniger unstrukturierte Daten wie PDF. Hier könnte bspw. Document AI als Prozess-AddIn dienen um solche Dokumente in einem automatisierten Prozess verfügbar zu machen: https://cloud.google.com/document-ai?hl=de


Wizard-Engine

Da besteht noch Luft nach oben, aus meiner Sicht:

Auszug Blog-Artikel 2015


Die Google Cloud selber, bietet da nicht direkt Werkzeuge für Endkunden-Wizards. Mit der Kombination der Werkzeuge von "Prozess Engine" und "Client-Unabhängigkeit", lässt sich dies aber gut realisieren. Gerade Flutter bietet dazu bspw. mit dem Stepper Widget ein gutes Werkzeug an.



Client-Unabhängigkeit

Die breite Nutzung des TV zur Freigabe von E-Rechnungen ist mir heute nicht bekannt. Aber die Gerätevielfalt ist eine Tatsache. Wenn auch bspw. Tablets vermehrt durch Foldable-Smartphones abgelöst werden:

Auszug Blog-Artikel 2015

Die Google Cloud bietet für die Clients selber nicht direkt Lösungen an. Google aber schon. So haben sich Angular und Flutter rasant weiterentwickelt. Mit beiden ist es möglich, verschiedene Geräte mit einer Source zu bedienen.



Berechtigungen & Kompetenzen

Bei diesem Thema sind wir noch nicht da, wo wir sein könnten. Die Kompetenzordnungen sind vielfach nach wie vor unnötig kompliziert und nicht durchgängig bis zum Kunden automatisiert anwendbar:

Auszug Blog-Artikel 2015

Es gibt verschiedene Produkte, die hier unterstützen können. Für die Daten-Analyse als Input, siehe weiter unten bei der Funktion "Daten-Analyse". Da die effektiven Berechtigungen und Kompetenzen in der Regel im Kernbankensystem gepflegt werden, konzentrieren wir uns an dieser Stelle auf die real-time Berechnung von Berechtigungen und Kompetenzen, insb. im Zusammenhang mit Ergebnissen aus einer Daten-Analyse.

Hierzu bietet sich Dataflow als skalierbarer Streaming-Lösung an: https://cloud.google.com/products/dataflow?hl=en

Mehr zum Thema Dataflow und Apache Beam finden Sie hier: https://ronnyfuchs.blogspot.com/2024/05/cloud-serie-streaming-mit-apache-beam.html


Offene Schnittstellen

OpenBanking ist nach wie vor aktuell. Die damals propagierte Erweiterung von einfachen Rest-API hin zu ganzen Workflow-API ist noch nicht ganz soweit. Vereinzelt gibt es Onboarding-Schnittstellen in diese Richtung. Aber da besteht noch Potential. Bevor aber die internen Workflows nicht vollständig digitalisiert sind, können sie auch nicht als offene Schnittstelle angeboten werden. Für diesen Punkt braucht es also noch etwas mehr Zeit.

Auszug Blog-Artikel 2015

Für das Management und die Orchestrierung von API hat Google mit Apigee ein Spitzenprodukt im Sortiment: https://cloud.google.com/apigee?hl=en


Daten-Analyse

Aktueller könnte das Thema fast nicht sein, die Daten-Analyse:

Auszug Blog-Artikel 2015

Als Input für Workflows wird sie meiner Meinung nach nach wie vor nicht oft verwendet. Aber bei diesem Thema entfaltet sich die geballte Innovation von Google im Bereich Datenspeicherung, Verarbeitung und Analyse. Es gibt zahlreiche Produkte, welche hier aufgeführt werden könnten. Eine kleine Auswahl davon:

BigQuery: Ein Data Warehouse, in Kombination mit weiteren Produkten ein Data Lakehouse. Hochintegriert in die AI/ML-Produkte von Google bietet es unglaublich viele Möglichkeiten der Datenanalyse: https://cloud.google.com/bigquery?hl=en

Erwähnenswert in diesem Zusammenhang sind sicher auch die Möglichkeiten der integrierten Vektor-Suche: https://ronnyfuchs.blogspot.com/2024/09/bigquery-vektor-suche.html

Wenn es darum geht, Daten visuell zu analysieren und aufzubereiten, stehen mit Looker und Looker Studio leistungsstarke Werkzeuge zur Verfügung: https://cloud.google.com/looker?hl=en / https://cloud.google.com/looker-studio?hl=en

Last but not least: Vertex AI. Die wohl aktuell leistungsstärkste AI-Plattform auf dem Markt: https://cloud.google.com/vertex-ai?hl=en

Vertrex AI ist hoch integriert. Sie können aus verschiedenen Google-Produkte wie bspw. BigQuery Vertex AI verwenden, ohne die Applikation (in dem Fall BigQuery) verlassen zu müssen.


Konklusion
AI ist, nicht nur aber auch, im Zusammenhang mit Cloud in aller Munde. Dabei ist AI eigentlich kein Thema für sich, es spielt nur (fast) überall mit. Dabei geht es nicht um AI in der Form von "wir haben AI", es geht darum, dass die Funktion besser wird. Besser im Kontext von Kosten reduzieren und/oder Verkauf von Produkten und Dienstleistungen unterstützen. Kein Kunde denkt sich, ah, die Bank Abc hat AI, dann eröffne ich ein Konto. Und genau so sollten IT-Lösungen nicht einfach "powered by AI" sein, sie müssen gut sein. Ob mit oder ohne AI. Wenn man sich die Werkzeugvorschläge ansieht stellt man fest, es geht hauptsächlich um Daten. Und gute Daten sind die Grundlage von maschinellem Lernen und AI. Und um mit den Daten arbeiten zu können, braucht es Prozesse. Workflows. Data Pipelines. Datenbanken. Und natürlich effizienter Speicher. Erst diese robuste Foundation macht es möglich, darauf aufbauend mit AI gezielt weitere Verbesserungen zu erzielen. Und genau bei dieser Foundation kann Ihnen die Google Cloud helfen. Denn sie ist in vielerlei Hinsicht mit unter das Herzstück von Google selbst. Gehen Sie also in erster Linie den Schritt in die Cloud, um ihre Daten (-Prozesse) zu verbessern. Der Rest ergibt sich Schritt für Schritt.

Für den Weg in die Cloud empfiehlt sich eine fundierte interne Cloud Foundation. Um aus den hunderten und tausenden Produkten und Möglichkeiten einen passenden ersten Setup und ein adäquates Vorgehen zu definieren, ist es allenfalls ratsame, einen (externen) Spezialisten beizuziehen.


Montag, 14. Oktober 2024

Buzzword-Puzzle: Data Lake Ware House Vault Mesh Fabric


Im Zusammenhang mit analytischen Daten gibt es jede Menge Begriffe, welche die jeweils optimale Architektur definieren. In diesem Beitrag ordne ich ein paar von diesen Begriffen etwas ein.

Erzählen wir die Geschichte von vorne, als Bill Inmon, der Vater vom Datawarehouse (DWH), den Begriff und das Konzept Anfang der Neunzigerjahre des letzten Jahrhunderts einführte. Bill Inmon definierte und charakterisiert(e) das Datawarehouse wie folgt: "A subject oriented, nonvolatile, integrated, time variant collection of data in support of management's decisions." Daraus lässt sich bereits einiges ableiten. Die Daten sind wohlstrukturiert, es bezieht sich auf ein Subjekt, also um eine definierte Struktur. Die Daten sind unveränderlich und haben eine zeitliche Dimension. Dazu gibt es eine klare Zielsetzung, Entscheidungen vom Management zu unterstützen. Daten werden mittels ETL: Extract Transform Load in ein DWH geladen. Das T vor dem L ist hier wichtig, weil die Daten zuerst transformiert werden, bevor sie geladen werden. Im DWH selber sind die Daten dann entsprechend zielgerichtet strukturiert vorhanden. Bill Inmon hat dutzende von Bücher zum Thema geschrieben. Es wäre vermessen zu behaupten, diese paar Sätze würden dem Thema gerecht. Zum Vergleich mit den anderen Begriffen und zur Einordnung sollte es aber vorerst ausreichen.

Das DWH entstand in einer Zeit, wo Speicherplatz noch rar und teurer war. Jüngere Leser können sich dies vielleicht nicht ganz vorstellen. Man sammelte nur die Daten die wirklich für das Business relevant waren und in einer Form, wie man sie für den Zweck effizient nutzen konnte. Der Speicher wurde aber immer grösser und immer günstiger und es kam die Zeit, als man Daten einfach auf Vorrate speichern konnte. Niemand weiss für was, aber vielleicht kann man sie einmal brauchen.

Das war die Geburtsstunde vom Data Lake. Während ein Warenhaus (Warehouse) ordentlich strukturiert Produkte anbietet die nachgefragt werden, sind stille Wasser tief und die Tiefen der Meere grösstenteils unbekannt. Die Erfindung des Begriffs lässt sich nach meinen bescheidenen Recherchen fundiert keiner einzelnen Person zuordnen. Die Grundlagen schufen aber sicher zu einem wichtigen Teil Google mit dem MapReduce-Projekt (etwas mehr dazu in diesem Artikel zum Thema Streaming-Applikationen), dem Google Dateisystem und nicht zuletzt Doug Cutting, dem Erfinden von Apache Lucene und Hadoop, welches auf MapReduce aufsetzt und Ideen vom Google Dateisystem aufgriff. Hadoop wurde 2006 das erste Mal veröffentlicht. Damit war erstmals die Grundlage geschaffen, dass man auch mit günstiger Hardware riesige Datenmengen (zentral) verwalten konnte. Eine wichtige Grundlage eines Data Lakes. Damit kommen wir zu den Charaktereigenschaften. Ein Data Lake ist eine Sammlung von strukturierten aber vor allem auch unstrukturierten Daten. Daten in einem Data Lake können unterschiedliche Formate haben (Texte, Bilder, Audio, Video etc.) und sich auch semantisch von einander unterscheiden. Was ein Data Lake ausmacht ist, dass über definierte API zentral auf die Daten zugegriffen werden kann. Ein Data Lake ist also eine Art Integrations-Layer. Die technische Integration ist gelöst und wird bereitgesellt. Was man inhaltlich wie mit den Daten macht oder machen kann, ist nicht festgelegt oder zumindest nicht für alle Daten. Um Daten aus einem Data Lake nutzbar zu machen, müssen sie inhaltlich semantisch erschlossen und nicht selten technisch transferiert werden. Dies führte dazu, dass der Data Lake oftmals in Co-Existenz mit einem Data Warehouse war und dies in einer bidirektionalen Form: 1) Aus dem Data Lake werden einzelne Daten gezielt mittels ETL in ein Data Warehouse geladen. 2) Grosse Daten wie Videos werden im Datawarehouse nur mittels Metadaten referenziert. Die Daten selber bleiben im Data Lake und werden bei Bedarf direkt aus dem Data Lake geladen. Nebenbemerkung: Werden (zu) wenige Daten über die Zeit strukturiert nutzbar gemacht, spricht man abwertend auch von einem Data Swamp.

Damit sind wir bei der Verschmelzung und dem Begriff Data Lakehouse oder Data Lakewarehouse angekommen. Die Nutzung von Daten in einem Datawarehouse und einem Data Lake über eine zentrale API wäre wunderbar. Und noch besser, wenn man sie direkt kombiniert verwenden könnte. Diese Verschmelzung bieten Produkte wie bspw. Googles BigQuery in Kombination mit Cloud Storage. Sie können klassisch strukturierte Daten in BigQuery speichern und daneben bspw. Daten in Form von CSV oder JSON/JSONL im Cloud Storage speichern. Auf beide Ressourcen können sie via BigQuery-Interface zugreifen und dabei sogar Daten aus BigQuery mit einer CSV-Quelle in einem SQL-Statement kombinieren, ohne dass das CSV zuerst mittels ETL in BigQuery geladen werden muss. Und voilà, da haben Sie ein Data Lakehouse. Selbstverständlich können Sie das nicht mit allen Daten gleichermassen direkt ohne E und T machen. Aber die Adapter werden mehr und mehr und beinhalten bspw. auch Standard SQL-Datenbank und NoSQL-Datenbanken. Ein Data Lakehouse bietet wo notwendig und hilfreich die Vorteile eines Data Warehouses bei gleichzeitiger Möglichkeit, unstrukturierte oder noch unbekannt strukturierte Daten auf Vorrat zu speichern und bei Bedarf einfach zu analysieren und nutzbar zu machen.

Schön, dieses Data Lakehouse. Aber wie organisiert man es am besten? Sie ahnen es, es gibt mehrere Möglichkeiten. Schauen wir uns zwei bekannte Möglichkeiten an, um ein weiteres Buzzword zu erschlagen.

Medaillen-Architektur:
In dieser Architektur-Form organisiert man die Daten anhand des Reifengrades der inhaltlichen Erschliessung. Klassisch Bronze, Silber und Gold. Daten im Bronze-Bereich sind roh, so wie sie von einem Drittsystem gespeichert werden. Silber-Daten haben bereits eine erste Transformation hinter sich, besitzen bspw. eine eindeutige Id über den ganzen Data Lake oder sind hinsichtlich einzelner Attribute normiert auf ISO-Code (Länder, Währungen etc.). Die Gold-Daten schliesslich können vom Business verwendet werden. Sie besitzen dem Business bekannte Attributsnamen und verkörpern sinnvollerweise Business-Objekte. Wir kommen wenig später beim Data Vault nochmals auf diese Aufteilung zurück.

Data Vault
Damit sind wir beim nächsten Buzzword, Data Vault, angekommen (wir sprechen hier von Data Vault 2.0, welches 2013 veröffentlicht wurde).

Wichtig ist das Verständnis, dass Data Vault 2.0 zwei grundlegende Architektur- oder besser Design-Prinzipien für die Daten definiert:

  1. Hub, Link, Satellite (HLS):
    Dieses grundlegende Konzept der Datendefinition gab es bereits in der Version 1.0. Die Hub-Tabellen stellen Business-Objekte wie Kunden, Produkte und Bestellungen dar. In ihnen werden die eindeutigen Schlüsseln gespeichert. Die Link-Tabellen enthalten die Verbindungen zwischen verschiedenen Entitäten. Die Satelliten-Tabellen schliesslich, enthalten die Attribute zu den Hub- oder Link-Objekten. In einer Hub-Tabelle kommt ein Kunde nur einmal vor, mit einer eindeutigen Id. In der Satelliten-Tabelle kann dieser Kunde aber mehrmals vorkommen. So können bspw. Historisierungen abgebildet werden.
  2. Landing Zone, Raw Data Vault, Business Data Vault, Information Mart:
    Dies beschreibt den Datenlade-Prozess von links nach rechts: In der Landing Zone werden die Daten gespeichert, wie sie sind. Also im Original. Im Raw Data Vault kommt die HLS-Modellierung der Daten zum Zuge. Die Daten aus der Landing Zone werden mittels HLS abgebildet. Im Business Data Vault werden spezifische Business-Views abgebildet, die einen spezifischen Use Case abdecken. Im Information Mart werden die Daten schliesslich effektiv zugänglich gemacht. Das kann eine Visualisierung sein oder auch spezifische API mit Metadaten etc.
Sie haben vielleicht bereits die Ähnlichkeit zwischen der Medaillen-Architektur und dem Lade- oder Aufbereitungsprozess von Data Vault festgestellt. Und tatsächlich lässt sich dies gut in Einklang bringen:
  • Bronze:
    - Landing Zone
  • Silber:
    - Raw Data Vault
    - Business Data Vault
  • Gold:
    - Information Mart
Damit lässt sich Data Vault grundsätzlich gut mit einem Data Lakehouse umsetzen. Oder ein Data Lakehouse mit Data Vault strukturieren. Aber es gilt festzuhalten: Nur weil man das Data Lakehouse in vier anstelle von drei Töpfen organisiert, hat man noch kein Data Vault umgesetzt. Data Vault hat man umgesetzt, wenn man im Topf 2, Silber/Raw Data Vault, die Daten mit HLS strukturiert.

Ein Buzzword für eine echte Kombination kenne ich bislang noch nicht. Wenn Data Vault mit einem Data Lakehouse umgesetzt haben, haben Sie aktuell einfach Data Vault mit einem Data Lakehouse umgesetzt. Haben Sie einfach ein Data Lakehouse mit den vier Töpfen, haben Sie, je nach Benennung und Verwendung der Töpfe, ein Data Lakehouse mit Data Vault 2.0 Ladeprozess umgesetzt.

Wenn Sie Zweifel haben, dass eine zentrale Einheit es schafft, die Daten in den Gold-Standard oder nur schon in Use Case spezifische Business Views zu bringen, dann sind Sie nicht alleine. Data Mesh wurde 2019 von Zhamak Dehghani propagiert. Data Mesh orientiert sich u.a. am Domain Driven-Konzept von Eric Evans aus dem Jahre 2003 und besagt, dass auch die analytischen Daten von den Entwickler-Teams der transaktionalen Daten in Eigenverantwortung allen bereitgestellt werden müssen. Es ist ein soziotechnischer Ansatz für eine dezentrale Datenarchitektur. Data Mesh impliziert "Data as a Product" mit entsprechender Domänenverantwortung. Data Warehouse, Data Lake, Data Vault sind zentralistische Ansätze, welche sich in der Regel auch auf die Organisation auswirken. Dedizierte Teams sind verantwortlich für den Auf-, Ausbau und den Betrieb der Lösungen. Dabei beziehen sie (meist) transaktionale Daten aus den operativen Systemen um sie wiederum für verschiedene Stakeholder nutzbar zu machen. Data Mesh ist mehr ein kulturellen Wandel in der Art und Weise, wie Unternehmen über ihre Daten denken, denn eine technische Lösung. Anstatt dass Daten als Nebenprodukt eines Prozesses gesehen werden, werden sie zu dem eigentlichen Produkt (Stichwort "Data as Product"), bei dem die Datenproduzenten (resp. die Owner dieser System) als Datenprodukteigentümer fungieren. Technisch gesehen können einzelne Teams ihre Datenprodukte intern natürlich auch bspw. mit einen Datawarehouse oder strikt nach Data Vault umsetzen und ihre Datenprodukte bspw. über entsprechende Dashboards oder Rest API zur Verfügung stellen. Dass jedes Team innerhalb derselben Unternehmen einen eigenen richtigen Data Lake aufbaut und unterhält, ist wohl eher weniger empfehlenswert und auch nicht der Sinn von Data Mesh. Wenn Sie mehr über Data Mesh wissen möchten, finden Sie hier einen guten Überblick.

Das Gegenteil von einem soziotechnischer Ansatz ist eine Fabrik, könnte man sagen. Damit wären wir mit Data Fabric beim letzten Buzzword von diesem Artikel angekommen. Data Fabric kann als eine Art virtuelle (Architektur-) Schicht angesehen werden, welche Daten von verschiedenen Quellen u.a. mit Hilfe von KI in real-time aggregiert und kontrolliert zugänglich macht. Obwohl man heute so einiges einfach in einen Data Lake speichern kann gibt es Datenspeicher, welche nicht zentral erschlossen werden können. Dies kann verschiedene Gründe haben. Der technische Prozess lohnt sich (noch) nicht oder die Daten sollen nicht redundant gehalten werden. Dennoch möchte man bestimmte Daten aus einem Data Lake, Data Lakehouse, aus verschiedenen Data Warehouses und weiteren Quellen vielleicht in einer zentralen Sicht haben. Data Fabric hat aber nicht nur eine aggregierende Funktion. Data Fabric kann, je nach Tool, auch als Discovery genutzt werden. Also um noch nicht erschlossene Daten zu entdecken. Data Fabric speichert dabei selber keine Inhaltsdaten. In einer Data Fabric werden nur jeweils Metadaten zu Quellen gespeichert. Data Fabric ermöglicht in der Regel eine feingranulare Zugriffsregelung um spezifische Data Governance-Konzept einer Unternehmung um zu setzen. Data Fabric ersetzt kein vorstehend genanntes Buzzword, kann aber hilfreich um diese zentral zu erschliessen und eine konsolidierte Sicht darauf zu geben. Data Fabric ist nicht das Gegenteil von Data Mesh wie eingangs als Überleitung vielleicht suggeriert wurde. Als zentralistischer Ansatz ist es aber dennoch mindestens ein Stück weit ein  mentaler/methodischer Widerspruch. Technisch gesehen ist Data Fabric in der Regel ein Software-Tool, welches wiederum auf verschiedene Tools zurück greift. Eine bekannte Data Fabric-Lösung ist Dataplex von Google.