Data Engineer'lar Governance'dan genellikle şöyle bahseder:<ul><li>"Bize iş çıkaran bir süreç."</li><li>"Doldurulması gereken formlar, onay bekleyen talepler."</li><li>"Asıl işimizden zaman çalan bürokratik katman."</li></ul>Anlıyorum. Çünkü Governance çoğu zaman tam da böyle sunuluyor.Ama sahada gördüğüm şey farklı. Governance eksikliğinin en ağır bedelini ödeyen, Data Engineer'ların kendisi.<h2 id="d1428215-c546-4b2d-89f1-1c35ba7e6112" data-toc-id="d1428215-c546-4b2d-89f1-1c35ba7e6112" style="font-size: 24px; line-height: 1.2;">Tanıdık Gelecek</h2>Sabah açıyorsun bilgisayarı. Pipeline kırmızı.Koşuyorsun bakıyorsun — kaynak sistemde bir kolon tipi değişmiş. Kim değiştirdi? Ne zaman? Neden? Kimse seni haberdar etmemiş.Ya da şu: Üç aydır güvenle çalışan bir ETL süreci, bir sabah yanlış sonuç üretiyor. Nedeni? Upstream'de biri sessizce bir iş kuralını güncellemiş. Sana sormamış. Çünkü senin o veriyi kullandığını bilmiyordu.Ya da en klasiği: Aynı alan, iki farklı sistemde iki farklı anlam taşıyor. Sen ikisini birleştiriyorsun. Rapor çıkıyor, sayılar tutmuyor. Suçlanan sen oluyorsun.Bunların hiçbiri teknik bir hata değil. Hepsi bir Governance problemi.<h2 id="60d00b2a-ddfa-4c27-ad9b-6709016b31bf" data-toc-id="60d00b2a-ddfa-4c27-ad9b-6709016b31bf" style="font-size: 24px; line-height: 1.2;">Mühendis Neden Öder Bu Bedeli?</h2>Çünkü Governance olmadığında boşluğu mühendis dolduruyor.<ul><li>Tanım yoksa mühendis varsayıyor. </li><li>Sahiplik belirsizse mühendis üstleniyor. </li><li>Değişiklik süreci yoksa mühendis reaktif çalışıyor.</li></ul>Zamanının büyük bölümü gerçek mühendislik işine değil — önceki kararların hasarını onarmaya gidiyor.<blockquote>Governance eksikliği, mühendisi mimar olmaktan çıkarır. Tamirci yapar.</blockquote><h2 id="202e1e71-ae9e-4345-b0fd-9bb0473d5e46" data-toc-id="202e1e71-ae9e-4345-b0fd-9bb0473d5e46" style="font-size: 24px; line-height: 1.2;">Governance Mühendise Ne Verir?</h2>Soyut konuşmayalım. Sahada farkı yaratan üç şey var.Data ContractKaynak sistem bir veri üretiyor. Sen o veriyi tüketiyorsun. Arada hiçbir anlaşma yok.Data Contract, bu anlaşmayı yazılı hale getirir. Alan adları, tipler, güncelleme sıklığı, kalite beklentisi — hepsi kayıt altında. Kaynak sistem değişmek istediğinde önce seni etkileyen yerlere bakılır. Sabah sürpriziyle değil, önceden haberdar olarak uyanırsın.LineageHangi tablo hangi kaynaktan besleniyor? Hangi rapor hangi modele bağlı? O modeli kim kullanıyor?Lineage olmadan bu soruların cevabı ya kimsenin kafasında ya da hiç yok. Bir değişiklik yapmak istediğinde tam olarak neyi etkileyeceğini bilemiyorsun. Ya aşırı temkinli davranıyorsun ya da farkında olmadan bir şeyleri bozuyorsun.Lineage, mühendise bir radar verir. Değişiklikten önce etkiyi görürsün.Sahiplik ve Değişiklik Süreci"Bu alan kimin sorumluluğunda?" sorusunun cevabı net değilse, herkes değiştirebilir. Kimse sormaz. Kimse haber vermez.Sahiplik ve değişiklik süreci, bu sorunun cevabını önceden belirler. Upstream'deki bir değişiklik downstream'i etkileyecekse, onay sürecinden geçer. Sen de dahil olursun.<h2 id="4ec45930-2f1a-4db8-9af6-517644d278cd" data-toc-id="4ec45930-2f1a-4db8-9af6-517644d278cd" style="font-size: 24px; line-height: 1.2;">"Ama Bu Benim İşim Değil"</h2>Data Engineer'lardan sık duyduğum bir cümle: "Governance iş biriminin işi. Ben pipeline kurarım."Kısmen doğru. Governance'ın kural yazma, onaylama, politika belirleme kısımları iş biriminin sorumluluğunda.Ama Governance'ın teknik omurgası — data contracts, lineage, metadata yönetimi, kalite kurallarının koda yansıması — tamamen mühendislik alanında.Bunu iş birimine bırakırsan, ya hiç yapılmaz ya da yanlış yapılır.<blockquote>Governance'ın teknik kısmını kim inşa edecek? Mühendis değilse kim?</blockquote><h2 id="5246de7f-d9d8-49c3-a996-634c3e4640cf" data-toc-id="5246de7f-d9d8-49c3-a996-634c3e4640cf" style="font-size: 24px; line-height: 1.2;">Nereden Başlanır?</h2>Her şeyi aynı anda yapmak gerekmez.Bir adım at: Ürettiğin veya tükettiğin en kritik veri akışını seç. O akış için basit bir data contract yaz. Alan adları, tipler, beklentiler. Kaynak ekiple paylaş. İmzalatma kelimesini kullanmana gerek yok — sadece "bunu doğrulayabilir misiniz?" yeterli.Bu küçük adım, iki şeyi değiştirir. Kaynak ekip senin o veriye bağlı olduğunu öğrenir. Sen de değişikliklerden haberdar olmaya başlarsın.Geri kalanı buradan büyür.<h2 id="a44b6b88-e018-4cef-a113-e108c156f4ff" data-toc-id="a44b6b88-e018-4cef-a113-e108c156f4ff" style="font-size: 24px; line-height: 1.2;">Son Söz</h2>Governance seni yavaşlatmaz. Seni kaostan korur.Kaos zaten orada. Governance olmadığında onu sen absorbe ediyorsun. Governance olduğunda ise kaos görünür hale gelir, doğru sahibine gider.Mühendis olarak zamanını ve enerjini nereye harcamak istiyorsun? Kırık pipeline'ları yamıyor olmak mı, yoksa sağlam sistemler inşa etmek mi?Bu konularda sorularınız varsa veya nerede durduğunuzu birlikte değerlendirmek istiyorsanız bana ulaşın.Sevgiler,Atacanİletişimde kalalım!🔗&nbsp;LinkedIn: <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.linkedin.com/in/atacangarip/">https://www.linkedin.com/in/atacangarip/</a>

Veri yönetişim disiplininin Veri Mühendisleri perspektifinden ele almaktadır.

Veri Yönetişimi: Data Engineer'ın Sessiz Müttefiki

Read articles, tips, and resources to help you learn, grow, and succeed. Explore our latest posts covering education, community, and personal growth

Blog – Insights, Tips & Resources for Learning and Growth

Explore articles, tips, and insights to help you succeed in learning, community building, and personal development.

Veri Yönetişimi: Data Engineer'ın Sessiz Müttefiki

Veri Yönetişimi: Data Engineer'ın Sessiz Müttefiki

Related Posts