Kurumsal yapılarda mimari kararlar iki şekilde bozulur: ya hiç yazılmaz (herkes farklı hatırlar), ya da aşırı süreçle boğulur (kimse hareket edemez). Benim yıllardır en verimli gördüğüm model, “hafif RFC” disiplinidir: kısa, zaman kutulu, sahipliği net ve karar izi bırakan bir süreç.
Hafif RFC neyi çözer?
Hafif RFC, özellikle şu alanlarda etkilidir:
- Platform standardizasyonu (logging, auth, network pattern’leri)
- Büyük değişiklikler (landing zone, segmentasyon, DR modeli)
- Güvenlik kırılımı olan kararlar (break-glass, key mgmt, secrets)
- Operasyon modelini değiştiren işler (on-call, rollout, incident)
Sürecin 4 kuralı
- Tek sahip: RFC’nin bir yazarı olur, “komite dokümanı” olmaz.
- Zaman kutusu: inceleme 3–5 iş günü gibi net bir pencere.
- Karar izi: kabul/ret/erteleme ve gerekçe tek yerde.
- Operasyon gerçekliği: sadece “mimari güzel” değil, runbook/ölçüm/rollback düşünülür.
RFC şablonu (tek sayfalık)
Benim önerdiğim şablon; kısa ama karar almak için yeterlidir:
- Problem: neyi çözüyoruz, neden şimdi?
- Kapsam: dahil/haric
- Seçenekler: 2–3 alternatif (artı/eksi)
- Öneri: seçilen yol ve gerekçesi
- Riskler: teknik + güvenlik + operasyon
- Maliyet: ekip zamanı, lisans, bakım
- Rollout/rollback: nasıl yayılır, nasıl geri alınır?
- Operasyon: alert, runbook, sahiplik
Bu şablonun gücü, herkesi aynı sorulara cevap vermeye zorlamasıdır.
İnceleme modeli: “review” değil “görüş + veto”
Hafif RFC’de herkesin onayı gerekmez. Ben daha net bir model tercih ederim:
- Görüş: herkes yorum bırakabilir (ör. 48 saat)
- Veto: sadece belirli roller (security, network, platform owner) veto hakkına sahip
- Karar: owner (veya teknik lider) kararı yazar ve kapatır
Bu model, hız ile risk kontrolü arasında iyi bir denge kurar.
Karar kaydı: RFC bitince ADR’ye düşür
RFC’nin çıktısı bir “karar kaydı”na dönüşmeli. Bu, ileride tutarlılığı korur:
- Seçilen yaklaşım
- Reddedilen alternatifler
- Tarih ve sahip
- Değişiklik koşulları (hangi sinyal değişirse tekrar bakarız?)
Süreç büyüdükçe RFC deposu, mimari hafızaya dönüşür.
En sık hata: RFC’yi proje planına çevirmek
RFC “nasıl yapacağız?”dan önce “ne yapacağız ve neden?” sorusuna cevap vermeli. Aksi halde doküman, task listesine döner ve etkisini kaybeder.
Hafif RFC disiplinini oturttuğunuzda şu dönüşümü görürsünüz: mimari kararlar daha az tartışmalı hale gelir, incident sonrası sürprizler azalır ve yeni gelen ekip üyeleri daha hızlı bağlanır.