Zum Inhalt springen
Alexander von Boguszewski
Alexander von Boguszewski
  • Startseite
  • Referenzarchitekturen & Datenmodelle
  • Impressum

Kategorie: Statusupdate

status
AvB Alexander von Boguszewski
· 21. Januar 2026 · 1 Minute zu lesen


Wir reden ständig über „AI‑powered“, „All‑in‑one“ und „Data xxx Architecture“. Klingt großartig, leider kauft niemand Buzzwords. Kunden kaufen kürzere Durchlaufzeiten, weniger Ausschuss, niedrigere Kosten, mehr Umsatz.

Bei „AI‑powered Forecasting“ höre ich nur teurer Proof‑of‑Concept.
Sagt stattdessen: Unsere Prognosen reduzieren eure Bestände um bis zu 20 % und senken Out‑of‑Stocks.

„Self‑Service Analytics“? … ohh nicht noch ein weiteres Tool.
Sagt: Antworten in Minuten statt Tickets an das Data‑Team.

„Real‑time Insights“? … 2010 hat angerufen
Sagt: Ihr seht Risiken bevor sie teuer werden – nicht im Monatsreport.

Weniger Folien, mehr Wirkung. Streicht Fachchinesisch. Versprecht Ergebnisse, nicht Features. Wer Business Value nicht in einem Satz anteasern kann, hat oft keinen!

Business Value > Features

BuzzwordsAndValue

reply

OH NEIN, die Delos / Microsoft Cloud schützt gar nicht vor Datenabfluss.

AvB Alexander von Boguszewski
· 22. Oktober 2025 · 1 Minute zu lesen
https://www.golem.de/news/innenministerium-baden-wuerttemberg-zugriffe-durch-drittstaaten-bei-delos-cloud-moeglich-2510-201397.html (golem.de)

Statt klar zu sagen „Wir können oder wollen es nicht besser“, kommt dann als Stellungnahme juristischem Kauderwelsch und politischer Wortakrobatik: „nicht in vollem Umfang von vollständiger Souveränität gesprochen werden, da theoretisch Zugriffe auf Anwendungsdaten durch Drittstaaten – zumindest in einer Grauzone – nicht ausgeschlossen werden können“– was für eine peinliche Ausrede!

Dass Drittstaaten – in diesem Fall die USA – theoretisch und praktisch auf unsere Daten zugreifen können, ist doch kein Geheimnis. Wer wirklich digitale Souveränität will, muss eigene Fähigkeiten aufbauen. Punkt. Wer das nicht tut, sollte wenigstens den Mut haben, es offen zuzugeben.
Und ja, den Angriffsvektor Software gibt es auch woanders, aber dieses Rumgeeier ist nur noch nervig.

Wer digitale Souveränität ernst nimmt, muss sie auch konsequent umsetzen. Alles andere ist Augenwischerei.

 

note
AvB Alexander von Boguszewski
· 21. Oktober 2025 · 2 Minuten zu lesen

Die Gefahren einer Cloud-Monokultur sind grade offensichtlich geworden.

Gestern hat Amazon gezeigt, wie fragil unsere digitale Welt ist. Ein technischer Fehler in ihrer Infrastruktur, und plötzlich fallen Signal, Fortnite, Snapchat, aber auch Behörden-Systeme aus. Nicht, weil diese Dienste schlecht gebaut wären – sondern weil sie sich freiwillig in die Abhängigkeit eines der drei Hyperscaler begeben haben. Das ist kein IT-Problem. Das ist ein strategisches Versagen. Es zeigt aber vor allem die Bedeutung einer sauberen globalen Infrastrukturarchitektur.
Digitale Souveränität ist kein Buzzword. Sie ist überlebenswichtig. Wenn ein einziger Cloud-Anbieter zum Single Point of Failure für ganze Branchen wird, sind wir systematisch verwundbar. Es geht nicht um „mehr Uptime“, sondern um Architektur, die uns resilient macht: Datenhoheit, entkoppelte Systeme, echte Multi-Cloud-Optionen. All das diskutiere ich seit Jahren wenn ich mit meinen Klienten über Architekturoptionen spreche – doch es wird kaum umgesetzt.
Solange wir uns weiter in die Arme von Amazon, Google & Co. werfen, bleiben wir Geiseln ihrer Infrastruktur. Wir brauchen dringend mehr Investitionen in offene Standards, gemeinsame (europäische) Multi-Cloud-Plattformen sowie politische Rahmenbedingungen, die technologische Eigenständigkeit fördern. Bemühungen diese Souveränität „künstlich“ herzustellen sind zum Scheitern verurteilt, wir brauchen resiliente, und vor allem wettbewerbsfähige Ökosysteme die als echte Architektur Option wahrgenommen werden. Oder warten wir einfach auf den nächsten GAU?

repost
AvB Alexander von Boguszewski
· 21. Oktober 2025 · 1 Minute zu lesen

Reblog via digitalrechte

We at the Center for Digital Rights and Democracy (Zentrum für Digitalrechte und Demokratie) are proposing a concept to fund the #Fediverse with tax money!

The German federal government should set up a funding program with a fixed budget of 20.000.000€ and clear responsibilities.
This should be implemented in the budget for 2026, because time is running fast.

Seize the opportunity now!

Spread our plan! #foefed_digitalrechte

https://digitalrechte.de/news/for-a-sovereign-internet-why-the-fediverse-needs-state-funding-and-support-now

repost
AvB Alexander von Boguszewski
· 1. Oktober 2025 · 1 Minute zu lesen
When I politely decline scheduling a "quick call", it's not because I don't literally have the time — there's always room for 15 minutes here or half an hour there! — it's that I can't afford to… | David Heinemeier Hansson | 39 comments (linkedin.com)
When I politely decline scheduling a "quick call", it's not because I don't literally have the time — there's always room for 15 minutes here or half an hour there! — it's that I can't afford to spare the attention.

„Quick Call“ ist gelogen.
Es gibt keine 15-minütigen Gespräche. Es gibt lediglich 15 Minuten Redezeit, hinzu kommen Vorbereitung, Nachbereitung und die Zeit für den Kontextwechsel. Jeder Anruf reißt dich aus dem Flow, zwingt dich, dich neu einzudenken, und hinterlässt ein offene Enden, die du später aufräumen musst. Das ist kein „kurzer Austausch“, das ist ein Denk-Bruch.

Ich mag Meetings lieber, um Entscheidungen zu treffen, nicht um den Status zu checken. Brainstorming-Sessions sind auch okay – aber nur, wenn sie gut vorbereitet sind.

note
AvB Alexander von Boguszewski
· 30. September 2025 · 1 Minute zu lesen

Technical Debt? Klar: schlechter Code, AdHoc Fixes, teure Wartung. Das ist lästig, teuer, aber machbar. Doch das echte Problem was ich immer häufiger Wahrnehme ist

Architecture Debt – wenn Systeme, Daten und Prozesse nicht zusammenpassen, sondern gegeneinander arbeiten.

Bildlich gesprochen ist Technical Debt ein undichtes Dach. Architecture Debt wenn das ganze Haus falsch gebaut ist – und du wirfst Jahr für Jahr Geld in Reparaturen, die das eigentliche Problem nicht lösen.
Viele Unternehmen behandeln Architecture Debt wie Technical Debt: Refactoring, neue/bessere Tools, optimierte Implementierunge – und wundern sich, warum alles immer langsamer, teurer und komplizierter wird. Dabei liegt das Problem nicht in der Umsetzung, sondern im Design.
An alle Entscheider: Hört auf, nur die Symptome zu bekämpfen. Stellt nicht die Frage: „Wie bringen wir die nächste Anwendung schneller live?“ Sondern: „Wie bauen wir eine Systemlandschaft, die uns wirklich voranbringt?“
Wer nur Technical Debt angeht, verliert gegen Ineffizienz. Wer Architecture Debt ignoriert, setzt die Zukunft aufs Spiel.

reply
AvB Alexander von Boguszewski
· 26. September 2025 · 2 Minuten zu lesen
Most leaders have felt it: IT projects are different. They blow budgets, miss deadlines, and sometimes even sink organizations. by Alexander BudzierAlexander Budzier (linkedin.com)

I agree wholeheartedly with the call for modularity and slower, more deliberate decisions. But let’s go further, not just to slow down decisions, but to make them reversible. By shipping smaller, learning faster, and designing for change, you turn fat tails into manageable(r) bumps. Ironically embracing reversibility means you need less governance, not more. No more endless committees approving five-year roadmaps. Just clear guardrails, fast feedback, and the option to course-correct.

But looking from an SI PoV if you start pushing modular, iterative approaches, you’re essentially telling clients, “Hey, you don’t need us for 5 years—just for 6 months at a time.” And you can’t hide behind big budgets and long timelines. You’ll have to deliver, fast and often. No more blaming “complexity” or “changing requirements” for why nothing works. That’s terrifying if your business model is dependency, not value. But here’s the kicker: If you don’t do it, someone else will. The more tailored the system, the higher the chance of scope creep, integration issues, but also new Change Requests and Budget Increases. Unfortunately missed deadlines, blown budgets, and broken promises turn clients into enemies. They’ll badmouth you, sue you, or just never call again. So, what’s riskier: Changing, or being the last dinosaur standing?

article
AvB Alexander von Boguszewski
· 2. Januar 2025 · 1 Minute zu lesen

Über die Feiertage habe ich eine erste Version meiner Data Reference Architecture erstellt, die als Grundlage für moderne, skalierbare und effiziente Datenlösungen dienen kann. Die Architektur beinhaltet wichtige Prinzipien und Komponenten, die in den meisten Datenplattformen eine zentrale Rolle spielen. Die aktuelle Version (0.1) ist erst ein erster Entwurf. Vieles muss noch vereinfacht und konsolidiert werden, um den Anforderungen von großen Unternehmen gerecht zu werden. Ziel ist eine praxisnahe und dennoch flexible Basis, die sich an unterschiedliche Anwendungsbereiche anpassen lässt

Hier zum PDF: DataArchitecture_0_1.

note
AvB Alexander von Boguszewski
· 20. Dezember 2024 · 1 Minute zu lesen

Die Qualität der Daten bestimmt die Qualität der KI. Wir müssen sicherstellen, dass die Daten, die wir analysieren, auch gut sind. Das bedeutet, die Daten zu bereinigen, vorzuverarbeiten und zu ordnen, um Genauigkeit und Konsistenz zu gewährleisten. Das sollte uns dazu veranlassen, unsere Datapipelines zu verbessern. Investitionen in Data Governance, Datenqualitätssicherung und Datenmanagement sind daher unerlässlich, um einen Mehrwert zu schaffen.

Um die Vorteile der KI voll auszunutzen, muss man seine Daten verstehen. Dazu gehört nicht nur eine solide Wissensbasis, sondern auch die Beherrschung der Metadaten, die die Struktur und Semantik der Daten beschreiben.
Für die Nutzung in der echten Welt brauchen wir außerdem eine zuverlässige Datenlieferkette. Neben einer stabilen und skalierbaren Ingestion und Transformation Pipelines ist auch die Datenqualität und -kontrolle wichtig.

article
AvB Alexander von Boguszewski
· 13. Dezember 2024 · 3 Minuten zu lesen
Beispiel Medallion-Architektur mit Archimate

In meinen letzten Projekten habe ich eine Referenzarchitektur entwickelt, die als Grundlage für den Aufbau von Datenplattformen dient, die sich gut skalieren und anpassen lassen. Ein zentrales Element dieser Architektur ist die Medaillon-Architektur. In meiner Referenzarchitektur kann man die Medallion-Architektur mit den Komponenten „Data Processing“ und „Data Storage Component“ umsetzen. Die einzelnen Schichten (Bronze, Silber, Gold) sind mit Datenobjekten strukturiert.

Beispiel Medallion-Architektur mit Archimate
Medallion-Architektur

Ich möchte uns jetzt mal die Vor- und Nachteile dieses Ansatzes vorstellen:

Weiterlesen →

Beitragsnavigation
1 2 Weiter »
This site is powered by WordPress and styled with the Autonomie theme