Bir teknoloji incelemesinin ilk oturumunda tekrarlayan bir sahne vardır: masaya mimari şeması istendiğinde, karşı taraftan gelen belge çoğu zaman satış sunumunun bir sayfasıdır — kutular, oklar, bulut ikonu ve üç katman. Aynı oturumda teknik ekibin kıdemli bir üyesine sistemin gerçekte nasıl çalıştığı sorulduğunda, anlatılan yapı ile o sayfadaki yapı arasında birkaç kritik fark ortaya çıkar; bir servis şemada tekken üretimde ikiye ayrılmıştır, şemada olmayan bir kuyruk yapısı kritik yolun üzerindedir, ve şemadaki bir bileşen aslında iki yıl önce devre dışı bırakılmıştır. Kimse yanlış beyanda bulunmamıştır; şema hazırlandığı gün doğruydu, sonra sistem yürüdü, şema yürümedi. İnceleme açısından buradaki bulgu mimarinin zayıflığı değil, mimarinin şirket düzeyinde bilinen bir nesne olmamasıdır.
İkinci bir sahne, aynı oturumun ilerleyen saatinde belirir. Bir tasarım kararının gerekçesi sorulduğunda — neden bu veritabanı, neden bu senkron çağrı, neden bu üçüncü taraf servis — verilen cevap genellikle şudur: o dönem öyle karar verilmişti, kararı veren kişi artık şirkette değil, ama değiştirmeye kimse cesaret edemiyor çünkü nelerin kırılacağı bilinmiyor. Bu cevap, incelemeyi yürüten tarafın kulağında teknik bir detay olarak değil, bir yükümlülük beyanı olarak kaydedilir: şirket, kendi sisteminin bazı bölümlerini kullanabiliyor ama değiştiremiyor.
Bu iki gözlemin altındaki mekanizma bir ihmal değil, tamamen rasyonel bir kısayoldur. Erken dönemde mimari, birkaç kişinin aynı odada bulunduğu, aynı bağlamı paylaştığı ve kararı beş dakikada aldığı bir ortamda oluşur; böyle bir ortamda kararı belgelemenin marjinal faydası düşük, maliyeti ise doğrudan geliştirme zamanından düşülen bir kalemdir. Ekip küçükken paylaşılan sözlü bağlam, yazılı mimariden hem daha hızlı hem daha isabetlidir, zira sürekli güncellenir. Sorun kısayolun kendisinde değil, kısayolu geçerli kılan koşulun sessizce ortadan kalkmasındadır: ekip büyüdükçe, kurucu geliştiriciler yöneticiliğe geçtikçe ve sisteme yeni katılan her mühendis bağlamı yalnızca kodu okuyarak inşa etmek zorunda kaldıkça, paylaşılan zihinsel model dağılır, fakat onun yerini alacak yazılı katman hiç kurulmadığı için boşluk fark edilmez. Bilgi kaybolmaz; erişilebilirliğini kaybeder.
Bu erişilebilirlik kaybının en pahalı biçimi, bağımlılık katmanında ortaya çıkar. Modern bir uygulama, kendi yazılan kodun birkaç katı büyüklüğünde üçüncü taraf bileşen taşır; bunların bir kısmı lisans rejimi bakımından ticari kullanımı koşullu kütüphanelerdir, bir kısmı artık bakımı yapılmayan projelerdir, bir kısmı ise fiyatlandırması kullanım hacmine bağlı dış servislerdir. Bu üç kategori aynı build çıktısında yan yana durur ama şirket için tamamen farklı riskler taşır: birincisi hukuki, ikincisi operasyonel, üçüncüsü marj riskidir. Envanteri tutulmayan bir bağımlılık kümesinde bu ayrım hiçbir zaman yapılmaz, ve inceleme sırasında ilk kez yapıldığında ortaya çıkan bulgular tipik olarak kapanış takvimini uzatan türden olur.
Uygulama boyutu, belgeden ayrı ve genellikle daha belirleyici bir katmandır. Bir şirkette güncel bir mimari dokümanı bulunması, mühendislerin günlük kararlarını o dokümana göre alması anlamına gelmez; aradaki farkı ölçen en pratik gösterge, mimari kuralın ihlal edildiği durumların nasıl ele alındığıdır. Kural ihlali kod incelemesinde yakalanıyor ve tartışmaya açılıyorsa mimari yaşayan bir kısıttır; ihlal üretime çıktıktan aylar sonra bir arıza vesilesiyle fark ediliyorsa doküman bir niyet beyanıdır. İnceleme tarafı bu ayrımı belgeyi okuyarak değil, son dönemdeki değişiklik kayıtlarında aynı kararın kaç farklı biçimde uygulandığına bakarak tespit eder; aynı işlevin sistemde üç farklı desenle çözülmüş olması, mimarinin uygulama katmanında kurulmadığının en açık göstergesidir.
Ölçüm katmanı, teknoloji mimarisinde en sık boş bırakılan boyuttur, çünkü ölçülmesi gereken şey sezgiye ters düşer. Sistem çalıştığı sürece ölçülecek bir şey olmadığı varsayılır; oysa mimarinin ölçülmesi, sistemin çalışıp çalışmadığının değil, büyüme altında nasıl davranacağının ölçülmesidir. Birim işlem başına altyapı maliyetinin hacimle nasıl değiştiği, yeni bir mühendisin ilk anlamlı katkısına kadar geçen süre, bir değişikliğin fikirden üretime ulaşma süresi, üretim ortamındaki arızaların kaçının aynı bileşende tekrarladığı — bu göstergeler mimarinin ölçek karşısındaki davranışını, mimari dokümanın kendisinden çok daha güvenilir biçimde tarif eder. Bu göstergeler tutulmuyorsa, iş planındaki büyüme senaryosunun teknoloji tarafı doğrulanamaz kalır, ve doğrulanamayan bir senaryo yatırım komitesinde iyimser değil, riskli sayılır.
Sahiplik boyutunda aranan şey bir unvan değil, bir karar yetkisidir. Çoğu şirkette teknoloji mimarisinden sorumlu kişi vardır ama o kişinin bir mimari kararı reddetme, bir bileşenin kullanımını durdurma ya da teknik borç ödemesi için sprint kapasitesi ayırma yetkisi yoktur; bu yetki fiilen ürün takvimini yöneten tarafta durur. Böyle bir yapılandırmada mimari, ticari baskı ile teknik gereklilik arasındaki her çatışmada öngörülebilir biçimde geri adım atar, ve bu geri adımların birikimi birkaç yıl sonra ölçekleme kapasitesini belirleyen asıl faktöre dönüşür. İnceleme masasında sorulan soru bu nedenle 'mimariden kim sorumlu' değil, 'son on iki ayda hangi mimari kararı kim, hangi gerekçeyle reddetti' biçimindedir; reddedilmiş karar örneği üretilemeyen bir sahiplik yapısı, işlevsel olarak sahipsizlikle aynı sonucu verir.
Süreklilik boyutu, bütün bu katmanların birleştiği yerdir ve değerlemeye en doğrudan bağlanan boyutdur. Bir sistemin kritik bölümleri hakkında yalnızca bir kişi konuşabiliyorsa, o kişinin şirkette kalması bir insan kaynakları meselesi değil, işlem yapısının bir maddesi hâline gelir; kilit personel taahhüdü, earn-out tetikleri ve kapanış öncesi bilgi aktarım koşulları bu noktadan doğar. Buradaki değerleme etkisi teknoloji riskinden değil, kurucu ya da anahtar mühendis bağımlılığından kaynaklanır, ve alıcı tarafında bu bağımlılık genellikle iki kalemle fiyatlanır: devralma sonrası ilk on sekiz ayda beklenen yeniden inşa maliyeti ve o dönemde ertelenecek ürün geliştirme kapasitesinin fırsat maliyeti. Her iki kalem de nakit akışı projeksiyonunu doğrudan aşağı çeker.
Bu tablonun düzeltilmesi, kapsamlı bir mimari yeniden yazımı gerektirmez; gereken şey, mimariyi şirketin bildiği bir nesneye dönüştüren dört ayrı mekanizmadır. Birincisi, sistemin gerçek hâlini tarif eden ve değişiklikle birlikte güncellenen bir mimari tanımıdır — kutular ve oklar değil, bileşen sınırları, veri sahipliği ve bileşenler arası sözleşmeler düzeyinde. İkincisi, alınan her önemli mimari kararın gerekçesi, değerlendirilen alternatifleri ve kabul edilen ödünleşimiyle birlikte tutulduğu bir karar kaydıdır; bu kayıt, kararı veren kişi ayrıldığında kararın gerekçesinin de ayrılmasını engelleyen tek mekanizmadır. Üçüncüsü, lisans rejimi ve bakım durumu sınıflandırılmış bir bağımlılık envanteridir. Dördüncüsü, mimari kısıtların kod incelemesi ve otomatik denetim aşamasında fiilen uygulandığı bir kontrol katmanıdır.
BEIREK'in bu alandaki müdahalesi, teknik ekibin yerine geçmek değil, mühendislik kararı ile yatırım kararı arasındaki tercüme katmanını kurmaktır. Uygulamada bu, önce sistemin gerçek hâlinin bileşen ve bağımlılık düzeyinde haritalanması, ardından her kritik bileşen için sahiplik, karar yetkisi ve devir edilebilirlik durumunun tek bir kayıtta sabitlenmesi biçiminde işler; bu kayıt, incelemeye giren tarafın soracağı soruların şirket içinde önceden sorulmuş olmasını sağlar. İkinci katman, mimari kararların kaydını bir arşiv işlemi olmaktan çıkarıp karar anına bağlayan bir ritimdir: kararın gerekçesi onay anında değil, öneri anında yazılır, zira onaydan sonra yazılan gerekçe kararın kendisini değil, kararın savunmasını kaydeder.
Üçüncü katman, mimarinin ölçek davranışını gösteren sınırlı sayıda göstergenin düzenli olarak raporlanmasıdır — birim maliyet eğrisi, değişiklik teslim süresi, tekrarlayan arıza yoğunlaşması ve yeni mühendisin verimlilik eşiğine ulaşma süresi. Bu göstergeler teknik ekip için performans ölçütü değildir; yatırım komitesinin büyüme senaryosunu doğrulayabileceği tek kanıt zinciridir, ve bu nedenle finansal raporlama ritmiyle aynı takvimde işletilir. Dördüncü katman, kritik bileşenlerin her biri için en az iki kişinin çalışma düzeyinde yetkin olmasını sağlayan bir rotasyon disiplinidir; bu disiplin süreklilik boyutunu, iyi niyet beyanından denetlenebilir bir duruma dönüştürür.
Bir şirketin teknolojisinin değeri, o teknolojinin ne kadar iyi çalıştığında değil, çalışma biçiminin şirket tarafından ne kadar bilindiğinde ortaya çıkar; zira alıcı, çalışan bir sistemi değil, devralınabilir bir kapasiteyi satın alır. Masaya konulan mimari belgesi ile mühendisin anlattığı sistem arasındaki mesafe, bu iki şeyin ne kadar ayrıştığının en doğrudan ölçüsüdür — ve bu mesafe, inceleme başladığında kapatılabilecek bir şey değildir.