Kurumsal Mimarinin Asıl Görevi
İkinci yazıda bir harita çıkartıp adını KOM yani Knowledge Ownership Model koyduk. Bilginin katmanları olduğunu ve her bir katmanın sahiplik seviyesini tanımladık.
Bir ustanın büyüklüğü yaptığı işle değil, kendinden sonra o işi yapabilenlerle ölçülür.
Knowledge Lock-in Serisi — 5
Kurumsal Mimarinin Asıl Görevi
Bir mimari kurul toplantısı düşünün. Yeni bir ürün gündemde ve sunumlar yapılıp sorular soruluyor. Bu sorular genelde;
- Maliyet nedir?
- Mevcut standartlarımıza uyuyor mu?
- Güvenlik gereksinimlerini karşılıyor mu?
- Hangi ekip sahiplenecek?
- Legacy sistem ile bir entegrasyon ihtiyacı var mı?
Hepsi doğru sorular. Ancak neredeyse hiçbir kurum içi toplantıda şu sorulmaz (en azından ben denk gelmedim)
“Bu teknolojinin bilgisi üç yıl sonra nerede yaşayacak?”
İşte bu yazıda tam da bu sorunun neden mimari komitelerde olması gerektiğini anlatacağım. Knowledge Lock-in Serisinin son yazısı.
Yazıya başlamadan önce buraya nasıl geldiğimizi kısaca bir hatırlayalım;
İlk yazıda bir tez ortaya attık ve kurumların asıl riskinin Vendor Lock-in değil Knowledge Lock-in olabilir dedik.
İkinci yazıda bir harita çıkartıp adını KOM yani Knowledge Ownership Model koyduk. Bilginin katmanları olduğunu ve her bir katmanın sahiplik seviyesini tanımladık.
Üçüncü yazıda ölçümün nasıl olması gerektiğine değindik. Sinyaller, metrikler ve on soruluk bir öz değerlendirme.
Dördüncü yazıda artık hareket zamanı diyerek değişimi başlattık. Sözleşmeden çalışma biçimine, kurumsal hafızadan insan yönetimine uzanan bir playbook ortaya çıkardık.
Şimdi geriye tek bir soru kaldı;
Peki tüm bunları kim sürdürecek?
İşte bu final yazısında bu sorunun cevabını vereceğiz. Diyelim ki dördüncü yazıda bahsettiğim playbook’u uyguladınız. ADR yazmaya başladınız. Runbookları güncellediniz. Vendor ilişkisinde reverse pairing’e geçtiniz. Sözleşmeye bilgi transferi maddeleri eklediniz. Kısacası harika bir yıl geçirdiniz. Herkes mutlu. Ama bu harika yılı geçirmenize yardımcı olan kurum çalışanı işten ayrılır, proje biter, ekip dağılır ya da yeni bir kriz gelir ve öncelikler değişirse. Yeni bir vendor gelir ve kimse ona bir yıl önce kazanılmış beklentiyi anlatmazsa. Böyle bir durumda ne olur? Belli bir süre geçer ve kurum içinde şu ses duyulur;
Biz bunu bir dönem yapıyorduk
Playbook neden erir?
İşte bu Knowledge Lock-in’in en sinsi halidir. Çünkü bu kez kaybolan bilgi değildir bilgiyi koruma pratiği kaybolmuştur.
Buradan çıkarılması gereken sonuç nettir. İyi pratikler kişilere ve projelere bırakıldığında erir. Kalıcılık ancak pratik bir yönetişim mekanizmasına gömüldüğünde mümkündür. Ve kurumsal teknolojide bu mekanizmanın adı bellidir. Kurumsal Mimari
Mimari Karar Kapısına Bir Soru Daha Eklemek
ADG yani Architecture Decision Gate çok havalı bir tabirdir. Kurumsal mimarinin en somut aracıdır diye bilirim. Yeni bir ürün, yeni bir platform, yeni bir vendor … hepsi bu onay noktasından geçer/geçmelidir. İşte bu onay noktasına tek bir kriter eklemek uzun vadede her şeyi değiştirir. Nedir bu kriter; Hedef bilgi sahipliği seviyesi.
Bugün bir çok mimari kurulda karar şöyle çıkar;
Bu ürünü / vendor’u / teknolojiyi onaylıyoruz
Oysa şöyle çıkması her şeyi değiştirir;
Bu ürünü, operasyonel bilgide 24 ay içinde Seviye 3 hedefiyle onaylıyoruz. Bu hedefe nasıl ulaşılacağı proje planında yer alacaktır.
Küçük bir fark gibi görünebilir ama etkisi büyüktür. Birinci cümlede bilgi sahipliği kimsenin sorumluluğunda değilken ikinci cümlede artık bir hedef, bir plan ve bir taahhüttür. Aslında var olan ADG’ye aşağıdaki üç sorunun eklenmesi yeterli olacaktır;
- Bu teknolojinin hangi bilgi katmanları kritik?
- Bu katmanlarda hedef sahiplik seviyemiz ne ve neden?
- O seviyeye kim, nasıl ve ne zaman ulaştıracak?
ADG’ye eklenecek sorulardan önce ve sonra
Bunlar bürokratik sorular değildir. Bugün sorulmadığında ilerleyen zamanlarda cevapsız kalacak olan sorulardır. Benim gibi regülasyona tabi sektörlerde çalışanlar için ayrıca bir hususu daha belirtmek isterim. Rügülasyonlara tabi olan kurumlarda dış kaynak kullanımına dair düzenlemeler genel olarak şunu bekler; Kurum, kritik fonksiyonlar üzerindeki kontrol ve gözetim sorumluluğunu devredemez. Hizmeti dışarıdan alabilirsiniz ama sorumluluğu dışarıya asla veremezsiniz. Bu beklentinin pratikteki karşılığını çok basit bir test ile ölçebilirsiniz.
Bir denetim sorusu geldiğinde cevabı kim veriyor?
Kurum ekibi kendi sistemini kendi kelimeleriyle anlatabiliyorsa kontrol kurumdadır. Ancak cevap için her seferinde vendor’un kapısı çalınıyor ve vendor’un masada olması isteniyor ise bu yalnızca teknik bir eksiklik değil aynı zamanda yönetişim boşluğudur. Kısacası Knowledge Lock-in regüle sektörlerde aynı zamanda bir uyum riskidir. Konuyu üst yönetim gündemine taşımak için belki de en güçlü argümanda bu risktir.
KOM’u Yaşayan Bir Envantere Dönüştürmek
İkinci yazıda bahsettiğim KOM matrisi bir kere doldurulup sonrada unutulacak bir şablon değildir. Çoğu kurumda zaten bir envanter uygulaması vardır. Sistemler, sahipleri, kritiklik seviyeleri, bağımlılıkları vb. başlıklar bu envanter uygulamasında hazır bulunmaktadır ya da bulunmalıdır. Bu zaten kurumsal mimarinin klasik varlıkları arasında yer alır.
Önerim çok basit. Bu envantere bir boyut daha ekleyin ve her kritik sistem için mevcut ve hedef KOM seviyelerini yazın. Yılda bir gözden geçirilsin. Bu sayede bilgi sahipliği dediğimiz şey bir kişinin farkındalığından çıkıp kurumun izlediği bir varlığa dönüşmüş olur.
Kurusal Mimari Envanteri — KOM Sevileri
Bu aynı zamanda önceliklendirmeyi de kolaylaştırır. Kritikliği yüksek fakat sahiplik seviyesi düşük olan sistemler envanterde kendiliğinden görünür hale gelir.
Görünmeyen risk yönetilemez. Envanter riski görünür kılmanın en sade yoludur.
Yavaş yavaş yazının ve serinin sonuna doğru gelirken değinmek istediğim üç konu daha var. Sorunun çözümü ile ilgili önerilerden bahsettik ama bunların sürdürülebilir olması için nasıl bir yol izlemek gerek. Buna da değinmek gerekiyor.
Yönetişimin Görünmeyen Yarısı: Teşvikler
Bir yönetişim çerçevesi yazabilirsiniz. ARG’lere yeni kriterler de eklenebilir ve envanteri de güncel tutabilirsiniz. Ancak ADR yazmak, bilgi transfer oturumu yapmak, runbook güncellemek gibi işlemler hiçbir performans değerlendirmesinde görünmezse uzun vadede yapılmaz. Bunun nedeni kurumlarda insanlar ödüllendirilen davranışları tekrar ederler. Burada aslında üçüncü yazıda ki uyarıyı hatırlamak gerekiyor.
Metrik Fetişizm mi
Eğer ADR sayısını hedef olarak belirlerseniz elinizde boş ADR’lerden başka bir şey olmaz. Burada ödüllendirilmesi gereken şeyin çıktı yerine yetkinliklik olması gerektiğini unutmayın. Teşvik doğru yapıldığında dokümantasyon zaten kendiliğinden gelecektir.
“Kaç ADR yazdınız?” değil “Ekibiniz bu sisteme bağımsız müdahale edebiliyor mu?” motivasyonu daha değerlidir.
Yönetişimin Görünmeyen Yarısı: Teşvik ve Metrik Fetişizm mi
Bunun yanında kaçınılması gereken ve yıllar içinde tecrübe ettiğim üç tuzaktan da bahsetmek isterim.
- Doküman Polisi Olmak: Kurumsal mimari ekipleri insanların peşinden doküman kovalayan bir birim haline gelirse iki şeyi kesin kaybeder. Doküman kalitesi ve ekiplerin iyi niyeti. EA’nı rolü denetlemek değil, mümkün kılmaktır. Şablonu hazırlar, süreci kısaltır ve doğru olan yolu en güzel seçenek haline getirir.
- Şablon Dolduruculuğu: Hazırladığınız şablonların düşünülmeden gelişi güzel doldurulmuş olması size sadece bilgi var hissi verir. Kolaya kaçmadan düşünülerek ve doğru soruların sorulduğu bir ADR’ye ihtiyacınız olduğunu unutmayın.
- Yönetişimi Bürokrasiye Çevirmek: Her karar için 5–6 onay gerektiren süreç insanları süreci aşmaya iter. Bilgi yönetişimi ağırlaştıkça etkisi azalır. Kestirme yol arayışı başlar ve yine elinizde içi boş dokümanlar olur.
Bu 3 tuzağın ortak paydası şudur; yönetişimi bir kontrol aracı olarak kurgulamak. Halbuki amaç kontrol etmekten değil sürekliliktir.
Bu seriye bir soru ile başlamıştık. Ya kurumların asıl riski kullandıkları ürün değilde o ürün hakkında ki bilgileri ise? Beş yazı boyunca bu soruyu takip ettik. Sorunu tanımladık, haritasını çıkarttık, ölçtük, harekete geçtik ve son olarak da çözümün kalıcı olması adına yolu belirledik.
Vardığımız yer ilk yazıda söylediğimiz cümlenin ta kendisi oldu:
Kurumsal Mimari’nin görevi yalnızca teknoloji standartları belirlemek değildir. Asıl görevi teknoloji bilgisinin kurumsallaşmasını sağlamaktır. Çünkü teknoloji değişir, vendor değişir, ürünler değişir, çalışanlar değişir, mimari yaklaşımlar değişir ancak kurumsal bilgi kaybedildiğinde yerine koymak yıllar alır.
Ve gerçek teknolojik bağımsızlık ürün sahipliğiyle değil bilgi sahipliğiyle başlar
Bu seriyi okuduktan sonra yapılacak yüzlerce şeyin olduğunu fark etmişsinizdir. Ama en değerlisi ve ilk yapmanızı tavsiye edeceğim şey ilk fırsatta en kritik sisteminizi seçin.
KOM matrisini doldurun. Beş katmanın her biri için mevcut seviyenizi dürüstçe işaretleyin. Sonuç sizi rahatsız ederse doğru yerdesiniz demektir. Çünkü bilgi sahipliği yolculuğu bir projeyle değil dürüst bir tespitle başlar.
Bu beş yazı boyunca beni takip edip okuduğunuz ve geri bildirim verdiğiniz için teşekkür ederim.
Bu seriyi yazarken amacım hazır bir reçete sunmak değildi. Kurumsal teknoloji dünyasında yetirince konuşulmadığını düşündüğüm bir riski görünür kılmak ve tartışmaya açmaktı.
Kendi kurumunuzda ki deneyimlerinizi, itirazlarınızı ve farklı bakış açılarınızı duymak beni ayrıca mutlu eder.
Seri: