Kimball oder Data Vault 2.0: Welcher Modellierungsansatz auf Azure Databricks passt

Am Ende sieht jede gut gebaute Datenplattform für ihre Nutzer gleich aus: Kennzahlen und ihre Blickwinkel, verständlich benannt, schnell abfragbar. Ob darunter Kimball oder Data Vault 2.0 liegt, erkennt im Dashboard niemand.

Entschieden wird eine Ebene tiefer, bei einer Frage, die weniger technisch ist, als sie klingt: An welcher Stelle wird aus mehreren Quellsystemen eine gemeinsame Sicht, und wie oft muss diese Arbeit wiederholt werden, wenn sich etwas ändert? Kimball erledigt sie mit Kimball-Mitteln in Silber oder im Ladeschritt nach Gold. Data Vault 2.0 verankert sie einmal im Datenmodell und bezahlt dafür mit zusätzlichen Schichten und einer Methode, die das Team tragen muss. Diese Wahl ist eine Grundsatzentscheidung: Im laufenden Betrieb ist der Wechsel des Fundaments teuer, im Greenfield kostet er nichts. Aus unseren Projekten wissen wir, dass diese Entscheidung selten bewusst getroffen wird und Teams sie Jahre später teuer nachholen.

Praktisch heißt das: Die Antwort ist Kimball oder Data Vault 2.0. Fällt sie auf Kimball, bleibt eine zweite Frage, und die entscheidet über die Skalierbarkeit: Kommt Kimball in einfacher Medallion-Architektur aus, mit Quellmodulen in Silber und der Zusammenführung im Ladeschritt nach Gold? Oder bekommt Silber eine Integrations- und Harmonisierungsschicht, in der Schlüsselzuordnung, Regeln und Kennzahlen genau einmal liegen? Beide Bauweisen sind Kimball. Sie unterscheiden sich darin, wo die Arbeit liegt, die mehrere Quellen zu einer Sicht macht.

Warum Kimball oder Data Vault 2.0

Die Frage hat zwei Achsen. Auf der Modellachse, also welches Datenmodell die Integration trägt, stehen zwei etablierte Standards mit ausgereifter Methodik und breiter Praxiserfahrung zur Wahl: Kimball und Data Vault 2.0. Mehr steht dort nicht zur Wahl, die Entscheidung ist binär. Auf der Architekturachse liegt bei Kimball die Frage, wie viel Silber vorwegnimmt. Kimballs eigenes Vokabular reicht dafür aus: Konformierte Dimensionen sind bei Kimball der Mechanismus, mit dem Quellen zusammengeführt werden, die Kimball Group nennt sie „the essence of integration". Und die Arbeit dahinter, Deduplizieren mit Gewinnerregeln, Konformieren, Bridge Tables bauen, gehört in Kimballs ETL-Architektur ausdrücklich in den Back Room, also vor die Präsentationsschicht. Eine Integrations- und Harmonisierungsschicht in Silber ist nichts anderes als dieser Back Room, persistiert und modular gebaut.

Ein hybrider Ansatz ist das nicht, und das Wort vermeiden wir bewusst. Die Kimball-Literatur nennt „Hybrid" etwas anderes: einen normalisierten Kern nach Inmon, aus dem dimensionale Marts befüllt werden. Unsere Harmonisierungsschicht ist nicht normalisiert, sondern fachlich modelliert, mit Zuordnungstabellen, konformierten Kernobjekten, Bridge Tables und Stichtagstabellen. Und ein Business Vault ist sie auch nicht, obwohl sie dessen Rolle übernimmt: Ein Business Vault besteht aus Hubs, Links, Satellites, PIT- und Bridge-Tabellen auf Hash-Schlüsseln und setzt einen Raw Vault voraus. Wer Data Vault kennt, würde die Bezeichnung zu Recht zurückweisen. Modelliert wird nach Kimball, in Silber wie in Gold.

Ein Wort zu One Big Table, denn das Muster wird im Lakehouse-Umfeld regelmäßig als Alternative genannt: breite, flache Tabellen statt Sternschema, mit dem Argument, dass Joins auf spaltenorientierten Engines teurer seien als Redundanz. Das Muster beantwortet aber eine andere Frage. Es beschreibt, wie Daten an einen einzelnen Konsumenten ausgeliefert werden, nicht, wie mehrere Quellen integriert werden. Eine breite Tabelle ohne modellierte Schicht darunter bedeutet, dass jede Quelländerung ungebremst auf das Konsumobjekt durchschlägt. Als Ableitung aus einem Sternschema, etwa für ML-Features oder ein einzelnes Dashboard, sind breite Tabellen dagegen völlig legitim. One Big Table lässt sich also als Auslieferungsform nutzen, als Modellierungsansatz für das Fundament der Plattform dagegen nicht.

Die übrigen Ansätze sind keine echte Alternative für moderne Setups: Ein vollnormalisiertes Inmon-Warehouse ist als Integrationsschicht auf einem Lakehouse wegen der Join-Tiefe und des fehlenden Tooling-Ökosystems praktisch verdrängt, Anchor Modeling bleibt eine akademische Nische. Und eine Abgrenzung nach oben: Beide Ansätze modellieren strukturierte Quelldaten. Für Dokumente, Embeddings und Vector Search braucht eine AI-fähige Plattform eigene Bausteine, die von dieser Entscheidung unberührt bleiben.

Kimball, zwei Bauweisen

Am konkreten Fall wird der Unterschied sichtbar. Zwei ERP-Instanzen liefern dasselbe Geschäftsobjekt: Die Standorte arbeiten teils auf erp_a, teils auf erp_b, beide Systeme liefern Lieferbelege und kennen dasselbe Material, aber unter verschiedenen Schlüsseln und mit verschiedenen Attributen. Dazu kommt ein CRM mit den Kunden.

Kimball in einfacher Medallion-Architektur. Silber besteht nur aus Quellmodulen. Jede Quelle wird für sich modelliert: technisch bereinigt, fachlich umbenannt, historisiert mit Gültig-ab, Gültig-bis und Aktuell-Kennzeichen, auf ihre Granularität festgelegt und getestet. Aus den SAP-Tabellen likp und lips werden delivery_header und delivery_item, aus mara wird material, jedes Objekt noch mit den Schlüsseln der eigenen Quelle. Wichtig ist, was Silber hier nicht ist: kein Integrationsschritt. Es wird nichts über Quellen hinweg zusammengeführt, kein Schlüssel zwischen Systemen zugeordnet, keine Attributentscheidung zwischen Quellen getroffen. Das alles macht der Ladeschritt nach Gold, je Gold-Objekt.

Diese Bauweise ist bewusst schlanker als die Silber-Schicht, wie Databricks und Microsoft sie beschreiben. Databricks nennt Silber die Schicht, in der Daten „matched, merged, conformed and cleansed" werden, Microsoft nennt als Beispiel das Zusammenführen von Kundendatensätzen über Systeme hinweg. Wer dieses Zusammenführen kaum braucht, weil jedes Geschäftsobjekt aus einer Quelle kommt und eine Lesart der Zahlen gilt, spart sich die Schicht. Er bezahlt dafür an einer anderen Stelle, sobald sich das ändert.

Kimball mit Integrations- und Harmonisierungsschicht. Die Quellmodule bleiben, wie sie sind. Darüber kommt in Silber eine zweite, modulare Schicht, in der Schlüssel über Systeme hinweg zugeordnet, Attribute und Kennzahlen harmonisiert und Geschäftsregeln einmal hinterlegt werden. Je Zweck ein Objekt: eine Schlüsselzuordnung, die festhält, dass Material 4711 im ERP A und MAT-4711 im ERP B dasselbe Material sind. Ein harmonisiertes Kernobjekt Material mit einer entschiedenen Gewinnerregel je Attribut. Eine gemeinsame Werteliste für die Statuscodes beider Systeme. Eine Bridge Table für die Kundenhierarchie aus Konzern, Tochter und Standort. Eine vorgerechnete Kennzahl Liefertreue, in der beide Lesarten als benannte Spalten nebeneinander stehen, gegen den Wunschtermin und gegen den bestätigten Termin. Eine Stichtagstabelle mit dem Lagerbestand zum Monatsende, bevor Korrekturbuchungen kamen. Gold liest nur noch diese harmonisierten Objekte und stellt das Sternschema zusammen.

Jeder dieser Bausteine hat einen Kimball-Namen. Bridge Tables sind Kimballs Antwort auf Mehrfachbeziehungen und Hierarchien unterschiedlicher Tiefe. Stichtagstabellen heißen bei Kimball Periodic Snapshots, eine Zeile je Periode statt je Buchung. Die Historisierung folgt seinem Typ 2 mit genau den drei Spalten, die er als Minimum nennt. Und dass zwei unverträgliche Lesarten derselben Kennzahl zwei Namen bekommen, statt sich einen zu teilen, ist Kimballs Regel für konformierte Fakten. Die Schicht übernimmt die Rolle, die im Data Vault Hubs, Same-as-Links und Business Vault zusammen haben, aber mit diesen Mitteln und ohne Methodenzwang.

Vier Regeln halten die Objekte lesbar. Erstens: Der Katalog ist die Schicht, das Schema ist die Herkunft, also das Quellsystem in Bronze und bei den Quellmodulen, harmonized für die Harmonisierungsschicht, die Fachdomäne in Gold und common für geteilte Dimensionen. Zweitens: Der Tabellenname ist das Geschäftsobjekt, Englisch, Einzahl, in Bronze der Originalname der Quelle, die Umbenennung passiert im Quellmodul. Das Quellsystem steht im Schema und nicht noch einmal im Tabellennamen. Drittens: Ein Präfix nennt nur die Bauform, nie die Datenart. map_, ref_, bridge_, kpi_ und snapshot_ in der Harmonisierungsschicht, fact_ und dim_ ausschließlich in Gold, wo sie die Rolle des Objekts sind. Harmonisierte Kernobjekte tragen kein Präfix. Kein md_ und kein td_: Die Datenart ist ein Metadatum für den Katalog, sie ändert sich mit der Verwendung, und ein Rename bricht Views, dbt-Modelle, Power-BI-Datasets und die Lineage-Historie. Viertens: Historisierung überall gleich, valid_from, valid_to, is_current, technische Spalten mit führendem Unterstrich wie _source_system und _loaded_at.

Zwischen den beiden Bauweisen gilt eine feste Regel. Die einfache Medallion-Architektur ist der Startpunkt. Sobald eine zweite Quelle dasselbe Geschäftsobjekt liefert oder eine zweite Lesart derselben Kennzahl gelten soll, kommt die Integrations- und Harmonisierungsschicht dazu. Quellmodule und Gold bleiben stehen, nur die Logik zieht aus den Gold-Ladeschritten in die neue Schicht um. Und eine Einschränkung nach unten: Liefert je Geschäftsobjekt ohnehin nur eine Quelle, ist die Schicht leer. Dann ist die einfache Medallion-Architektur nicht der Kompromiss, sondern die richtige Wahl.

Der dbt-Leitfaden beschreibt dieselbe Bewegung als Weg von quellkonformen zu geschäftskonformen Daten, mit der Schichtung Staging, Intermediate und Marts, und mit dem Ziel, jede Transformation genau an einer Stelle anzuwenden. Er zieht allerdings eine Grenze, die auch Kimballs Back Room zieht: Zwischenmodelle sind nicht für Endnutzer gedacht. Wer Quellmodule und Harmonisierungsschicht für Data Science öffnet, verlässt an dieser Stelle bewusst die reine Lehre und übernimmt die Verantwortung, dass daraus keine Insellösungen mit eigenen Zahlen entstehen.

Data Vault 2.0: Integration und Geschäftslogik getrennt und modular

Data Vault 2.0 materialisiert die Integration als eigene modellierte Schicht in Silber, nach einer festen Methode, und trennt dabei zwei Dinge, die bei Kimball im selben Ladeschritt liegen: Der Raw Vault integriert technisch über Geschäftsschlüssel, der Business Vault trägt die fachlichen Regeln, der Information Mart liefert das Sternschema. Jede Ebene ist für sich austauschbar und erweiterbar.

Der Hub hält die Geschäftsschlüssel und ist die eine Stelle, an der beide Quellen auf dieselbe Geschäftsidentität zeigen. Die Satellites halten die Quellversionen verlustfrei und historisiert nebeneinander, nur eingefügt, nie überschrieben, geladen nur mit technischen Regeln. Der Business Vault liegt darüber und entscheidet, welche Sicht gilt: berechnete Satellites für Regeln, Same-as-Links, wenn zwei Schlüssel dasselbe Objekt bezeichnen, PIT- und Bridge-Tabellen als Abfragehilfen für Stichtage und Wege durch das Modell. Er ist optional und wird sparsam gebaut, nur was das Geschäft braucht. Die Methode ist musterbasiert: Hubs, Links und Satellites folgen festen Ladeschablonen, deshalb wird ein Data Vault in der Praxis mit einem Generator erzeugt, etwa datavault4dbt oder AutomateDV als offene dbt-Pakete oder einem kommerziellen Werkzeug, nicht von Hand geschrieben. Wie die Bausteine im Detail funktionieren und was sie kosten, haben wir im Artikel Data Vault 2.0 auf Azure Databricks beschrieben; hier interessiert nur die Position im Vergleich.

Beide Wege enden im selben Gold: einem konformierten Sternschema. Der Unterschied liegt vollständig davor.

Wo die Integrationslogik lebt

Zwei Arbeiten verschwinden in keinem der beiden Ansätze. Das Schlüssel-Mapping, also die Feststellung, dass Material 4711 in erp_a dasselbe ist wie MAT-4711 in erp_b. Und die Gewinnerregel: Beide Quellen liefern eine Materialbezeichnung, eine muss gelten. Die Ansätze unterscheiden sich nicht darin, ob diese Logik existiert, sondern wo sie liegt und wie oft sie geschrieben wird. Es gibt drei Orte.

Bei Kimball in einfacher Medallion-Architektur liegt sie im Ladeschritt nach Gold, je Gold-Objekt. Das Material-Mapping steckt in der Union von fact_delivery, noch einmal in dim_material und bei jedem weiteren harmonisierten Objekt wieder. Dasselbe gilt für jede Abteilung, die mit einer eigenen Lesart derselben Kennzahl dazukommt. Neue Quelle heißt: ein neues Quellmodul plus eine Erweiterung jeder betroffenen Union. Bei zwei Quellen und einer Handvoll Objekte ist das unerheblich, bei vielen Quellen und vielen Objekten ist es die Stelle, an der Definitionen auseinanderlaufen.

Bei Kimball mit Integrations- und Harmonisierungsschicht liegt sie genau einmal in Silber. map_material beantwortet die Zuordnungsfrage, material trägt die Gewinnerregel, kpi_delivery_reliability beide Lesarten der Liefertreue unter zwei Namen. Jedes Gold-Objekt liest dieselben Antworten. Neue Quelle heißt: ein neues Quellmodul plus neue Zeilen in der Schlüsselzuordnung, die Gold-Objekte bleiben unberührt. Was diese Bauweise nicht hat: einen Standard und einen Generator. Welche Objekte in die Schicht gehören, wie sie heißen und dass keine Kennzahl ein zweites Mal in Gold gerechnet wird, legen Konventionen fest, und das Review hält sie ein.

Bei Data Vault 2.0 wird die Integration einmal je Geschäftsobjekt deklariert. Der Hub trägt den Geschäftsschlüssel, die Satellites bewahren beide Quellversionen, der Business Vault fällt die Gewinnerregel zentral. Verwenden beide Systeme denselben Geschäftsschlüssel, integriert der Hub von selbst. Verwenden sie verschiedene, wie hier, ist die Zuordnung eine fachliche Regel und liegt als Same-as-Link im Business Vault. Jeder Information Mart erbt diese Integration. Data Vault macht die Integrationslogik also nicht kleiner. Es erzwingt, dass sie genau einmal existiert, dass die Eingangsdaten erhalten bleiben, gegen die man sie prüfen kann, und dass alle Bausteine demselben Muster folgen.

Auf einen Satz gebracht: Kimball in einfacher Medallion-Architektur implementiert die Integration je Gold-Objekt, Kimball mit Harmonisierungsschicht einmal in Silber mit Kimball-Mitteln, Data Vault einmal im Modell nach Methode.

Die Grenzen von Kimball

Kimball startet schneller und hat drei Grenzen, die über die Bauweise und über den Wechsel zu Data Vault entscheiden.

Die erste ist die Skalengrenze der einfachen Medallion-Architektur. Zuordnung, Harmonisierung und Geschäftsregeln laufen im Ladeschritt je Gold-Objekt zusammen. Diese Objekte wachsen mit jeder weiteren Quelle, mit jeder Abteilung, die dasselbe Geschäftsobjekt anders liest, und mit jeder zusätzlichen Kennzahl, und jede Änderung fasst sie alle an. Der Pflegeaufwand wächst mit dem Produkt aus Quellen, harmonisierten Objekten und Lesarten. Eine Zahl, ab der es eng wird, geben wir bewusst nicht an: Die Treiber sind die Zahl und Verschiedenheit der Quellen, die Zahl der Lesarten derselben Kennzahl, die Historisierungspflichten und die Kompetenz im Team, und sie wirken zusammen. Die Integrations- und Harmonisierungsschicht hebt diese Grenze, weil Zuordnung und Regeln einmal liegen. Was bleibt, ist eine andere Art von Grenze: Disziplin statt Methode. Es gibt keinen Standard, der vorgibt, welche Objekte in die Schicht gehören, keinen Generator, der sie baut, und nichts, das verhindert, dass die Schicht zu einem zweiten Gold wird, in dem dieselbe Kennzahl noch einmal steht. Ziehen Quellenzahl, Lesarten und Nachweispflichten gleichzeitig an, ist die einmal deklarierte Integration von Data Vault die verlässlichere Wahl, sofern das Team die Methode trägt. Und eine Beobachtung aus der Praxis als Warnung: Plattformen, die bei den Quellmodulen stehen bleiben und die Konformierung in semantische Modelle und Berichte verlagern, haben die Integration nicht gespart, sondern unsichtbar gemacht, mit den Folgen, die wir in Business-Logik im BI-Tool beschrieben haben.

Die zweite ist Logik-Drift. Geschäftslogik lebt genau einmal. Bei der einfachen Medallion-Architektur im Ladeschritt nach Gold, bei der Bauweise mit Harmonisierungsschicht dort, und nirgends sonst: nicht in den Quellmodulen, die strukturell bleiben, und nicht noch einmal in Gold, das nur zusammenstellt. Die Versuchung ist an beiden Enden groß, eine berechnete Kennzahl hier, eine Statusableitung dort. Sobald das passiert, lebt dieselbe Logik in zwei Schichten, und nichts im Modell verhindert, dass die Versionen auseinanderlaufen. Data Vault erzwingt dieselbe Trennung strukturell, denn der Raw Vault ist per Definition nie fachlich interpretiert. Bei Kimball bleibt sie eine Konvention, die das Review hält.

Die dritte ist die Historisierung. Sie gehört an genau eine Stelle je Objekt: in die Quellmodule und, bei der zweiten Bauweise, in die harmonisierten Kernobjekte, jeweils mit Gültig-ab, Gültig-bis und Aktuell-Kennzeichen. Gold leitet sich daraus ab. Ob einzelne Gold-Dimensionen zusätzlich eine eigene Historie tragen, ist eine Frage des Use Cases, kein Muss. Wichtig ist nur, nicht zwei konkurrierende Zeitachsen parallel zu pflegen, denn das Zusammenführen getrennt gepflegter Verläufe mit korrekten Gültigkeitsintervallen ist genau die Aufgabe, die Data Vault mit PIT-Tabellen strukturell löst und die man sich bei Kimball nicht freiwillig einhandeln sollte.

Was bei der Modellierung auf Azure Databricks zu beachten ist

Die Medallion-Schichtung von Azure Databricks gibt die Zuordnung vor, entscheidet die Frage aber nicht. Die Dokumentation beschreibt den Gold Layer als die Schicht, in der für Reporting und Analytics dimensional modelliert wird, und verortet den Beginn der Datenmodellierung im Silver Layer, den sie als Ort für Bereinigung, Deduplizierung und Joins beschreibt und in dem sich eine unternehmensweite Sicht bilden soll. Genau dort trennt sich, was Medallion offenlässt: ob in Silber nur Quellmodule liegen, Quellmodule mit einer Harmonisierungsschicht oder ein Data Vault. Dass eine Plattform Bronze, Silber und Gold hat, ist noch kein Datenmodell, das haben wir in Medallion ist kein Datenmodell ausgeführt.

Ein Einwand kommt auf Azure Databricks verlässlich: Delta Time Travel historisiere doch bereits, eine eigene Historie in Bronze oder Silber sei deshalb überflüssig. Das verwechselt zwei Dinge. Time Travel ist an Aufbewahrungsfristen gebunden, standardmäßig sieben Tage für die Datendateien und 30 Tage für das Transaktionslog, und die Dokumentation rät ausdrücklich davon ab, die Tabellenhistorie als langfristige Archivlösung zu verwenden. Es ist ein Betriebswerkzeug für Rollbacks und kurzfristige Vergleiche je Tabelle. Die fachliche Frage, welche Materialbezeichnung am Jahresultimo galt, beantwortet nur das Datenmodell, in welchem Ansatz auch immer. Bronze als Vollhistorie ist dagegen ein Archiv, das man selbst baut: jede Lieferung angehängt, nie überschrieben. In der Data-Vault-Welt heißt genau das Persistent Staging Area, und es ist die Voraussetzung, eine Harmonisierungsschicht oder einen Raw Vault jederzeit neu aufzubauen.

Für die Umsetzung selbst ändert die Wahl wenig an den Werkzeugen: Alle drei Bauweisen laufen auf Delta Lake, werden über Unity Catalog governt und lassen sich mit dbt oder Lakeflow Declarative Pipelines bauen. Für den Data-Vault-Weg nehmen datavault4dbt, das Databricks und Fabric als Plattformen unterstützt, oder AutomateDV als offene dbt-Pakete den größten Teil der Generierungsarbeit für Hubs, Links, Satellites und PIT-Tabellen ab, kommerzielle Werkzeuge wie VaultSpeed oder WhereScape gehen darüber hinaus. Für die Kimball-Wege gibt es diesen Generator nicht, dort trägt die Namenskonvention die Ordnung.

Ein Blick nach vorn gehört in diese Entscheidung ebenfalls: Mit Unity Catalog Metric Views verlagert Databricks die Definition von Geschäftskennzahlen in die Plattform, als zentral definierte, wiederverwendbare Metriken über den Gold-Strukturen, die Dashboards, Assistenten und externe BI-Werkzeuge gleich rechnen. Je mehr Konsum über solche deklarierten Metriken läuft, und je mehr davon durch AI-Werkzeuge wie natürlichsprachige Abfragen entsteht, desto mehr wird das konformierte Sternschema zur einzigen Stelle, an der Integration physisch stattfinden muss, und desto teurer wird jede Harmonisierung, die stattdessen verstreut in BI-Tools liegt. Ein sauber modelliertes, dokumentiertes Gold ist damit zugleich die beste Schnittstelle für LLM-gestützte Analytik, denn ein kryptisches Quellfeld lädt einen Assistenten zum Raten ein: Je unklarer die Bedeutung, desto mehr Raum für erfundene Antworten.

Entscheidungsmatrix: wann welcher Weg

Die Wahl folgt aus dem Kontext, nicht aus einer Methodenpräferenz. Die Kriterien lassen sich als Geschäftsfragen stellen:

Die Bewertung je Kriterium ist unsere Einschätzung aus Projekten, keine Messung. Sie ersetzt nicht die Prüfung am konkreten Ist-Stand aus Quellen, Volatilität, Nachweispflichten, Abnehmern und Team. Die Bilanz: Zwischen den beiden Kimball-Bauweisen entscheidet, ob Integrationsarbeit überhaupt anfällt. Zwischen Kimball mit Harmonisierungsschicht und Data Vault entscheidet weniger die Komplexität als die Kompetenz: Beide leisten die Integration einmal, aber nur das Team, das die Methode trägt und generiert, bekommt den Standard von Data Vault ohne seine Kosten.

Fazit

Kimball und Data Vault 2.0 liefern am Ende dasselbe Sternschema. Sie unterscheiden sich darin, wo die Integrationslogik lebt. Kimball in einfacher Medallion-Architektur trägt, solange jedes Geschäftsobjekt aus einer Quelle kommt und eine Lesart gilt; sobald das kippt, kommt die Integrations- und Harmonisierungsschicht dazu, und Zuordnung, Regeln und Kennzahlen liegen einmal in Silber, mit Kimball-Mitteln und ohne Methodenzwang. Data Vault 2.0 lohnt sich, wenn viele heterogene Quellen, laufende Änderungen und harte Nachweispflichten zusammenkommen und das Team die Methode trägt und mit einem Generator umsetzt. Es gibt keine pauschal richtige Wahl, die Entscheidung folgt aus dem Kontext. Im Greenfield kostet sie nichts, im laufenden Betrieb ein Vielfaches. Deshalb gehört sie an den Anfang.

← Zurück zum Blog