Bu yazıda, Yazılım Mimarisi’nde 1990’lardan beri kullanılan Architectural Decision Records (ADR) metodunun Kurumsal Mimari’ye nasıl uyarlanabileceği konusuna değineceğiz..
Yazılım geliştirme süreçlerinde _özellikle orta ve büyük ölçekli projelerde_ uygulamanın yapısı ve bileşenleriyle ilgili mimari kararlar sıklıkla alınmakta. Projenin başlangıç evresinde daha yoğun olarak alınan bu kararlar, genellikle bütün takımı etkiliyor ve tüm üyeler tarafından bilinmesi ve uygulanması büyük önem taşıyor. Projenin sonlarına doğru ise alınan yeni karar sayısı azalırken, daha önce alınan kararların yürürlükten kalkması veya düzenlemeye gidilmesi gündeme geliyor.
ADR burada imdada yetişerek, fazla detaya boğulmadan kararların kolay ve anlaşılır bir dil ile kayıt altında alınmasını ve herkes tarafından kolaylıkla erişilebilmesini sağlıyor. Yazılım projelerinde bu kararlar genellikle ekip içerisinde alınarak, kaynak kodların tutulduğu ortamda (GitLab, TFS vb) saklanıyor. Özellikle son yllarda kurumların girdiği çevik (agile) dönüşümler, süreçlerde oluşturulan “gereksiz” dokümanların ortadan kalkması gibi faydalı bir sonuç doğurdu (çoğu kurumun bunu “sıfır dokümantasyon” olarak biraz yanlış yorumlaması ise ayrı bir yazı konusu). Dolayısıyla ADR gibi gerçekten basit ve kullanışlı bir yöntem daha da değer kazanmaya başladı.
Kurumsal Mimari süreçlerinde de, Yazılım Mimarisi’nde bahsettiğimize benzer bir ihtiyaç mevcut. Genellikle üyeleri Kurumsal Mimari Ekibi ve IT Yönetimi’nden oluşan Mimari Komite tarafından alınan bu kararların (yeni bir uygulamanın satın alınması, bir uygulamanın hayatına son verilmesi, yeni bir teknolojinin veya tekniğin benimsenmesi, network ve donanım altyapısı değişiklikleri vb), kapsama alanı bir yazılım/proje ekibi değil, tüm IT birimleri ve hatta iş birimlerini de kapsayarak kurumun tamamı. Dolayısıyla kararların bir Mimari Karar Defteri’nde kayıt altına alınması daha büyük önem taşıyor.
Karar defteri kullanmamızdaki temel gerekçeleri kısaca listeleyecek olursak :
- “Neden?” sorularının kolaylıkla yanıtlayabilmek
- Kurumsal hafıza oluşturabilmek ve tarihçeyi görebilmek
- Bilgi paylaşımını ve şeffaflığı artırabilmek
- Olası tartışma ve anlaşmazlıkların önüne geçebilmek
Peki karar defterimizi tutarken nelere dikkat etmeliyiz?
- Kararlar belirli bir şablon ile metin bazlı olarak kayıt altına alınmalıdır (Confluence gibi wiki uygulamalardaki şablon yapıları kullanılabileceği gibi, bir Word dokümanı da iş görecektir)
- Her karar, ilgili konu üzerindeki tartışmaları değil, nihai hükmü belirtmelidir (Kaynaklar tartışmaya açılan konuların da bu ortamda kayıt altına alınmasını tavsiye etse de, bu “fikirlerin” başka bir ortamda yönetilmesi gerektiği düşüncesindeyim)
- Kararlar tüm çalışanların kolaylıkla erişebileceği bir ortamda bulunmalıdır (Kurumsal Mimari uygulaması, şirket wiki’si, intranet portal, ortak alanda bir klasör vb)
- Her karar birkaç sayfayı geçmeyecek yapıda olmalı ve gereksiz bilgi içermemelidir
- Her kararın tekil bir karar numarası olmalıdır
- Kararlar birbirlerine yaptıkları referansları, karar numaraları üzerinden yapmalıdır
- Kararlar yoruma ve olası değişiklik önerilerine açık olmalıdır
Örnek bir mimari karar şablonu :
Karar No: Tekil karar numarası
Tarih : Kararın geçerlilik tarihi
Karar Başlığı : Bir cümle ile kararın kısa ifadesi
Durum : Kabul – İptal – Revizyon
Karar Vericiler : Mimari ekip ve yönetimden ilgili isimler
Karar Kategorisi : Eğer varsa tasnif için bir kategorizasyon
Kararın Gerekçesi : Kararın alınmasındaki nedenler
Karar Metni : Birkaç paragraf ile kararın detayı
Etkileri : Karar sonrasında hayatınızda nelerin değişeceği, yani olumlu ve olumsuz yan etkileri
.
Kaynaklar :
• https://resources.sei.cmu.edu/asset_files/Presentation/2017_017_001_497746.pdf
• http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions
• https://dev9.com/blog-posts/2017/5/increasing-software-transparency-with-lightweight-architectural-decision-records
• https://www.utdallas.edu/~chung/SA/zz-Impreso-architecture_decisions-tyree-05.pdf