Dijital transformasyona ilişkin olarak insani ve kültürel faktörler, strateji, süreç, araç ve teknoloji gibi bileşenlerden bahsedilebilir.
Aslında teknolojiyi araç ve süreçleri daha etkin ve yetkin kılan bir katalizör olarak görebiliriz. Yani teknoloji, araç ve süreçlerin içinde yer alır. Araçları günün koşullarına göre en fazla ve hızlı değişkenlik arz eden faktör olarak değerlendirebiliriz.
Tüm etmenler arasında en önemli bileşen hiç şüphesiz insan kaynağı ve kurumsal kültür faktörüdür (Kültür, stratejiyi kahvaltı niyetine yer. Peter Drucker). İnançlı, dirençli ve çalışkan bir ekip strateji ve süreçlerdeki eksiklikleri telafi ederek kurumu zaman ve maliyet açısından kısmen sub-optimal da olsa başarıya ulaştırabilir.
Özellikle alınan kararlara ve yapılan seçimlere dahil edilmişse, yetkin bir ekip, mahcup olmamak ve mahcup etmemek adına ekstra fedakarlıkla bunu başarabilir.
Ancak bu ekibin ağırlık olarak Joel Spolsky’nin “Smart and Getting Things Done” diye tariflediği GTD yani “işi oldurma” mind-set’inde olması gerekir. GTD kafasında olmanın en temel gereksinimi sorunlar karşısında pes etmeyen(resilient) ve sonuç almak için yapılması gerekeni yapan, iş seçmeyen sonuç almaya odaklanan profil olmaktır.
Ne yazık ki büyük bir organizasyonun tamamının GTD, smart, resilient kimselerden oluşması gerçekçi bir beklenti değil. Fakat transformasyonu drive eden çekirdek bir ekip olmalı ve bu ekibin içerisindeki hakim ve ağırlıklı profil GTD olmalı.
Teknoloji dönüşümü söz konusu olduğu için her çıkan yeni teknolojiyi takip eden veya ettiği izlenimi doğuran değer üretmekten çok teknoloji deneyimlemeyi önceleyen profillerin öne çıkması söz konusu olabilir. Teknik bilgileri nedeniyle bu profiller kişiliklerine ve motivasyonlara bağlı olarak değişen vadede katkı sağlayabilirler ama omurgayı bu profiller üzerine inşa etmek veya GTDlere göre bu Tech-Monkey’leri yüceltmek veya öne çıkarmak hatalı bir tercih olur. Zira bu profiller hem yeterince sabırlı ve dirençli olmaz hem de işin odağını değer üretmekten teknoloji deneyimlemeye kaydırabilirler.
Kurum içerisinde GTD yaklaşımına sahip olması nedeniyle açıktan veya içten içe herkesin takdirini kazanmış kimseler başlangıçta “tech. stack”e çok hakim olmasa da çekirdek ekipte güçlü biçimde yer almalı. Bu profillerin inisiyatifte yer almasının başlıca yararları:
· Değişim karşısında kurumsal direnci azaltırlar.
· Mevcut sistemde “değer”in nerede olduğu, risklerin ne olduğu gibi kritik konulara hakim oldukları için doğru önceliklendirme ve execution yaparlar.
· Değer üretme odaklı oldukları için FOMO(Fear of Missing Out) psikolojisiyle over-engineered sistemler kurgulanmasını engellerler.
Ancak bu profilleri biraz daha yenilikçi kişilerle harmanlamak verimli bir tartışma ve farklı öncelikler arasında optimum dengeyi yakalama konusunda yararlı olur. Ayrıca bu arkadaşlar günlük operasyonun sağlıklı yürümesine aşırı derecede odaklanarak genel resme daha yukarıdan ve uzun vadeli bakma konusunu ikinci plana atmış olabilirler. Etkin bir liderlikle onlara bu bakış açısını kazandırmak hem kuruma hem bu kişilerin kariyer gelişimine büyük katkı sağlayacaktır.
Bu çekirdek ekibi bir özel time benzetirsek tim personelinin gösterişli boylu poslu iri yarı vs. olmasından çok gözü pek, dirençli ve soğukkanlı olması daha değerli. Tabii ki imaj ve iletişim bakımından bu tarz profiller de yer alabilir.
Bu çekirdek ekibi bir kaleyi ele geçirmeye çalışan öncü birlikler gibi görebiliriz. Burada öncelikli hedef bir koçbaşı gibi kalenin kapısını kırmak, surlara bayrak dikmek veya içeri sızıp en etkili direnç noktalarını etkisiz hale getirmek olmalı. Yani bu ekip en zor ve değeli misyona saldırmalı. Böylece ekibin geri kalanında bir inanç, moral ve motivasyon tesis edip, kar topu etkisiyle başarının parçası olma arzusunu yaygınlaştırmak hedeflenmeli.
Transformasyon stratejisine ilişkin önemli konulardan birisi de sisteme ilişkin algı ve kültürü doğru şekillendirmek. Yazılım Mühendisliğinin önemli figürlerinden Fred Brooks, 1987 tarihli “No Silver Bullet- Essence and Accident in Software Engineering” başlıklı efsanevi makalesinde “Bir yazılım ürünü; uygulamalar, kullanıcılar, regülasyonlar ve makinalar arasındaki kültürel matris ilişkisinin içine gömülmüş bir sistemdir. Tüm bu etmenler sürekli bir değişim içerisindedir ve bu değişim de kaçınılmaz biçimde yazılım ürününü değişmeye zorlar.” der.
Yani aslında hiçbir dönüşüm projesi nihai değildir. Gittikçe artan bir hızda yeni değişim ihtiyaçları gündeme gelecektir. Dolayısıyla bu gerçeği kurumun DNAsına işlemek gerekir.(Mecbur kalmadan önce değiş. Jack Welch)
Bu noktada “Core domain modelini çok iyi kurgular ve izole edersek görece basit ve küçük eforlu çalışmalarla transformasyon yapabilir miyiz? “ düşüncesi oluşabiliyor. Bu maalesef çok gerçekçi değil. Her ne kadar fundamental algoritmalar veya iş kuralları görece daha az değişebilir veya değişimi daha kolay sağlanabilir olsa da UX her zaman değişmeye açık hatta değişmek zorunda olan bir konu. UX sadece arayüz değil. İçinde “application logic” dediğimiz uygulamaların akış mantığını ve UI’ı da barındırıyor. Bu bileşenler pek çok sistemde işin doğası gereği “core domain model”den daha büyük ve karmaşık olabiliyor. Yani periferinin büyüklük ve karmaşıklığının çekirdekteki “core model”den fazla olması çoğunlukla sadece “accidental” değil malesef “ essential”. Örneğin, farklı client agentlar (web, mobil, kiosk..) veya 3rd party entegrasyonları için aynı core modelin farklı presentasyon ve akış mantıkları barındırmak zorunda olması son derece yaygın rastlanan bir durum.
Bu durumu mahalle berberlerinin belirli aralıklarla dükkanın dekorasyonunu değiştirmesine benzetiyorum. Traş işinin core modeli çok değişkenlik göstermiyor yada saç sakal kesim modalarında değişim, bırakın dekorasyon değiştirmeyi, eldeki makas ve bıçağı bile değiştirmeyi gerektirmiyor. Ama onlar kullanıcı deneyimi ve tatminini üst seviyede tutabilmek endişesiyle core business’ı doğrudan ilgilendirmeyen ve üstelik hayli masraflı olan dekorasyon değişikliğini sürekli yapmak zorunda olduklarını düşünüyorlar.
Kaldı ki hasbelkader temel iş kurallarımızı teknolojik değişime karşı bağışık tutabilsek bile –ki bunun geçerliliği ve sağlıklılığı da tartışılır- işimizin sunuş ve dış dünyayla etkileşme biçimi, yani çekirdeğin etrafındaki büyük ve geniş çevre teknolojiden kaçınılmaz biçimde etkileniyor.
Bu noktada toplumsal yaşamın modernleşme süreciyle dijital transformasyon arasında ilginç bir tezattan bahsetmek mümkün:
Toplumsal modernleşme; şehirleşme, yerleşik hayata geçme, büyük ve gösterişli binalar, uzun yıllar ayakta kalacak üst ve altyapılar inşa etme, bir yerde kök salma olarak ortaya çıkarken -ki medeni şehirli demek- cloud native dönüşüm tam tersine göçebe kültürünü çağrıştırıyor:
Herhangi bir servisin nerede çalıştığının bir önemi yok. Bugün burada yarın orada çalışabilmeli. Bugün on-prem private cloud’da yarın X public cloud’unda ertesi gün Y cloud’unda çalışabilmeli.
Sistem, içi devasa mobilyalar ve dekorasyonlarla donatılmış çok katlı devasa binalar yerine adeta bir göçebe obası gibi gerektiğinde kolayca kaldırılıp başka yere taşınabilen küçük çadırlar veya karavanlar gibi olmalı. Yani birbiriyle ve üzerinde çalıştığı altyapıyla girift ve ayrılmaz ilişkilerle bağlı devasa sistemler yapmak yerine, herhangi bir altyapıya yüksek bağımlılığı olmayıp, ihtiyaç duyduğu minimal altyapıyı kendi içinde barındıran küçük bileşenlerden oluşan ve her zaman değişmeye ve göç etmeye hazır sistemler inşa etmeliyiz. Container tabanlı mikroservis mimarisi de tam olarak bu demek zaten.
Her zaman değişmeye hazır olmak, değişimin riskini minimize etmekle mümkün. Bu da ancak otomasyonu en üst seviyeye taşımakla sağlanabilir:
· Altyapı ve provisioning seviyesinde tüm sistemi “Infrastructure as Code” yaklaşımıyla kolayca paketlenebilir ve state’ini istediğimiz gibi ileri-geri alabilir, replay edilebilir formda tutmak
· Uygulama seviyesinde korkmadan değişiklik ve deneme yapabilmek için geniş ve kapsayıcı bir regresyon test süiti inşa etmek gerekir.
Dijital dönüşüm projelerine ilişkin taktik seviyede bir kaç öneride bulunmak gerekirse;
Dönüşüm sürecinde aksi yönde “hard constraint”ler yoksa one-shot, big-bang dönüşümler yerine kademeli geçişler tercih edilmeli. Eski sistemi, hedef sistemin bir parçası olan modern bir katmanın arkasına hapsedip, peyderpey eski sistemden parçalar koparıp yeni sisteme taşımak, bu süreçte talepleri cevaplarken öncü katman üzerinde duruma göre istekleri eski veya yeni sisteme yönlendirmek ve zamanla eski sistemi bu biçimde boğarak yok etmek riskleri azaltan bir yaklaşım olarak benimsenebilir (Strangler Pattern). Benzer biçimde eski sistemle yeni sistem arasındaki etkileşim ihtiyacının yeni sistemde bir entropi ve korozyon oluşturmaması için iki sistem arasındaki etkileşim bir “anti-corruption layer” üzerinden gerçekleştirilebilir. Bunu da ele geçirmek istediğimiz bir kaleyi kuşatıp tüm giriş çıkış, ikmal ve lojistik mekanizmasını denetim altına alarak, hatta uzun vadeli kuşatmalarda etrafına alternatif bir yaşam kurarak zamanla teslim olmaya zorlamak gibi düşünebiliriz.
Test otomasyonu konusuna hiçbir zaman “geç kaldık, artık iş işten geçti” gözüyle bakılmamalı. Çünkü geliştirme devam ettikçe değişiklik yapmanın riski ve zorluğu artıyor. Ama değişikliğin de bir noktada kaçınılmaz olduğunu biliyoruz. Test otomasyonu süreci hayata geçirilirken sabırlı yaklaşılmalı. İlk 3–6 ayı yatırım ve öğrenme süreci gibi görmeli. Hemen ilk günden bir “silver-bullet” etkisiyle sorunları çözeceği beklentisine girilmemeli. Anlamlı bir fayda sağlanabilmesi için code covarage’ın belirli bir seviyeye ulaşması (en az %20–50) ve ekibin efektif test case’ler yazabilir noktaya ulaşması gerekir.
Cloud native, container tabanlı mikroservis sistemlerinde çok fazla “moving part” olduğu için, küçük parçaların development ve test ortamları için dahi birleştirilmesi ve ayakta tutulması ciddi bir learning curve ve efor gerektirecektir. Bundan kaçınmak için projenin çok erken aşamalarında DevOps süreci kurgulamak geliştirme ve test süreçlerinde çok fazla zaman kaybını yaşanmasını engelleyecek çok önemli bir otomasyon adımıdır. Dolayısıyla “hele bir mevcut birkaç modülü taşıyalım, DevOps’a sonra bakarız” yaklaşımı hiç akıllıca bir yaklaşım değildir.
Özetle, digital transformasyonu uzun süreli yatay seyirler ve nadiren aşmak zorunda kaldığımız çok yüksek merdiven basamakları şeklinde değil de her an hafif meyilli bir yokuşu tırmanarak sürekli yükselmek biçiminde ele almalı, kurumsal kültüre de bu algının hakim olmasını sağlamalıyız.
