Knowledge Ownership Model: Bilgi Gerçekten Kimin?

Kökü sende olmayan hiçbir ağacın gölgesine güvenme. Rüzgar estiğinde sana sadece yaprakları kalır, meyvesi değil!

Knowledge Lock-in Serisi — 2

Knowledge Ownership Model — KOM

Bir önce ki yazıda asıl sorunun ne olabileceğini yorumlamaya çalışıp farklı bir soru ile dikkatleri Knowlodge Lock-in tarafına çekmiştik. Peki bu bilgi dediğimiz şey tam olarak nedir? Bilgi bizde mi yoksa dışarıda mı sorusuna tam olaran Evet/Hayır cevabını vermemiz kolay değildir. İşte burada devreye sorunu parçalara bölmek ve her bir parçayı anlamlandırmak gerektiğini fark ettim. Bilgi tek parça değildir. Bu yazıda tam da bunu çözmeye çalışacağım: bilgiyi katmanlarına ayırmak, her katmanın sahiplik seviyesini tanımlamak ve tüm bunları tek bir haritada birleştirmek.

Bu haritanın adı: Knowledge Ownership Model (KOM)

Bilgi Tek Bir Parçadan Oluşmaz

Çalıştığınız kurumda ki kritik bir uygulamayı düşünün. “Bu sistemin sorumluluğu bize mi ait, bu sistemde işi kim yapacak” sorusu sorulduğunda tartışmalar başlar. Kaynak kodu bizde diyen farklı bir katmandan yeni bir geliştirme ya da özelliğin kullanımı hakkında destek talep edildiğinde farklı bir katmandan bahsettiğimizi çoğu zaman fark etmeyiz.

Peki sistemi biliyorum dediğimiz de aslında neyi kast ediyoruz? KOM ile bildiğimizi söylediğimiz bilgi’nin katmanlarını derinlemesine inceleyeceğiz. Bir teknoloji hakkında ki bilgi beş farklı katmanda yaşar.

Bilginin Katmanları

Bu katmanlar; Mimari Bilgi, Entegrasyon Bilgisi, Operasyonel Bilgi, Konfigürasyon ve Tunning, Karar Gerekçeleri olarak gruplanır.

Mimari Bilgi: Sistemin neden bu şekilde tasarlandığıdır. Hangi alternatifler değerlendirildi? Neden bu topoloji seçildi? Neden bu pattern? Bu katman kaybolduğunda kurum, kendi sisteminin arkeolojisini yapmak zorunda kalır.

Entegrasyon Bilgisi: Sistemin nasıl yaşatıldığıdır. Incident geldiğinde ilk nereye bakılır? Restart sırası nedir? Hangi log hangi sorunun habercisidir? Bu bilgi çoğu zaman hiçbir dokümanda yazmaz; yaşanarak öğrenilir ve yaşayanla birlikte kurumdan çıkar.

Konfigürasyon ve Tuning Bilgisi: Neden bu parametrelerdir. Thread pool neden 50? Timeout neden 30 saniye? Cache TTL neden bu değer? Bu katman genellikle çalışıyor, dokunma refleksiyle korunur ve arkasındaki gerekçe zamanla buharlaşır.

Karar Gerekçeleri: Nelerin elendiği ve neden elendiğidir. Seçilmeyen alternatifler, denenip vazgeçilen yaklaşımlar, reddedilen teklifler. Bu katman belki de en kolay kaybedilen katmandır. Sonuç zaten ortadadır ve kimse tercih edilmeyenleri nedenleriyle saklama gereği duymaz. Oysa bir sonraki mimari kararın kalitesi geçmişte neyin neden elediğini bilmeye bağlıdır.

Bilgiyi katmanlarına ayırdığımıza göre artık bu katmanların sahipliklerini belirleyerek haritalandırma adımına geçebiliriz. KOM’un ikinci ekseni de bu kısmı 5 seviyede ele alır.

Her Katmanın Bir Sahiplik Seviyesi Vardır

Sahiplik Seviyeleri Katmanları

Seviye 0 Tüketici: Bilgi tamamen kurum dışındadır. Kurum sistemi kullanır ama nasıl çalıştığını bilmez.

Seviye 1 Tercüman: Bilgi hala dışarıdadır, ancak kurum içinde tek bir kişi vendor ile kurum arasında köprü kurar. O kişi karar verici değildir sadece vendor ile kurum arasında bir köprü görevi görür. “Onu bir Ahmet Bey bilir.”

Seviye 2 Anlayan: Ekip sistemi anlıyor, mimariyi tarif edebiliyor, sorunu teşhis edebiliyor. Ancak bağımsız olarak değişiklik yapamıyor; bir şeyi değiştirmek için hala vendor’a ihtiyaç var.

Seviye 3 Bağımsız: Ekip değişiklik yapabiliyor, incident’ı bağımsız çözebiliyor, yeni gereksinimi implemente edebiliyor. Vendor/Danışman hala danışılan bir kaynak olabilir ancak operasyonel bir bağımlılık yoktur.

Seviye 4 Kurumsallaşmış: Bilgi kişiden bağımsızdır. Dokümante edilmiş, aktarılabilir durumdadır, ekip üyesi değişse bile bilgi kurumda kalır.

KOM Matrisi: İki Ekseni Birleştirmek

Artık elimizde hem bilginin katmanları hemde bu katmanların sahiplik seviyeleri vardır. Bundan sonra yapılması gereken bu iki eksini birleştirmektir.

Her satır bir bilgi katmanı, her sütun bir sahiplik seviyesi. Kritik bir sisteminizi seçip her katman için mevcut seviyenizi ve hedef seviyenizi işaretlediğinizde, bilgi sahipliğinizin durumunu görebilirsiniz.

KOM Matrisi

Bu matris üzerinde iki işaret kullanıyoruz. Bunlar; mevcut seviye ve hedef seviye. İkisi arasında ki mesafe o katmanda ki bilgi açığını gösterir. Peki yukarıda örnek bir senaryoya göre hazırlanmış matrisin seviye seviye açıklaması nedir?

Mimari bilgi, Mevcut Seviye 1, Hedef Seviye 3: Platform yıllar önce kurulmuş, mimari kararları bilen tek kişi kurum tarafında bir teknik lider. O kişi ayrılırsa mimari bilgi tamamen kaybolur. Hedef, bu bilginin en az ekip seviyesinde anlaşılır ve bağımsız karar verilebilir olması.

Entegrasyon bilgisi, Mevcut Seviye 2, Hedef Seviye 3: Ekip hangi servisin hangi servisi çağırdığını biliyor, mapping kurallarını okuyor. Ancak yeni bir entegrasyon eklemek veya mevcut bir kuralı değiştirmek için vendor’a danışmak zorunda. Hedef, bu işlemleri bağımsız yapabilmek.

Operasyonel bilgi, Mevcut Seviye 1, Hedef Seviye 4: Incident geldiğinde ilk aranan numara vendor’un destek hattı. Kurumdaki tek kişi vendor ile iletişim kuruyor ama çözüm üretemiyor. Bu katman en kritik açık ve hedef operasyonel bilginin kişiden bağımsız doküman’larla desteklenmiş ve aktarılabilir olması.

Konfigürasyon ve tuning, Mevcut Seviye 0, Hedef Seviye 3: Parametre değerleri vendor tarafından ayarlanmış, gerekçeleri hiçbir yerde kayıtlı değil. Kurum çalışıyorsa dokunma modunda. Hedef, parametrelerin nedenlerinin bilinmesi ve gerektiğinde bağımsız ayarlanabilmesi.

Karar gerekçeleri Mevcut Seviye 1, Hedef Seviye 3: Platformun neden seçildiği, alternatiflerin neden elendiği tek bir kişinin hafızasında. O kişi ayrıldığında bir sonraki büyük mimari kararın kalitesi düşer çünkü geçmişte neyin neden denenip vazgeçildiğini bilen kimse kalmaz.

Tabi bu matriste hedefin her zaman 4 olması pek olası bir durum değildir. Her katmanın kendine özgü ihtiyaçları vardır. Seviye 4 bilginin iyi bir şekilde dokümante edilmesi, aktarılabilir olması ve kişilerden bağımsız yaşayabilmesi için en ideal seviye olsa bile bu çok ciddi bir yatırımdır.

Burada hedef seviye bilginin kritikliği ile orantılı olmalıdır. Bir ofis uygulamasında Seviye 2’nin olması yeterli olabilecekken müşteriye dokunan, gelir üreten veya regüle edilen bir sistem için Seviye 3’ün altı risk demektir.

KOM matrisi doldurmak aynı zamanda bu önceliklendirmeyi görünür kılmaktır. Hangi sistemde hangi katmanda ne kadar yatırım yapılacağını bilinçli bir şekilde belirlemek nihai hedef olmalıdır.

Artık bilgiyi katmanlarına ayırıp her katmanın sahiplik seviyesini belirledikten sonra bunları birleştirerek KOM matrisini oluşturduk.

Peki bu haritayı nasıl dolduracağız? Mevcut durumu nasıl ölçeceğiz? Bilgi sahipliğini hissediyorum yerine ölçüyorum diyebileceğimiz noktaya nasıl geleceğiz?

Bir kurumun bilgi sahipliğini ölçmenin ilk adımı, bilgiyi katmanlarına ayırmaktır. İkinci adımı ise her katmandaki seviyeyi dürüstçe kabul etmektir.

Bir sonraki yazıda bu soruları yanıtlayarak sürecin nasıl işlediğini beraber göreceğiz.

Zaman ayırıp okuduğunuz için teşekkür ederim.