Yazılım Mimarı CV Şablonu: Trade-off Defterinden Etki Haritasına, Mimari Zihniyeti Özgeçmişe Taşıma Rehberi

Bir yazılım mimarı işe alırken, referans olarak en son yazdığı sınıf değil. O sınıfın neden var olduğuna dair açıklama istenir. Zira mimarın elindeki en hatırı sayılır ürün çalışan kod değil, o koda giden yolun haritasıdır. İşte bu yüzden yazılım mimarı özgeçmişi, klasik bir teknik CV'den farklı düşünülmesi gereken bir belgedir. Aslına bakılırsa, bu yazı, bir mimarın CV'sinde nelere yer vermesi ve neleri sessizce dışarıda bırakması gerektiğini. Başka hiçbir kaynakta bu sırayla bulamayacağınız bir çerçevede ele alıyor.

Yazılım mimarı kimdir, yazılım mühendisinden farkı nedir?

Yazılım mimarı, kodu yazan kişi değil; o kodun neden o şekilde yazıldığını belirleyen kişidir. Mühendis probleme çözüm üretir, mimar ise o çözümün on yıl sonra da ayakta kalıp kalamayacağını sorgular. Bu nedenle iki rolün CV'si aynı şablonla yazılamaz.

Bir yazılım mühendisinin özgeçmişinde "X framework'ü ile Y özelliği geliştirdim" cümlesi yeterli olacaktır. Bir mimar içinse aynı cümle fakat şu hale geldiğinde anlam kazanır: "X framework'ünü seçerken Y alternatiflerini değerlendirdim. NFR gereksinimleri nedeniyle Z trade-off'unu kabul ettim. Sistem ölçeklenebilirlik hedefine ulaştı." Görüldüğü gibi mimarın anlatısında teknoloji değil, karar vardır.

Genelde, bu ayrımı anlamadan yazılan her yazılım mimarı CV'si, aslında "kıdemli yazılım mühendisi CV'si" olmaktan öteye geçemez. İK ekipleri bunu sezgisel olarak ayrım eder; hatta bazen mimar unvanı taşıyan fakat mimari karar anlatısı olmayan özgeçmişleri doğrudan eler. Bu yüzden ilk hamle, mimar rolünün ne olduğunu kendinize netleştirmektir.

CV'nin Merkezine Teknoloji Değil Karar Almak

Yazılım mimarı CV şablonu arayan çoğu kişi. İnternette "mimari CV örneği" diye arar ve karşısına teknoloji listesiyle dolu belgeler çıkar. Aslına bakılırsa, oysa teknoloji listesi, mimar için başlangıç noktasıdır, varış noktası değil. Bir mimarın özgeçmişinde okuyucu şu sorulara cevap bulmalıdır:

• Bu kişi hangi koşullarda hangi teknolojiyi seçti?
• Bu seçimin bedeli ne oldu ve kimlerle müzakere edildi?
• Zaman içinde seçimini değiştirdiyse, bunu hangi veriye dayanarak yaptı?

Bu sorulara cevap vermeyen bir CV, mimarı değil kıdemli geliştiriciyi anlatır. Mimar CV'sinin merkezinde "karar alma anları" yer almalıdır. Bu anlar kimi zaman bir mimari karar günlüğünde (ADR) yazılıdır. Şöyle ki, bazen bir RFC dokümanında, bazen bir retrospektif notunda. CV, bu kaynaklardan beslenen kısa ve öz bir özettir.

Mimari karar günlükleri (ADR) özgeçmişte nasıl anlatılır?

Mimari Karar Günlüğü (Architecture Decision Record), yazılım mimarlığının en somut çıktılarından biridir. Pek çok mimar ADR yazar ancak bunu CV'ye taşımayı unutur. Oysa ADR, mimarın ne düşündüğünü değil, neyi neden düşündüğünü gösteren en güçlü kanıttır.

CV'de ADR anlatmak için iki yaklaşım vardır. Birincisi, belirli bir projedeki kritik kararları cümle içinde mektir. Şöyle ki, ikincisi, ADR yazımını bir yetkinlik olarak ayrı bir bölümde belirtmektir. İkisi de işe yarar, ne var ki birincisi her zaman daha etkileyicidir zira kararın bağlamını da taşır.

Trade-off Cümlelerinin Anatomisi

İyi yazılmış bir mimari cümlesi, okuyucuya üç şey verir: bağlam, seçenek, sonuç. Mesela:

Çoğu durumda, "Sipariş yönetimi modülünde event sourcing yaklaşımını benimsedik; bu karar. Audit trail ihtiyacı ile write amplification arasındaki trade-off sonucu olgunlaştı."

Bu cümlede "neden event sourcing" sorusu cevaplanmış, alternatifler ima edilmiş ve iş sonucu sezdirilmiştir. Mimar CV'sinde her cümle bu üçlüyü içermelidir. Eğer bir cümle yalnızca "X teknolojisini kullandım" diyorsa, o cümle mühendis CV'sinde yer almalıdır, mimar CV'sinde değil.

Genelde, burada dikkat edilmesi gereken nokta, trade-off anlatısının kibir içermemesi gerektiğidir. Mimar sürekli isabetli kararı vermiş gibi yazmamalı; geçmişte yanıldığı. Geri hamle attığı durumları da mütevazı bir dille anlatabilmelidir. Genelde, bu tür dürüstlük, bilhassa kıdemli mimar arayan ekipler için altın değerindedir.

NFR pusulası: hız, güvenilirlik, ölçeklenebilirlik

Pratikte, yazılım mimarı deyince akla ilk gelen kavramlardan biri NFR bir başka deyişle işlevsel olmayan gereksinimlerdir. Yanıt süresi, erişilebilirlik, ölçeklenebilirlik, güvenlik, gözlemlenebilirlik; bunlar fonksiyonel olmayan ancak mimarın birincil sorumluluğunda olan başlıklardır.

Mimar CV'sinde NFR'lerin anlatımı. Şöyle ki, çoğu zaman ya göz ardı edilir ya da "yüksek erişilebilirlikli sistem" gibi jenerik ifadelerle geçiştirilir. Oysa okuyucu, somut olanı duymak ister. Hangi iş yükü için ne tür bir NFR hedefi belirlendi? Bu hedefe ulaşmak için hangi mimari kalıplar kullanıldı? Hedef tutturulamadıysa neden?

NFR anlatısı, mimarın bir kalite mühendisi mi yoksa bir vizyon sahibi mi olduğunu ortaya koyar. Somut NFR cümleleri, vizyonun gerçekçi olduğunu gösterir. Çoğu durumda, mesela "ödeme servisinde p99 gecikme hedefi 200 ms olarak belirlendi ve bu hedefe circuit breaker kalıbı ile ulaşıldı" cümlesi. "yüksek performanslı sistem tasarladım" cümlesinden on kat daha değerlidir.

Genelde, aynı şekilde, NFR'lerin birbiriyle çeliştiği durumları anlatmak da güçlü bir anlatıdır. Tutarlılık ve erişilebilirlik arasındaki CAP teoremi gerilimi. Gecikme ve throughput arasındaki denge, maliyet ve gözlemlenebilirlik arasındaki ödünleşim; bunlar mimarın günlük dünyasının gerçekleridir. CV'de bu tür gerilimlerin yer alması, okuyucuya "bu kişi gerçekten mimari düşünüyor" mesajını verir.

Domain sınırları ve modüler düşünce

Yazılım mimarı, kodu değil domain'i şekillendiren kişidir. Net konuşmak gerekirse, dolayısıyla CV'de domain modelleme yetkinliği, teknoloji bilgisinden daha ön planda olmalıdır. Domain-Driven Design bilgisi, bounded context yaklaşımı, ubiquitous language pratiği; bunlar mimarın dilinin temel kelimeleridir.

Ancak burada dikkat edilmesi gereken bir ayrım var: mimar. DDD'yi bilen kişi değil, DDD'yi nerede uygulanabilir, nerede uygulanamaz bilen kişidir. Sahada, her projede bounded context çıkarmaya çalışan bir mimar, mimariyi abartmış demektir. CV'de bu ayrımı göstermek için "X domain'inde bounded context ayrımını uyguladım. Pratikte, y domain'inde ise monoliti tercih ettim zira..." tarzı cümleler çok etkili olur.

Modüler düşüncenin CV'ye yansıması, proje anlatımlarında kendini ortaya koyar. Her projede "hangi modüller ayrıldı, neden ayrıldı, bu ayrım zaman içinde nasıl evrildi" soruları cevaplanmalıdır. Sadece "mikroservis mimarisi tasarladım" yazmak, o mikroservislerin neden o şekilde bölündüğünü anlatmamak, CV'yi sığ bırakır.

Gerçekte, teknoloji radarı: her şeyi bilmek değil, doğru şeyi seçmek

Yazılım mimarı CV'lerinin en sık düştüğü tuzaklardan biri, "biliyorum" listesini mümkün olduğunca uzatmaktır. Mimar, her şeyi bilen kişi değil, yerinde zamanda doğru teknolojiyi seçen kişidir. Teknoloji radarı konsepti burada güzel bir metafor sunar: Adopt, Trial, Assess, Hold.

CV'de teknoloji radarı mantığı, üç şekilde yansıtılabilir. Birincisi, "X'i denedim, Y'ye geçtim, gerekçem Z" formatında öğrenme anlatısı. İkincisi, belirli bir teknoloji için "denedik, beğenmedik, geri döndük" cesur cümlesi. Sahada, üçüncüsü, bir teknolojiyi "henüz denemedim ama takip ediyorum" diye belirtmek, ki bu da dürüstlüğü ortaya koyar.

Bu noktada bir parantez açmak iyi olur: mimar, sürekli yeni framework öğrenen kişi değildir. Pratikte, mimar, sektörel trendleri takip eden, ne var ki bunları kurumun bağlamına oturtan kişidir. CV'de her satıra güncel teknoloji yazmak yerine, birkaç kritik teknoloji üzerine derinlemesine anlatı kurmak çok daha değerlidir.

Diyagram ve modeller: görsel anlatı gücü

Yazılım mimarı, soyut düşünür. Fakat bu soyut düşünce, somut bir artefata dökülmediği sürece ekip için anlamsızdır. Açıkçası, c4 modeli, UML diyagramları, sequence diyagramları, mimari haritalar; bunlar mimarın ekibine bıraktığı en önemli miraslardır.

Pratikte, cV'de bu yetkinliği anlatmak için iki yol vardır. Birincisi, portföy benzeri bir GitHub veya kişisel blog bağlantısı eklemektir. Açıkçası, ikincisi, belirli bir proje anlatımında "sistem mimarisini C4 modeli ile dokümante ettim" gibi somut cümleler kullanmaktır. İkinci yol, portföye erişimi olmayan işveren için de geçerli olduğundan daha sağlıklıdır.

Diyagram anlatısının gücü, mimarın iletişim becerisini de yansıtır. Çünkü bir diyagram çizmek, yalnızca teknik bilgi değil, hedef kitleye göre sadeleştirme becerisi gerektirir. Yönetim kuruluna göstereceğiniz diyagram ile geliştirici ekibine göstereceğiniz diyagram aynı değildir. CV'de bu farkındalığı yansıtan cümleler, mimarın ekip içindeki gerçek rolünü ortaya koyar.

Paydaş iletişimi: mimarın görünmeyen yüzü

Yazılım mimarı CV'lerinin en büyük eksikliği, paydaş iletişiminin göz ardı edilmesidir. Oysa mimar, günde belki birkaç saat kod yazarken, saatlerini toplantılarda. RFC yorumlarında, ürün yöneticisi ile tartışmalarda ve CFO'ya teknik borç sunumlarında geçirir. Bu görünmeyen mimar yüzü, CV'de en az teknik yüz kadar yer almalıdır.

Paydaş iletişimi anlatırken dikkat edilmesi gereken, jargondan kaçınmaktır. "Mimari sunum yaptım" yerine "iş birimi için trade-off dokümanı hazırladım. Bu doküman sayesinde bütçe onayı alındı" yazmak, iletişimin somut etkisini gösterir.

Burada sık yapılan hata, paydaş iletişimini sadece "sunum yaptım" cümleleriyle süslemektir. Sahada, oysa mimarın gerçek iletişim başarısı, kararların kabul görmesi, direnişin yönetilmesi ve çatışan çıkarların uzlaştırılmasıdır. CV'de bu tür durumlar kısa da olsa yer aldığında, mimarın kurum içindeki gerçek etki çevresi gözükür.

Teknik borç yönetimi: sessiz bir müzakere

Teknik borç, yazılım mimarının günlük gerçekliğidir. Kısaca, ancak CV'lerde çoğu zaman ya hiç bahsedilmez ya da "teknik borcu azalttım" gibi yüzeysel cümlelerle geçilir. Oysa teknik borç anlatısı, mimarın en güçlü anlatılarından biri olabilir.

İyi bir teknik borç anlatısı şu unsurları içerir: borcun nasıl ayrım edildiği. Ödemenin hangi koşullarda ertelendiği, hangi koşullarda öncelik aldığı, ödeme sırasında kullanılan strateji ve ödemenin iş tarafına etkisi. Bu unsurların herhangi birinin eksik olması, anlatıyı zayıflatır.

Mimar, teknik borcu yönetirken çoğunlukla iki taraf arasında denge kurar: bir yanda hız, diğer yanda sürdürülebilirlik. CV'de bu dengenin nasıl kurulduğunun anlatılması, mimarın yönetici yönünü de ortaya koyar. Net konuşmak gerekirse, zira teknik borç, salt teknik bir mesele değil, iş kararları ile iç içe geçmiş bir müzakere konusudur.

Mentorluk ve standart belirleme

Şöyle ki, yazılım mimarı, çoğu zaman bir ekibin teknik pusulasıdır. Bu pusulayı kurmak, yalnızca mimari kararlar vermekle değil, ekibin gelişimine katkıda bulunmakla olur. Aslına bakılırsa, mentorluk, kod inceleme standartları, mühendislik prensiplerinin belirlenmesi; bunlar mimarın kurumda bıraktığı izlerdir.

CV'de mentorluk anlatırken, sahiplenicici bir dil yerine sistem-kurucu cümleler tercih edilmelidir. Bir noktada, "Ekip için pair programming oturumları organize ettim", "design review kültürü oluşturdum". "mimari prensipler dokümanı hazırladım" gibi cümleler. Mimarın asıl başarısının tek bir kişiyi değil, bir ekibi dönüştürmek olduğunu kanıtlar.

Standart belirleme ise mimarın yazılı mirasıdır. Belirli bir test kapsama hedefi, API tasarım prensipleri. Kod stili kuralları, Git workflow standartları; bunlar mimarın ekibinde bıraktığı somut eserlerdir. Somut olarak, cV'de bu standartların varlığı, mimarın kurumda kalıcı bir etki yarattığını gösterir.

Mimarın CV'sinde Sayılar ve Ölçüm

Yazılım mimarı CV'lerinde sayı kullanımı hassas bir dengedir. Mühendis CV'sinde satır sayısı gibi saçma metrikler yer alabilir fakat mimar CV'sinde sayılar, etki ile orantılı olmalıdır. Çoğu durumda, performans iyileştirmesi, maliyet tasarrufu, ekip büyümesi, sistem ölçeği gibi metrikler anlamlıdır. "X framework'üne üç yıldır kullanıyorum" gibi süre sayıları ise mimar için anlamsızdır.

Sahada, sayı kullanırken dikkat edilmesi gereken, mümkünse sayının bağlamını da vermektir. "Latency'i yüzde kırk azalttım" cümlesi tek başına müphemdir. "p99 latency'i 800 ms'den 480 ms'ye düşürdüm, bu daödeme başarı oranını artırdı" cümlesi ise somut ve inandırıcıdır. Mimar, sayıları bağlamıyla birlikte sunar.

Bu noktada bir uyarı: uydurma veya abartılmış sayılar, mimar CV'sinde telafisi çetrefilli hasar bırakır. Somut olarak, mülakatta bu sayıların nasıl ölçüldüğü sorulduğunda tutarsız cevap vermek, mimarın güvenilirliğini sarsar. Bu nedenle CV'deki her sayı, mülakatta savunulabilir olmalıdır.

Sık yapılan hatalar

Yazılım mimarı özgeçmişlerinde tekrar eden hataları bir liste halinde vermek, bu yazının en pratik bölümlerinden biri olabilir. Şimdi sıralayalım:

• Aslına bakılırsa, teknoloji çöplüğü: 30+ teknoloji listelemek, mimarın derinliksizliğini gösterir. Her satıra teknoloji yazmak yerine, kritik olanları seçip açıklamak daha değerlidir.
• Net konuşmak gerekirse, sadece işlevsel anlatı: "Müşteri paneli geliştirdim" cümlesi mühendis anlatısıdır. Mimar anlatısı, işlevin arkasındaki kararı içermelidir.
• Etkisiz trade-off: "X seçtik zira iyiydi" gibi gerekçesiz seçim anlatıları, mimarın gerçek bir karar almadığını düşündürür.
• Diyagramsız mimar: Hiçbir diyagram artefaktına atıf yapmamak, mimarın somut bir çıktı bırakmadığını gösterir.
• İletişimsiz mimar: Yalnızca teknik cümlelerle dolu, paydaş ve ekiple iletişimden bahsetmeyen CV'ler, "kod odaklı mühendis" izlenimi verir.
• Statik CV: Mimari kararlar zaman içinde evrilir. CV'de bu evrimi yansıtmamak, mimarın zaman içinde öğrenmediğini düşündürür.
• Kısaca, sertifika şovu: Sertifikalar mimar için mühim olabilir fakat birbirinin tekrarı niteliğindeki sertifikaları alt alta dizmek. CV'yi reklam broşürüne çevirir.

Bu hataların ortak noktası, mimarın neyi bildiğine odaklanıp neyi yaptığını göz ardı etmesidir. Çoğu durumda, oysa mimar CV'si, bilgi vitrini değil, karar günlüğüdür.

CV şablonunuzda bulunması gereken bölümler

Şimdiye kadar mimar CV'sinin ruhunu anlattık. Şimdi iskeletine, diğer bir ifadeyle bölümlerine bakalım. Bir yazılım mimarı CV şablonu, klasik bir teknik CV'den değişik olarak şu bölümleri içermelidir:

Profesyonel Özet

Kısaca, üç-dört cümlelik bir özet, mimarın ne tür sistemlerle çalıştığını. Hangi ölçekte kararlar verdiğini ve hangi alanlarda derinleştiğini melidir. Sahada, "10+ yıllık deneyimli yazılım mimarıyım" gibi cümleler yerine, somut bağlam veren cümleler tercih edilmelidir.

Temel yetkinlik alanları

İşin aslı, teknoloji listesi değil, "mimari karar verme", "NFR optimizasyonu", "domain modelleme", "teknoloji seçimi", "paydaş iletişimi" gibi yetkinlik kümeleri. Her kümenin altında bir-iki destekleyici cümle olabilir.

Kritik projeler ve karar anlatıları

Bu bölüm, CV'nin kalbidir. Sahada, her projede: bağlam, mimarın rolü, kritik kararlar, sonuç ve öğrenilen ders anlatılmalıdır. Projeler kronolojik olmak zorunda değildir; etki sırasına göre de sıralanabilir.

Teknik borç ve modernizasyon çalışmaları

Bu bölüm çoğu CV'de eksiktir. Oysa mimar için en değerli projelerden biri, eski bir sistemin dönüşümüdür. Bu bölümde strateji, süreç ve sonuç anlatılmalıdır.

Mimari artefaktlar ve dokümanlar

ADR'ler, RFC'ler, mimari prensipler dokümanları, diyagram kütüphaneleri. Bu artefaktlar, mimarın somut çıktılarıdır. CV'de "ekibe bıraktığım eserler" olarak nebilir.

Mentorluk ve organizasyonel etki

Bu bölüm, mimarın kurumda bıraktığı insan tarafı etkiyi gösterir. Ekip büyütme, design review kültürü oluşturma, mühendislik prensipleri yerleştirme gibi başlıklar buraya yazılabilir.

Konuşmalar, yayınlar, açık kaynak

Mimar için opsiyonel fakat değerlidir. Genelde, bir blog yazısı, bir konferans konuşması, açık kaynak bir kütüphane, mimarın sektörel etkisini kanıtlar. Burada kayda değer olan, nicelik değil niteliktir.

Yazılım mimarı CV örneği: kısa bir yapı

Şimdiye kadar anlattıklarımızı somutlaştırmak için kısa bir iskelet örnek verelim. Tabii ki gerçek CV'niz bu iskeletten çok daha zengin olmalıdır, fakat yapı şöyle düşünülebilir:

1. Başlık: Yazılım Mimarı, uzmanlık alanı (ör. Dağıtık sistemler, domain-driven tasarım).
2. Özet: Hangi tür sistemlerde, hangi ölçekte mimari rol üstlendiğinizin iki-üç cümlelik özeti.
3. Temel Yetkinlikler: Dört-altı ana yetkinlik alanı, her birinin altında bir-iki cümle.
4. Deneyim: Üç-dört kritik proje, her biri için bağlam-rol-karar-sonuç formatında.
5. Kısaca, mimari Artefaktlar: İki-üç somut eser (ADR kütüphanesi, mimari prensipler dokümanı, diyagram seti).
6. Mentorluk: Ekip gelişimine katkı, kültür oluşturma çalışmaları.
7. Net konuşmak gerekirse, teknik Borç Projeleri: Varsa en az bir modernizasyon veya borç ödeme anlatısı.
8. Konuşma ve Yayın: Opsiyonel olarak sektörel etki kanıtları.

İşin aslı, bu iskelet, "cv şablon" arayanlar için sağlam bir başlangıç noktasıdır. Üzerine kendi bağlamınızı eklemek size kalır.

Mimar özgeçmişinde ATS uyumu

Teknik roller için ATS uyumu, yazılım mimarı CV'leri için de geçerlidir. Şöyle ki, fakat mimar CV'sinde ATS uyumu, sadece anahtar kelime yerleştirmekten ibaret değildir. ATS'nin okuyabildiği formatta yazmak, kritik karar cümlelerini korumak kadar gerekir.

Mimar CV'sinde ATS için dikkat edilmesi gereken başlıklar şunlardır: başlıkların standart isimlerle yazılması ("Deneyim". "Eğitim", "Yetkinlikler"), tabloların ve grafiklerin kaçınılması, standart font ve punto kullanılması, PDF olarak gönderilmesi. Bu teknik detaylar, CV'nin okunmasını sağlarken, asıl anlatının gücü başka bir şeydir: karar günlüğü.

Anahtar kelime olarak "yazılım mimarı", "mimari karar", "domain-driven design", "NFR", "ADR" gibi terimler, ATS tarafından yakalanabilir. Fakat bu terimler cümle içinde doğal olarak yer almalı, anahtar kelime yığınına dönüşmemelidir. ATS geçerli, insan ikna edici bir CV, mimar CV'sinin altın standardıdır.

Sonuç yerine bir pusula

Somut olarak, bu yazıyı bir "sonuç" cümlesiyle bitirmek yerine, sınırlı bir pusula bırakmak istiyorum. Yazılım mimarı CV'nizi yazarken kendinize şu soruları sıkıntı:

• Bu cümle, bir kıdemli mühendis CV'sinde de olabilir mi? Cevap evetse, o cümleyi yeniden yazın.
• Sahada, bu cümle, hangi kararı hangi seçenekler arasında verdiğimi gösteriyor mu? Hayırsa, cümleyi genişletin.
• Kısaca, bu cümle, iş tarafına etkiyi somut olarak taşıyor mu? Hayırsa, etkiyi dahil edin.
• Bu cümle, mimarın yalnızca kod yazan değil, yön gösteren kişi olduğunu yansıtıyor mu? Hayırsa, cümleyi yeniden kurgulayın.

Bu dört soruya cevap verebilen her cümle, mimar CV'sinin haklı bir cümlesidir. Diğerleri ya mühendis CV'sinde ya da yönetici CV'sinde yer almalıdır. Mimar CV'si, kendine özgü bir belgedir; zira mimar, yazılım dünyasında kendine özgü bir roldür.

Bu yazı süresince bir yazılım mimarı CV şablonu arayışının aslında ne aradığını açıklamaya çalıştım: sadece bir format değil. Bir mimari anlatı kurgusu. Formatı herhangi bir modern CV şablonundan alabilirsiniz, ne var ki anlatı kurgusu mimarın kendi zihninden çıkmalıdır. Bu yüzden CV şablonunuz hazır olduğunda, içini doldurmak için kendi karar günlüklerinize geri dönün. Orada, CV'nizde yazmanız gereken cümlelerin çoğu zaten yazılmış durumda.