Bei der Arbeit an Soft­ware­kom­po­nen­ten kön­nen Ent­wick­ler eine breite Palette von Frame­works, Ent­wurfs­mus­tern und Prin­zi­pien nut­zen, um ihre Pro­dukte zu ska­lie­ren und ihre Archi­tek­tur naht­los anzu­pas­sen, um neue Anwen­dungs­fälle zu unter­stüt­zen und eine zuneh­mende Nut­zung und Kom­ple­xi­tät zu bewäl­ti­gen. Auf diese Weise kön­nen Soft­ware­ent­wick­lungs­teams eine opti­mierte Leis­tung und Zuver­läs­sig­keit sicher­stel­len, wenn ihre Platt­form (und ihr Wert) wächst.

Daten­teams haben jedoch nicht so viel Glück. Wäh­rend die ers­ten Monate des Lebens­zy­klus einer Daten­platt­form oft von der Begeis­te­rung über die Bewäl­ti­gung kom­ple­xer tech­ni­scher Her­aus­for­de­run­gen und der Freude über die Bereit­stel­lung einer ers­ten Welle von Daten­pro­duk­ten geprägt sind, folgt dar­auf oft eine ent­mu­ti­gende Spi­rale aus zuneh­men­der Kom­ple­xi­tät, stei­gen­den Kos­ten und abneh­men­den Erträgen.

Im Gegen­satz zu ande­ren Pro­ble­men, mit denen wir als Daten­teams kon­fron­tiert sind, unter­schei­den sich unsere Ska­lier­bar­keits­pro­bleme von Natur aus von denen, mit denen Soft­ware­teams kon­fron­tiert sind. In der Daten­welt kom­men diese Pro­bleme in Form von unver­meid­li­cher tech­ni­scher Kom­ple­xi­tät (wie dem Mischen einer Viel­zahl von Mus­tern, um Daten über eine stän­dig wach­sende Liste von Sys­te­men zu bewe­gen und umzu­wan­deln) und der ein­zig­ar­ti­gen Posi­tio­nie­rung der Daten­platt­form inner­halb des Unter­neh­mens (da schließ­lich jede Geschäfts­ein­heit ent­we­der direkt oder indi­rekt mit ihr ver­bun­den ist).

In die­ser Post-MDS-Welt, in der Daten­teams hin­sicht­lich ihrer Aus­ga­ben gründ­lich über­prüft wer­den und stän­dig auf­ge­for­dert sind, ihren Wert unter Beweis zu stel­len, ist es daher wich­ti­ger denn je, Stan­dards und Grund­sätze für die erfolg­rei­che Ska­lie­rung einer Daten­platt­form zu defi­nie­ren. Die­ser Arti­kel kon­zen­triert sich auf fünf Grund­sätze, die für die Errei­chung die­ses Ziels ent­schei­dend sind, und bie­tet gleich­zei­tig Stra­te­gien für ihre Anwendung.

1 Das Wesent­li­che nicht aus den Augen ver­lie­ren (d. h. den geschäft­li­chen Nutzen)

In den meis­ten Fäl­len haben Daten­platt­for­men das Poten­zial, einer der wert­volls­ten Ver­mö­gens­werte des Unter­neh­mens zu sein. Auf dem Weg, ihren Wert zu bewei­sen, kon­zen­trie­ren sich Daten­teams jedoch lei­der häu­fig auf das Was und nicht auf das Warum.

Wenn Sie die im Inter­net ver­füg­ba­ren Daten­in­halte durch­ge­hen, wer­den Sie meist auf kom­plexe Daten­ar­chi­tek­tu­ren oder Lob und Kri­tik an bestimm­ten Tech­no­lo­gien sto­ßen. Ande­rer­seits sind Inhalte, die sich auf die Ermög­li­chung nach­ge­la­ger­ter Anwen­dungs­fälle oder die Mes­sung der Aus­wir­kun­gen von Daten­in­itia­ti­ven kon­zen­trie­ren, rela­tiv sel­ten. Mei­ner Ansicht nach ist dies ein Sym­ptom für ein zen­tra­les Pro­blem, mit dem sich Daten­teams aus­ein­an­der­set­zen müs­sen: Wir kon­zen­trie­ren uns schnell zu sehr auf das, was wir auf­bauen, und ver­lie­ren aus den Augen, warum wir es aufbauen.

Die­ses Pro­blem kann dazu füh­ren, dass Daten­teams nur noch um des Bau­ens wil­len bauen. Ein ska­lier­ba­re­rer Ansatz besteht statt­des­sen darin, nach wert­schöp­fen­den Daten­in­itia­ti­ven Aus­schau zu hal­ten und den geschaf­fe­nen Wert kon­ti­nu­ier­lich zu reflek­tie­ren (und wenn mög­lich zu mes­sen). Zu die­sem Zweck emp­fehle ich die fol­gen­den vier Strategien:

Her­aus­fin­den, wel­che Daten wich­tig sind (Nicht alle Daten sind gleich)

Da es mit den heu­ti­gen Tech­no­lo­gien extrem ein­fach ist, rie­sige Daten­men­gen zu gene­rie­ren, zu spei­chern und umzu­wan­deln, kön­nen Daten­teams schnell von der rasant wach­sen­den Zahl der zu betreu­en­den Daten­sätze über­wäl­tigt wer­den. Die Auf­merk­sam­keit, die Sie einem Daten­satz wid­men soll­ten, muss sich jedoch nach sei­ner Bedeu­tung rich­ten, die durch die Ver­knüp­fung mit den nach­ge­la­ger­ten Anwen­dungs­fäl­len bestimmt wird.

Ver­bin­den Sie jede Initiative/jedes Pro­jekt mit dem Wert, den es gene­rie­ren wird

Bevor ein Daten­pro­jekt grü­nes Licht erhält, sollte es im Hin­blick auf den (direk­ten oder indi­rek­ten) geschäft­li­chen Wert bewer­tet wer­den, den es schaf­fen wird. Diese wich­tige Übung gewähr­leis­tet die Abstim­mung mit Ihren Stake­hol­dern und ermög­licht es Ihnen, Ihre Daten­pro­jekte mit nach­ge­la­ger­ten Initia­ti­ven zu ver­knüp­fen. Das Ver­fas­sen von Design­do­ku­men­ten für Daten­pipe­lines und andere Arten von Daten­kom­po­nen­ten ist ein guter Ansatz, um sicher­zu­stel­len, dass das, was Sie auf­bauen, mit klar defi­nier­ten Geschäfts­zie­len und ‑metri­ken übereinstimmt.

Suchen Sie kon­ti­nu­ier­lich nach neuen, hoch­wirk­sa­men Anwendungsfällen

Daten­teams sind in der Regel dar­auf ange­wie­sen, Anfra­gen und poten­zi­elle Pro­jekte von ande­ren Abtei­lun­gen und Geschäfts­be­rei­chen zu erhal­ten. Auch wenn es ver­lo­ckend sein mag, sich auf sol­che Pro­zesse zu ver­las­sen, soll­ten Sie stets nach poten­zi­ell wert­schöp­fen­den Berei­chen Aus­schau hal­ten, in denen Daten genutzt wer­den kön­nen. Ganz gleich, ob es sich um ein inter­nes Daten­pro­dukt oder eine Daten­an­wen­dung han­delt, die in das Pro­dukt des Unter­neh­mens ein­ge­bet­tet wer­den kann – wich­tige Anwen­dungs­fälle könn­ten unter­ge­hen, nur weil das Daten­team Dinge in sei­ner eige­nen Ecke ent­wi­ckelt hat.

Bit­ten Sie häu­fig um Feed­back von Ihren Nutzern

Daten­teams kon­zen­trie­ren sich leicht auf die fal­schen Metri­ken. Eine erhöhte Nut­zung könnte uns zum Bei­spiel ein Gefühl der Errun­gen­schaft ver­mit­teln. In einer daten­ge­steu­er­ten Umge­bung benö­ti­gen die Men­schen jedoch Daten in allen Berei­chen – eine hohe Nut­zung bedeu­tet also nicht unbe­dingt, dass alles gut läuft oder dass die Nut­zung in wert­schöp­fen­den Anwen­dungs­fäl­len erfolgt. Mit zuneh­men­der Ska­lie­rung der Platt­form wer­den sich irgend­wann Risse zei­gen (von Pro­ble­men mit der Daten­qua­li­tät bis hin zu gerin­ger Ent­wick­lungs­ge­schwin­dig­keit), und wenn Sie von Ihren Nut­zern abge­kop­pelt sind, müs­sen Sie deren Ver­trauen erst wie­der auf­ho­len. Ver­su­chen Sie statt­des­sen, häu­fig um Feed­back zu bit­ten, sei es über ein­ge­bet­tete Feed­back-Mecha­nis­men in den von Ihnen ange­bo­te­nen Tools oder über ein ein­fa­ches Feed­back-For­mu­lar, das Sie alle paar Monate an die Nut­zer senden.

2 Auto­ma­ti­sierte Stan­dards sind Ihr bes­ter Freund

Eine der größ­ten Her­aus­for­de­run­gen bei der Ska­lie­rung einer Daten­platt­form besteht darin, dass sie in viele Rich­tun­gen gezo­gen wird. Ganz gleich, ob es sich um den Zustrom von Pro­jek­ten han­delt, die neue Daten­kom­po­nen­ten erfor­dern, oder um den end­lo­sen Strom von Ad-hoc-Anfra­gen – irgend­wann wird das Daten­team zu einem Eng­pass. Die­ser Zeit­punkt führt in der Regel zu einer unglück­li­chen Ent­schei­dung: der Ein­füh­rung eines Selbst­be­die­nungs­mo­dells, ohne die rich­ti­gen Grund­la­gen dafür zu schaf­fen. Das bedeu­tet, dass andere Teams ihre eige­nen Daten­sätze oder Pipe­lines erstel­len, um Erkennt­nisse zu gewin­nen – was gut beginnt, bis jemand irgend­wann fest­stellt, dass man kei­nem Daten­satz mehr trauen kann.

Die Emp­feh­lung lau­tet hier nicht, die Selbst­be­die­nung zu ver­mei­den. Statt­des­sen soll­ten Sie Stan­dards dafür fest­le­gen, wie Dinge zu tun sind, und deren Durch­set­zung so weit wie mög­lich auto­ma­ti­sie­ren. Diese Stan­dards kön­nen grund­le­gende Dinge wie Tabel­len-/Spal­ten-/Mo­dell­ben­en­nungs­kon­ven­tio­nen und obli­ga­to­ri­sche Doku­men­ta­tion oder dif­fe­ren­zier­tere Ansätze wie obli­ga­to­ri­sche Tests und die aus­schließ­li­che Ver­wen­dung kon­trol­lier­ter Daten­sätze in Pro­duk­ti­ons­pipe­lines umfassen.

Die Anwen­dung sol­cher Stan­dards – z. B. durch Auto­ma­ti­sie­rung der kon­ti­nu­ier­li­chen Inte­gra­tion (CI) – gewähr­leis­tet ein Min­dest­maß an Kon­sis­tenz und ver­hin­dert Sze­na­rien, in denen die Daten­platt­form schließ­lich zu einem Daten­chaos oder ‑sumpf wird.

Es ist jedoch wich­tig zu beach­ten, dass die Stan­dards, für die Sie sich ent­schei­den, eine kon­krete geschäft­li­che Recht­fer­ti­gung haben soll­ten und die Ent­wick­lungs­ge­schwin­dig­keit nicht ohne greif­bare Vor­teile beein­träch­ti­gen soll­ten. Das rich­tige Gleich­ge­wicht zwi­schen Stan­dar­di­sie­rung und Ite­ra­ti­ons- bzw. Lie­fer­ge­schwin­dig­keit hängt vom Unter­neh­mens­kon­text und den Anwen­dungs­fäl­len ab, in denen die Daten genutzt wer­den, aber in jedem Fall ist ein Min­dest­maß an Stan­dar­di­sie­rung erforderlich.

3 Fra­gen Sie sich häu­fig, ob Sie die rich­ti­gen Werk­zeuge für den aktu­el­len Maß­stab haben

Als Inge­nieur weiß ich, wie leicht es ist, sich zu sehr an das nette Paket zu klam­mern, das Sie für X gebaut haben, oder an das Open-Source-Pro­jekt, das Sie für Y genutzt (und viel­leicht dazu bei­getra­gen) haben. Aber wenn Ihre Daten­platt­form wächst, ist es wich­tig, Ihre Archi­tek­tur rou­ti­ne­mä­ßig zu über­prü­fen, um Berei­che zu iden­ti­fi­zie­ren, in denen die Werk­zeuge ein Upgrade (oder ein Down­grade) benötigen.

Migra­tio­nen sind natür­lich mit Kos­ten ver­bun­den und immer hei­kel – aber sie zum rich­ti­gen Zeit­punkt durch­zu­füh­ren und ein Play­book für den Aus­tausch von Kom­po­nen­ten Ihrer Platt­form zu haben, ist eine wich­tige Fähig­keit für jedes Daten­team. Um ein­schät­zen zu kön­nen, wel­che Tools für Ihre der­zei­tige Grö­ßen­ord­nung nicht geeig­net sind, ist es mei­ner Mei­nung nach uner­läss­lich, für jede Kom­po­nente inner­halb Ihres Stacks eine aktu­elle, umfas­sende Ant­wort auf die fol­gen­den Fra­gen zu haben:

  • Wie viel kos­tet es? (In Bezug auf den tech­ni­schen Auf­wand für die War­tung, die Infra­struk­tur­kos­ten, die Preise usw.) Sind diese Kos­ten für uns akzep­ta­bel? Wie wer­den sich diese Kos­ten im Laufe des nächs­ten Jah­res entwickeln?
  • Geben wir Res­sour­cen (Ent­wick­lungs­zeit, Geld usw.) dafür aus, die an ande­rer Stelle einen grö­ße­ren geschäft­li­chen Nut­zen brin­gen würden?
  • Ver­fügt es über alle wich­ti­gen Funk­tio­nen, die wir der­zeit benö­ti­gen und die wir im nächs­ten Jahr benö­ti­gen wer­den? Wenn nicht, gibt es andere Optio­nen, die die von uns gewünsch­ten Funk­tio­nen bie­ten? Wenn es sol­che ande­ren Optio­nen gibt, wie hoch wären die Kos­ten für die Migration?

Bei die­ser Übung wer­den Sie mit Sicher­heit auf Berei­che sto­ßen, in denen Sie Dinge ganz aus dem Ver­kehr zie­hen kön­nen (z. B. Pipe­lines oder Tools, die kei­nen sinn­vol­len Wert lie­fern), auf andere, in denen Sie ein Sys­tem durch ein ande­res erset­zen müs­sen (viel­leicht haben Sie einen Echt­zeit-Inges­tion-Pro­zess ent­wi­ckelt, aber alle aktu­el­len geschäfts­kri­ti­schen Ver­brauchs­sze­na­rien erfor­dern nur Batch), und schließ­lich auf Berei­che, in denen Sie ein Upgrade benö­ti­gen (z. B. den Wech­sel von einem inter­nen Daten­ver­schie­bungs­pro­zess zu einem eta­blier­ten Tool, das sofort mehr Funk­tio­nen bietet).

Ein prak­ti­sches Bei­spiel: Obwohl dbt-Tests ein her­vor­ra­gen­der Aus­gangs­punkt sind, um die Daten­qua­li­tät für Ihre wich­tigs­ten Assets zu gewähr­leis­ten und den Ver­brau­chern das Ver­trauen in die von ihnen ver­wen­de­ten Daten zu ermög­li­chen, sto­ßen sie schnell an die Gren­zen ihrer Nütz­lich­keit, wenn Sie Ihrer Daten­platt­form wei­tere Sys­teme hin­zu­fü­gen und begin­nen, pro­duk­tive (oder sogar ope­ra­tive) Anwen­dungs­fälle zu unter­stüt­zen. Sobald der Auf­wand, den Sie für Daten­vor­fälle und das Debug­gen von Daten­pro­ble­men auf­wen­den, Ihre Road­map beein­träch­tigt, ist es viel­leicht an der Zeit, von dbt-Tests auf eine Daten­be­ob­ach­tungs­kom­po­nente umzusteigen.

4 Seien Sie nicht zu ehr­gei­zig (set­zen Sie Prio­ri­tä­ten bei Ihren Problemen)

Die­ser Grund­satz geht Hand in Hand mit dem oben genann­ten. Genauso wie es äußerst wich­tig ist, Migra­tio­nen bei Bedarf durch­zu­füh­ren, ist es noch wich­ti­ger, unnö­tige Migra­tio­nen zu vermeiden.

Das der­zei­tige Tempo, mit dem sich der Daten­raum wei­ter­ent­wi­ckelt, bedeu­tet, dass neue Tech­no­lo­gien, Para­dig­men und Archi­tek­tu­ren eine Kon­stante sind. Tech­no­lo­gie­kon­zerne über­den­ken stän­dig ihre Ansätze im Umgang mit Daten, und egal, wie sehr Sie sich bemü­hen, die meis­ten Ihrer Platt­for­men wer­den immer ein paar Schritte hin­ter den Daten­pio­nie­ren zurück­blei­ben. Das ist jedoch keine schlechte Sache.

Wenn Sie über den aktu­el­len Stand der Tech­nik nach­den­ken und ver­su­chen, Lücken in Ihrer Platt­form zu iden­ti­fi­zie­ren, soll­ten Sie sich von dem geschäft­li­chen Nut­zen lei­ten las­sen, den Sie sich von dem Upgrade ver­spre­chen. Sicher, die Funk­tion X hört sich auf dem Papier gut an, aber wel­che kon­kre­ten Geschäfts­fälle wer­den damit gelöst, und für wel­che ande­ren Initia­ti­ven kön­nen Sie den Migra­ti­ons­auf­wand verwenden?

Ich glaube, dass es wich­tig ist, auf dem neu­es­ten Stand der Tech­nik zu blei­ben und sich über die Erfah­run­gen ande­rer Daten­teams zu infor­mie­ren, aber die Ent­schei­dung, ein neues Tool oder Para­digma ein­zu­füh­ren, muss immer auf der Grund­lage des erwar­te­ten geschäft­li­chen Nut­zens getrof­fen wer­den. Dar­über hin­aus ist es wich­tig, dass Sie Ihre geschäft­li­chen Prio­ri­tä­ten stets im Auge behal­ten und sie ent­spre­chend aktua­li­sie­ren, wenn sich die Umge­bung des Daten­teams ändert.

5 Ver­la­ge­rung eines Teils der Ver­ant­wor­tung nach links (und rechts)

Sobald die oben genann­ten Berei­che abge­deckt sind und vor allem, wenn die Daten­platt­form anfängt, wich­tige Pro­jekte zu unter­stüt­zen, kann das Daten­team in die Rolle eines Platt­form­teams wech­seln. Das bedeu­tet, dass Sie getrost damit begin­nen kön­nen, die Ver­ant­wort­lich­kei­ten zu nuan­cie­ren und das Daten­team von der Last der Ver­wal­tung von Geschäfts­me­tri­ken und Quell­da­ten­pro­ble­men zu befreien.

Der Zeit­punkt für die­sen Über­gang ist ent­schei­dend, da die Dezen­tra­li­sie­rung der Ver­ant­wort­lich­kei­ten nur dann erfolg­reich sein kann, wenn Sie bereits die rich­ti­gen Grund­la­gen geschaf­fen haben:

  • Die Daten­platt­form zu einem wert­schöp­fen­den Sys­tem machen, das für den Erfolg des Unter­neh­mens von ent­schei­den­der Bedeu­tung ist (so dass für andere Teams ein Anreiz besteht, ihre Zeit in daten­be­zo­gene Arbeit zu investieren)
  • Stan­dar­di­sie­rung der ver­schie­de­nen Pro­zesse, Defi­ni­tion kla­rer Schnitt­stel­len und Mini­mie­rung des Arbeits­auf­wands für die Teams, die zur Platt­form bei­tra­gen (als Pro­du­zen­ten, Kon­su­men­ten oder Mitwirkende)
  • Das rich­tige Tool­set, das es Ihnen ermög­licht, neue Teams ein­zu­bin­den und sich in einer kom­ple­xe­ren Struk­tur zurechtzufinden

Anstatt zu ver­su­chen, alle Ihre Daten­pro­dukte auf einen Schlag auf ein dezen­tra­les Modell umzu­stel­len, erhö­hen Sie Ihre Erfolgs­chan­cen, wenn Sie die Umstel­lung schritt­weise vor­neh­men. Begin­nen Sie zunächst mit der Iden­ti­fi­zie­rung der wich­tigs­ten Daten­sätze und Daten­pipe­lines, für die Sie dies können:

  • Ver­träge mit den Daten­pro­du­zen­ten abschließen
  • Ver­la­ge­rung der Ver­ant­wor­tung für die Defi­ni­tion von Metri­ken auf die ent­spre­chen­den Geschäftsteams

Sobald diese erste Initia­tive erfolg­reich ist, kön­nen Sie damit begin­nen, das Spek­trum der Pipe­lines, die dem neuen Modell unter­lie­gen, auf der Grund­lage ihrer Bedeu­tung für das Unter­neh­men zu erwei­tern. Es ist völ­lig in Ord­nung, die­ses Modell nicht auf alle Daten­sätze anzu­wen­den – wenn eine Daten­pipe­line noch kei­nen sinn­vol­len geschäft­li­chen Anwen­dungs­fall hat, muss sie nicht in hohem Maße regu­liert werden.

Die oben genann­ten Punkte sind letzt­lich die Krö­nung der ers­ten vier in die­sem Arti­kel bespro­che­nen Grund­sätze. Viele Dezen­tra­li­sie­rungs-/Da­ten­ver­net­zungs­in­itia­ti­ven schei­tern, weil ent­we­der die rich­ti­gen Grund­la­gen feh­len oder das Daten­team ver­sucht, einen sehr opti­mis­ti­schen (und unrea­lis­ti­schen) Über­gang von einem voll­stän­dig zen­tra­li­sier­ten zu einem dezen­tra­li­sier­ten Ansatz zu voll­zie­hen, anstatt die Umstel­lung schritt­weise vorzunehmen.

In die­sem Arti­kel haben wir fünf Prin­zi­pien unter­sucht, wie Sie Ihre Daten­platt­form erfolg­reich ska­lie­ren und zu einer wert­schöp­fen­den Kom­po­nente machen kön­nen, wenn sie an Größe, Kom­ple­xi­tät und Bedeu­tung zunimmt. Ihre Anwen­dung erfor­dert nicht, dass Sie bestimmte Tools oder Tech­no­lo­gien ver­wen­den. Statt­des­sen han­delt es sich um Richt­li­nien, die bei der Arbeit an Daten­pro­jek­ten uni­ver­sell ange­wen­det wer­den kön­nen (mit Aus­nahme bestimm­ter Son­der­fälle / Nischenbranchen).

Der von uns erör­terte End­zu­stand, d. h. ein hybri­der Auf­bau zwi­schen einem zen­tra­li­sier­ten Ansatz (bei dem das Daten­team Eigen­tü­mer der End-to-End-Platt­form ist) und einem dezen­tra­li­sier­ten / Data-Mesh-Ansatz (bei dem ver­schie­dene Teams ihre Daten­pro­dukte End-to-End erstel­len und besit­zen), erhöht Ihre Chan­cen auf eine erfolg­rei­che Ska­lie­rung der Platt­form beim Über­gang von einem Ansatz zum ande­ren – aber die Eig­nung für Ihr Team hängt auch von Ihrer Bran­che und dem Kon­text ab, in dem Sie tätig sind.

Wenn es nur einen Grundsatz/eine Regel gibt, die Sie sich mer­ken soll­ten, dann ist es dieser/diese: Es ist äußerst wich­tig, Ihren Ansatz und den Weg, den Sie ein­ge­schla­gen haben, immer wie­der neu zu bewer­ten. Was Sie von 0 auf 1 gebracht hat, ist etwas ganz ande­res als das, was Sie von 1 auf 10 (und so wei­ter) brin­gen würde. Dies ist eher ein uni­ver­sel­ler Grund­satz, der mei­ner Mei­nung nach für Daten­platt­for­men beson­ders rele­vant ist.

Quelle: medium.com