YAZILIM MİMARİSİ
Organizasyon Yapısı, Başarılı Bir Yazılım Mimarisi için Önemli mi ?
Yazılım Mimarisi’nin başarılı şekilde oluşturulabilmesi için önemli bir etken olan Organizasyon yapısınının, yazılım içerisindeki modül tasarımına yansımasından yani Conway yasasından bahsetmek istiyorum.
Melvin E. Conway 1967 yıllarında şu konuyu gözlemlemiştir; kuruluşlar ve işletmelerin kendi iletişim sistemlerini yansıtan yazılımlar geliştiriyorlar. Buradan da aşağıdaki Conway Yasası ortaya çıkmıştır
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.[2][3]
— Melvin E. Conway
Bu yasa temelinde yazılım modülleri arasındaki ilişkiye benzer bir yapının, organizasyon yapısında olduğu ve buna parallellik gösterdiği üzerinedir. Sistem yapısındaki yazılım arayüzleri, organizasyonlar da bulunan sosyal sınırlar ile benzer şekilde çalışır ve iletişim yöntemleri içerir. Conway sosyolojik gözlemle bu yasayı ortaya koymuş. 1968 National Symposium bu Conway Yasası olarak adlandırılmaya başlanmıştır.
Bu konu neden çok önemli ?
Uzunca bir süre Askeri, Telekom, Devlet Kurumları, Banka/Finans Şirketleri vb için yazılım geliştirme ekiplerinde çalıştım. Ekip yapıları bu organizasyon yapısına göre kurgulandığında, veya bu birimlerle çok iç içe tasarlandığında daha başarılı yazılımların çıktığını farkettim.
Bu başarının altında bence 2 neden yatıyor.
- Birincisi, geliştirici ekipler organizasyon yapısı içerisinde doğal olarak dağılıyor ve bu şekilde modülleri ve modül arayüzleri Conway yasasının doğallığı içerisinde oluşturmuş oluyorlar.
- İkincisi, geliştirici ekip organizasyondaki domain(alan) uzmanları ile birlikte çalıştıklarında gereksinimleri daha iyi analiz edip ihtiyaçları yerinde tespitten kaynaklanıyor.
Not: Burada başarılıdan kastettiğim müşterinin isteklerine uyumluluk. Yoksa bu yazılım tekrar tekrar kullanılması anlamında söylemiyorum. Çünkü iş yaptığınız organizasyona olan bağımlılık giderek artacağı için terzinin bir kişiye yaptığı özellikte bir ürün ortaya çıkacak, bu ürün o kişi/organizasyon için çok uygun olurken, başka müşterilere veya organizasyonlara kolay bir şekilde uyarlanamaz halde olacaktır.
Yeni Mimari Yaklaşımların Organizasyon Yapısı ile (Micro-service ve Micro-Frontends) Bir İlgisi Var mı ?
Evet var. Monalith yapıdan Microservis yapısına, hatta Microfrontend yapısına geçişte, yazılımdaki modülerlik direk olarak ekipleri ve bu ekipler arası iletişimide etkilemektedir.
Geliştirici ekiplerin micro seviyede yazılımlar ile eşleştirilebildikleri için daha uyumlu ve başarılı yazılımlar ortaya çıkmaktadır. Örneğin bu sayede aşağıdaki bölümleme çok daha basit bir şekilde yapılabilmektedir.
- Fatura Servisleri,
- Reklam ve Kampanya Servisleri
- Ürün Servisi
- Satış Servisi
- Müşteri Hizmetleri
- CRM vb…
Not: Bu konuda yazılım geliştirme yöntem ve araçlarının giderek Conway yasasına uygun olarak micro yapılara dönüştüğünü yukarıdaki resimden de görebilirsiniz.
Büyük Yazılım Firmaları için Durum Nasıl ?
Evet Amazon, Facebook, Google, Microsoft vb.. bir çok yazılım firması için organizasyon yapısı çok ama çok önemlidir. Çoğunuz aşağıdaki karikatür çizimi bir yerlerden hatırlıyordur. Bu aslında şirketin içerisinde ki ürün yapısı ile şirket organizasyonu arasındaki ilişkinin bir gösterimi, yansımasıdır 😃
Not: Organizasyon yapılarındaki parçalanma ve iletişimin şirketlerin yazılımlarına direk yansıdığını görebilirsiniz.
- Apple örneğin ortadaki kırmızı (Steve Jobs ve Tasarım Ekibi) tüm ürünler bu yapının çevresinde şekillenmiş bundan dolayı bir uyum söz konusu
- Amazon da ise Scalability (Ölçeklenebilirlik) için ekipler belli limitleri geçmeyen hiyerarşik yapıda birbirlerine bağlı
- Yukarıdaki resimden Google, Microsoft, Facebook Oracle ve diğer şirketlerin durumunu çıkarabilirsiniz.
Organizasyon Yapıları
Divisional Organization yapısında ürünler, onun altında kendi VP of Marketting, Engineering ve Finance olarak dallara ayrılırken bazı insan kaynakları, kanun vb.. konular direk CEO bağlı ekipler tarafından yapılabilir.
Functional Organization yapısında ise yeteneklerin tüm ürünler için cross-cut matrix şeklinde kullanılması anlamına geliyor ki buda CEO ve altındaki yönetim ekibin tüm ürünlerin yönetimi ve koordinasyonu konusundaki önemini gösteriyor.
Örnğin Apple ürünleri arasındaki uyumu sağlayabilmek için Functional bir organizasyon yapısına sahiptir. Bu konuda Apple’s Organization Crossroads linkindeki yazıyı okuyabilirsiniz. Microsoft’un Microsoft Why Microsoft’s Reorganization Is a Bad Idea yazısını okuyabilirsiniz.
Amazon 2 PT (Two Pizza Teams)
Organizasyon yapısı ile yazılım arasındaki konuya belkide en iyi örnek Amazon’un yazılım ekiplerinde uyguladığı (Two Pizza Teams) tekniğine göre ekipleri oluşturma konseptinden geçiyor.
Amazon bildiğiniz gibi eTicaret ve Bulut Teknolojileri konusunda dünya lideri konumunda. Bunu gerçekleştirmek içinde sürekli innovasyon yaparak yeni teknolojiler üretmeli ve bunu müşterilerine servis olarak vermeli.
Amazon bu ölçeklenme problemini bir anda teknolojik olarak gerçekleştirmedi. İlk önce organizasyon yapısını , takımların büyüklüğünü ve birbirleri arasındaki iletişimin kurallarını belirledi. Daha sonrasında bu kaliteli servisler ortaya çıktı. Bu yazıda Amazon’un bu stratejilerinden bahsetmek istiyorum.
Takımların büyüklüğü 2 pizzanın besleyeceğinden büyük olmamalı. Bunun arkasında yatan felsefe çok fazla iletişim, iletişim problemlerini çözmez. Örneğin bir yemeğe, düğüne, doğum günü partisine gittiniz. Genelde çok fazla insan olsada insanların 5erli, 6şarlı gruplar halinde toplanıp konuştuğunu görürsünüz. Buda iletişim açısından takım sınırlarımızı göstermektedir.
Aşağıdaki formül bize iletişimde kurulan bağlantı karmaşıklığını veriyor
- 6 kişide => 15 bağlantı
- 12 kişide => 66 bağlantı
- 50 kişide => 1225 bağlantı
Peki 2 PT Kaç Kişiden oluşmalı ve Nasıl Bir Rol Dağılımı Olmalı
- 1 Takım Lideri
- 1 Tasarımcı/UX uzmanı
- 1 veya 2 UI Geliştiricisi
- 1 veya 2 Backend Geliştiricisi
- 1 QA uzmanı
- 1 Ürün sahibi(product owner) /iş analisti
Yukarıdaki bölümleme bizim eskiden beri gelen klasik IT bölümlememizin dışında olan bir yönelim. Ama bu yönelimler DevOps’un giderek gelişmesi, ekip elemanlarının farklı sorumlulukları alabilmesi zamanla kırılacak ve aşağıdaki resimden yavaş yavaş 2PT ‘ye evrilecektir.
Diğer bir konuda İletişim Yöntemi. Bu kısımda belirledikleri bir takım iletişim kurallarının Amazon ne kadar fayda sağladığını sizde mevcut AWS (Amazon Web Servislerinin) oluşmasında bu kuralların ne kadar etkili olduğunu görebilirsiniz. Bu kurallar ;
- Tüm takımlar verilerini ve fonksiyonalitelerini birbirlerini servis arayüzleri ile sağlayacaktır.
- Takımlar sadece bu servis arayüzleri üzerinden birbirleri ile iletişim kurmalıdır.
- 2nci madde dışında hiç bir iletişim şekli olmamalıdır. Ne başka bir takım diğer takımın veri modelini okuyabilmeli, ne ortak bir bellek modeli kullanılmalı. Tüm bunlar yasak. Tek iletişim birbirlerine sağlanan servisler üzerinden gerçekleştirilmeli.
- Bu iletişim sırasında hangi teknolojinin kullanıldığının bir önemi yok. HTTP, Corba, Pubsub, özelleşmiş bir çok protokol kullanılabilir.
- İstinasız tüm servisler dışarıya açılacak şekilde tasarlanmalı ve geliştirilmelidir.
Zaten yukarıdaki kuralları 2002'den beri işleten Amazon AWS ile tüm altyapısını dünyaya açtı ve dünyanın en büyük bulut sağlayıcısı olduğunu görebilirsiniz.
Yukarıda bahsedilen kurallar ile kaç yıl önceden microservis kavramını şirket yapısını ve kültürüne nasıl yerleştirdiğini görebilirsiniz.
Özet: Tüm bu verdiğim örnekler yazılım konusunda düzgün bir mimari yapı oluşturabilmek için, şirketler kendi organizasyon yapılarına, iletişim yöntemlerine ve kültürel yapılarını gözden geçirmek zorunda olduğudur.
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
