Low-code ne zaman yetmez? Platformdan çıkma kararını veren beş sinyal

Low-code platformu yetmemeye başladığında bunu önce fatura, sonra kota hataları, en sonunda da geliştirme hızı söyler. Üç sıkışma noktası var: platformun kotaları, kullanım arttıkça büyüyen lisans bedeli ve kuralların platformun ifade edebildiği sınırı aşması. Dördüncü bir nokta daha var ve en geç fark edileni odur, çıkış maliyeti. Karar vermek için uygulamanın durmasını beklemeyin. Aşağıdaki beş sinyalden ikisi aynı anda görünüyorsa, o uygulamanın bir sonraki yılını nerede geçireceğini bugün konuşun.

Önce platformların hakkını verelim

İç kullanıma dönük, dar kapsamlı işlerde low-code gerçekten hızlıdır. Bir form, bir tablo, bir onay adımı ve bir bildirimden oluşan talep yönetimi uygulaması iki haftada ayağa kalkar. Aynı işi sıfırdan yazmak, kimlik doğrulamadan dağıtım hattına kadar her şeyi kurmayı gerektirdiği için iki ay sürer. Yirmi otuz kişinin kullandığı, ömrü bir iki yıl olan, veri hacmi küçük bir araç için bu iki ayı harcamak çoğu zaman israftır.

Platformların en güçlü olduğu yer, şirketin Excel'de yürüttüğü süreçlerin ilk durağı olmak. Excel'den yazılıma geçerken aradaki basamağı low-code doldurur: süreç netleşir, alanlar oturur, kimin ne yaptığı belli olur. Sorun, o basamağın kalıcı ev sanılması.

Birinci sinyal: kota duvarına yaklaşıyorsunuz

Low-code platformlarının sınırları belgelenmiştir ve genelde kimse okumadan imzalar. Airtable'da kayıt limiti taban (base) başınadır ve o tabandaki bütün tablolar aynı havuzu paylaşır: ücretsiz planda 1.000, Team planında 50.000, Business planında 125.000 kayıt. Tabloları bölmek işe yaramaz, çünkü sayaç taban seviyesinde işler.

Microsoft tarafında iki ayrı limit katmanı var ve ikisi birbirinden bağımsız sayılır. Hak edişe dayalı (entitlement) limit lisansa bakar: Power Platform ve Dynamics 365 ücretli lisansları kullanıcı başına 24 saatte 40.000 istek alır, Power Apps per-app lisansları, kullandıkça öde planı ve Power Platform erişimi içeren Microsoft 365 lisansları ise 6.000 istek alır. Üstüne servis koruma limitleri gelir: kullanıcı başına, beş dakikalık kayan pencerede 6.000 istek, 1.200 saniye birleşik yürütme süresi ve 52 eşzamanlı istek. Aşarsanız sistem 429 döner ve Retry-After başlığıyla ne kadar bekleyeceğinizi söyler.

Bu rakamların pratikteki anlamı şu: gece çalışan büyük toplu işler bu mimaride iyi gitmez. İstekleri toplu (batch) göndererek sayıyı düşürmek de hak ediş limitini atlatmaz, çünkü Microsoft dokümanı bu yolu açıkça kapatıyor ve toplu istekler yürütme süresi limitine daha hızlı tosluyor. Microsoft'un kendi tavsiyesi, periyodik büyük işlerden gerçek zamanlı entegrasyona geçmek. Kuyruğa aldığınız gece işinin sabah yarım kalmasını bir kez yaşayan ekip, bu cümleyi farklı okur.

İkinci sinyal: fatura kullanıcı sayısıyla değil, kullanımla büyüyor

Satın alma kararı verilirken bakılan rakam genelde kullanıcı başına aylık ücrettir. Asıl soru başka: faturalandırma birimi ne ve bu birim işiniz büyüdükçe büyüyor mu?

Üç model var. Koltuk başına ücretlendirme tahmin edilebilir, çünkü ekip büyüdükçe artar. Kayıt ya da depolama başına ücretlendirme, veriniz biriktiği için artar ve eski veriyi silmediğiniz sürece asla düşmez. Üçüncüsü en kaygan olanı, çalışma birimi başına ücretlendirme. Bubble'ın "workload unit" ölçüsü sayfa yüklemelerini, veri tabanı aramalarını, dosya yüklemelerini ve zamanlanmış akışları sayar. Yani uygulamanız popüler olduğu için pahalılaşır. Plan kotasını aştığınızda ek kullanım faturaya yansır.

Pratik kontrol şu: mevcut faturanızı kullanıcı sayısına değil, işlem hacmine bölün. Sipariş başına, talep başına, kayıt başına maliyet çıkarın. Sonra bu sayıyı iki yıl sonraki hacimle çarpın. Bulut maliyetlerinde olduğu gibi, buradaki sürpriz de hep aynı yerden gelir: birim maliyet küçük göründüğü için kimse çarpmayı yapmaz.

Üçüncü sinyal: mantık, platformun ifade edebildiğinin ötesine geçti

Bu sinyal faturada görünmez, ekibin konuşmasında görünür. "Bunu değiştirirsek başka ne bozulur bilmiyorum" cümlesi duyulmaya başladıysa sınırdasınız demektir.

Sebebi teknik ve basit. Kodda bir değişikliğin ne yaptığını diff gösterir, otomatik testler doğrular, inceleme süreci ikinci bir göz koyar. Görsel editörde bu üçü de zayıftır. İki ay önceki hâliyle bugünkü hâli arasındaki farkı satır satır göremezsiniz, karmaşık iş kuralına otomatik test yazmak çoğu platformda ya mümkün değildir ya da ayrı bir ürün satın almayı gerektirir. Uygulama üç dört kritik kuralı geçtiğinde değişiklik korkusu başlar ve o korku, teknik borcun görsel araçlardaki karşılığıdır.

Ayrım için işe yarayan bir ölçüt: uygulama tek bir sistemde, tek bir kaydı yönetiyorsa platform rahat taşır. Aynı anda üç sistemde tutarlılık gerektiren, para hesaplayan, geriye dönük denetim izi tutması gereken işler ise platformun doğal olarak iyi olmadığı yerler.

Dördüncü sinyal: çıkış planınız yok

Bu maddeyi satın almadan önce sormak gerekir, çıkmaya karar verince değil. Bubble'ın kendi dokümanı net yazıyor: uygulamalar yalnızca Bubble platformunda çalışır ve uygulamayı kod olarak dışarı aktarmanın bir yolu yoktur. Verinizin ve tasarımınızın sahibi sizsiniz, uygulamayı çalıştıran kodun sahibi Bubble. Veriyi CSV olarak ya da API üzerinden dışarı alabilirsiniz, mantığı alamazsınız. Şirket kapanırsa kaynak kodu açık lisansla yayımlama taahhüdü var, bu da güzel bir taahhüt ama günlük operasyonda işinize yaramaz.

Buradan çıkan sonuç şudur: low-code uygulamasını taşımak, veri taşıma işi değil yeniden yazma işidir. Veri tarafı zaten taşınabilir; asıl kayıp, yıllar içinde ekranlara ve akışlara gömülmüş kuralların hiçbir yerde yazılı olmamasıdır. Sözleşmeyi imzalarken üç soruyu sorun: Veriyi hangi formatta, hangi sıklıkta ve otomatik olarak alabiliyor muyum? Uygulama mantığının insan okuyabilir bir dökümü var mı? Hesabım kapanırsa verime kaç gün erişebiliyorum?

Beşinci sinyal: hangi uygulamaların çalıştığını kimse bilmiyor

Low-code'un en büyük faydası, yazılımcı olmayan kişilerin uygulama yapabilmesi. En büyük riski de aynı cümle. OWASP'ın bu alandaki listesi başlangıçta Low-Code/No-Code Top 10 adıyla çıktı, sonra yapay zekâ destekli geliştirmeyi de kapsayacak şekilde Citizen Development Top 10 adını aldı. Liste on madde, sahada en çok karşılaşılanlar birkaç tanesi.

CD-SEC-02, hesap taklidi. Çoğu platformda bir akış, onu tetikleyen kişinin değil, bağlantıyı kuran kişinin kimliğiyle çalışır. Finans müdürünün kurduğu bir onay akışını iki yüz kişiyle paylaştığınızda, o iki yüz kişi finans müdürünün yetkileriyle veriye dokunmuş olur. CD-SEC-03, yetki kötüye kullanımı; platformun paylaşım ayarı ile arkadaki sistemin yetkilendirme modeli birbirini tanımaz. CD-SEC-09, varlık yönetimi eksikliği; yani kimsenin envanterinde olmayan, yapanın şirketten ayrıldığı, hâlâ üretim verisine bağlı uygulamalar. Bu sonuncusu onaysız yapay zekâ kullanımıyla aynı kökten gelir: araç ne kadar kolaysa, BT'nin haberi olmadan yapılan iş o kadar çoktur.

Çözüm platformu yasaklamak değil, görünür kılmak. Üretim verisine bağlanan akışların kişisel hesap yerine servis hesabı kullanması, uygulamaların bir envanterde sahibiyle birlikte durması ve en az geliştirme ile üretim ortamının ayrılması, çoğu platformda bir günlük yönetim işidir.

Hibrit kurgu: veriyi ve kuralları platformun dışında tutun

Bir uygulamanın yıllarca yaşayacağını düşünüyorsanız, platformu arayüz ve akış katmanı olarak kullanın, kayıt sistemi olarak değil. Veri kendi veri tabanınızda dursun, iş kuralları kendi API'nizin arkasında çalışsın, low-code tarafı bu API'yi çağırsın. Böylece platform değiştirmek ekranları yeniden yapmak demek olur, şirketin bilgisini yeniden keşfetmek demek değil.

Bunun bedeli var: bu kurgu gerçek geliştirme gerektirir, yani low-code'un vaat ettiği hızın bir kısmından vazgeçersiniz. O yüzden her uygulamaya uygulanmaz. Ayrımı basit tutun: ömrü belli ve kısa olan, veriyi sadece okuyan araçlar tamamen platformda kalsın; şirketin para kazandığı sürece dokunan her şey dışarıda bir çekirdeğe yaslansın.

Geçiş kararı verildiyse, tek seferde değil akış akış

Yeniden yazma projelerinin klasik hatası, çalışan bir sistemi kapatıp altı ay sonra yenisini açmaya çalışmak. En çok acıtan tek akıştan başlayın. O akışı kendi kodunuza taşıyın, low-code uygulaması aynı veriyi okumaya devam etsin, kullanıcı iki arayüzü bir süre birlikte kullansın. Sonra ikinci akış. Platformdaki uygulama bir noktada sadece okuyan bir rapor ekranına dönüşür ve kapatmak ayrı bir proje olmaktan çıkar.

Taşırken yapılacak ilk iş kod yazmak değil, mevcut kuralları yazıya dökmek. Ekranlardaki her koşullu alan, her otomasyon adımı, her gizlenmiş buton bir iş kuralıdır ve çoğu hiçbir dokümanda yoktur. Bu dökümü çıkarmadan başlayan ekip, aynı kuralları kullanıcı şikâyetleriyle tek tek yeniden öğrenir.

Bu hafta yapılabilecek somut iş

Bir tablo açın ve şirkette çalışan her low-code uygulamasını satır olarak yazın. Sütunlar: uygulama adı, sahibi, kullanıcı sayısı, bağlandığı sistemler, aylık maliyet. Sonra çoğu envanterde bulunmayan iki sütunu ekleyin: platform kotasının yüzde kaçı dolu ve bu uygulamadan çıkmak gerekirse plan ne.

İkinci sütunu boş kalan satırlar, risk taşıyan satırlardır. Kota doluluğu yüzde altmışı geçmiş ve çıkış planı boş olan bir uygulama varsa, sıradaki iş o. Hangi uygulamanın platformda kalması, hangisinin kendi kodunuza taşınması gerektiğine birlikte bakmamızı isterseniz, envanterinizi çıkardıktan sonra yazın.