Uyumlu ekip ve yazılım mimarisi: sosyo-teknik bir sistem

kapanış bildirimi

Bu makale İngilizce olarak da mevcuttur. Teknik yardımla tercüme edildi ve yayınlanmadan önce editoryal olarak gözden geçirildi.

Bir daha gösterme.

Görünüşe göre yazılım mimarisi yalnızca yazılımın yapılandırılması ve işlevsel olmayan gereksinimlerin uygulanmasıyla ilgilidir. Ancak gerçekte yazılım insanlar içindir ve insanlar yazılım yazar. Bu nedenle bunu sosyo-teknik bir sistem olarak anlamak gerekir. Bunun yazılım mimarisini anlama açısından etkileri vardır.

Sosyoteknik sistem terimi, belirli bir sonuç üretmek için belirli bir şekilde yapılandırılmış organize bir grup insanı ve ilgili teknolojileri ifade eder. Diğer şeylerin yanı sıra, 1950'lerde Büyük Britanya'da kömür madenciliği sektöründe yürütülen araştırmalara kadar uzanıyor. Sosyoteknik sistemler fikri bu nedenle yeni değil ve kesinlikle moda değil. Önemli bir anlayış, bir kuruluşun başarısının, yalnızca eklenen ve uyum sağlaması gereken değiştirilebilir bireylerden oluşan teknik bir sistem olarak değil, sosyo-teknik bir sistem olarak ne kadar iyi işlediğine bağlı olmasıdır.

Adı zaten ne olduğunu söylüyor: sistem teknik bir bileşenden (makineler gibi) ve sosyal bir bileşenden (teknik bileşenleri çalıştıran ve kullanan çalışanlar) oluşur. Her ikisi de ancak bir arada görülebilir çünkü yakından ilişkilidirler. Bu nedenle insan-makine iletişiminin yanı sıra insan iletişimini de düşünmeliyiz.

Bu yaklaşım, çeşitli nedenlerden dolayı yazılım geliştirme ve mimari açısından ilgi çekicidir: Birincisi, yazılım geliştirme genellikle tamamen teknik bir görev olarak anlaşılır ve yönetilir. Ama sadece görünüşte öyle görünüyor. Yazılımı sosyo-teknik bir sistem olarak ele almak, önemli iyileştirmeler elde etme fırsatı sunar. İkinci olarak, çoğu yazılım yalnızca teknik sorunları çözmez; kullanıcılara ve diğer ilgili taraflara ekonomik fayda sağlamalıdır.

Bu nedenle yazılımın bu grup insanla önemli bir ilişkisi vardır, çünkü yazılımın değeri bu grup için sağlanan ekonomik faydaya dayanmaktadır. Bu sosyal yön, bir yazılım geliştirme projesinin başarısı için temeldir. Ve son olarak yazılım ekipler halinde uygulanır. Geliştirme aşamasında bile yönetilmesi gereken bir sosyal ağ var. Bu görevi özellikle iyi yaparsanız kendinizi etkili ve verimli bir şekilde geliştireceksiniz.

Aslında yazılım mimarisi her iki sosyal sistemle de yakından ilişkilidir: geliştiriciler ve kullanıcılar (bkz. Şekil 1). Yazılım mimarisi, kullanıcıları yeterince destekleyen teknik bir çözüm bulmalıdır. Kullanım kolaylığı, performans, ölçeklenebilirlik veya güvenlik gibi yazılım nitelikleri dikkate alınmalıdır. Dolayısıyla mimarinin bu kısmı ancak bu sosyal sistemle etkileşim içinde değerlendirilebilir. Bir mimari ancak kullanıcı grubu için yeterli niteliklere sahipse ölçülebilir. Bazı insanlar için kullanılması öznel olarak imkansız olan bir şey, başkaları için kabul edilebilir ve hatta ideal olabilir; Vim veya Emacs gibi editörler hakkındaki tartışmaları düşünün.

Bir sistemi modüllere ayırmanın amacı sistemin karmaşıklığını yönetilebilir hale getirmektir. Bu, modülerleştirmenin yalnızca ilgili geliştirme ekibiyle etkileşim halinde değerlendirilebileceği anlamına gelir. Görünüşte iyi olan modülerleştirme bile ekip için anlaşılması zor olabilir ve düşük üretkenliğe yol açabilir. Örneğin, bir ekip, iyi bir devir işlemi olmadan başka bir ekipten bir sistemi devralmış olabilir, bu da iyi modülerleştirmeye rağmen yeni ekibin sistemi anlamasını ve değiştirmesini zorlaştırabilir.

Sistemin kötü yapılandırılmış olması da düşünülebilir ancak ekip bu yapıya uzun süredir alışmıştır ve bu nedenle sistemi yeterince iyi değiştirebilmektedir. Bu, ekibin yazılımı teslim etmesini zorlaştırır çünkü yeni bir ekip onu anlamakta zorluk çeker. Bu teknik bir sorundan ziyade sosyal bir sorundur.

Conway yasası

Conway yasası, bir kuruluşun, tasarımı kuruluşun iletişim yapılarını kopyalayan bir sistem geliştireceğini belirtir. Örneğin yazılım geliştirme için bu şu anlama gelir: İki ekibin iki görevi varsa ve gerektiğinde birbirleriyle iletişim kurarlarsa, yazılımda tek arayüze sahip iki modül oluşturacaklar. Klasik olarak Conway yasası daha çok bir engel olarak görülüyordu: Ekipler belirli bir şekilde organize edildiklerinde yalnızca belirli mimariler yaratabilirler. Eğer UI ve backend ekibi varsa mimaride UI ve backend de oluşturulacaktır.

Ancak organizasyon şeması iletişim ile karıştırılmaktadır. Ancak insanlar ve ekipler, organizasyon şemasında belirgin bir ilişkileri olmasa bile iletişim kurarlar. Organizasyon şeması iletişim üzerinde önemli bir etkiye sahip olsa da aynı değildir. Bu aynı zamanda iyi bir haber: organizasyon şeması statik olsa da, dahil olan her kişi projedeki iletişim akışlarını etkileyebilir.

İletişim ve mimari arasındaki bağlantı başka bir sorun yaratır: İletişim artık etkili olmazsa veya kesintiye uğrarsa sistem mimarisi zarar görür. Özellikle büyük projelerde iyi iletişimi sürdürmek zordur. Dolayısıyla özellikle burada iletişim ilk başta zor olabiliyor, daha sonra mimari sıkıntı yaşayabiliyor.

Melvin Conway, 1967'de kanunu hakkındaki orijinal makalesinde bu tür sorunları anlattı. Yazılım mimarları mimarinin kalitesini korumak, hatta geliştirmek istiyorsa, projedeki iletişimi etkilemeli ve çalışmasını sağlamalıdırlar.

Ters Conway manevrasının bir sonucu olarak (bkz. Şekil 2), mikro hizmetler hareketi bağlamında Conway yasasına ilişkin anlayış değişti: İnsanlar bunu bir engel olarak görmek yerine artık onu mimari tasarlamak için kullanmak istiyor. Ekipler tanımlandığından ve her birine belirli bir sorumluluk atandığından, bu ekiplerin her birinin kendi sorumluluğuna karşılık gelen bir modül veya mikro hizmet uygulaması beklenir. Dolayısıyla organizasyonu belirli bir şekilde yapılandırmak mimariyi dolaylı olarak tanımlar. Conway'in ters manevrası bu nedenle yazılımı sosyo-teknik bir sistem olarak görüyor ve sosyal taraftaki önlemler aracılığıyla teknik tarafı etkiliyor.