Solution Architect rolüne geçiş, tek bir sertifika ya da kursla olmuyor; kod yazma becerisinin ötesinde farklı bir bakış açısı geliştirmeyi gerektiriyor. Bu geçişte öne çıkan somut adımlara bakalım.
Tek Projeden Birden Fazla Projeye Bakabilmek
Geliştirici rolünde tek bir projenin detaylarına odaklanmak yeterli olabiliyor. Mimari düşünmeye geçişte, birden fazla projenin/servisin birbirleriyle nasıl etkileşime girdiğini, ortak altyapı ihtiyaçlarını görebilmek gerekiyor. Bakış açısı "bu fonksiyon nasıl çalışır"dan "bu sistemler bir arada nasıl ölçeklenir"e kaymalı.
Teknoloji Seçimlerini Gerekçelendirebilmek
Bir teknolojiyi "popüler olduğu için" değil, projenin gereksinimlerine (ölçeklenebilirlik, ekip yetkinliği, bakım maliyeti) göre seçmek önemli. Her mimari kararı yazılı olarak gerekçelendirmek (bir ADR - Architecture Decision Record yazmak gibi), hem kararları netleştiriyor hem de gelecekte "neden böyle yapılmıştı?" sorusuna cevap veriyor.
İş Birimiyle Aynı Dili Konuşabilmek
Solution Architect rolünün büyük bir kısmı, teknik kararları iş birimine anlaşılır şekilde anlatabilmekle ilgili. "Mikroservis mimarisine geçelim" demek yerine, "bu değişiklik şu iş riskini azaltır, şu maliyeti getirir" diye konuşabilmek gerekiyor.
Kod Yazmaktan Vazgeçmeden Mimari Düşünmek
Mimari rolüne geçerken kod yazmayı tamamen bırakmamak faydalı oluyor; kod yazmaya devam etmek, alınan mimari kararların gerçekte uygulanabilir olup olmadığını test etmeyi sağlıyor. Sadece diyagram çizen bir mimar olmaktan kaçınmak önemli.
Sonuç
Solution Architect olmak, daha iyi kod yazmaktan çok, daha geniş bir bağlamda düşünebilme ve bu düşünceleri hem teknik ekibe hem iş birimine anlaşılır şekilde aktarabilme becerisiyle ilgili.