Uygulama geliştirme yaşam döngümüzün henüz otuzuncu Sprint başındaydı. İki haftalık koşu görevlerini Sprint Planning toplantısında zaten belirlemiştik. Takım olarak 13 Story Point’e sahip Production Support Buffer mecburen her sprint içerisine dahil ettiğimiz bir maliyet. 17 yaşındaki Microsoft .Net tabanlı devasa ERP(Enterprise Resource Planning) ürünümüz ek geliştirmeler veya önceki yıllardan kalan teknik borçlar sebebiyle bazen üretim ortamı sorunları ile karşımıza gelmekte. Büyüklüğüne nazaran Code Coverage oranının düşük olması yeni ilavelerin var olan yapılara olan etkisini anlamamızı zorlaştırıyor. Ben, Mali İşler ve Ortak Modüller(Kimsenin bilmediği bir modül varsa böyle gelin) ekibindeyim. Lakin ERP’nin diğer modüllerinde de benzer sorunlar olabiliyor.
Bazen kod kalite standartlarını korumak, bakım maliyetlerini düşürmek, minimum sorunla sürümleştirmek, hızla ölçekleyebilmek ve çabuk adaptasyon için geliştirilmiş yeni kültür, ilke, mimari model veya araçları gözden kaçırırız(farkına varmayız) Bu, uzun ömürlü ürünlerin ilerleyen zamanlarda ki modernizasyonunu oldukça güçleştirebilir. Tabii her şeyi de sorgusuz sualsiz benimsememeliyiz. Değişime açık ama sakin davranmalıyız.
O gün her zaman ki gibi Madelein yanıma oturdu ve acil çözüm bekleyen müşteri sorunlarının en önemli olanlarından birisinden bahsetmeye başladı. Tüm öncelikleri bir kenara bırakıp bu üretim problemine yoğunlaşmam ve en kısa sürede çözüme ulaştırmam gerekiyordu. Bu, bazı stand-up meeting toplantıları sonrası yaşadığımız standart bir durum. Gün geçtikçe azalan ama bir süre daha hayatımızın parçası olacak bir gerilim hatta. Her ne kadar müşterinin de dahil olduğu kurumsal çaptaki Dijital Board ile işler önceliklendirilse de, bayilerden ve ana yüklenici firmadan gelen üretim ortamı sorunları göz ardı edilemiyor.
Bir bayinin kısa süreliğine de olsa fatura kesememesi ya da stok sahasındaki mobil cihaz süreçlerinde meydana gelen yavaşlık nedeniyle durma noktasına gelen sevkiyat, elbette ortaya çıkan zararlar düşünülünce kriz ortamının bir mantar bulutu gibi geliştiricinin masasında patlamasına neden olmakta(Ve kimse radyoaktif maddeyle kaplanmış bir geliştiricinin yakınlarında olmayı tercih etmez)
Bu nedenle müşteri isteklerinin doğru şekilde parçalanması, ortak paydaşlarda el sıkışılması, önceliklendirmelerin ve iş değerlerinin üst kademeden itibaren şeffaf bir şekilde görülebilmesi elzem derecede önemli. Bunu aşmak için modüllerdeki iş sahipleri ve scrum master’lar belirli aralıklarda müşteri ve üst yönetim ile bir araya gelerek kabul kriterleri üzerinde müzakerelerde bulunup vaziyet hakkında bilgi paylaşımında bulunuyorlar. Bu sayede her şeyin şeffaklıkla tüm birimlere akması sağlanıyor.
Shelby’nin Monolitik Dünyası
Tamamiyle monolitik karakteristikte bir yazılım olarak niteleyebileceğimiz ERP ürünü gerçek bir Legacy sistem. 2002 yılında .Net Framework’ün ilk sürümüyle birlikte geliştirilmeye başlanmış, N-Tier mimariye göre yazılmış, zaman içerisinde SOA(Service Oriented Architecture) evrimini gerçekleştirmiş, tek Microsoft SQL Server örneği ile çalışan, 8500 ekran, 4500 tablo, 27binden fazla Stored Procedure’den oluşan ve sahada 10bin personel tarafından kullanılan bir Asp.Net Web Forms uygulaması(Şimdi pek çoğunuz “ne kadar da demode bir teknoloji kullanıyorlar” diyebilirsiniz ama unutmayın; Bu monolitik mimari yıllardır ve halen müşteri için olan görevini başarıyla yerine getiriyor)
Shelby, çevresel olarak entegre olduğu çeşitli tipte sayısız servise de sahip. Eski nesil SSIS(Sql Server Integration Services) paketlerinden yeni nesil REST servislerine, kurum dışı WCF uç noktalarından SOAP bazlı Web hizmetlerine kadar oldukça geniş bir dal budak yığını söz konusu. Sektörün bir gereği olarak yurt dışı firmalarla yapılan bir çok entegrasyon noktası bulunuyor. Bazılarıyla TCP gibi protokollerle iletişim kuruluyor. Regülasyonlar sebebiyle devlet kurumları ile entegre olunan noktalar da mevcut. Kocaman bir ekosistem işte :)
Monolitik bir sistem her zaman kötü çocuk değildir. Shelby sahip olduğu dezavantajlara nazaran tek bir paket olması nedeniyle üretime alma, performans ve hata izleme ile bağımlılık yönetimi gibi konularda dağıtık mimariye göre daha avantajlı durumda.
Nitekim dağıtık sistemlerin yönetilmesi ve yaşatılması zordur. Öyle ki dağıtık sistemlerde üretime alma sürecinin otomatikleştirilmesi, test süreçlerine ait otomasyonun her aşamasında uygulanması(Unit Test, Functional Test, Regression Test, User Acceptance Test), yazılım ve operasyon ekiplerinin daha yakın çalışması(DevOps), her servisin çalışma zamanı performansının izlenebilmesi, takibinin yapılması, versiyonunun yönetilmesi vb bir çok şey gereklidir.
Güncel .Net Framework sürümüne evrilmiş olsa da SonarQube ile başlanan teknik borç azaltma çalışmaları öncesi yaklaşık 2 milyon satır koda sahip olan bir üründen söz ediyoruz. Big Bang öncesi %17 kadarı tekrarlı koddan oluşuyordu (Doğruyu söylemek gerekirse turuncu bankada çalışırken gördüğüm C ile yazılmış devasa muhasebe paketinden sonra Tanrı Nesneler-God Object içeren bir uygulama daha görmek şaşırtıcı değil) SonarQube, çeşitli seviyelerden gelen toplam teknik borcun temizlenmesi için 786 adam günlük bir tahminlemede bulundu.
Teknik borçların azaltılması şarttı çünkü bir sene öncesinde başlanmış olan dönüşüm süreci kapsamında yeni araç ve kültürlere adapte olunurken Shelby’nin modernize edilmesi gerekiyordu. Terk edilemeyecek kadar önemli bir role sahip olan ürünün baştan yazılması maliyeti ciddi anlamda yüksekti. Bu nedenle hedeflerden birisi sonraki yıl onun teknik borcunun sıfırlanması olarak belirlenmişti. Bunu yapmazsak CI/CD hattındaki Quality Gate noktasına takılacağımız ve Gandalf’ın o meşhur ‘you shall not pass’ sözüyle karşılaşacağımız aşikar.
İşin başında ve sonrasında,
ThoughtWorks firmasının zamanında verdiği danışmanlık sonrası sunduğu 171 sayfalık rapor, dev monolitik ERP uygulamasının mikro servis dönüşümüne tabii olmasının zorunlu olduğunu belirtmişti. Bunun için bir çok Anti-Pattern’i bünyesinde barındıran ürünün öncelikle teknik borçlarından arındırılması önemli.
SonarQube’nin pek çok çıktısı benzer kural ihlallerini verdiğinden genç arkadaşlarımızdan oluşan bir ekip(deneyimli yazılımcıların yanına eklenen stajyerlerden oluşan bir grup parlak beyin) Roslyn ile kokan kısımları hızlıca bertaraf etti. İşin başında teknik borcun farkında olup ürünleşme yolundaki engelleri de bilen ve CEO’ya doğrudan raporlama yapan yazılım grup müdürü dahi vardı. Bizzat kodlamaya katıldığını ve teknik borcun temizlenmesi için elinden geleni yaptığını gözlerimle gördüm. Kısa sürede teknik borcun akıllı kod parçaları ile 133 güne kadar indiği görülmüştü. Asıl sorun Complexity değerleri yüksek olan God Object damgalı sınıfların nasıl ayıklanacağıydı. İşte bu noktada daha önceden öğrenip de ne zaman kullanırız dediğimiz bazı kavramlar değer kazanıyor (Çok fazla if bloğu veya switch koşulu barındıran ve bu nedenle Complexity değeri yüksek çıkan bir fonksiyonda hangi tasarım kalıbını kullanarak çözüm üretirsiniz?)
Burası konfor alanınız dışına çıkmanızı gerektiren, iletişimin ön plana çıktığı, mücadelesi yüksek bir yer. Bu bence iyi bir şey. Çünkü daha fazlasını kaldırabileceğinizi görüyorsunuz.
Dönüşmeye Çalışmak ve Sıkıntılar (Dijital Dönüşüm)
Çeşitli ürün gruplarından farklı teknolojilerle geliştirilmiş bir çok sistemin bir arada yer aldığı kaotikleşmiş, bakım maliyetlerinin yüksek olduğu, sirkülasyon nedeniyle bilgi kaybının yaşandığı, basit bir kod düzeltmesinin(hotfix gibi) çıkılması için dahi rutin geçiş gününün beklendiği bir ortam söz konusuydu. ERP bir yana yeni nesil ürünler ile de haşır neşir olunuyor, kaçınılmaz modernizasyon çalışmaları pek çok ekipçe planlamalara dahil ediliyordu.
Kabaca bir yanda yeni nesil savaş uçağının geliştirilmesi, diğer yanda kırk yıllık tankların modernize edilmesi öteki tarafta amfibik yetenekleri ile diğer unsurları taşıyacak uçak gemisinin yapımı noktasında çalışan bir çok insan olduğunu hayal edin. Akıllı ve dikkatlice hareket edilmediği takdirde 135mm tank topu taşıyan ve uçacağına kesin gözüyle bakılan bir mühendislik harikası icat etmeniz içten bile değil.
Uzun yıllarını şirket bünyesinde geçirirken pek çok konuda bilgi sahibi olan bir geliştirici, özellikle o şirket kültürünün şartları düşünüldüğünde değerlidir. Bu tip çalışanların kaybı ister istemez bazı kritik müdahale bilgilerinin de uçmasına sebebiyet verebilir.
Çalışanlar arası bilgi transferinin daha iyi yapılabileceği çevik iletişim teknikleri ve farklı modüllerdeki kişilerin çapraz yetkinlikler kazanabileceği Tribe usülü yapılar bu kayıplara belki çözüm olabilir.
Yine de işin can alıcı kısmı insanların buna ne kadar istekli olduğuyla da alakalıdır.
Bu bağlamda çevik metodolojilere adapte olunup Scrum ile yürünmesine, DevOps kültürünün benimsenmesine, ürün taşıma sisteminin yani CI/CD(Continuous Integration/Continuous Delivery-Deployment) hattının kurgulanıp TFS yerine git bazlı Azure DevOps platformuna geçilmesine karar verildi. Feature bazlı geliştirmeyi desteklemek adına Git Flow stratejisi tercih edildi. Artık develop isimli branch tabanlı olarak açılan Feature setleri üzerinde yapılan geliştirmelerin test sonuçlarından gelen bilgilere göre tekrar develop hattına, oradan master’a merge edilmesi söz konusu. Hatta kod yamaları için de Git Flow stratejisi tercih ediliyor. Üretim ortamında aldığımız bir hata için rutin geçiş gününü beklememiz şart değil. Acil geçiş mi? Hiç sorun değil!
git extension tarafından bir görüntü
Her feature, Scrum Board üzerinde açılmış bir User Story veya Work Item ile ilişkili. Derlenmesi neredeyse bir saati bulan(şimdilik) ERP her öğle vakti teste, iki haftada bir her pazartesi dondurularak(freeze) pre-prod ortamına ve o haftanın çarşamba gecesi üretim ortamına çıkıyor(Şu vakitler haftada bir üretim ortamına çıkılması da gündemde) Benim için heyecan uyandıran tüm bu otomatikleştirilmiş etkileşim Azure DevOps üzerinden yönetiliyor. Hedef bu periyotların dışına çıkıp istenildiği zaman üretim ortamına özellik eklenebilmesi. Lakin bunun için biraz daha yolumuz var.
Araya renk katacak bir ekran görüntüsü de koyalım. Fotoğrafta buradaki belki de en renkli takımlardan olan lTunes klanının board’u yer alıyor. Bu renkli oluşumda onları motive eden yöneticileri Ismail KIRTILLI nın rolü çok büyük(Şekerpınar’daki bu board hiç bozulmadan Maslak’taki yeni ofise de taşındı)
Her ne kadar süreç otomatik hale getirilmiş olsa da üretim geçişleri çoğunlukla CAB(change advisory board) süreci üzerinden ilerletiliyor. Acil geçiş ihtiyaçları mutlaka direktör onayından geçiriliyor. Geçişin etkisi, kritikliği ve geri alma planları sürece dahil edilmeye çalışılıp sorun olduğunda bir önceki doğrulanmış versiyona dönebilmek için ne gerekirse yapılıyor.
Tüm bu çetrefilli işlerin yanında şirketin kültür dönüşümünün sancıları da olmadı değil. Bizi en çok zor anlayan her zaman olduğu gibi müşteri tarafıydı. ERP, onların göbekten bağlı olduğu bir sistemdi ve şimdi isteklerini sprint’ler başlamadan önce ürün sahipliği rolünü üstlenerek ilk kez temas ettikleri yazılım ekipleri ile birlikte belirlemeye çalışmak başlarda onlara da zor gelmişti. Binalar arası bir otoban olmasıydı belki de bizi birbirimizden uzaklaştıran ama sonunda alıştılar…
Aslında biz yazılım ekipleri çoğunlukla SCRUM, KANBAN gibi metodolojiler ile uğraşıyoruz. Ancak üst yönetim kademisine baktığımızda benzer stratejilerin dijital board gibi terimlerle uygulandığını da görmekteyiz. SAFE(Scaled Agile Framework) aslında tam da bu kademenin uygulayacağı türden bir pratik.
Yeni Nesil Ürünler ve Gelecek Vizyonu
İlk başladığım zamanlarda bu yeni nesil ürünlere biraz temkinli yaklaştığımı ifade etmek isterim. Henüz deneysel sürümlerde olan platformların ürünleştirilip müşteriye sunulmasına her zaman karşıyım. Deneyimlemek daima tavsiye ettiğim heyecanlı bir çalışma ama müşterinin bakış açısı çok daha farklı oluyor. Onlar sorunsuz ürünlere yeni isteklerini ekletmek istiyorlar.
“Ayıkla pirincin taşını” dememek yerine gerçekten emin olup ürünleştirmek bu tip kurumsal firmalar için çok daha iyi. Sonuçta Start-Up kültüründen oldukça farklı dinamikler söz konusu. Bu nedenle hype teknolojileri ürünleştirmeden önce belki de Technology Radar gibi bir kaynağa bakarak ilerlemekte yarar var.
Neler geliyor, kimi mercek altına alalım, ne için hazırlık yapalım, hangisine adapte olalım ve benzeri soruların cevapları stratejik olarak önemli. Pek tabii yazılımcıları da bu noktada teşvik etmek, cesaretlendirmek ve hata yapmaktan korkmamalarını sağlamak lazım. Elbette hata yapma toleransının kabul edilebilir sınırlarını da iyi belirlemek gerekiyor.
Yeni nesil ürünler çok daha şanslı. Microsoft’un açık kaynak ve platform bağımsız .Net Core tabanlı Web API servisleri ile konuşan Vue/Angular tabanlı önyüz sistemlerinden oluşan bu çözümlerde deneyselliğe de izin veriliyor.
Yazılımcıların hata yapmalarına müsaade etmek gelişimi destekleyen en önemli unsurdur. Bu hatalardan ders çıkartıldığı müddetçe.
Javascript yerine daha çok Typescript tercih ediliyor, webpack gibi modern paketleyiciler, Node.js gibi sunucular kullanılıyor. Tamamen Dockerize edilerek ölçeklenebilirliği kolaylaşan uygulamalar, Azure üzerindeki CI/CD (Continuous Integration/Delivery-Deployment) hattında Test standartlarına uyulmaya çalışılarak yaşıyor. Yaygınlaştırılmaya başlanan Selenium entegrasyonları ile fonksiyonelliklerin davranış odaklı test senaryoları üzerinden kontrolü yapılıyor. Günün herhangi bir anında kolayca sürüm çıkılması ve container çoklaması ile performans iyileştirilmesi mümkün.
KONG arkasında yönetilen bu ürünler çoğunlukla kendi veritabanları ile çalışırken pek çoğunda PostgreSQL gibi farklı alternatifler de değerlendiriliyor(Hatta Shelby’nin veritabanının domain bazlı olarak parçalanmasından önce PostgreSQL’e geçişi ile ilgili deneysel çalışmalar yapılmakta. Üzgünüm Microsoft ama topyekün bakıldığında lisanslama maliyetlerin çok pahalıya gelebiliyor) Yeni nesil ürünler kendi Bounded Context’leri içinde konumlandırıldıklarından mikro servis yapısına daha uygunlar. Henüz mezun olmuş ya da birkaç yıllık iş tecrübesi bulunan geliştiricilerin aşina olduğu ve kolayca adapte olabileceği ortamlar.
Son zamanlarda geniş bir stajyer programı uygulanıyor. Özellikle uzun dönem stajyer arkadaşlar doğrudan okyanusa bırakılıyor ve aktif olarak müşteri isteklerinin karşılanması ile ilgili görevlerde çalışıyor.
İnsan Kaynakları ekibinin üniversitelere bizzat giderek iyi bir eleme programı uyguladığına inanmaya başladım gördüklerimden sonra. Şirket, çekirdekten yetiştirmenin meyvelerini günden güne alıyor.
Her Şeyin Farkında Olmalıyız (İzleme, Erken Tedbir ve Otomatikleştirme)
İster onyedi yaşındaki ERP ürünü olsun ister yeni doğmuş, emekleyen, yürümeye henüz başlamış yeni nesil ürünler, izleme(monitoring) her şeydir.
Her ne kadar erken uyarı sistemlerini tam olarak robotlaştıramasak da çalışma zamanında oluşan sıkışmaları görmek, hataları koda girmeden yakalayabilmek adına çeşitli araçlardan yararlanıyoruz. Shelby’nin dünyasını genellikle Riverbed üzerinden izliyoruz(Open APM ve HP Diagnostics kullanan ekipler de var) Yavaşlayan bir ekran varsa, ön yüz sayfa taleplerinden Data Access Layer metotlarına ve arka plandaki SQL çağrılarına giderek sorunu tespit etmemiz ve çözmemiz kolaylaşıyor. Yavaşlamaya başlayanlar genellikle yoğun iş kuralı içeren stored procedure’ler veya indeksleri bozulan tablolar oluyor(Veritabanı ekibiyle yapılan koordineli çalışma ile sorunlar bertaraf edilebiliyor ama kalıcı çözümler için bazı bazı kaynak sıkıntısı da yaşanıyor)
Rutin olarak yapılan işlerden birisi de sistemin yavaşladığı noktaları Riverbed veya muadili bir araç üzerinden yakalayıp nasıl çözebiliriz sorusuna cevap bulmaya çalışmak. Böylece uygulamanın gizli saklı tüm sırlarını görüyor, MSMQ yerine Apache Kafka veya RabbitMQ’ya geçmeliyiz gibi yorumlarda bulunabiliyoruz.
RiverBed ürününden bir ekran görüntüsü. Temsili.
Vakit ve belki de yeterli kaynak olsa bu ve benzer sorunları problem olarak sınıflayıp ITIL(Information Technology Infrastructure Library) felsefesinde geçen ilkelere göre kalıcı olarak çözmek çok da güzel olur.
Yeni nesil ürünlerin Elasticsearch tarafına atılan sayısız log verisini Kibana üstünden takip ediyoruz. Şu meşhur ELK üçlemesini ele aldığımızı ifade edebilirim. Bu log gerçekten çok büyük önem arz ediyor. Üretim ortamına ait sıkıntılı durumlarda kayıtlardaki izlere bakarak yazılıma müdahale bile etmeden çözümler üretebiliyoruz.
ElasticSearch içeriği daha güzel bir şekilde izlediğimiz Kibana'dan bir görüntü
Yeni şeyler ekledikçe ürünlerin kalitesini korumamız da lazım. Bunun için SonarQube’ye, güvenlik noktasındaki açıkların tespiti için Fortify’a başvuruyor, OWASP(Open Web Application Security Project) gibi standartlara bağlı kalmaya çalışıyoruz.
Yeni nesil ürünlerdeki en yakın dostumuz ise Chrome’un F12 tuşu. Ön yüzün arka taraftaki REST servislerine hangi tip çağrı ve payload bilgisi ile eriştiğini görmek, problem yaşanan durumlar için ilgili senaryoları local geliştirme ortamında kolayca tatbik edip çözüm bulmamızı kolaylaştırıyor. Senaryoları gerçekleştirirken ağırlıklı olarak Postman ve SOAP UI gibi araçlardan yararlanıyoruz.
REST Api tipindeki servisler her ne kadar popüler olarak kullanılsa da bazı ürünlerde yeni nesil gRPC protokollü versiyonları kullanmak ve hatta Event-Driven yaklaşımlara geçmek çok daha iyi olabilir.
Bazı işleri otomatik hale getirebiliyoruz. Kullanıcıların sıklıkla tekrarladığı aynı şeyleri RPA(Robotic Process Automation) süreçleri ile kontrol altına alıyoruz. Bu da şirket bünyesinde yaygınlaştırılmaya çalışan bir alan. Sonuçta önemli bir zaman ve maliyet kazancı olacağı ortada.
Vizyon
Kurumsal boyuttaki uygulamaların yenilenmek üzere tekrardan masaya yatırılması sıklıkla gündeme gelir. Sadece yeni isteklerin karşılanması değil baş ağrılarının giderilmesi ve modern çağa uymak için bu gereklidir. Bu nedenle somut ve cesaret isteyen adımlar atılmalıdır. Bu kararlılığı bir veya iki kişinin ya da bir takımın göstermesi yetmez. Konunun müşteri ile tartışılabilecek ve sayısal veriler ile desteklenebilecek şekilde en üst yönetim kadrosu tarafından da benimsenmiş olması beklenir. İnsiyatif alma isteği uyandıracak iç motivasyon unsurları önemlidir. Ancak hepsi bir yana bir teknoloji vizyonunun olması şarttır. Hangi durumdayız, nereye gitmek istiyoruz, bu yolda ilerlemek için hangi teknolojileri mercek altına almalıyız, kısa vadede hangi kararları uygulamalı uzun vadeye ne şekilde yaymalıyız…
Şahsen bulunduğum mavi teknoloji firmasının gerek bir önceki gerek şu anki yazılım grup müdürleri bir eylem planı oluşturmak, radikal kararlar almak ve korkmadan bunları sahiplenmek konusunda oldukça cesaretliler. Karar verici mecradakilerin sahip olduğu vizyon ile değişimi desteklemeleri önemli bir mesele.
Geçtiğimiz yaz ayında yapılan bir toplantıda Shelby’nin modernizasyonu kapsamında aşağıdaki maddelerdekine benzer işlerin planlandığını ifade edebilirim.
- Web Site’ların ilk etapta Web Application’a çevrilmesi ve ilerleyen dönemlerde Blazor çatısına taşınması(Sıcak bir noktada)
- En kısa sürede DevOps ekibinin hazırız dediği Blue/Green dağıtım stratejisine geçilmesi.
- MSSQL veritabanının PostgreSQL dönüşümüne başlanması. Kısa vadede yoğun iş kuralları içeren SP’lerin EF tarafında karşılıklarının oluşturulma maliyetlerinin çıkartılması.
- Orta vadede bir ORM(Object Relational Mapping) kullanımına geçilmesi.
- Teknik borç hedeflerinin yerine getirilmesi hususunda devam eden Fortify, Sonarqube, Testinium çalışmalarının tamamlanması (Testinium üzerinde modül bazlı olarak given-when-then senaryoları yazılmaya başlandı)
- Platformda .Net Framework 4.8 versiyonuna geçilmesi ve kod içerisinde C# 8.0 destekli yeni kalite standartlarının adaptasyonu(Yazıyı tamamladığım tarih itibariyle bitmişti)
- N-Tier yapının 3-Tier formuna indirgenmesi.
- Performans ölçümlemede OpenAPM ürününe geçilmesi için gerekli çalışmalarının yapılması(ki geçildi)
- Servis bağımlılıkları sebebiyle duran WS-* transaction yapılarının terk edilerek farklı bir stratejinin kullanılmasına başlanması.
Buradaki bazı kararları değil almak düşünmenin bile çok zor olduğu kurumsal dünyalar olduğu aşikar.
Sonuç
Şüphesiz ki pek çok büyük oyuncunun dönüşmeye çalıştığı/dönüştürdüğü platformlar ile haşır neşir olduğumuz bir zaman dilimindeyiz. Yirmi yıl önceki dönüşümler tekrarlanıyor ve ileride de tekrarlanacak. Hatta daha kısa periyotlarla değişime adapte kalmamız gerekecek. Eğer şirketiniz aşağıdakileri yapıyorsa ciddi anlamda değişimi düşünmek gerekebilir.
- Programa eklenen ve müşteri testi yapılmış yeni bir özellik için üretime çıkış gününü bekliyoruz.
- Geliştirdiğimiz ve üretime aldığımız özelliklerin müşteri için oluşturduğu katma değeri bilmiyor/ölçümleyemiyoruz.
- Az zamanımız olduğu için bazı testleri atlamak zorunda kalıyoruz.
- Üretim ortamında oluşan bir sorunu çözmek için kullandığımız tekniğe onu düzeltmek için tekrar dönme fırsatı bulamıyoruz.
- Temel kod metriklerini aşan devasa sınıflar ve veritabanı nesneleri üzerinde hata ayıklama işlemleri yapıyoruz.
- Sahip olduğumuz ürünün ne kadar büyük bir teknik borcu olduğunu bilmiyoruz.
Bu dünyada birbirinden farklı eski-yeni bir çok teknolojiyi bir arada görüyoruz. Yeni nesil araçlar sayesinde önceden önlemlerimizi almak, teknik borçlanma gibi konuları bertaraf etmek, her noktasını test ettiğimizden emin olduğumuz ürünleri sürümlemek artık çok daha kolay. Hazırlıklarımızı buna göre yapmalı ve kendimizi sürekli geliştirmeliyiz.
Yazıda bahsettiğim ne kadar şey varsa sadece bulunduğum ERP uygulaması ve çevresindeki gelişmelerden ibaret. Robotik süreç otomasyonu(RPA-Robotic Process Automation), yapay zeka, makine öğrenimi, IoT(Eşyanın Interneti), finansman, sigorta, filo, raporlama vb işlerle uğraşan daha pek çok ekip var ve hepsi bu büyük ekosistemin bir parçası olarak gelişimini sürdürüyor.
Bahsedilen Terimler
Yazı boyunca aşağıdaki listede yer alan terimlerden bahsettim. Eminim ki bir çoğuna aşinasınız ama çoğunu da bilmiyorsunuz. Bildiklerinizi de iyi bilip bilmediğiniz konusunda tereddütleriniz var. Bu yüzden bilmedikleriniz dahil var olanları da araştırıp pekiştirmenizi, üzerlerine eklenecek yeni daha neler olduğunu sürekli araştırmaya devam ederek canlı kalmanızı tavsiye ederim. Benim sekiz saatlik sonsuz döngüm neredeyse her gün bu şekilde işliyor. Zamansal paradox yaratarak oturduğum yerde kara delik açan bu cümle ile yazıma son veriyorum. Hepinize mutlu günler dilerim.
#agile #scrum #sprint #storyPoint #safe #workItem #dotNet #dotNetCore #nodeJs #typescript #vue #angular #erp #monolithic #legacySystem #nTier #SOA #SOAP #REST #WCF #sonarQube #codeCoverage #technichalDepth #qualityAssurance #mssqlServer #postgreSql #gitFlow #vsts #tfs #azureDevOps #branch #fortify #owasp #roslyn #CI/CD #continuousIntegration #continuousDelivery #continuousDeployment #dockerize #container #microService #kong #riverBed #ITIL #CAB #antiPattern #godObject #boundedContext #dataAccessLayer #chromeDevTools #thoughtWorks #microService #hypeTech #techRadar #SSIS #IoT #yapayZeka #robotik #postman #soapUI #rpa