Saymaktan bıktığım kadar kurumsal sistem taşıdım. Oracle'dan Oracle'a, AS400'den Oracle'a, monolitten dağıtık yapıya — her çeşit. Ve sürekli gördüğüm örüntü, eski sistemlerin çok eski olması değil. Organizasyonların düzenli olarak eski sistemin gerçekte ne yaptığını küçümsemesi ve yenisinin ne yapacağını abartması.
"Eski" Pratikte Genellikle Ne Anlama Geliyor
Bir yönetici bir şeye "eski sistem" dediğinde genellikle şu üç şeyden birini kastediyor:
- Mevcut ekibin bilmediği teknoloji üzerinde çalışıyor
- O zamandan beri ayrılan kişiler tarafından yapıldı
- Modern bir arayüzü yok
Bunların hiçbiri aslında değiştirme argümanı değil. Dokümantasyon, bilgi transferi ve muhtemelen daha iyi bir ön yüz argümanı. Bilgi açığını çözmek için sistemi yeniden yapmak, anahtarları kaybettiğiniz için evi yeniden inşa etmek gibi.
Tehlikeli eski sistem eski teknoloji değil — belgelenmemiş davranış. On beş yıl boyunca stored procedure'lere birikmiş iş kuralları. 2011'den kalma, kimsenin hatırlamadığı belirli bir yasal gereksinim nedeniyle var olan kenar durum işleme. "Sadece çalışan" ve her denetimi geçen ama kimsenin tam olarak anlamadığı hesaplama mantığı.
Bu sistemi taşıdığınızda teknolojiyi taşımıyorsunuz. Davranışı taşıyorsunuz. Ve davranışın gerçekte ne olduğunu bilmiyorsanız, bir şeyi kaçıracaksınız. Finansal hizmetlerde kaçırdığınız şey bir denetimde, yasal bir gönderimlerde veya fon mutabakatında ortaya çıkıyor.
Modernizasyon Tuzağı
Organizasyonlarda tekrarlanan örüntüyü gördüm: bir "modernizasyon" girişimi onaylanıyor, yeni platform seçiliyor, geçiş projesi başlıyor. On sekiz ay sonra yeni sistem canlıya alınıyor. İki yıl sonra insanlar yeni sistemin sınırlamalarını — tahmin edin ne ile — belgelenmemiş geçici çözümler ve yamalar büyüyen bir katmanla aşıyor.
Çark dönüyor. "Modern" sistem kimsenin anlamadığı eski sisteme dönüşüyor. Döngü tekrarlanıyor.
Bu hiçbir zaman taşımamak için bir argüman değil. Mevcut sistemin gerçek davranışını dokunmadan önce anlamaya yatırım yaparak ve gerçekte hangi sorunu çözdüğünüze dair net bir görüşle kasıtlı olarak taşımak için bir argüman.
Modernizasyon Gerçekte Nasıl Görünmeli
Bir geçiş veya modernizasyon girişimine yaklaştığımda, ilk aşama her zaman arkeoloji. Bu sistem gerçekte ne yapıyor? Dokümantasyonun söylediği değil — gerçekte ne yapıyor? Bu, kodu okumak, kenar durumları çalıştırmak, en uzun süredir sistemi işletenlerle konuşmak demek.
Bu aşama hiçbir zaman popüler değil. Görünür çıktı üretmiyor. Hiçbir satıcının kapsam beyanında yer almıyor. Ama geçişin başarılı olup olmayacağını ya da yeni bir dizi problemi daha iyi pazarlamayla üretip üretmeyeceğini belirleyen çalışma bu.
İkinci baktığım şey: yeni mimari alan için daha mı iyi, yoksa sadece daha mı modaya uygun? Microservice'ler her zaman iyi yapılandırılmış bir monolitten daha iyi değil. Cloud-native her zaman düzenlenmiş finansal veri için on-premise'den daha iyi değil. Doğru cevap spesifik yasal ortama, ekibin operasyonel kapasitesine ve gerçek ölçek gereksinimlerine bağlı — son konferansta duyurulana değil.
Yetenek Boyutu
İşe alım perspektifinden, özellikle bir geçişten sağ çıkmış insanlar arıyorum. Yönetim sunumundan yönetmiş değil — gerçekten uğraşmış, projenin ortasında belgelenmemiş davranışı keşfetmiş ve nasıl ele alacağını bulmuş. Bu deneyim ikame edilemez.
Yalnızca greenfield sistemler inşa etmiş mühendislerin kör noktası var. "Bu sistem herkesin yazmadığı ne yapıyor?" sorusunu bir şeye dokunmadan önce sorma içgüdüsüne sahip değiller.
Üretim sistemlerine gömülü kurumsal bilgi, bir organizasyonun sahip olduğu en değersiz varlıklardan biri. Her geçişi önce arkeoloji projesi olarak ele alın. Teknoloji eninde sonunda değiştirilecek — neden yaptığının bilgisi, kaybetmeyi göze alamayacağınız şey.