خانه / Agile / قانون کانوی

قانون کانوی

قانون کانوی

در سال 1967آقای Melvin Conway مقاله ای رو با عنوان “How Do Committees Invent?” را به Harvard Business Review ارائه داد که بدلیل اینکه در اون مقاله نتوانست فرضیه خود را اثبات کند آن مقاله از طرف HBR رد شد. اما سال بعد مقاله را توسط مجله معروف IT آن زمان Datamation به چاپ رسانید. یکی از فرضیه های مهم آن مقاله جمله معروف زیر می باشد:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

این مقاله و فرضیه های آن بعد ها به عنوان قانون کانوی معروف شد.

به عنوان بخشی از این مقاله بخش زیر از سایت ویکی پدیا انتخاب شده است:

Conway’s law was not intended as a joke or a Zen koan, but as a valid sociological observation. It is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.

 

بسیار مهم است که توجه کنیم که این قانون نه تنها به طراحی نرم افزار که بر نوع کنش و ارتباطات تیم های درگیر در فرآیند تولید نرم افزار نیز تاثیر گذار بوده و قابل تعمیم است. ساختار ارتباطی که قانون کانوی مورد اشاره قرار می دهد در حقیقت دقیقا ساختار چارتی و رسمی سازمان نمی باشد، بلکه ارتباطات غیر رسمی درون سازمان را نیز شامل می شود که می توانند بر جنبه های مختلفی تاثیر گذار باشند. همچنین عواملی از جمله توضیع جغرافیایی سازمان و غیر متمرکز بودن سازمان نیز بر این مساله تاثیر بسیار مهم و به سزایی خواهد داشت.

از یک نظر قانون کانوی به زبان ساده معرف این موضوع است که هر بخشی از یک سازمان که دارای معماری خاص مورد نیاز خود می باشد، جهت تجمیع و ارتباط میان بیزینس سازمان در سطح کلان باید دارای Interface ای جهت برقراری ارتباط و تعامل با بخش های دیگر و سیستم های دیگرسازمان می باشد؛ و در نتیجه ارتباط و تعامل میان این Interface ها مورد نیاز می باشد, و در نتیجه تعاملی میان واحدهای سازمانی که مسئولیت ایجاد و توسعه این بخش ها را بر عهده دارند نیز مورد نیاز است و شکل می گیرد؛ و این خود باعث افزوده شدن dependency و complexity میان این سیستم ها خواهد شد.

 

از نقطه نظر قانون کانوی طراحی ماژولار محسوس و معقول است. با طراحی این چنینی می توان اطمینان داشت که تمام اعضای تیم A نیازمند ارتباط دائمی با اعضای تیم B نمی باشند. در عوض اعضایی که بر روی ماژول مشابه مشغول فعالیت هستند تلاش خود را هماهنگ می کند؛ و فقط هنگامی که Interface ای طراحی می شود(Published Interface) نیاز به همکاری و تعامل با اعضای تیم دیگر را خواهد داشت.

 

قانون کانوی بیان می کند که سازمان بزرگ نسبت های ارتباطی بسیار زیادی دارد. و ارتباطات در نهایت غیر ممکن و یا بسیار سخت خواهد شد. و نهایتا این می تواند منجر به این شود که معماری را به شدت تحت تاثیر قرار دهد و در نهایت به شکست بینجامد. و اینکه ارتباطات بسیار زیاد و بیش از اندازه یک ریسک واقعی برای پروژه است.

 

قانون کانوی بخصوص از دیدگاه توسعه نرم افزار به عنوان محدودیت شناخته می شود. فرض کنید که یک پروژه بصورت ماژولار بصورت زیر طراحی شده است. تمامی توسعه دهنده هایی که بر روی UI کار می کنند به درون یک تیم جمع می شوند؛ توسعه دهنده هایی که Backend کار هستند در تیم Backend قرار می گیرند و توسعه دهنده هایی که متخصص لایه ی دیتابیس هستند در تیم Database قرار می گیرند. این توضیع تیمی این مزیت را دارد که هر سه تیم دارای متخصصینی در حوزه ی تکنولوژی خاص می باشند. از آنجایی که اعضای تیم دارای مهارت مشابه هستند و در حوزه ی تخصصی خود کار می کنند می توانند همدگیر را راحت تر پشتیبانی کنند.

 

به زبان ساده شما وقتی جهت توسعه و طراحی یک محصول از چند تیم بصورت مجزا استفاده می کنید باعث می شود که در حداقل شرایط شما طراحی برای محصول خود داشته باشید که به تعداد تیم ها دارای لایه های مجزا خواهد بود.

اولین مشکل هنگامی است که با سناریوهایی مواجهید که نیاز است که تغییرات در تمامی لایه ها(در شکل بالا تمامی سه لایه) اعمال شود. UI نیازمند این می باشد که feature جدید را رندر کند, Backend نیازمند این می باشد که logic را پیاده سازی کند و دیتابیس نیازمند این می باشد که ساختار مورد نظر درون دیتابیس را اعمال کند. و این اتفاقات می تواند منجر به موارد زیر باشد:

  1. افرادی که درخواست پیاده سازی feature را دارند مجبورند که با همه ی تیم ها صحبت کنند.
  2. تیم ها نیاز دارند که کارهاشون رو با هم هماهنگ کنند و interfaceهای جدیدی را ایجاد کنند.
  3. هنگامی که تیم ها درون اسپرینت کار می کنند؛ این وابستگی ها می تواند منجر به تاخیر شود.

به سخن ساده این رویکرد منجر می شود که وابستگی بسیار زیادی ایجاد کند و سربار ارتباطی و هماهنگی بالایی را ایجاد می کند. در نتیجه سازمانهایی که هدفشون پیاده سازی ویژگی های جدید با سرعت بالا می باشد با این رویکر به مشکل برخورد خواهند کرد.

معکوس قانون کانوی

از زمانی که کانوی این قانون رو ارائه داده سیستم های بسیار زیادی طراحی و توسعه داده شده اند. بسیاری از این سیستم ها را اصطلاحا “Legacy Systems” می گویند. در برخی موارد این سیستم ها ساختار خاصی را برای افرادی که در سیستم مسئولیت پشتیبانی و نگه داری سیستم را به عهده دارند, و حتی در سطح بالاتر بر سطح سازمان می گذارند.

به عنوان مثال, سیستم سه لایه (طراحی معمول) شامل لایه های database و business و GUI رو در نظر بگیرید. مدتی بعد توسعه دهنده های اصلی چنین سیستمی شرکت رو ترک می کنند, حداقل تاثیری که این تصمیم و ترک توسعه دهنده ها بر شرکت خواهد گذاشت, این است که چنین سیستمی که دارای پیچیدگی در هر سه لایه می باشد؛ نیازمند متخصصی در هر سه لایه می باشد, دیتابیس پر است از طراحی های توابع و store procedureها پیچیده و trigger ها و محدودیت های دیتابیسی که فقط یک متخصص دیتابیس می تواند آنرا درک کند. GUI مملو شده است از کدهای جاوا اسکریپت و CSS و HTM که هر کسی قادر به درک آن نمی باشد. و لایه بیزینس هم اونقدرها ساده نیست که توسط هر کسی قادر به درک باشه.

چنین موقعیتی باعث میشه که سازمان انتخاب دیگه ای نداشته باشه؛ جز اینکه سه متخصص رو استخدام کنه. در این شرایط قانون کانوی به شیوه ی عکس عمل می کنه و چنین سیستمی بر روی ساختار سازمانی تاثیر خواهد گذاشت.

مجددا تاکید می شود که این موارد نه تنها در سطح خرد که در سطح کلان نیز بر سازمان تاثیر خواهد گذاشت. تمامی سازمانها بر اساس سیستم هایی که دارند محدود و مجبور می شوند.

هر دو قانون کانوی و کانوی معکوس شده با هم به عنوان The Homorphic Force شناخته می شوند.

نکته ی مهم اینکه؛ این فشار و اجبار به عنوان عاملی جهت نگه داشتن و حفظ ساختار فعلی سیستم؛ حتی اگر سیستم از تکنولوژی ای به تکنولوژی دیگر یا حتی پلت فرم دیگر منتقل شود؛ عمل می کند.

نهایتا باید به این نکته تاکید داشت که بهنگام درک و طراحی معماری سیستم به قانون کانوی و تاثیرات آن هم در سطح ریز و پایین سازمان و هم در سطح کلان سازمان توجه داشت؛ و اینکه تا چه اندازه عدم توجه به این قانون مهم می تواند بر طراحی بد معماری تاثیر بگذارد؛ و به عکس یک ساختار خوب سازمانی می تواند منجر به یک طراحی خوب و بهتری شود.

درباره ی masoud@admin

همچنین ببینید

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل هرچند تفکر و ایده ی ورای Microservices …

Problem Solving و Critical Thinking حلقه های گمشده ی مهندسی

Problem Solving Problem Solving یا توانایی حل مسئله بخشی از جریان فکری و تفکر انسان …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن