API Governance’ı Dokümandan Yürürlüğe Taşımak

Kuralların olmadığı yerde özgürlük değil, güçlü olanın kaosu vardır; gerçek düzen, herkesin sınırlarını bilerek güvenle üretebildiği bir adalet zeminidir.

Mimari standart, ancak otomatik olarak doğrulanabildiği, uygulanabildiği ve ölçülebildiği kadar vardır

Mimari Standart Nerede Yaşıyor?

Standartlar yazıldı, dokümante edildi ve büyük bir gururla duyurusu yapıldı. Artık herkes bu standartlara uyacak sanıldı. Ama üç sprint sonra kimse dokümanın yüzüne bile bakmadı.

Bu, kurumsal mimarinin en tanıdık hikayesidir. Enterprise Architecture ekibi bir API standartı hazırlar. Kimlik doğrulama zorunlulukları, isimlendirme kuralları versiyonlama politikası, trafik profilleri her şey didik didik edilir ve günlerce emek verilik dokümante edilir. Architecture Review Board’da onayıda aldıktan sonra ekiplere duyurusu yapılır. Buraya kadar her şey doğru yapılmıştır.

Sonra zamanla doküman ile production arasında açılan bir mesafe oluşur. Bu mesafe de nelerin olduğunu biliyorsunuz aslında. Standartlar okunmaz, okunsa bile farklı yorumlanır. Biri external derken internete açık olanı kastetmiştir ama farklı biri kurum dışı herhangi bir tüketiciyi kasteder. Bazen biri çıkar ve ölüm kalım! meselesi yaptığı bir işi hiçbir kurala uymadığı halde prod ortama taşır ve sonra hallederiz der. Ama asla halledilmez. Test ortamında yapılmış olan bir profil tanımı prod ortama taşınmıştır ama bunu da kimse fark etmez. Zaten istesede fark edemez. Çünkü fark edilecek bir mekanizma yoktur. Belirli bir zaman sonra şu dedikoduları duyarız;

• O doküman güncel değil, sen bir mimariye sor.
• Test’te çalışıyordu prod ortamda profil adı farklıymış.
• Gateway’de elle açmıştık sonra kapatmayı unuttuk.
• Bu API dışarı açık mı? Valla bilmiyorum emin değilim.

Bu cümlelerin ortak özelliği ise ihmal itirafı olmamasıdır. Hepsi kuralın yaşadığı yer ile kuralın uygulandığı yer arasındaki boşluğu temsil ediyor. İşte bu boşluk kurumların kendileri hakkında yanlış bir şey bilmesine yol açar. Halbuki standart yayınlanmıştır, onaylanmıştır ve imzalanmıştır. Dolayısıyla kurum kendisini uyumlu sanmakta haklıdır. Ama bu uyumun ölçülüp değerlendirildiği hiç olmamıştır. Bunun adı Beyan Uyumudur. Daha havalı bir deyimle Declared Compliance. Beyan uyumu açık uyumsuzluktan daha risklidir. Çünkü uyumsuzluk bir gün patlar ve görünür. Beyan uyumu ise sorunun görülmesini geciktirir. Şimdi bahsettiğim bu boşluğu Kurumsal Mimarinin cevaplaması gereken tek bir soru üzerinden irdeleyelim. Sorumuz:

Production’da ki 500 API’nin gerçekten bu standarda uyduğunu nasıl ispatlarız?

Bu soruya yazı boyunca cevap arayacağız ve sürekli bu soruya döneceğiz.

Aynı kelimeyi farklı şeyler için kullanıyoruz

Mimari yönetişim tartışmaları çoğu zaman terim karmaşasında boğulur. İlke mi konuşuyoruz standart mı? Kural mı kontrol mü? Bu ayrımlar akademik görünür ama değildir; çünkü her birinin yaşadığı yer ve uygulanma biçimi farklıdır.

Tek bir örnek üzerinden gidelim.

Bir kurumun mimari ilkesi şudur: Secure by Default. Aslında ilke dediğimiz kavram bir yön beyanıdır. Ölçülemez, doğrulanamaz ve doğrudan uygulanamaz. Sadece tartışmayı yönlendirir karar vermez. Mimari standartlar belirlenen bu ilkeden türer.

Kurum dışına açılan hiçbir API kimlik doğrulama olmadan yayınlanamaz. Standart artık bir yön değil, bir hükümdür. Ama hala insan diliyle yazılmıştır ve yorum gerektirir.

Standarttan bir yönetişim kuralı (governance rule) türer. Yani aslında belirtmek istediği şey tam olarak şudur:

Exposure = External => SecurityProfile = EXTERNAL_STRICT

Kural artık koşul ve sonuç içerir. Belirsizlik büyük ölçüde giderilmiştir. Yukarıda belirttiğim ifadenin neyi anlatmak istediğini birazdan açıklayacağım.

Kurallardan ise bir teknik kontrol türer artık. CI/CD aşamasında çalışan bir doğrulama adımı ve gateway üzerinde çalışan bir runtime politikası.

Yönetişim Süreci

Daha önce belirttiğim governance rule kısmını detaylandıralım.

Exposure = External => SecurityProfile = EXTERNAL_STRICT

Burada ki (=>) sembolü aslında if..else..then kalıbında ki then’i temsil etmektedir.

Exposure ise bir API’yi kimin çağırabildiğini söyleyen sınıflandırmadır. Teknik bir ayar değildir. Internal, Partner ve External genelde verilen değerlerdir. Bu değerlerin ne anlama geldiğini ise kurum tanımlar ve tanımın netliği kendi başına bir yönetişim işidir. Bir ekip “external” derken internete açık olanı, bir diğeri kurum dışı herhangi bir tüketiciyi kastediyorsa kural doğru çalışsa bile yanlış sonuç üretir.

SecurityProfile ise tek bir ayar değildir. Kurumun önceden tanımlayıp adlandırdığı bir ayar grubudur. Aslında yukarıda belirtilen EXTERNAL_STRICT içeriği şu şekildedir:

EXTERNAL_STRICT
  Kimlik doğrulama   : zorunlu
  Anonim erişim      : kapalı
  TLS                : zorunlu, minimum sürüm sabit
  Payload sınırı     : sıkı
  CORS               : yalnızca izinli origin listesi
  Hata gövdesi       : detay dışarı sızmaz

Yapılmış olan bu gruplama aslında bir kolaylık olarak görülmemelidir. Bu bir zorunluluk olmalıdır. Bu altı ayarı her API için tek tek tanımlarsanız 500 API’lik bir portföyde 500 farklı kombinasyon oluşur. Ama bu şekilde bir gruplama yapıldığında bu profili kullanan tüm api’lerin güncellenmesi (SecurityProfile güncellenmesi) çok daha kolay ve güvenli olacaktır.

Not: Burada belirtilen EXTERNAL_STRICT ifadesi zorunlu bir isimlendirme ya da bir dokümanda yazıldığı için verilmemiştir. Her kurum kendi bünyesinde farklı isimlendirme yapabilir.

Burada anlamamız gereken asıl önemli nokta şudur. Sol tarafı geliştirici belirtir. Sağ tarafı ise platform belirler. Bu ayrımın neden bu kadar önemli olduğuna ise daha sonra geleceğim.

Çoğu kurumda Yönetişim Süreci görselinde belirttiğim adımların ilk ikisi varken son ikisi yoktur. İlke ve standart yazılıdır ama kural ve kontrol insana ve gözden geçirme toplantılarına havale edilmiştir. Mimari yönetişim dediğimiz şey bu sürecin bütününü yönetme disiplinidir. Mimari uyum ise sürecin sonunda ölçülen şeydir.

Uyum için vardır ya da yoktur demek bir Kurumsal Mimar için yeterli değildir. O yüzden Mimari Uyum derken tam olarak neyi kastettiğime de kısaca değinmem gerekiyor.

Uyum ikili bir kavram değildir. TOGAF uyum düzeylerini toplam altı kademede tanımlar. Bunlar; irrelevant (ilgisiz), consisten (tutarlı), compliant (uyumlu), conformant (uygun), fully conformant (tam uygun) ve non-conformant (uygunsuz). Bu kademeler arasındaki fark bir sistemin standardın bazı özelliklerini karşılayıp diğerlerini karşılamaması ya da standardın ötesine geçmesi gibi durumları ayırt etmek içindir. TOGAF’ın kendisi de bu terminolojinin kurumdan kuruma değişebileceğini ancak bir uyum stratejisi kurarken bu ayrımların yararlı olduğunu belirtir.

Otomasyon ise doğası gereği ikili çalışır: geçti veya geçmedi. Bir kuralı otomatize ettiğimizde o kuralın gri bölgesinden de feragatlık etmiş oluruz. Yani:

“external API’de kimlik doğrulama var mı?” sorusunun gri alanı yoktur. Ama “bu servisin sınırı doğru çizilmiş mi?” sorusunun cevabı evet/hayır ile sınırlanmayabilir.

Dolayısıyla mesela “her şeyi otomatikleştirmek” değildir. Burada asıl mesele hangi kuralın hangi kademede olduğunu bilmek ve ikili cevabı olanları insan gündeminden çıkarmaktır.

Kural Nerede Yaşıyor?

Doküman olarak yönetişim

Geleneksel yönetişim süreci görselin solundaki gibidir. Süreç sol tarafta ki gibi olduğunda her katmanda bilgi kaybı oluşur. Doküman kararın gerekçesini değil sonucunu içerir. İnsan yorumu ise bağlama göre değişir.

Önerilen süreç ise görselin sağındaki gibidir. Bu yaklaşımın sektördeki adı Governance-as-Code. Altyapının kod olarak tanımlanması (infrastructure-as-code) ve politikaların kod olarak tanımlanması (policy-as-code) kalıplarının devamıdır. Yönetişim kuralları da versiyonlanabilir, gözden geçirilebilir, test edilebilir ve otomatik uygulanabilir birer artefakt haline gelir. Şunu söylemekte bir sakınca görmüyorum;

Bir mimari standart, ancak otomatik olarak doğrulanabildiği, uygulanabildiği ve ölçülebildiği kadar vardır. Geri kalanı iyi niyettir ve iyi niyet denetlenemez.

Buradan şu sonuca varmamak gerekiyor; bütün mimari kararlar otomatikleştirilmelidir. Bizim sorguladığımız otomatikleştirilmesi mümkün olanlar neden hala manuel yapılıyor.

Her standardın uygulama noktası aynı değildir

Bir API’nin üzerinde konuşulacak onlarca kural vardır. Bunları sınıflandırmadan konuşmak hepsini aynı mekanizmaya sıkıştırma hatasına yol açar. Aşağıdaki tabloda bir API’nin yönetişim yüzeyini ayrıştırmak için basit bir örnektir

| Katman             | Standart örneği               | Uygulama noktası     |
|--------------------|-------------------------------|----------------------|
| Tanım              | Geçerli bir OpenAPI tanımı.   | CI/CD                |
| İsimlendirme       | Adlandırma kuralları          | CI/CD (linter)       |
| Güvenlik           | Kimlik doğrulama zorunluluğu  | CI/CD + Runtime      |
| Trafik             | Rate limit profili            | Runtime              |
| Yönlendirme        | Backend adresi değil, alias   | CI/CD + Runtime      |
| Gözlemlenebilirlik | Correlation ID zorunluluğu    | Runtime              |
| Dayanıklılık       | Timeout ve bulkhead değerleri | Runtime              |
| Yaşam döngüsü      | Versiyonlama ve deprecation   | CI/CD                |
| Sahiplik           | Owner ve criticality metadata | Metadata doğrulaması |

Burada asıl dikkat edilmesi gereken şey tek bir kontrol noktası her şeyi çözmez. İsimlendirme kuralı CI/CD işidir. Tanım derlenmeden önce okunur. Kurala uymuyorsa PR geçmez. Runtime burada bir yorum yapmamalıdır.

Trafik profili ise direk runtime işidir. CI/CD tarafının tanımda “rate limit profili: HIGH” yazdığını doğrulayabilir ama bu profilin gerçekten uygunladığını ancak gateway bilir. Tanımın doğru olduğu uygulamanın doğru olduğu anlamına gelmez.

Güvenlik katmanı ise her iki uygulama noktasında da vardır. CI/CD tarafı bir güvenlik şeması tanımı olduğunu kontrol ederken runtime ise bu güvenlik şemasının gerçekten zorunlu kılındığını garanti eder.

Aynı yüzeye bilgi açısından bakmak

Yukarıda ki tablo teknik bir sınıflandırmadır. Aynı tabloya bir de bilginin nerede yaşadığı açısından bakmak tezimizin sınırını netleştirir. Önce ki yazılarımda bilginin kurumda nerede yaşadığını beş katmanda modellemiştir. Knowledge Ownership Model’de katmanlar şunlardı: mimari bilgi, entegrasyon bilgisi, operasyonel bilgi, konfigürasyon ve tuning, karar gerekçeleri. Modelin amacı, “bu sistemi biliyoruz” cümlesini parçalarına ayırmaktı; çünkü kurumlar genellikle bazı katmanlarda güçlü, bazılarında tamamen boştur.

API yönetişimini bu mercekten geçirdiğimizde ortaya şu çıkıyor:

Knowledge Ownership Model’e göre API yönetişim katmanları

Ortada ki üç katman otomatize edilebilir. Mimari bilgi ve Karar gerekçeleri ise insanda kalır. Burada birde dördüncü katmana dikkat çekmek isterim. Çünkü bir çok kurumun kör noktası burasıdır. Acil gelen bir talep ile gateway üzeride yapılmış olan manuel bir işlem hiçbir dokümanda olmaz ve daha sonra otomasyona dahil edilmez ise zamanla süreç yine baltalanmış olur. Bu katmanı versiyon kontrolüne taşımak Governance-as-Code’un en az konuşulan ama en somut kazancıdır.

Geliştirici neyi bilmelidir?

Otomatikleştirmede yapılan en büyük hata karmaşıklığı developer tarafına devretmektir. Kurallar oluşturulur ve developerlardan platformun teknik detaylarını belirtmesi istenir. Bu sayede maneul gözden geçirme ortadan kalkmış olur yerine de daha kötü birşey gelmiş olur. Şöyle bir tanım okuduğunuzu düşünün;

[ApiPolicy(
    RateLimit = 1000,
    RateLimitWindow = "1m",
    PolicyTemplate = "TrafficOptimization",
    TimeoutMs = 5000,
    AuthScheme = "oauth2-introspection")]
public class PaymentTransferApi { }

Burada geliştirme yapan kişinin platformun nasıl çalıştığını bilmesi beklenir. Rate limit değerinin ne olması gerektiğini, hangi politika şablonun uygun olduğunu, timeout’un kaç milisaniye olacağını geliştirici karara bağlıyor. Peki bu bilgileri nereden alacak? Ya dokümandan ya da yanında oturan arkadaşından öğrenecek. Arkadaşı ise ben böyle yaptım diyerek örneği gönderecek. Sonra umud edip sistemin stabil çalışması için dua edeceğiz. Peki aynı tanımın aşağıdaki gibi olduğunu varsayarsak nasıl olur;

[ApiGovernance(
    Domain = "payments",
    Exposure = Exposure.External,
    Criticality = Criticality.High)]
public class PaymentTransferApi { }

Daha önce belirttiğim kuralın kod tarafında ki karşılığı budur. Geliştirici teknik bir karar vermiyor. Bir mimari niyet belirtiyor. Bu API ödemeler alanına ait, kurum dışına açık ve kritiklik seviyesi yüksek. Bu üç bilgi developer tarafından bilinebilir ve hatta doğru bileceği tek şeydir. Teknik kararı ise platform veriyor.

Niyet
  Exposure    = External
  Criticality = High
        ↓
Mimari kurallar
        ↓
Güvenlik         = EXTERNAL_STRICT
Trafik profili   = CRITICAL
Gözlemlenebilirlik = STRICT

Bu ayrım kritiktir. Çünkü niyet yavaş değişir implementasyon ise hızlı değişir. API’nin kritikliği yılda bir kez değişir. Rate limit değerleri, güvenlik şemaları ve gateway politikaları çok daha sık değişir. Niyeti kodda, implementasyonu platformda tutmak, ikisinin farklı hızlarda yaşamasına izin verir.

Sürecin her halaksında niyetin biraz aşındığı duruma Niyet Kaybı diyebilirim. kaybın pratik ölçüsü basittir. Geliştiricinin platform detayını ne kadar bilmek zorunda kaldığı. İlk verdiğim örnekte kayıp yüksektir çünkü geliştirici niyeti değil sonucu yazıyor ve bu bilgi kendisinde kalıyor. Burada niyet kaybını azaltmak için kuralları bir dosyada yazılı olarak tutmak güvenlidir.

Kural bir dosyada olduğunda

Mimari kurallar insan diliyle yazıldığı sürece yorumlanabilir. Otomatik doğrulama sayesinde ise değerlendirilir. Aradaki fark yönetişim bütün ağırlığını taşır. Basit bir kural seti şöyle görünebilir;

rules:
  - when:
      exposure: internal
      criticality: high
    apply:
      security: INTERNAL_STRICT
      traffic: HIGH
      observability: STANDARD

  - when:
      exposure: external
      criticality: high
    apply:
      security: EXTERNAL_STRICT
      traffic: CRITICAL
      observability: STRICT

Artık bir wiki dokümanı olmaktan çıkmış ve kaynak dosya olmuştur. Kural artık versiyonlanıyor. “Bu kural ne zaman değiştir” sorusunun cevabı atılmış bir committir. “Neden değişti” sorusunun cevabı ise PR açıklamasındadır. “Kim onayladı” sorusuna da review kısmına bakarak cevap verebiliyoruz. Mimari yönetişimin yıllardır toplantı tutanaklarında aradığı izlenebilirlik aslında versiyon kontrolünün bedavaya verdiği bir özelliktir.

Kural artık test edilebiliyor. Bir kural setine örnek girdiler verip beklenen çıktıyı doğrulayabilirsiniz. “Kritikliği yüksek, dışa açık bir API için hangi profil çıkar?” sorusu bir birim testi olur. Ve kural artık geri alınabiliyor. Yanlış bir yönetişim değişikliği bir sonraki deploy’a kadar beklemek zorunda değil. Elbette sadece bu yapının olması yeterli değildir. Bunun da kontrol edilmesi gerekmektedir. Genelde tavsiyem üç kontrol noktasının oluşturulmasıdır.

Üç Kontrol Noktası

Kuralların otomatik doğrulaması yetmez. Nerede çalıştığı da önemlidir. Bunu da üç noktada kontrol edebiliriz.

Tasarım Anında (Design Time): API tanımı doğrulanır. Geçerli bir şema var mı, isimlendirme kurallarına uyuyor mu, zorunlu metadata alanları dolu mu? Bu aşama development yapılan ortamda çalıştığında en verimli olduğu andır. Çünkü hata yazıldığı anda görünür.

Derleme Anında (Build Time): Mimari uyum kontrol edilir. Niyet okunur ve tanımlanan kurallar ile eşleştirilir. Tanımlanan profil ile beklenen profil karşılaştırılır.

Architecture Compliance: FAILED

  Rule      GOV-SEC-003
  API       payment-transfer-api
  Violation Dışa açık API'ler ANONYMOUS güvenlik profiliyle
            yayınlanamaz.
  Required  EXTERNAL_STRICT
  Ref       docs/standards/security.md#external-apis

Bu çıktısının değeri hatayı bulmasından dolayı değildir. Hatayı doğru zamanda ve doğru kişiye göstermesindendir. Aynı ihlalin üç dört hafta sonra bir review esnasında fark edilmesi maliyeti çok daha fazla arttırabilir.

Çalışma Anında (Runtime): Burada kural fiilen uygulanır. Kimlik doğrulama, yetkilendirme, rate limiting, yönlendirme vb. CI/CD’nin garantileyemeyeceği kısımlar. Pipeline kısmı konfigürasyonu doğrularken gerçekten uygulandığını kontrol edemez.

Şunu da belirtmekte fayda var. Bir API tanımının kurallara uyması o kuralların gateway’de uygulandığı anlamına gelmez. Tanım dosyasını denetlemek ile çalışan sistemi denetlemek aynı şey değildir. Birincisi niyeti doğrularken ikincisi gerçekliği denetler. Sadece birincisini kuran kurumlar uyum raporunda yeşil görünürken production’da açıkta kalabilir.

Peki Governance-as-Code’un bir bedeli yok mu? Birazda bundan bahsedelim.

Governance-as-Code’un Bedeli

Governance-as-Code’un bana göre üç bedeli vardır.

Birincisi: oluşturulan rule engine (kural motoru) zamanla eskir. Yazılmış olan kurallar bakımsız kalır ve ekipler kuralı öğrenmektense bu kuralı atlamanın yolunu öğrenir. Bir wiki sayfasında duran doküman eskidiğinde bunu kimse fark etmez ama pipeline tarafında sürekli aynı hatayı görüp düzeltmediğimizde herkesin gördüğü uyarı artık görmezden gelinen ve hızlıca geçilen bir ifadeye dönüşür.

İkincisi ise yönetişim aracınında bir bağımlılık üretmesidir. Kuralları belirli bir ruleset formatında yazdığınızda o formatın ekosistemine bağlanmış olursunuz.

Üçüncüsü: her kural bu maliyeti hak etmez. Yılda iki kez ihlal edilen bir kuralı otomatikleştirmenin maliyeti, ihlallerin maliyetinden yüksek olabilir. Otomasyon kararı da bir mimari karardır ve gerekçesi yazılmalıdır.

İstisnaların Yönetimi

İstisnaslar bir arıza gibi görünmemelidir. Bunları bir özellik olarak ele almamız süreçlerin daha hızlı ilerlemesini sağlar. Mimari yönetişim hiçbir zaman herşeyi %100 kurala bağlayıp %0 istisna üzerine bir süreç hayal etmez. Çünkü böyle bir hedef ilk gerçek iş ihtiyacında ya kırılır ya da görmezden gelinir. Yüksek hacimli bir ödeme akışı standart trafik profiline sığmayabilir. Devralınan bir sistem, isimlendirme kuralına bugün uyduramayacağınız bir yüzeye sahip olabilir. Burada bilinmesi gereken istisna olan şeylerin sorun olması değildir. Eğer bu durumlar kayıt altına alınmazsa sorun olur.

exceptions:
  - rule: TRAFFIC_STANDARD
    api: payment-batch-settlement
    requestedProfile: CRITICAL
    reason: >
      Gün sonu toplu mutabakat penceresinde
      standart profil yetersiz kalıyor.
    owner: payments-platform-team
    approval:
      architectureDecision: ADR-1427
    expires: 2027-01-01

Yukarıda “reason” ile bir istisnayı görünür hale getiriyoruz. İstisnasının kime ait olduğunu, gerekçesini, onay kararını, son kullanma tarihini bu yapıda görebiliyoruz. İşin güzel tarafı bu versiyonlandığı için denetim izide kendiliğinden oluşuyor.

Beş bilgi katmanına geri dönersek: karar gerekçeleri katmanı, makinenin üretemeyeceği ama zorunlu kılabileceği tek katmandı. İstisna yönetimi tam olarak budur. Makine gerekçeyi yazamaz; ama gerekçe yazılmadan ilerlenmesine izin vermeyebilir. Süresi dolmuş bir istisna, artık istisna değildir.

Beyandan Kanıta

Bütün bunların sonunda ne elde ediyoruz? Yazının başındaki soruya dönme vakti geldi: production’daki 500 API’nin standarda uyduğunu nasıl ispatlarız?

Cevap bir tablodur. Ama nasıl bir tablo?

Production API sayısı                ~500
Mimari uyum                          ~%95
Güvenlik uyumu                       %100
Trafik profili uyumu                 ~%97
İsimlendirme uyumu                   ~%96

Onaylı istisna                          18
Süresi dolmuş istisna                    3
Onaysız sapma                            8

Yukarıda ki tablonun son üç satırı bilginin olduğu kısımdır. Burada Onaysız Sapma olarak belirttiğim kısım aslında “ne kurala uyan ne de onaylı bir istisnası olan konfigürasyonu” temsil etmektedir. Yönetişimin gerçek karneside bu sayıdır. Çünkü uyum yüzde çok hızlı yükseltilebilir. Kuralı gevşetir, kapsamı daraltır ve sert kuralların alarm seslerini kıstığınızda bu yüzde hızlıca artar. Halbu ki oanysız sapma sayısını bu gevşetlemelerle azaltamazsınız. Yz düzeltirsiniz ya da gerekçesini yazıp onaylanmış istisnaya çevirirsiniz.

Mimari yönetişimin olgunluğu, beyan ettiği şeyle kanıtlayabildiği şey arasındaki farkla ölçülür.

Burada bir uyarıda bulunmak istiyorum. Bu tablo eğer bir performans karnesine dönüşürse ölçtüğü şeyi ölçmeyi bırakır. Başka bir yazıda değindiğim Goodhart Yasasını hatırlatmakta fayda var.

Bir ölçüt hedefe dönüştüğünde ölçüt olmaktan çıakr. Uyum oranı bir KPI haline geldiğinde ne olacağını tahmin etmek için kahin olmaya gerek yoktur. Kurallar yazılır, zor kurallar uyarı seviyesine indirilir, istisna talepleri enflosyana uğrayıp gerekçe alanlarınada “iş gereksimi” yazılıp kapatılır. Altı ay sonra elimizde kağıt üzerinde %99 uyumlu bir portföy ve hiçbir şey ifade etmeyen bir dashboard olur. Bu ölçümün amacı mimari kaliteyi puanlamak değil, nerede durduğunuzu bilmek. Tespit aracı, değerlendirme aracı değil.

Tespit aracı, bir değerlendirme aracı değildir.

Peki bu süreçleri otomatikleştirdiğimizde mimarlar işsiz mi kalacak? Ne yapacak bu kadar mimar?

Mimarın işi ne olur?

Yönetişimin otomatize edilmiş olması mimarın işini azaltmaz sadece değiştirir. Bugün pek çok kurumda mimari kurul, her implementasyonu gözden geçiren bir merci olarak çalışıyor. Gündemin önemli bir kısmı, aslında makine tarafından cevaplanabilecek sorularla geçiyor: bu API’nin kimlik doğrulaması var mı, isimlendirme kurallarına uygun mu, metadata’sı dolu mu?

Bu sorular gündemden çıktığında geriye kalan iş şu:

Kuralı tasarlamak. Kuralı yönetmek. Kuralın etkisini ölçmek ve istisnaları karara bağlamak.

Bunların hiçbiri otomatikleştirilemez, çünkü hiçbiri ikili bir cevaba sıkışmaz. Bir kuralın kuruma uygun olup olmadığı, bir istisnanın gerekçesinin yeterli olup olmadığı, bir sistemin sınırının doğru çizilip çizilmediği, bunlar yargı gerektiren sorular. Otomasyon, mimarı bu sorulara geri gönderiyor.

Sonuç olarak standart yazılabilir, onaylanabilir ve yayınlanabilir. Ama uygulandığı gösterilemiyorsa o standart sadece bir beyandır.

Bu yazıda anlattığım model bir araç seçimi değil, bir sıralama önerisi: önce kuralın nerede yaşadığını sorun, sonra nerede uygulandığını ve en sonunda nasıl ölçüldüğünü. Bu üç sorunun cevabı olmadan kurulan hiçbir yönetişim modeli, kurumun kendisi hakkında doğru bilgi üretmez.

Peki mimari niyeti geliştiriciden minimum efor ile nasıl toplarız? Bu niyeti platformdan bağımsız bir modele nasıl çeviririz? Ve aynı niyeti farklı gateway ailelerinde nasıl aynı sonuca dönüştürürüz? Bir sonraki yazıda bunun çalışan bir implementasyonunu kuracağız. Açık kaynak olarak tasarladığım ve şuanda test ettiğim modülün nasıl çalıştığını irdeleyip çıktısını inceleyeceğiz. Buraya kadar okuyup zaman ayırdığınız için teşekkür ederim. Geri dönüşleriniz benim için değerlidir.

Kaynaklar

• TOGAF — Architecture Compliance (uyum düzeyleri ve uyum gözden geçirme süreci): https://pubs.opengroup.org/architecture/togaf91-doc/m/chap48.html
• OpenAPI Specification: https://spec.openapis.org/oas/latest.html
• Architecture Decision Records — Michael Nygard, “Documenting Architecture Decisions” (2011, kavramı ortaya koyan özgün yazı): https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
• ADR topluluk merkezi: https://adr.github.io/
• Knowledge Ownership Model — beş katmanlı bilgi modelinin tanımlandığı yazı: https://medium.com/@omurucum/knowledge-ownership-model-bilgi-ger%C3%A7ekten-kimin-9a36028ac7d0