YazılarYayımlandı

Vendor Lock-in Değil, Knowledge Lock-in

TOGAF 9.2 ile TOGAF 10 arasında ki yenilikleri ve bu yeniliklerin getirdiği esnekliği öğrenmeye çalıştığım bir dönemde kurumsal teknoloji dünyasında yıllardır konuştuğumuz Vendor Lock-in kayramının…

İyi şeyler inandığında, daha iyi şeyler sabrettiğinde ve en iyi şeyler ise hiç vazgeçmediğinde gelir!

Knowledge Lock-in Serisi — 1

Kurum Sınırı ve Vendor’ın Yeri

TOGAF 9.2 ile TOGAF 10 arasında ki yenilikleri ve bu yeniliklerin getirdiği esnekliği öğrenmeye çalıştığım bir dönemde kurumsal teknoloji dünyasında yıllardır konuştuğumuz Vendor Lock-in kayramının gerçekten bu kadar odaklanacak bir konu olup olmadığını düşünmeye başladım. Ya bu kavrama ayırdığımız odak aslında bize farklı bir sorunu görmemize engel oluyor ise? Ya kurumların asıl bağımlılığı kullandıkları ürünler değil de, o ürünler hakkındaki bilgi ise? İşte bu makaleyi yazmak istemem de ki asıl motivasyon bu sorular oldu. Tam olarak odağın nasıl paylaştırılması gerektiğine geçmeden önce şunu da belirtmekte fayda var; Teknoloji Satın Almak Yanlış Değildir. Bu yazı da her uygulamanın kurum içinde geliştirilmesi gerektiğine veya vendorların gereksiz olduğuna kanaat getirmek amacında değildir. Sorun teknoloji satın almak değildir. Asıl soru;

Teknolojiyi satın aldıktan sonra bilgi kimin elinde kalıyor?

Satın Alınan Ürünler, Devredilen Kararlar

Bir çok kurumda süreç aslında benzerlik gösteriyor. Önce ürün satın alınıyor sonra implementasyon için vendor devreye giriyor. Zamanla mimari kararlar bile vendorlar tarafından alınıp süreç devam ettiriliyor ve kurum içinde ki çalışanlardan şu cümleler duyulmaya başlanıyor;

“Bunu vendor’a soralım.”

“Bu sistemi onlar daha iyi biliyor.”

“Bu değişikliği ancak onlar yapabilir. Kendi kurdukları sistemi en iyi onlar bilir.”

İşte tamda burada teknoloji kurumun olsa bile bilgi kurumdan çıkmaya başlamış oluyor.

Peki Vendor Lock-in Gerçekten En Büyük Risk mi?

Vendor Lock-in önemli bir risktir. Ancak çoğu zaman görünen sonuçtur; asıl neden olmayabilir. Şöyle düşünelim; Ürün değişebilir, sözleşme feshedilebilir, platform göç edebilir. Peki yıllar içerisinde oluşmuş bilgi birikimi? Bunun bir migration aracı ya da fesih maddesi yoktur. Görev ya da iş değişikliği sırasında yapılan kısa süreli aktarımların ne kadar faydalı olduğu da zaten ayrı bir konudur. İşten ayrılmaya yeni bir iş planı oluşturmuş personelin bu aktarımı ne seviye de doğru ve eksiksiz yaptığı aktarımı alanın ise ne seviye de anladığı ve hangi tecrübelerden geçtiği ayrı bir konudur. İşte burada devreye Knowledge Lock-in tanımı devreye giriyor.

Knowledge Lock-in Nedir?

Bir kurum yıllardır kullandığı entegrasyon platformunu yenilemeye karar verir. Proje başlar başlamaz ilk soru gelir: “Bu routing kuralı neden böyle yazılmış?” Cevabı bilen kimse yoktur. Çünkü kuralı yazan vendor çalışanı 1–2 yıl önce ya başka projeye geçmiştir ya da işten ayrılmıştır. Alınan kararın gerekçesi hiçbir yerde kayıtlı değildir. Kurum kendi sisteminin yapısını dışardan satın almak zorunda kalır. İşte bu senaryonun devamında kurumlarda sıkça duyduğumuz o güzel cümle gelir:

“Bu işi farklı bir firmaya veremeyiz/vermeyelim”

Neden?

“Çünkü sistemi onlar kurdu en iyi onlar bilir.”

İlk başta bu durumda bir gariplik yok gibi gelir. Peki ya soruyu değiştirirsek farklı bir soru sorarsak:

“Neden sadece onlar biliyor?”

Eğer bir sistemi yalnız mevcut vendor sürdürebiliyorsa problem yeni vendor değildir. Problem, kurumun bilgi sahipliğini zaman içinde kaybetmiş olmasıdır. İşte gerçek bağımlılık ve kitlenme burada başlar.

Knowledge Lock-in tek bir projede bir anda oluşmaz. Her projede parça parça büyür. Bu parçalar;

  • Dokümantsyon eksik kalır
  • Mimari kayıtlar kayıt altına alınmaz
  • Bilgi transferi ertelenir ya da eksik yapılır
  • Operasyon tamamen vendor tarafına bırakılır
  • Yeni projelerde yine aynı vendor tercih edilir

Dikkat edilirse bu maddelerin hiçbiri tek başına bir karar değildir. Herhangi bir kurumda çalışan hiç bir çalışan “bilgiyi kurum dışına taşıyalım” demez. Her madde günün koşuluna göre haklı görünen önceliklendirmelerdir. Projenin teslim tarihi yaklaşmıştır, ekip çok yoğundur (her zaman yoğundur zaten) dokümantasyon en önemsiz görünen kısımdır ve “sonra” yazılacaktır. İşte Knowledge Lock-in’i sinsi yapan da tam olarak budur. Kötü bir kararın sonucunda oluşmamıştır. Küçük bir kar tanesi olarak başlayıp çığa dönüşür. Buda yıllara yayılan bir süreçtir.

Zamanla oluşan Knowledge Lock-in süreci

Peki Kurumsal Mimari Açısından Bakıldığında

KM’nin görevi yalnızca teknoloji standartları belirlemek değildir. Asıl görevi, teknoloji bilgisinin kurumsallaşmasını sağlamaktır. Çünkü teknoloji, vendor ya da ürün değişebilir. Ancak kurumsal bilgi kaybedildiğinde yerine koymak çoğu zaman yıllar alır.

Sonuç olarak artık tüm suçu vendorlara atmak yerine yönetici/sorumlu olarak çalıştığımız kurumlarda bilgi sahipliği fikrini daha sık dile getirmemiz gerekmektedir. Çünkü gerçek teknolojik bağımsızlık ürün sahipliğiyle değil bilgi sahipliğiyle başlar.

Bir kurumun en değerli teknolojik varlığı kullandığı ürünler değil, o ürünler hakkında sahip olduğu bilgidir.

Peki kurumlar bu riski nasıl ölçebilir. Bilgi gerçekten kurum içinde mi yoksa dışında mı yaşıyor nasıl tespit edilir. TOGAF sertifikasyon ve 9.2’den 10.0 standartlarını/farklarını çalıştığım ve ITIL ile de harmanladığım zamanlarda fark ettiğim bir boşluktan yola çıkarak geliştirdiğim Knowledge Ownership Model (KOM) bu soruna çözüm olacaktır. Sektörel olarak kabul görmüş devasa standartların (TOGAF ve ITIL) pratik hayattaki kör noktalarını ya da kısıtlarını gidermek adına geliştirdiğim yeni bir sentez model/yaklaşım önerisidir.

KOM’u anlattığım bir sonra ki yazımda görüşmek üzere. Geri dönüşleriniz benim için kıymetlidir. Zaman ayırıp okuduğunuz için teşekkür ederim.

Kaynaklar

  1. https://www.opengroup.org/togaf-standard-version-92-overview
  2. https://www.opengroup.org/togaf
  3. https://www.itil.com/