mimari-ve-izlenebilirlik · teknik-not

Mimari deponuz büyüyor. Mimari görünürlüğünüz neden artmıyor?

Daha fazla çıktı, hangi kararın hangi mimari bilgiye dayandığını kendiliğinden açıklamaz.

Bir mimari deposunda yüzlerce model, görünüm ve belge olabilir.

Strateji dosyası güncel. Yetenek haritası var. Gereksinimler bir araçta tutuluyor. Program yol haritası ayrı sunumda. Sistem envanteri güncelleniyor. Arayüz listesi başka bir tabloda.

Her parça kendi içinde doğru olabilir.

Yine de yönetici şu soruya cevap alamayabilir:

Bu gereksinim değişirse hangi program, sistem ve karar etkilenir?

Burada eksik olan yeni bir diyagram değildir. İlişkilerin karar sorusunu destekleyecek biçimde görünür ve sürdürülebilir olmasıdır.

Aynı kavramın beş ayrı çıktıda yaşaması başka bir sorun daha üretir: değişiklik hangi kopyaya yansıtıldı? Gereksinim kimliği aynı mı kaldı? Yol haritasındaki program adı değiştiğinde yetenek eşlemesi hâlâ geçerli mi?

Depo büyürken güncelleme maliyeti de büyüyebilir. Görünürlük artmıyorsa daha fazla çıktı, yalnızca daha fazla senkronizasyon borcu yaratır.

İki kutunun arasına ok çizmek ilişkiyi tanımlamaz

“bağlıdır”, “destekler”, “ilgili”, “bağımlıdır” gibi ilişkiler kolayca modelde yer alır. Fakat bu ilişki hangi anlamı taşıyor?

Bir sistem gereksinimi gerçekleştiriyor mu? Yalnız veri mi sağlıyor? Program bir yeteneği tamamen mi teslim ediyor, yoksa bir parçasına mı katkı veriyor? Bağımlılık zaman, veri, teknik arayüz veya ortak kaynak bağımlılığı mı?

GEREKSİNİM —[gerçekleştirilir]→ SİSTEM
PROGRAM A —[veri sağlar]→ PROGRAM B
YETENEK —[kısmen desteklenir]→ PROJE
SİSTEM —[ortak kaynağa bağımlı]→ HİZMET

Basitleştirilmiş ilişki örnekleri. Gerçek kurum veya proje verisi değildir. Okun yönünden çok ilişki türünün anlamını vurgulamak için oluşturulmuştur.

Program bağımlılığı, proje isimlerinin arasına ok çizmek değildir.

İlişki türü belirsizse model güzel görünebilir; değişiklik etkisi, sorumluluk ve karar desteği yine belirsiz kalır.

İlişkinin kendisi de öznitelik taşıyabilir. Kaynağı nedir? Kim doğruladı? Ne zamandan beri geçerli? Kesin bir ilişki mi, çalışma varsayımı mı? Bir program bir yeteneği “destekliyor” derken kapsam yüzde yüz mü, kısmi mı?

Bu ayrıntılar her ilişkiye eklenmek zorunda değildir. Fakat karar için kritik ilişkilerde belirsizlik görünmez bırakılmamalıdır.

Mimari görünürlük, karar sorusundan geriye kurulabilir

Mimari ekibine “bütün kurumu modelleyin” demek kolaydır. Ne kadar ayrıntının yeterli olduğu ise belirsizleşir.

Daha etkili başlangıç, karar sorusunu belirlemektir.

Örneğin:

• Bu yetenek hangi programlarla teslim ediliyor?
• Bu gereksinimin teknik karşılığı nerede?
• Bir program gecikirse hangi bağımlılık zinciri etkilenir?
• İki proje aynı ihtiyacı mı karşılıyor?
• Bir sistem emekliye ayrılırsa hangi bilgi akışları kesilir?

Her soru farklı görünüm ve ilişki seti gerektirir. Aynı depo içindeki her nesneyi aynı ayrıntı seviyesinde modellemek zorunda değilsiniz.

Bu nedenle mimari görünüm, depodaki bütün nesnelerin küçük bir kopyası değildir. Belirli bir karar sorusu için gerekli ilişkileri seçen bir bakıştır. Aynı kaynak modelden yönetim görünümü, program bağımlılığı görünümü veya bilgi akışı görünümü üretilebilir.

Karar sorusu değiştiğinde görünüm değişebilir. Yetkili varlık kimlikleri ve ilişki anlamları ise korunmalıdır.

STRATEJİK AMAÇ
↓
YETENEK
↓
GEREKSİNİM
↓
PROGRAM / SİSTEM
↓
KARAR / ETKİ

Hangi kararın hangi mimari bilgiye dayanabileceğini görünür hâle getirmek.

“Tek doğru kaynak” ile “tek görünüm” aynı şey değildir

“Tek doğru kaynak” (single source of truth) ifadesi mimari ve veri çalışmalarında sık kullanılır. Sorun, bunun her bilgiyi tek tabloda veya tek araçta tutmak şeklinde yorumlanmasıdır.

Gerçek kurumsal ortam çoğu zaman birleşik değil, federedir. Gereksinim yönetimi, portföy, finans, sistem envanteri ve mimari depo farklı işlevler için oluşmuştur. Hepsini tek araca taşımak teknik olarak mümkün olsa bile süreç sahipliği ve güncellik problemi bitmeyebilir.

Daha gerçekçi hedef, hangi bilginin nerede yetkili olduğunu ve kaynaklar arasındaki kimlik/eşleme ilişkisini görünür hâle getirmektir.

Bir gereksinimin yetkili kaynağı gereksinim yönetim sistemi olabilir. Program takviminin kaynağı başka araçtır. Sistem kimliği başka envanterde tutulabilir.

Tek bir ekranda bunları birlikte görmek istiyorsanız kaynakları zorla birleştirmek yerine otorite ve eşleme ilişkilerini tanımlayabilirsiniz.

Yani:

• hangi bilgi için hangi kaynak yetkili,
• aynı varlık farklı kaynaklarda nasıl tanınıyor,
• eşlemenin kesinliği nedir,
• hangi dönüşüm uygulanıyor,
• son görünüm ne zaman üretildi

gibi sorular görünür olmalıdır.

Tek kaynak ile tek görünüm aynı şey değildir.

Mimari depo sorgulanabilir bir karar yüzeyi olmalıdır

Bir kritik soruya cevap vermek için üç uzmanı toplantıya çağırıp dört dosyayı elle karşılaştırmak gerekiyorsa bilgi kurumda vardır, fakat mimari görünürlük zayıftır.

Sorgulanabilirlik yalnız SQL veya grafik sorgu dili anlamına gelmez. “Bu gereksinimi gerçekleştiren sistemler hangileri?”, “bu program gecikirse hangi yetenek etkilenir?” veya “bu bilgi ürünü hangi sistemler arasında akar?” sorularının tekrarlanabilir biçimde cevaplanabilmesidir.

İyi bir mimari depo bu cevapların kaynağını da göstermelidir. Aksi hâlde yeni bir sunum üretilir, fakat kararın hangi kayıt ve ilişkiye dayandığı yine kaybolur.

İlk müdahale: depo sayımını değil karar zincirini çıkarın

Mevcut modelleri ve dosyaları envanterlemek yararlıdır. Ancak başlangıç noktası yalnız “kaç model var?” olmamalıdır.

Bir kritik karar seçin. O kararın ihtiyaç duyduğu mimari bilgiyi geriye doğru izleyin.

1. Kararı tanımlayın.
2. Kararı etkileyen yetenek, gereksinim veya bağımlılıkları belirleyin.
3. Bu bilgilerin mevcut kaynaklarını bulun.
4. Aynı kavramın farklı kaynaklarda nasıl temsil edildiğini karşılaştırın.
5. İlişki türlerini açık adlandırın.
6. Eksik, çelişkili veya sürdürülemeyen bağları görünür hâle getirin.

Bu küçük zincir çalışıyorsa mimari depo için gerçek bir devam modeli oluşur. Çalışmıyorsa yeni yüzlerce görünüm üretmeden önce neden çalışmadığını bilirsiniz.

Sonra bakım davranışını tanımlayın: ilişkiyi kim sahipleniyor, hangi değişiklik yeniden incelemeyi tetikliyor, ne kadar süre güncellenmeyen bilgi “eski” kabul ediliyor ve kritik karar zinciri hangi aralıkta doğrulanıyor?

Devam ettirilebilirlik tam burada başlar. Modelin üretildiği gün doğru olması yetmez; kurum değişirken hangi bağların yeniden sınanacağını bilmek gerekir.

İyi mimari yalnızca anlaşılır olmamalı. Devam ettirilebilir de olmalıdır.

İLGİLİ ÇALIŞMA ALANI

Bağımsız mimari danışmanlığı

Strateji, yetenek, gereksinim, program ve sistem ilişkilerinin hangi kararı desteklediğini bağımsız olarak görünür hâle getirin.

Hizmeti inceleyin →

6 DK OKUMA