Knowledge Lock-in Nasıl Ölçülür?
İlk iki yazıda sorunu tanımlayıp bu sorunun nasıl ölçülebileceğine yönelik bir haritanın tanımını yaptık. Knowledge Lock-in ve Knowledge Ownership Model yazılarına göz atabilirsiniz.
Karanlığın derinliğini bilmeyen, ne kadar muma ihtiyacı olduğunu da bilemez.
Knowledge Lock-in Serisi — 3
İlk iki yazıda sorunu tanımlayıp bu sorunun nasıl ölçülebileceğine yönelik bir haritanın tanımını yaptık. Knowledge Lock-in ve Knowledge Ownership Model yazılarına göz atabilirsiniz.
Peki sırada ki adım ne? Modeli makul bulan bir yöneticinin soracağı ilk soru şu olacaktır; “Mevcut durumu nasıl ölçeceğiz?”. Çok yerinde ve haklı bir sorudur. Çünkü ölçülmeyen risk, yönetilmeyen risktir. Ancak burada önemli bir ayrım var. Knowledge Lock-in CPU, I/O vb. kullanımları ölçüp okuduğumuz bir dashboard değildir. Hem nicel hem de nitel göstergeleri bir arada dinlemeyi gerektirir. Bu yazıda her ikisine de değinmeye çalışacağım.
Kitlenme Belirtileri Nasıl Anlaşılır
Knowledge Lock-in’in en dürüst sinyalleri koridorlarda ki fısıltılarda gizlidir. Bunları ölçmek için öyle pahalı araçlara gerek yoktur. İyi bir dinleyici olmak yeterlidir.
-
Sinyal — “Bunu vendor’a soralım” frekansı. Bu cümle bir toplantıda bir kez geçebilir. Bu normaldir. Fakat aynı sistem hakkında her toplantıda tekrar ediyor ise artık bilgi kurumda değildir. Frekans arttıkça sahiplik düşer
-
Sinyal — “Incident’ta ilk aranan numara kimin?” Gece 02:30’da alarm çaldığında ekibin ilk refleksi ne? Runbook’mu açıyor yoksa vendor’un acil destek hattını mı arıyor? Bu refleks, operasyonel bilginin nerede yaşadığının en dürüst tespitidir. Çünkü kriz anında kimse rol yapmaz.
-
Sinyal — “Vendor toplantısında kurum tarafı soru mu soruyor, cevap mı veriyor” Eğer toplantılarda kurum çalışanları sürekli soru soran taraf ise bilgi asimetrisi vendor lehine demektir. Eğer kurum ekibi cevap veren, yönlendiren, hatta itiraz eden tarafsa bilgi sahipliği kurumdadır. Roller her iki yönde de işleyebilir. Önemli olan hangi yönde olduğunun farkında olmaktır.
-
Sinyal — “Yeni bir talep geldiğinde efor tahminini kim yapıyor” Bir iş birimi yeni bir gereksinim getirdiğinde efor tahminini kurum ekibi mi yapıyor yoksa “vendor’a sorup dönelim mi?” deniyor. Efor tahmini yapabilmek, sistemi yeterince bildiğinizin en pratik göstergesidir. Yapamıyorsanız, o sistemi bilmiyorsunuz demektir. Kullanıyor olmak bilmek anlamına gelmez!
Bu sinyallerin hiçbiri tek başına bir teşhis değildir. Ancak üç ya da dördü bir arada görünüyorsa Knowledge Lock-in artık bir olasılık değil mevcut bir durumdur.
Nitel sinyaller farkındalık yaratır, ancak yönetim kararlarını sayılar yönlendirir. Knowledge Lock-in sistemini ilk oluşturduğumda hangi metriklerin belirleyici olması gerektiği hakkında çok düşünüp istişare etme şansım oldu. Son noktada ise beş metriği kontrol edilmesini öneriyorum.
Sayılarla Konuşmak
Bus factor ve vendor factor. Bus factor yazılım dünyasında bilinen bir kavramdır. Bir proje de kaç kişi “otobüsün altında kalırsa” proje durur? Ancak Knowledge Lock-in bağlamında ben buna bir boyut daha ekledim. Bu vendor factor. Belirli bir vendor ilişkisi sonra erdiğinde kaç sistem operasyonu risk altına girer? Bus factor kişi bazlı kırılganlığı, vendor factor ise tedarikçi bazlı kırılganlığı ölçer. İkisine birlikte bakıldığında bilgi yoğunlaşmasının nerede olduğu görünür hale gelir.
ADR kapsama oranı. Architecture Decision Record çok havalı bir söylemi var. Mimari kararların neden alındığını kayıt altına alan kısa dokümanlardır. Metrik basit: kritik sistemlerdeki büyük mimari kararların yüzde kaçı bir ADR ile kayıtlı? Bu oran düşükse karar gerekçeleri katmanı (KOM’un beşinci satırı) büyük olasılıkla Seviye 0 veya Seviye 1’dedir.
Runbook kapsama oranı. Operasayonel senaryoların yüzde kaçı kurum için bir runbook ile dokümante edilmiş? Burada “var/yok” yetmez. Güncel ve kullanılabilir olması önemlidir. Altı ay önce yazılmış ve güncellenmemiş bir runbook olmayan bir runbook’tan sadece biraz daha iyidir.
Bağımsız müdahale olayı. Son 12 ayın incident’larına bakıldığında yüzde kaçı vendor desteği olmadan çözülmüş? Bu metrik operasyonel bilgi katmanının (KOM’un 3. satırı) gerçek seviyesinin sayısal karşılığıdır. Oran yükse ise Seviye 3 veya üzeri, düşük ise başka şeylerin konuşulması gerekmektedir.
Bilgi transferi yaşı. Son gerçek bilgi transferi toplantısı ne zaman yapıldı? “Gerçek” kelimesini özellikle bold yapıp vurguladım. Yapılan söyleşmelerde çoğu kurum bu maddenin varlığından bile haberdar olmayabilir. Sözleşmelerde var olan bu madde pratikte hiç gerçekleşmemiş bile olabilir. Bu metriğin yaşı arttıkça transferin etkinliği geometrik olarak düşer.
Knowledge Lock-in Radar
Aşağıdaki soruları, yıllar içinde farklı kurumlarda edindiğim deneyime dayanarak hazırladım. Teorik bir kontrol listesi değil; sahada Knowledge Lock-in’in gerçekten nerede ortaya çıktığını görmüş biri olarak sorduğum sorular. Bu yüzden öz değerlendirmeyi çok daha isabetli kıldığına inanıyorum.
On Soruluk Öz Değerlendirme
- Bu sistemde bir incedent olduğunda ekibimiz vendor’ı aramadan müdahale edebilir mi?
- Sistemin mimari kararlarını ve gerekçelerini anlatan güncel bir doküman var mı?
- Entegrasyon kurallarında değişiklik yapmamız gerektiğinde bunu bağımsız bir şekilde yapabiliyor muyuz?
- Konfigürasyon parametrelerinin neden mevcut değerlerinde olduğunu bilen birisi kurum içinde var mı?
- Son 1 yılda bu sistem için vendor’dan bağımsız bir bilgi transferi oturumu yapıldı mı?
- Vendor ilişkisi yarın sona erse sistemi altı ay içinde farklı bir ekiple sürdürebilir miyiz?
- Yeni bir ekip üyesi bu sistemi mevcut dokümantasyon ile üç hafta içinde devralabilir mi?
- Bu sistemle ilgili efor tahmini vendor’a danışılmadan yapılabilir mi?
- Geçmişte bu sistem için değerlendirilen ama seçilmeyen alternatifler ve gerekçelerini biliyor muyuz?
- Bu sisteme ait runbook’lar var mı en son ne zaman güncellendi?
Eğer bu soruların 7 tanesi ve üzerinde “evet” diyebiliyorsan KOM’da Seviye 3 ve üzerindeyizdir. 4–6 arasında kısmı sahiplik söz konusudur. En zayıf halkanın bulunup düzenlemenin oradan yapılması gerekir. 3 ve altında ise ciddi Knowledge Lock-in riski var demektir. Bilgi büyük ölçünde vendor tarafındadır. 1–2 projeyle düzeltilebilecek bir yapıdan ziyade yapısal olarak ciddi değişimin olması gerektiğini gösterir.
Tabi bu ölçüm ve çıkarımların bir de tuzağı var. Bu “öz değerlendirme” çıktısı bir efor ölçme değildir. ADR oranı hedef haline gelir ise boş ADR’ler, runbook sayısı KPI olduğunda kullanılmayan runbooklar ortaya çıkar. Aslında bu durum bilindik bir yasadır. Goodhart Yasası; bir ölçüt hedefe dönüştüğünde ölçüt olmaktan çıkar demektedir. Metriklerin amacı tespit yapmaktır performans değerlendirme değildir.
Knowledge Lock-in Ölçüm Tuzağı
Knowledge Lock-in’i ölçmenin amacı bir rapor üretmek değildir. hangi katmanda hangi seviyede olduğunuzu bilmek ve oradan hareket etmektir.
Sonuç olarak Knowledge Lock-in soyut bir endişe değildir. Doğru ve dürüst bir şekilde analiz edildiğinde ölçülebilen bir yapıdır. Peki ölçümleri yaptık metrikleri karşımıza aldığımızda sonucun kötü olduğunu gördüğümüz de ne yapacağız. Bir sonra ki yazıda bilgiyi geri kazanmak için yapılması gerekenleri anlatmaya çalışacağım. Sözleşmeden çalışma biçimine, dokümantasyondan insan yönetimine uzanan bir Knowledge Lock-in’den Çıkış Playbook’u sunacağum.
Buraya kadar okuyup zaman ayırdığınız için teşekkür ederim. Geri dönüşleriniz benim için değerledir.
Kaynaklar;