Low-code/no-code yönetişimi; platform ve uygulama envanteri, maker kimliği, ortam stratejisi, veri bağlantıları, DLP politikaları, rol ve yetki, ALM, test, kritik uygulama sınıflandırması, destek ve emeklilik süreçlerini kapsar. Küçük ekip içi otomasyon ile finansal veya müşteri etkili kritik uygulama aynı kapıdan geçmemelidir. Merkezî CoE veya enablement ekibi standart, gözlem ve destek sağlar; iş birimi ise süreç, veri ve sonuç sahipliğini korur.
Low-code ve no-code, geliştirme sorumluluğunu ortadan kaldırmaz; dağıtır
Görsel bileşenler, hazır bağlayıcılar ve otomasyon araçları teknik bariyeri azaltır. İş kullanıcısı hızlı prototip ve uygulama üretebilir. Ancak veri modeli, erişim, hata yönetimi, entegrasyon, test, performans, destek ve yaşam döngüsü sorumlulukları devam eder. Üretim kolaylaştıkça kurumsal görünürlük ve sınıflandırma daha önemli hâle gelir.
| Yaklaşım | Tipik üretici | Yönetişim ihtiyacı |
|---|---|---|
| No-code | İş kullanıcısı ve süreç sahibi | Şablon, veri sınırı, maker eğitimi ve destek |
| Low-code | Citizen developer + profesyonel ekip | ALM, entegrasyon, test, kod inceleme ve mimari |
| Pro-code uzantı | Yazılım geliştirici | SDLC, güvenlik, bağımlılık ve sürüm yönetimi |
| AI ile üretim | İş ve teknik kullanıcı | Üretilen varlık, prompt, bağlayıcı ve izin doğrulaması |
En büyük risk görünmeyen uygulama ve bağımlılık birikimidir
Bir kişinin hesabına bağlı kritik akış, kişisel dosyadan beslenen uygulama, üretim verisini dış servise aktaran bağlayıcı veya sahibi ayrılmış uygulama operasyon kesintisi yaratabilir. Düşük kod, yanlış erişim veya veri sızıntısının etkisini azaltmaz.
Gölge uygulama
Uygulama, akış, bot ve bağlantılar merkezi ekipçe bilinmez.
Kontrolsüz bağlantı
Kurumsal veri kişisel hesap veya dış servise taşınır.
Tek kişiye bağımlılık
Maker ayrıldığında iş mantığı ve erişim kaybolur.
Test edilmemiş değişiklik
Üretimde doğrudan düzenleme kritik süreci bozar.
- Kişisel hesap ve paylaşılan parola kullanımı
- Üretim ile geliştirme ortamının karışması
- Geniş yetkili bağlantı ve servis hesabı
- Onaysız premium veya dış connector
- Kaynak tablo ve kolon değişikliğinin akışı bozması
- Log, alarm ve hata kuyruğunun olmaması
- Belgesiz iş kuralı ve gizli teknik borç
- Destek, yedek ve emeklilik planının bulunmaması
Kontroller uygulamanın etkisine göre kademelendirilmelidir
Her uygulamaya kurumsal yazılım projesi kadar ağır süreç uygulamak yeniliği durdurur. Her uygulamayı serbest bırakmak ise risk biriktirir. Risk sınıfı; veri hassasiyeti, kullanıcı sayısı, finansal ve müşteri etkisi, otomatik işlem yetkisi, regülasyon, entegrasyon ve kesinti etkisine göre belirlenebilir.
| Sınıf | Örnek | Asgari kontrol |
|---|---|---|
| Düşük | Kişisel görev veya ekip içi basit takip | Onaylı ortam, sınırlı veri, otomatik envanter |
| Orta | Bölüm içi iş akışı ve raporlama | İş sahibi, test, bağlantı ve yedek sahiplik |
| Yüksek | Müşteri, finans, insan kaynakları veya onay süreci | Ayrı ortam, DLP, güvenlik inceleme, ALM, destek |
| Kritik | Para hareketi, mevzuat, üretim veya güvenlik işlemi | Profesyonel geliştirme, bağımsız test, süreklilik ve değişiklik kurulu |
Risk sınıfı uygulamanın büyümesiyle değişmelidir. Başlangıçta ekip içi olan çözüm yüzlerce kullanıcıya veya müşteri işlemine açıldığında yeniden değerlendirilmelidir.
Ortam ve kimlik stratejisi üretim sınırını belirler
Varsayılan ortamda kontrolsüz üretim yerine kişisel verimlilik, bölüm geliştirme, kurumsal geliştirme, test ve üretim ortamları ayrılabilir. Ortam oluşturma, premium connector, özel connector, gateway ve paylaşım yetkileri rol bazlı yönetilmelidir.
| Kontrol | Karar | Kanıt |
|---|---|---|
| Maker kimliği | Kim uygulama üretebilir? | Rol, eğitim ve onay kaydı |
| Ortam | Hangi risk düzeyi hangi ortamda? | Ortam politikası ve sahip |
| Paylaşım | Kim kullanıcı veya ortak sahip olabilir? | Grup ve uygulama rolü |
| Servis hesabı | Akış bireysel hesaptan bağımsız mı? | Yönetilen kimlik ve rotasyon |
| Admin | Ayrıcalıklı yetki nasıl izlenir? | JIT erişim ve audit izi |
DLP ve bağlantı politikaları veri akışını sınırlar
Kurumsal bağlayıcılar, kişisel servisler ve yasaklı bağlantılar sınıflandırılmalıdır. DLP politikası yalnız connector adına bakmamalı; verinin sınıfı, işlem yönü, ortam ve kullanım amacıyla birlikte tasarlanmalıdır. Özel connector ve HTTP çağrıları ayrıca gözden geçirilmelidir.
- Hangi veri kaynakları üretimde kullanılabilir?
- Kurumsal ve kişisel connector birlikte kullanılabilir mi?
- Dosya, e-posta ve mesajlaşma çıkışları nasıl sınırlanır?
- API anahtarı ve secret nerede tutulur?
- Gateway ve on-prem bağlantı kimin sorumluluğunda?
- AI modeli veya dış servise hangi veri aktarılır?
- Log ve hata içeriği hassas veri taşıyor mu?
- Veri saklama ve silme politikası nasıl uygulanır?
Kritik uygulamalar için ALM ve test zorunludur
Geliştirme, test ve üretim ayrımı; çözüm paketleme, sürümleme, bağımlılık, environment variable, secret ve deployment pipeline ile desteklenmelidir. Üretimde doğrudan düzenleme yalnız kontrollü acil durum süreciyle mümkün olmalıdır.
| Kapı | Kontrol | Kritik uygulama kanıtı |
|---|---|---|
| Tasarım | Süreç, veri ve risk sınıfı | Onaylı çözüm kaydı |
| Geliştirme | Standart bileşen ve erişim | Çözüm paketi, kod ve bağımlılık |
| Test | Fonksiyon, yetki, hata ve performans | Test sonucu ve iş sahibi kabulü |
| Yayın | Pipeline, sürüm ve geri alma | Deployment kaydı |
| İşletim | Log, alarm, kapasite ve destek | SLA ve sahiplik |
| Emeklilik | Veri, bağlantı ve lisans kapanışı | Arşiv ve silme kaydı |
CoE kontrol merkezi değil enablement ve gözlem kapasitesi olmalıdır
Center of Excellence veya Center of Enablement; platform standardı, envanter, risk politikası, şablon, eğitim, destek ve yeniden kullanılabilir bileşen sağlar. İş birimi süreç ve sonuç sahipliğini korur. Kritik uygulamalar profesyonel geliştirme ve güvenlik ekipleriyle ortak yürütülür.
- Platform kullanım amacını ve yasaklı alanları tanımlayın.
- Ortam, DLP ve kimlik taban çizgisini kurun.
- Tüm uygulama, akış, bot ve connector envanterini otomatik toplayın.
- Risk sınıflandırması ve yükseltme kurallarını yayımlayın.
- Maker eğitim, mentorluk ve onaylı şablon programı kurun.
- Kritik uygulamalar için ALM, test ve destek kapılarını uygulayın.
- Sahipsiz, kullanılmayan veya riskli varlıkları düzenli inceleyin.
- İş sonucu, kalite ve risk göstergelerini birlikte ölçün.
Senaryo: Satın alma onay uygulaması kritik sürece dönüşüyor
Bir ekip, düşük kodla teklif toplama ve onay uygulaması geliştirir. Başlangıçta on kullanıcı ve hassas olmayan veri vardır. Zamanla uygulama bütçe kontrolü, tedarikçi banka bilgisi, sözleşme ve ERP entegrasyonu taşır. Risk sınıfı yükseldiği için kişisel maker hesabından servis kimliğine geçilmeli; ayrı üretim ortamı, DLP, görev ayrılığı, audit log, test, yedek ve destek modeli kurulmalıdır. Gerekiyorsa uygulama profesyonel ekibe devredilir.
Başarı uygulama sayısıyla değil güvenli ve sürdürülebilir değerle ölçülür
| KPI | Ne ölçer? | Yanlış yorum |
|---|---|---|
| Aktif ve sahipli uygulama | Kullanılan varlıkların sorumluya bağlı olması | Toplam uygulama sayısı |
| Risk sınıfı uyumu | Kontrol kapılarının doğru uygulanması | Hiç yüksek risk olmaması |
| Değer süresi | İhtiyaçtan güvenli yayına süre | En hızlı prototip |
| Operasyon kalitesi | Hata, kesinti, destek ve geri alma | Yalnız kullanım sayısı |
| Yeniden kullanım | Onaylı bileşen ve şablon kullanımı | Kopyalanan uygulama sayısı |
| Emeklilik | Sahipsiz ve gereksiz varlıkların kapanması | Sıfır silme hedefi |
Kaynaklar ve gözden geçirme notu
Bu rehberde değişebilir veya teknik iddialar için öncelikle resmî kurum, ürün geliştiricisi ve birincil araştırma kaynakları kullanılmıştır. Bağlantılar 27 Temmuz 2026 tarihinde gözden geçirilmiştir.
- 01Microsoft Learn — Power Platform Governance Strategy
Power Platform kullanımında politika, yönetim, güvenlik, ortam ve operasyon yönetişimi yaklaşımını açıklar.
- 02Microsoft Learn — Establish a Power Platform Center of Excellence
CoE yapısında yönetişim, standart, eğitim, destek ve ölçüm sorumluluklarını tanımlar.
- 03Microsoft Learn — CoE Starter Kit Overview
Low-code varlık envanteri, gözlem ve yönetişim için örnek kurumsal yetenek setini açıklar.
- 04Google Cloud — AppSheet Automation
Citizen-led no-code otomasyonla birlikte IT governance ve güvenlik gereksinimlerini vurgular.
- 05CISA — Secure by Design
Yazılım ürünlerinin güvenliği kullanıcıya yüklemek yerine tasarım ve varsayılan ayarlara gömme ilkesini açıklar.