Discovery’den Mimari Karara Vaka Bağımlılıkları

Arven Holding'in açıklanmış dosyası yalnız yaklaşık çalışan sayısı, iki lokasyon, mevcut sanallaştırma/yedekleme ailesi, altyapı yaşı ve modernizasyon değerlendirmesini taşır. Buradan otomatik olarak 'yeni storage alınmalı' sonucu çıkmaz. İkinci vaka dersinde bir olası görüşme senaryosu kullanacağız: operasyon ekibi sabah raporlarının geciktiğini söylüyor. Bu ifade alıştırma girdisidir; Arven'in onaylı başlangıç gerçeği değildir. Önce gecikmenin hangi iş kararını, kaç kullanıcıyı ve hangi zamanı etkilediğini sor. Rapor gerçekten kritik mi, yoksa alışılmış bir tercih mi? Gecikme veri girişinden mi, uygulama işleminden mi, ağdan mı kaynaklanıyor? GOV.UK discovery rehberi önceden verilmiş çözüm önerisini problem olarak yeniden çerçevelemeyi ve varsayımları parçalamayı anlatır. Kamu hizmeti örneğini doğrudan Arven şartı yapmıyoruz; 'önce problemi anla' yöntemini kullanıyoruz. Yaklaşık 29 dakika anlatı, 30 dakika vaka bağımlılık çalışması ve 15 dakika kontrol planla. Çıktın iş sonucu–gereksinim–kanıt–mimari seçenek zincirinin ilk sürümüdür.

Görüşme öncesi bildiklerini kartlara ayır. KNOWN: mevcut açıklanmış olgular ve kaynakları. UNKNOWN: rapor süresi, veri hacmi, büyüme, hata alanı, lisans ve bütçe. ASSUMED: 'depolama darboğazı olabilir' gibi araştırma hipotezi; bu bir müşteri gereksinimi değildir. TBD: ölçümü kim, hangi tarihe kadar paylaşacak? Sorular katmanlı olmalı: hangi rapor; hangi iş kararı; bugünkü akış ve ölçülen gecikme; ne zaman kritik; rapor geç kalırsa ne olur? Sadece IT yöneticisini dinleme; raporu kullanan iş rolünü, işletim ekibini ve bütçe sahibini ayrı sor. Aynı kelime farklı sonuç demek olabilir. 'Performans' kullanıcı yanıt süresi, batch bitişi veya rapor tazeliği anlamına gelebilir. Her yanıtın konuşan rolünü, tarihini, belge/tutanak bağını ve teyit durumunu kaydet. Görüşme notunda 'müşteri istedi' yazmadan önce gerçekten yetkili bir talep mi, paydaş tercihi mi, çözüm hipotezi mi ayır. Bu temizlik olmadan mimari karşılaştırma hatalı ölçüye dayanır.

Discovery'den gelen cümleyi hemen teknik şartname satırına dönüştürme. Önce iş sonucu, ölçü, kapsam, koşul ve yetkili kaynak belirle. Örnek alıştırmada 'sabah raporu iş günü başlamadan hazır olmalı' ifadesi bir aday gereksinimdir; hangi rapor, kaç kayıt, hangi saat dilimi, tatil günü ve başarısızlık toleransı teyit edilmeden kabul kriteri değildir. NASA Systems Engineering Handbook üst ihtiyaçla iki yönlü gereksinim izini ve varsayımların baseline öncesi doğrulanmasını vurgular. NASA'nın uzay sistemi kuralları Arven alım prosedürü değil; öğretici izlenebilirlik ilkesi olarak kullanılır. Her aday gereksinime ID, müşteri cümlesi, kaynak, statü, iş önemi, ölçü, test ve owner ekle. Teknik mimarın önerdiği 'iki node daha' müşteri gereksinimi olamaz; o gereksinimi karşılamak için değerlendirilen seçenek olabilir. Bütçe sahibi maliyet sınırı söylemediyse boş bırak ve TBD aç. Şartname v1 ile görüşme notu v2 çelişirse geçerli belge/karar hiyerarşisini sor; en uygun görünen rakamı seçme. Gereksinim defteri yalnız kesin maddeleri değil açık doğrulamaları da taşır.

Gereksinim yazılırken risk defteri paralel ilerler. Sabah raporu verisi gecikiyorsa depolama büyütmek çözmeyebilir; hipotezin yanlış çıkması BoM maliyetini artırıp iş hedefini kapatmaz. Bu 'teknik risk' olarak yazılır: olay, olasılık veya belirsizlik, etki, erken işaret, doğrulama ve azaltma seçeneği. Ankara DR lokasyonu için RPO bilinmiyorsa 'DR hazır' değil kritik UNKNOWN ve olası iş sürekliliği riski kaydı aç. Mevcut lisans hakları teyitsizse vendor entegrasyonu ve TCO etkisi değerlendirmeye girer. Risk düzeyi tek başına ürün adına göre seçilmez; müşteri iş kaybı, süre, güvenlik ve karar geri döndürülebilirliği belirler. Bazı bilinmeyenler keşifle kapanır, bazıları POC ister, bazıları sözleşme incelemesi. Her riskin yanında soru, owner ve kapanış kanıtı olsun. Müşteriye 'hangi risk sizi daha çok durduruyor?' diye sor; ticari ve teknik ekip farklı öncelik taşıyabilir. Öncelik uyuşmazlığı varsa karar sahibini bulup alternatiflerin etkisini göster. Böylece mimari karara girerken belirsizlik saklanmamış olur.

Aday gereksinim ve riskler görünür olunca en az iki makul seçenek üret. Kurgusal rapor senaryosunda A seçeneği uygulama sorgusu ve veri akışını iyileştirme, B seçeneği altyapı kapasitesini artırma, C seçeneği rapor zamanlamasını ve iş sürecini değiştirme olabilir. Bu seçenekler satıcı kataloğu değildir; her biri farklı darboğaz hipotezini hedefler. Ölçüm göstermezse birine üstünlük verme. Kıyas tablosunda iş hedefi, test edilebilirlik, üç yıllık maliyet, işletim yükü, güvenlik, veri yeri, DR etkisi, lisans hakkı ve geri dönüşü aynı sırayla göster. Açık varsayım ve kanıt kalitesi her seçenek için farklı olabilir. Microsoft Learn ADR rehberi mimari kararın bağlamını, alternatiflerini, gerekçesini ve sonuçlarını kaydetmeyi önerir. Arven için ADR 'ürün X seçildi' notu değil, hangi müşteri şartına ve hangi ölçüme dayanarak hangi alternatifin neden seçildiğini açıklar. Büyük mimari karar önce teknik kanıt ve yetkili müşteri ölçütüyle kurulmalıdır. Test edilmemiş üstünlük iddiası ADR içinde ASSUMED kalır.

Mimari seçeneklerin bağımlılık ağını çıkar. Veri akışı değişirse güvenlik sınırı, backup kapsamı, DR replikasyonu ve işletim runbook'u değişebilir. Ek düğüm eklemek kapasiteyi artırabilir ama lisans metriği, enerji, rack ve destek maliyeti yaratır. Rapor zamanlamasını değiştirmek teknik maliyeti düşürebilir fakat iş rolünün kabul ettiği saat sınırını etkiler. HLD çizimi bu etkileri göstermelidir; yalnız veri yolu oku çizmek çözüm değildir. BoM ve TCO, seçilen mimari sürümünden türemeli; HLD v2 ile BoM v1 arasındaki fark karara taşınır. Bir seçenek DR lokasyonunun mevcut olduğu varsayımıyla uygun görünse bile Ankara site kapasitesi teyitsizse o bağ UNKNOWN kalır. Güvenlik veya veri yeri gereksinimi yeni açıklamayla değişirse ADR ve test planı yeniden açılır. Karar değişikliğinde eski ADR kaydı silinmez; yeni kayıt gerekçesiyle eskiyi değiştirir. Müşteriye alternatiflerin yalnız avantajlarını değil sınırlarını anlat; no-bid de kritik kısıt kapanmıyorsa geçerli bir sonuç olabilir.

Mimari öneri karara dönüşmeden önce hangi hipotezin hangi yöntemle test edileceğini yaz. Kurgusal sabah raporu gecikmesinde ölçümlü performans profili ve küçük kontrollü POC, uygulama mı altyapı mı sorusunu ayırabilir. Pilot daha sonra operasyon devri ve kullanıcı etkisini test edebilir. Demo, darboğaz kök nedenini kanıtlamaz. Test planı veri hacmi, ortam, başlangıç/bitiş ölçüsü, tekrar, başarı ve başarısızlık eşiği, geçersiz koşu ve müşteri gözlemcisini tanımlar. Bu alanların çoğu bir önceki Demo/POC/Pilot modülünde öğrenildi; şimdi vaka zincirine bağlanır. POC sonucu hangi ADR, BoM, TCO, risk ve teklif satırını değiştirecek önceden kaydedilir. Sonuç iyi olsa bile kaynağı ve temsiliyet sınırını yaz. İş rolü raporu farklı saatle kabul ederse aday gereksinimin sürümü değişir; eski test sonucunu yeni hedef için otomatik geçerli sayma. Teknik testin olumlu olması bütçe veya sözleşme onayı değildir. Müşteri karar ve iç bid kararı farklı makamda kalabilir.

Karar kapısında dört açık statü kullan: ilerle; şartla ilerle; ölçümü/keşfi tekrar et; dur. Şartla ilerle demek hangi bilgi eksik, hangi riski kim taşıyor, ne zaman ve hangi kanıtla kapanacak yazılmadan kullanılamaz. Arven'in yalnız başlangıç olgularıyla bu senaryoda koşulsuz ürün seçimi yapılamaz; iş hedefi, teknik baseline ve yetkili değerlendirme ölçütü gereklidir. Defterde müşteri özgün sözü, aday gereksinim ID, ADR sürümü, test raporu, açık risk ve karar makamını tek satırda bağla. Yeni bilgi gelince önceki 'kabul edildi' kaydını geriye dönük değiştirme; etkilediği satırları yeni sürümle aç. NASA'nın gereksinim izi ilkesi ve Microsoft'un ADR sürümleme yaklaşımı bu karar zincirinin denetlenebilirliğine yardımcı olur. Bir sonraki vaka dersinde teklif, POC ve değişikliklerin daha geniş etki zincirini işleyeceksin. Bu dersin iyi çıktısı satın alınacak ürün değil, hangi kararın hangi kanıt eksikliği nedeniyle beklediğini dürüstçe gösteren mimari karar taslağıdır.