Data Mesh ile Verinin Demokratikleşmesi: Organizasyonel ve Teknik Bir Dönüşüm

Günümüzde kurumların ürettiği ve iş kararlarında kullandığı veri hacmi hızla artarken, geleneksel merkezi veri platformları bu büyümeye ayak uydurmakta zaman zaman zorlanabiliyor. Farklı iş birimlerinden gelen taleplerin tek bir ekip üzerinden yönetilmesi, özellikle büyük ölçekli organizasyonlarda, veri sahipliğinin belirsizleşmesi ve teslimat sürelerinin uzaması gibi durumlara sebep olabiliyor. Bu çerçevede son yıllarda “Data Mesh” adıyla anılan, veriyi organizasyonun farklı domain’lerine dağıtılmış bir sorumluluk modeliyle ele alan yeni bir yaklaşım tartışılmaya başlandı. İlk defa 2019 yılında Zhamak Dehghani'nin "How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh" isimli makalesinde ortaya koyduğu Data Mesh kavramı, veri üretiminden tüketimine kadar uzanan sürecin domain odaklı bir yapı üzerinden yönetilmesini öneren sosyo-teknik bir yaklaşım sunuyor. Bu yazıda, bu yaklaşımın temel prensiplerini ve kurumlarda neden gündeme geldiğini ele almayı amaçlıyorum. Ama öncesinde yazının başlığında ve bir önceki cümlede geçen iki kavramı netleştirmekte fayda var.

Verinin demokratikleşmesi ne demek?

En özet tanımıyla verinin demokratikleştirilmesi, bir organizasyonda veriye erişimin sadece belli teknik ekiplerin (örneğin IT, BI, veri ambarı ekipleri) tekelinde olmaktan çıkarılıp, iş birimlerinden teknik olmayan kullanıcılara kadar herkesin ihtiyaç duyduğu verilere kolay, güvenli ve kontrollü bir şekilde ulaşabilmesi anlamına gelir.

Sosyo-teknik kavramı

Sosyo-teknik yaklaşım, bir sistemi sadece teknolojiye indirgemeyen, aynı zamanda o teknolojiyi kullanan insanların, ekiplerin, organizasyon yapısının ve iş süreçlerinin de sistemin bir parçası olduğunu  dikkate alan bir bakış açısıdır.

Data mesh dönüşümünde, kullanılacak yazılımlar, altyapılar, mimariler gibi teknik boyutlar kadar, hatta ondan daha fazla, organizasyon kültürü, roller ve sorumluluklar, ekipler arası iletişim gibi sosyal boyutlar da kritik rol oynuyor. Bu açıdan sosyo-teknik kavramının data mesh için çok uygun bir tanım olduğu söylenebilir.

Data Mesh ve Prensipleri

Data Mesh, büyük ölçekli veri organizasyonlarında veri yönetimini merkezi veri ekiplerinden dağıtık, domain-temelli ekiplere kaydırmayı amaçlayan bir yaklaşımdır. Yani, klasik tek bir büyük veri ambarı yerine, verinin sahipliği, üretimi ve tüketimini domain bazlı ekiplere dağıtarak yönetmeyi savunur. Bir teknoloji ya da Kimball, Inmon, Data Vault gibi bir veri ambarı tasarım metodu değildir. Dikkati çekmek ve dönüştürmek istediği kısım verinin yönetim şekli ve kurum içinde kullanım standartlarıdır.

Şimdi biraz da Data Mesh'in geleneksel yöntemlerle hangi noktalarda ayrıştığına maddeler halinde bakalım.

Geleneksel Yaklaşım (Data Lake/DWH)

• Tüm veri kaynakları merkezi bir ekip tarafından yönetilir.
• Merkezi ETL/ELT süreçleri vardır.
• Veri kalitesi, erişim ve modelleme tek ekipte toplanır.
• Veri ekibi her şeyden sorumludur.
• Veri sahipliği belirsizdir.

Data Mesh Yaklaşımı

Geleneksel yaklaşımdaki bu merkezi yapının ölçeklenemediğini ve verinin, onu üreten domain'in sorumluluğunda olması gerektiğini söyleyen Zhamak Dheghani'nin, Data Mesh kavramını dayandırdığı dört prensibe bakalım. 

• Domain Ownership

Data Mesh yaklaşımında verinin sahipliği, merkezi bir veri ambarı ya da BI ekibi yerine, veriyi üreten ve iş bağlamını en iyi bilen domain ekiplerine aittir. Bu prensip, veriyle ilgili kararların (tanım, kalite, kapsam, güncellik gibi) veriye en yakın noktada alınmasını amaçlar. Örneğin müşteri, bayi veya faturalama gibi farklı domain’ler, kendi süreçlerinden doğan verilerin anlamından ve doğruluğundan sorumludur.

Bu yaklaşım, merkezi ekiplerin “her şeyi bilen ve yöneten” bir yapı olmasını beklemek yerine, veri sorumluluğunu organizasyon geneline yayar. Böylece veri sahipliği daha net tanımlanır ve iş birimleri ile veri ekipleri arasındaki bağımlılıklar azalır.

• Data as a Product

Data Mesh’te veri, yalnızca raporlar için hazırlanan bir ara çıktı olarak değil, açık bir amacı ve tüketicisi olan bir ürün olarak ele alınır. Bir veri ürünü, ham veya işlenmiş verinin yanı sıra, bu verinin nasıl kullanılacağına dair açıklamaları, kalite beklentilerini, erişim kurallarını ve yaşam döngüsünü de kapsar.

Bu bakış açısı, “tablo üretip bırakma” anlayışından farklıdır. Veri ürünleri, tıpkı yazılım ürünleri gibi sürüm alabilir, iyileştirilebilir ve kullanıcı geri bildirimleriyle evrilebilir. Böylece son kullanıcılar, kullandıkları verinin neyi temsil ettiğini ve hangi amaçla üretildiğini daha net anlayabilir.

Dağıtık bir veri platformunun başarılı olabilmesi için öncelikle domain veri ekiplerinin, ürettikleri veriye ürün gözüyle bakması gerekir. Bu senaryoda veri, ekip için bir varlık ya da değer (asset) olurken, organizasyonun kalanı bu ekibin müşterisi olur. 

• Self-serve Data Platform

Her domain kendi veri ürününü geliştirirken kullanılan teknoloji/platform anlamında standardizasyon nasıl sağlanacak? Sayısız veri ürünü birbiriyle nasıl konuşacak?

Data Mesh, domain ekiplerinin kendi veri ürünlerini geliştirebilmesi için gerekli teknik altyapının merkezi bir platform ekibi tarafından sağlanması gerektiğini söyler. Bu altyapı, veri depolama, işleme, güvenlik, izleme ve kalite gibi ihtiyaçları kapsar. Domain ekipleri ise bu altyapıyı self-service bir şekilde kullanarak veri ürünlerini oluşturur. Ürünün üretimi ve müşterisiyle paylaşımı bu platform üzerinden yapılır.

Bu prensip, her domain’in kendi başına altyapı kurmasını değil, ortak ve standart bir platform üzerinden bağımsız hareket edebilmesini hedefler. Böylece teknik karmaşıklık merkezi olarak yönetilirken, domain'ler yalnızca ürünlerine odaklanır.

• Federated Computational Governance

Domain ekipleri tarafından bağımsız olarak geliştirilen veri ürünlerinin gerçek anlamda değer üretebilmesi için birbiriyle konuşabilir olması gerekir. Farklı domain’lere ait veri ürünlerinin ilişkilendirilip birlikte analiz edilebilmesi; yalnızca teknik entegrasyonla değil, ortak kurallar ve standartlar üzerinden mümkün hâle gelir.

Federated computational governance, veri yönetişiminin, domain’lerin özerkliğini koruyacak şekilde dağıtıldığı ancak birlikte çalışabilirliği sağlamak amacıyla bazı kararların organizasyon genelinde alındığı bir modeli ifade eder. Bu modelde, domain veri ürün sahipleri ile merkezi veri platformu ekipleri, ortak standartları ve kuralları birlikte belirler. Veri ürünlerinin kalite/erişim politikalarının ve birlikte çalışabilirliğin garanti edilebilmesi için olmazsa olmaz bir yapıdır.

Bu yönetişim yaklaşımının temel amacı, merkezi kontrol ile domain bağımsızlığı arasında sürdürülebilir bir denge kurmaktır. Organizasyon genelinde alınan kararlar, domain’leri sınırlamak için değil, veri ürünlerinin kullanılabilir, birleştirilebilir ve ölçeklenebilir bir ekosistem oluşturmasını sağlamak için vardır. Bu sayede veri ürünleri arasında bir ağ oluşur diyebiliriz.

Cross-Functional Ekipler

Yukarıda bahsettiğimiz prensipler, doğal olarak yeni bir ekip yapılanmasını beraberinde getiriyor. Veri ürünü geliştiren domain ekipleri, farklı yetkinlikteki takım üyeleriyle tam anlamıyla disiplinlerarası bir yapıya dönüşüyor. 

Ürünün vizyonunu ve yol haritasını belirleyen, müşteri memnuniyeti hedefiyle domain'in sahiplendiği veri ürününün kalitesini artırmaya odaklı, veri setlerinin tüm yaşam döngüsünden sorumlu, müşteri ihtiyaçlarını önceliklendiren bir ürün sahibine (Product Owner) ihtiyaç var. PO, aynı zamanda ürünün kullanımına yönelik başarı kriterlerini de belirler ve bunların takibini yapar.

Domain’lerin kendi veri akışlarını geliştirip işletebilmesi için ekiplerde veri mühendislerinin de yer alması gerekir. Bu tür disiplinlerarası ekiplerin doğal bir sonucu ise farklı yetkinliklerin birbirini beslemesidir. Bu yaklaşım, iş birimleri ile teknik ekipler arasındaki mesafeyi azaltarak daha hızlı ve bağlamı doğru çözümler üretilmesine katkı sunar.

Data Mesh Neden Gündemde?

Sektöre 5-10 yılda bir yeni kavramların girdiğini ve tartışıldığını görüyoruz. Bunların bir kısmı kullanıma girse de birçoğu "buzzword"  diye tabir edilen moda sözcük seviyesinde kalıp tarihe karışıyor.

Kurumlar yıllar boyunca veri ambarı, data lake gibi merkezi platformlara ciddi yatırımlar yaptı. Ancak veri hacmi, veri çeşitliliği ve veri tüketim senaryoları büyüdükçe, bu merkezi yapılar beklenen çevikliği  sağlamakta zorlanmaya başladı. Özellikle büyük organizasyonlarda, veri taleplerinin tek bir ekip üzerinden karşılanması zamanla bir darboğaz oluşturdu.

İş biriminden kopuk şekilde verinin mühendisliğini yapan, "domain-agnostic"  diye tabir edilen ekipler ortaya çıktı. Bu ekiplerle iş birimleri arasındaki mesafenin artması, özellikle veri sahipliği, veri kalitesi gibi konularda başarısız çıktılar oluşmasına da sebep oldu.

Data Mesh’i önceki veri mimarilerinden ayıran temel fark, problemi teknik kapasiteden çok organizasyonel yapı üzerinden ele alması. Geleneksel yaklaşımlar genellikle merkezi yöntemlerle çözüm geliştirirken, Data Mesh, verinin üretildiği iş birimlerine daha fazla sorumluluk yüklemeyi öneriyor. Bu bize, Data Mesh'in asıl sorunu, veri yönetim modeli ve sahipliğinde gördüğünü gösteriyor. Dolayısıyla bugün Data Mesh’in konuşuluyor olmasının nedeni, mevcut veri mimarilerinin organizasyonel gerçeklere uyum sağlamakta zorlanıyor olmasıdır diyebiliriz.

Son olarak, Data Mesh’in pratikte nasıl hayata geçirildiğine dair zihinlerde oluşabilecek bazı yaygın yanlış anlamaları netleştirmek faydalı olacaktır.

Data Mesh’in bir “buzzword” mü yoksa modern dünyada veri yönetiminin aradığı kan mı olduğu sorusunun net cevabını zaman gösterecek. Ancak bugün itibarıyla, bu yaklaşımın organizasyonel yapı, ekip sorumlulukları ve veriyle çalışma biçimi üzerine önemli sorular sordurduğu açık. Bu yönüyle Data Mesh, her kurum için uygulanması gereken bir modelden ziyade, mevcut veri yaklaşımlarını yeniden değerlendirmek için güçlü bir seçenek sunuyor.

Faydalanılan Kaynaklar

• Zhamak Dehghani (2019) – How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh
• Zhamak Dehghani (2020) – Data Mesh Principles and Logical Architecture
• McKinsey & Company – Demystifying Data Mesh