Önceki makalemde, yapay zeka gereksinim tanımlamasının mevcut durumunu—sürecin 'düzenlemekten' 'karar vermeye' nasıl kaydığını ve birçok işyerinin bu değişimin farkına varmadan düşüncelerini körü körüne dışarıya devrettiği endişemi yazmıştım.
Bu sefer, ilgili bir konuda başka bir alarm daha vermek istiyorum.
Sorun şu ki, CTO'lar ve dahili SE'ler, AI destekli geliştirme sayesinde artık çok hızlı kod yazabildikleri için, iş birimlerinin sadece sipariş alıcısı haline geliyorlar—yani 'dahili SI'cılar.'
AI Destekli Geliştirmenin Yarattığı Yeni Dinamikler
AI destekli geliştirmenin yaygınlaşmasının kodlama bariyerini çarpıcı biçimde düşürdüğü yadsınamaz bir gerçek.
Sonuç olarak, iş birimlerinden 'bunu istiyorum' veya 'bunu sistematize etmek istiyorum' gibi talepler daha önce benzeri görülmemiş bir hızla geliyor. İş çalışanlarının AI kullanarak gereksinimleri kendilerinin listelemesi, hatta prototipler oluşturması artık nadir bir durum değil.
İlk bakışta bu iyi bir şey gibi görünüyor. İş birimlerinin DX'e öncülük ettiği ve sistemleri hızlıca başlatmak için BT ile işbirliği yaptığı ideal bir senaryo gibi duruyor.
Ancak burada bir tuzak var.
Giderek daha fazla CTO ve dahili SE'nin 'sadece iş birimlerinden gelen taleplere şekil veren kişiler' haline geldiğini hissediyorum. Bir talep alıyorlar, teknik olarak gerçekleştiriyorlar ve teslim ediyorlar. Bu tam olarak bir dahili SI'cının yaptığı şeydir.
Sipariş Almanın Sonunda Bizi Bekleyen Şey
İş taleplerine yanıt vermek kendi başına yanlış değil. Sorun, her bir departmanın talebini olduğu gibi yerine getirmeye devam ettiğinizde ne olduğu.
Ben buna 'başıboş sistemler' ve 'başıboş veritabanlarının' çoğalması diyorum.
Satış kendi CRM'ini oluşturur, Pazarlama ayrı bir veri analiz platformu kurar ve Müşteri Desteği kendi bilet yönetimini inşa eder. Her departman, işlerine göre optimize edilmiş bir sistemi yüksek hızda aldıkları için memnundur.
Peki ya şirketin tamamı?
Veriler farklı yerlere dağılmıştır ve formatlar birleşik değildir. Aynı müşteri bilgisi birden fazla veritabanında farklı biçimlerde bulunur. Departmanlar arasında veri bağlamaya çalıştığınızda, manuel çalışma veya özel geliştirme gerekir.
Bu bir teknik silodur.
AI destekli geliştirme sistem kurmayı çok kolaylaştırdığı için, bu silolaşma benzeri görülmemiş bir hızda ilerler. Daha önce, yüksek geliştirme maliyetleri doğal bir fren görevi görüyordu. 'İnşa etmesi zor, o halde sadece gerçekten gerekli olanı sıkı bir şekilde seçelim' dinamiği vardı.
Şimdi o fren gitti. İnşa edilebildiği için inşa ediliyor. Sonuç olarak, başıboş sistemler ve veritabanları çoğalıyor ve yönetilmesi gereken uygulama ve altyapı sayısı sürekli artıyor.
Bunun AI Çağında Neden Ölümcül Olduğu
'Sistemler biraz dağınık olsa da çalıştıkları sürece sorun yok' diye düşünebilirsiniz. Ancak AI çağında bu silolaşma, daha önce hiç olmadığı kadar ölümcül sorunlara neden oluyor.
Sebebi basit: AI'nın değeri, veri entegrasyonunun derecesiyle orantılıdır.
AI, gerçek gücünü veriler tüm şirket genelinde entegre edildiğinde ve departmanlar arası kapsamlı içgörülere olanak tanıdığında gösterir. Yalnızca satış verileri, müşteri geçmişi, pazarlama etkileri ve finansal veriler entegre edildiğinde AI, yönetim kararlarına yardımcı olacak içgörüler sağlayabilir.
Başıboş sistemlerle dolu bir ortamda, veriler en baştan bağlı değildir. Departmanlar içinde küçük AI optimizasyonları elde edebilirsiniz, ancak gerçekten iş etkisi yaratan, şirket çapında AI kullanımına asla ulaşamazsınız.
Departman optimizasyonlarını biriktirerek, toplam optimizasyonu kalıcı olarak kaybedersiniz. Sipariş alan CTO'ların ve dahili SE'lerin farkında olmadan yarattığı risk budur.
CTO'ların ve Dahili SE'lerin Oynaması Gereken Gerçek Rol
Peki, CTO'lar ve dahili SE'ler nasıl olmalı?
Cevap açık: Sadece 'inşa edenler' değil, 'tasarımcılar ve karar vericiler' olun.
Buradaki 'tasarım', bireysel sistemleri tasarlamak anlamına gelmez. Tüm şirket için veri ve sistem mimarisini tasarlamak anlamına gelir.
Bir iş biriminden bir talep geldiğinde, sadece inşa etmek yerine, 'bu talebin şirket çapındaki mimari içinde nasıl konumlandırılması gerektiğini' yargılarsınız. Bazı durumlarda, 'Bu bireysel olarak inşa edilmemeli' demek zorunda kalırsınız. Mevcut platformlar genişletilerek halledilebiliyorsa, oraya yönlendirirsiniz.
Bu, iş birimleri için zahmetli görünebilir. 'Ben sadece bunun şimdi inşa edilmesini isterken neden tüm şirketten bahsediyorsun?' diye sorabilirler.
Ancak bu yargıyı yalnızca CTO'lar ve dahili SE'ler yapabilir. İş birimlerinin kendi alanlarını optimize etme teşvikleri vardır, ancak şirket çapındaki mimariyi koruma teşvikleri yoktur. Bu nedenle teknik uzmanlar, toplam optimizasyonun koruyucuları rolünü oynamalıdır.
'İnşa Etmeme Kararı' En Yüksek Teknik Beceridir
İronik bir şekilde, AI çağında CTO'lardan ve dahili SE'lerden istenen en önemli beceri 'inşa etmeme kararı' olabilir. Bu yüzden onlara 'karar vericiler' diyorum.
Bir iş biriminden bir talep gelir. Teknik olarak mümkündür. AI ile birkaç gün içinde şekillendirilebilir. Ancak, bunu inşa etmenin tüm şirket için gerçekten doğru olup olmadığını sorgulama gücüne sahip olmalısınız.
Bu talep mevcut platformlar tarafından karşılanabilir mi? Veri yapısı şirket kurallarına uygun mu? Benzer bir sistem başka bir departmanda zaten çalışıyor mu? Bireysel olarak optimize edilmiş bir sistem eklemek, gelecekteki veri entegrasyonunu zorlaştıracak mı?
Bu soruları sorabilmek, AI çağında gerçek teknik güçtür.
Kodlamayı AI halledecek. Ancak, neyin inşa edilip neyin inşa edilmeyeceğine karar vermek AI'nın yapamayacağı bir şeydir. Önceki makalede 'gereksinim tanımlamanın bir karar verme süreci haline geleceğini' belirttiğim gibi, CTO'ların ve dahili SE'lerin rolü de tamamen aynı yapıyı izler.
Sipariş alıcısı olmaktansa, şirket çapındaki mimarinin tasarımcıları olarak rolünüz, AI çağı sayesinde giderek daha önemli hale geliyor.
Gelecek Tahmin Edilemez Olduğu İçin 'Hazır Olma Durumu' Yaratmak
'İnşa etmeme kararının' önemini vurgulamış olsam da, CTO'ların ve dahili SE'lerin sahip olması gereken bir bakış açısı daha var.
AI çağında gelecek tahmin edilemez olduğu için, şirketi her an harekete geçebilecek bir durumda tutmalısınız.
Şu anda, 'SaaS Öldü' söylemi yayılıyor. Microsoft CEO'su Satya Nadella'nın 2024'ün sonlarında bu sözleri söylemesinden bu yana, birçok kişi SaaS'ın sonunu tahmin ediyor. Gerçekten de SaaS değerlemeleri sıkışıyor ve yatırımcı ilgisi hızla AI odaklı platformlara kayıyor.
Peki SaaS gerçekten ölüyor mu?
Bunun o kadar basit olduğunu düşünmüyorum. SaaS şirketleri, AI çağı için en uygun yazılım biçimini bulmak amacıyla Ar-Ge'ye büyük yatırım yapıyor. Ajan AI entegrasyonu, sonuç bazlı faturalandırma, sektöre özel AI platformları... Şu anda hayal edemediğimiz biçimlerde ürünlerin ortaya çıkma olasılığı yüksek.
Başka bir deyişle, hem 'SaaS öldü' sonucuna varıp şirket içi geliştirmeye atılmak, hem de 'SaaS yeterli' diyerek düşünmeyi durdurmak risktir.
Bir CTO/dahili SE'nin alması gereken duruş, birine veya diğerine bahse girmek değildir. İşler hangi yöne dönerse dönsün yanıt verebilecek bir mimari tasarlamaktır.
Spesifik olarak, verilerin nasıl tutulduğunu standartlaştırın ve belirli bir SaaS veya araca kilitlenmeyen bir yapı oluşturun. Sistem bağlantılarını API'ler aracılığıyla gevşek bir şekilde bağlı tutun. Başıboş sistemlerin çoğalmasına izin vermeyin; şirketin veri temelini birleştirin.
Bu tasarım felsefesiyle, SaaS gelişir ve daha iyi ürünler çıkarsa geçiş yapabilirsiniz. Tersine, belirli bir alan için şirket içi geliştirmenin daha iyi olduğu netleşirse oraya taşınabilirsiniz.
Geleceği tahmin edemezsiniz. Ancak ona yanıt verebilecek bir yapı oluşturabilirsiniz. AI çağında CTO'lardan ve dahili SE'lerden istenen mimari tasarımın özü budur. Tersine, bunu yalnızca teknik uzmanlar yapabilir. Bu değerli kaynakları bir dahili SI'cı olarak harcamanızı istemiyorum.
AI ile Yukarı Akış Süreçlerini Hızlandırmak
Yukarı akış süreçlerinin dönüşümünü destekleyecek bir araç olarak, bir ekran tanımı ve mock oluşturma AI aracı olan 'GEAR-UI'yi OSS (Açık Kaynak Yazılım) olarak yayınladık.
OSS yaparak, kullanıcıları uygulama engellerinden kurtarmayı ve öze odaklanmalarına yardımcı olmayı umuyoruz. Lütfen bunu özellikle tartıştığım 'inşa öncesi' yargılar için kullanın.
Özelleştirme ücretsizdir. Lütfen bundan yararlanın.
