Mimari Seçenekler, Trade-off ve ADR

Ön koşul: Arven iş problem cümlesini, portal–ERP–üretim bağlamını, kalite senaryolarını ve kısıt/TBD kaydını okuyabilmelisin. Bu derste aynı kabul sınırında en az üç mimari seçenek üretecek, ölçüt ve ağırlıkların sahibini belirleyecek, trade-off ve geri döndürme maliyetini görünür kılacak, kanıt düzeyini işaretleyip ilk ADR'yi yazacaksın. Yaklaşık 27 dakika kavram, 26 dakika Arven karar çalışması ve 13 dakika kontrol önerilir. Seçenek, yalnız aynı diyagramın farklı vendor logosu değildir. Veri akışının senkron veya asenkron olması, hangi verinin sistem kaydı olduğu, failure domain ve işletim sorumluluğu değişiyorsa gerçek mimari seçenek vardır. İlk seçenek mevcut ERP entegrasyonunu iyileştirmek, ikinci seçenek kabul/kuyruk katmanı eklemek, üçüncü seçenek daha kapsamlı ERP arayüzünü yenilemek olabilir. Bunlar Arven için öneri değil öğretim hipotezleridir; uygulanabilirliği sözleşme ve POC ile doğrulanır.

Trade-off, bir ölçütün iyileşmesi için başka bir alanda kabul edilen bedeldir. Performans, veri tutarlılığı, güvenlik, dayanıklılık, kurulum süresi, operability, değiştirilebilirlik ve üç yıllık TCO aynı tabloda görünmelidir. Önce vazgeçilmez kapıları iş sahibiyle belirle; bir seçenek bu kapıyı geçmiyorsa ağırlıklı toplam puanla kurtarılamaz. Sonra müzakere edilebilir ölçütlere göre karşılaştırma yap. Ağırlıklar mimarın kişisel tercihi değil karar sahibinin önceliğidir; değiştiklerinde sonuç nasıl değişiyor duyarlılık olarak göster. Farklı seçenekler için aynı veri kalitesi kullanılmalı. Birinin POC sonucu varken diğerinin broşür iddiası varsa kanıt düzeyleri açık yazılır. Bütün ölçütleri 1–5 puana çevirmek belirsizliği yok etmez; gerekirse 'doğrulanmadı' ve aralık kullan. Olumsuz sonucu gizleme, çünkü uygulama ve operasyon onu yaşayacaktır.

Architecture Decision Record, mimari açıdan önemli bir kararın bağlamını, seçeneklerini, seçimini ve sonuçlarını kısa biçimde saklar. Her toplantı notu ADR değildir; sistem yapısını, önemli kalite niteliğini veya geri dönüş maliyetini etkileyen kararlar için kullanılır. Arven'de portal–ERP aktarımının senkron veya kuyruklu olması böyle bir karardır. Kayıtta problem ve geçerli gereksinim sürümü, seçenekler, kabul edilen ve reddedilen gerekçeler, kanıt/POC, trade-off, risk, karar sahibi, tarih, durum ve yeniden açma tetikleri bulunur. Kararın confidence düzeyi açık yazılır; düşük güvenle seçilmiş bir tasarımın hangi deneyle teyit edileceği belirtilir. ADR tasarım kılavuzuna dönüşmemeli; ayrıntılı HLD, test ve BoM belgelerine bağlanmalıdır. Kabul edilen kaydı geriye dönük silmek yerine yeni ADR ile supersede et; böylece kararın neden değiştiği görülür.

Seçenekleri yalnız ilk kurulum çabasıyla kıyaslama. Arven'de kuyruklu akışa geçiş, portal mesaj sözleşmesi, ERP replay, gözlemleme, veri temizliği ve kullanıcı iletişimini değiştirebilir. Geri dönüş, eski akışa düğmeyi çevirmek değildir; geçiş sırasında alınmış fakat ERP tarafından kabul edilmemiş siparişler mutabakata ihtiyaç duyar. ERP arayüzünü yenileme daha yavaş olabilir ama sonradan tekrar değiştirme maliyeti daha düşebilir; bunu kanıtsız varsayma. Her seçenek için pilot kapsamı, veri migration veya çift yazım ihtiyacı, rollback anı, veri tutarlılığı kontrolü, bağımlı ekip ve çıkış maliyeti yazılır. Kademeli uygulama ve feature flag bazı riskleri azaltabilir ama iki akışı paralel işletme maliyeti yaratır. Mimari kararın reversibility düzeyini açıkça yaz ve yüksek geri dönüş maliyetli kararı daha güçlü POC kapısına bağla.