İş Analisti aslında bir Çözüm Mimarı mıdır?

Hayır, İş Analisti bir Çözüm Mimarı değildir, ancak Çözüm Mimarı'nın stratejik ortağıdır.

İş Analisti ile Çözüm Mimarı arasındaki ilişkiyi bir inşaat projesi üzerinden düşünürsek;

• İş Analisti, binada yaşayacak ailenin ihtiyaçlarını, kaç oda lazım, mutfak nereye bakmalı? belirleyen kişidir.

• Çözüm Mimarı ise o evin depreme dayanıklı olması için hangi kolonun nereye konulacağını ve tesisatın nasıl geçeceğini tasarlayan mühendistir.

İşte bu iki rolün ayrıştığı ve kesiştiği temel noktalar,

Odak Noktası, Ne vs. Nasıl

• İş Analisti (BA), "İş biriminin hangi problemi çözülmeli?" sorusuna odaklanır. Hedefi, iş değerini (Value) maksimize etmektir. Odak noktası İş Gereksinimleridir.

• Çözüm Mimarı (SA), Bu problem teknik olarak en verimli şekilde nasıl çözülür? sorusuna odaklanır. Hedefi, sistemin sürdürülebilir, ölçeklenebilir ve güvenli olmasını sağlamaktır. Odak noktası Teknik Tasarımdır.

Sorumluluk Alanları

Girdiler

• İş Analisti (BA), Paydaş görüşmeleri, pazar analizi.

• Çözüm Mimarı (SA), İş gereksinimleri (BA'dan gelen döküman).

Çıktılar

• İş Analisti (BA) Kullanıcı Hikayeleri (User Stories), Akış Diyagramları.

• Çözüm Mimarı (SA), Mimari Diyagramlar, Veri Modelleri, API Tasarımları.

Kritik Soru

• İş Analisti Müşteri bunu neden istiyor?, Sistem bu yükü kaldırabilir mi?

• Çözüm Mümarı Dil İş dünyasının ve kullanıcının dili. Yazılımın ve altyapının dili.

Kesişim Kümesi, Gri Alan

Her iki rol de Problem Çözücüdür. Analistin yazdığı bir gereksinim, mimarın teknik kısıtlarına takılabilir. Ya da mimarın önerdiği teknoloji, analistin hedeflediği kullanıcı deneyimine uymayabilir. Bu yüzden; • Analist, teknik kısıtları anlamalı (Teknik Analiz yetkinliği). • Mimar, iş hedeflerini özümsemeli (Ticari bakış açısı).  

İş Analisti, Çözüm Mimarına Dönüşebilir mi?

Evet, bu çok sık rastlanan bir kariyer yoludur.

Özellikle Teknik İş Analisti olarak çalışan kişiler, sistem mimarisi, bulut teknolojileri ve veri tabanı yönetimi konularında derinleşerek Çözüm Mimarı rolüne evrilebilirler. Ancak bu geçiş, kodun ve sistemin birlikte nasıl çalıştığını bilmeyi gerektirir.

Sonuç, Güç Birliği

İş Analisti ve Çözüm Mimarı el ele vermediğinde, Mimari tasarım başarılı, Analiz hatalı ya da herkesin ihtiyacını karşılayan ama her gün çöken bir sistem Analiz başarılı, Mimari tasarım hatalı ortaya çıkar. Sistem Analisti ve Çözüm Mimarı arasındaki iletişimi güçlendirmek için Veri Sözlüğü veya API Sözleşmesi ortak dokümanları geliştirilir.
Bir Sistem Analisti ile Çözüm Mimarı arasındaki iletişim, projenin fikir aşamasından yaşayan bir sistem aşamasına geçişindeki en kritik köprüdür. Eğer bu iki rol aynı dili konuşan dokümanlar üzerinden ilerlemezse, geliştirme ekibi çelişkili talimatlar arasında kaybolur.

API Sözleşmesi (API Contract / Swagger - OpenAPI)

Sistemin diğer bileşenlerle nasıl konuşacağını belirleyen en somut belgedir.

• İş Analisti, hangi verilerin dışarı açılması gerektiğini ve hangi alanların zorunlu olduğunu (Business Rules) belirler.

• Çözüm Mimarı, Verinin hangi protokollerle (REST, GraphQL, gRPC), hangi güvenlik katmanlarıyla ve hangi performans limitleriyle taşınacağını belirler.

• Ortak Fayda, Geliştirme ekibi, sistemin dış dünyaya açılan kapısını iki tarafın da onayıyla net bir şekilde görür.

Veri Sözlüğü ve Mantıksal Veri Modeli (Data Dictionary)

Veritabanı tasarımından önceki son duraktır.

• İş Analisti, veri alanlarının isimlerini, uzunluklarını, iş kurallarını örneğin, "TC Kimlik No 11 hane olmalı ve veri tiplerini tanımlar.

• Çözüm Mimarı, bu verilerin fiziksel olarak nasıl saklanacağını, indeksleme stratejilerini ve tablolar arası ilişkilerin Normalization / Denormalization sistem performansına etkisini planlar.

• Ortak Fayda, müşteri no dendiğinde her iki tarafın da aynı teknik ve iş tanımını anlamasını sağlar.

Durum Diyagramları (State Machine Diagrams)

Özellikle karmaşık yaşam döngüsüne sahip objeler örneğin Sipariş, Başvuru, Ödeme için kritiktir.

• İş Analisti, bir siparişin hangi durumlardan (Onay Bekliyor, İptal Edildi, Kargoya Verildi) geçebileceğini ve bu geçişlerin iş kurallarını belirler.

• Çözüm Mimarı, bu durum geçişlerinin sistemde hangi tetikleyicilerle Event-driven, Batch, Async gerçekleşeceğini tasarlar.

• Fayda, yazılımcıların statü yönetimi yaparken hiçbir iş kuralını atlamamasını sağlar.

Etkileşim Diyagramları (Sequence Diagrams)

Hangi sistem, hangi sırayla, kime ne soruyor? sorusunun görsel yanıtıdır.

• İş Analisti, kullanıcının başlattığı bir işlemin iş akış sırasını tanımlar.

• Çözüm Mimarı, bu akışın teknik bileşenler (Microservices, Cache layer, DB) arasındaki senkronizasyonunu ve hata yönetimi (Error handling) senaryolarını ekler.

• Fayda, sistemin darboğazlarını (bottlenecks) kod yazılmadan tespit etmeyi sağlar.

Bu dokümanlar statik birer dosya değil, canlı belgelerdir.

Mimari kısıtlar örneğin; seçilen veritabanının bir kısıtı analistin iş kuralını değiştirmesine neden olabilir; ya da analistin getirdiği yeni bir iş kuralı mimariyi revize etmeyi gerektirebilir.