عنوان سخنرانی: Architecture without Architects - XConf SEA 2021
سخنران: Erik Dornenburg (Head of Technology, ThoughtWorks Germany)
ويدئو: با همین "عنوان سخنرانی" در یوتوب تماشا کنید.
در این مطلب قصد دارم ویدئوی معرفی شده را تحلیل کنم و برداشتهای خود را از مفاهیم مطرح شده در آن با شما به اشتراک بگذارم. این سخنرانی صرفا درباره معماری نرمافزار نیست؛ بلکه درباره بازتعریف نقش قدرت، تصمیمگیری و تکامل در سیستمهای پیچیده نرمافزاری است.
مسئله اصلی سخنرانی، نقد یک استعاره است. استعارهای که سالهاست بدون پرسش پذیرفتهایم: نرمافزار مانند ساختمان است و بنابراین نیاز به معمار دارد. اما این قیاس از نظر مفهومی دچار خطای بنیادین است. در معماری ساختمان، طراحی قابل پیشینی است. بنا ساخته میشود و پس از آن تثبیت میشود. تغییرات پرهزینه و محدود هستند. اما در نرمافزار، فاز ساخت هرگز پایان نمییابد. سیستم دائما در حال بازتعریف، توسعه، بازآرایی و انطباق با نیازهای متغیر کسبوکار است. بنابراین اگر معماری را فعالیتی پیشینی و متمرکز بدانیم، عملا با ماهیت پویای نرمافزار در تعارض قرار میگیریم.
جایگزینی استعاره باغبان به جای معمار صرفا یک بازی زبانی نیست؛ یک جابهجایی فلسفی است. باغبان با سیستم زنده کار میکند. حذف میکند، هرس میکند، اصلاح میکند. با تغییرات فصلی سازگار میشود. کنترل کامل ندارد اما هدایت میکند. این استعاره با نظریه سیستمهای پیچیده همراستا است. نرمافزار سازمانی یک سیستم پیچیده تطبیقی است، نه یک مصنوع مکانیکی ایستا.اینجا پیام پنهان مهمی وجود دارد به این صورت که معماری در چنین سیستمی نباید طراحی ایستای ساختار باشد بلکه باید مبتنی بر سیاستگذاری و قاعدهگذاری پویا باشد.
یکی از عمیقترین بخشهای سخنرانی جایی است که درباره انتزاع صحبت میکند. مثال ORM و انفجار حافظه، یا مثال MTU در سیستم معاملاتی، نشان میدهد که انتزاع اگر بدون درک پیادهسازی استفاده شود، تبدیل به دام میشود. تحلیل مهم اینجاست: در بسیاری از سازمانها، نقش معمار با فاصله گرفتن از کد تعریف میشود. اما در ویدئو عملا استدلال میشود که چنین فاصلهای خطرناک است. زیرا تصمیم معماری در نهایت در لایه اجرا معنا پیدا میکند. در واقع معماری بدون فهم implementation، بیشتر شبیه ایدئولوژی است تا مهندسی. این نکته برای سازمانهای مالی و بانکی که با latency، throughput و محدودیتهای زیرساختی سر و کار دارند، اهمیت دوچندان دارد. یک فیلد اضافه در یک پیام میتواند مدل هزینه یا عملکرد کل سیستم را تغییر دهد.
بخش مربوط به نقض آگاهانه REST، یکی از نقاط کلیدی سخنرانی است. اینجا سخنران عملا یک اصل مهم را مطرح میکند: اصول معماری هدف نیستند، ابزارند. اگر پایبندی کامل به یک الگو باعث تخریب تجربه کاربر شود، آن الگو باید تعدیل شود. این نگاه، معماری را از سطح دگماتیک به سطح پراگماتیک میآورد. این موضع، معماری را به حوزه ارزش کسبوکار متصل میکند. یعنی معیار نهایی انطباق با یک maturity model نیست بلکه صحت معماری، رضایت کاربر و تحقق ارزش است.
یکی از لایههای انتقادی مهم سخنرانی، حمله به وسواس سازمانها بر نمودارهای سطح بالا است. نمودار چهار لایهای، وابستگیهای درهمتنیده واقعی را نشان نمیدهد. در نتیجه شکاف بین معماری مستند شده و سیستم واقعی شکل میگیرد. اینجا یک پیام مدیریتی مهم وجود دارد: معماری اگر قابل سنجش و قابل اجرا نباشد، تبدیل به artifact تزئینی میشود.
مهمترین پیشنهاد عملی سخنرانی، مفهوم Fitness Function است. اینجا یک چرخش مفهومی رخ میدهد: به جای اینکه بگوییم ساختار سیستم باید چگونه باشد، میگوییم سیستم باید چه ویژگیهایی را حفظ کند. این یعنی انتقال تمرکز از شکل به رفتار. Fitness Function ها نقش قوانین شهرسازی را بازی میکنند:
کوپلینگ نباید از حد مشخصی فراتر رود
زمان پاسخ نباید از آستانه عبور کند
وابستگیها نباید بیش از چند نسخه عقب بمانند
سیستم باید در برابر خرابی مقاوم بماند
این رویکرد، معماری را از تصمیمهای ایستا به معیارهای قابل اندازهگیری منتقل میکند. از دید تحلیلی، این یک حرکت از معماری دستوری به معماری مبتنی بر constraint است.
نقش معمار را نه به عنوان طراح کل، بلکه به عنوان راهنما تعریف شده.
راهنما:
مسیر را مشخص میکند
قواعد را تعریف میکند
معیارها را شفاف میکند
اما اجرا را به تیم واگذار میکند
این مدل با سازمانهای Agile و DevOps همخوان است و با ساختارهای سلسلهمراتبی سنتی در تضاد است. به بیان دقیقتر، معماری در این دیدگاه یک فعالیت مستمر اجتماعی است، نه اینکه صرفا یک deliverable فنی باشد.
این سخنرانی در ظاهر درباره معماری بدون معمار است، اما در عمق درباره سه چیز است:
خطر استعارههای نادرست در شکلدهی ذهنیت مهندسی
ضرورت پیوند معماری و پیادهسازی
جایگزینی کنترل متمرکز با هدایت مبتنی بر سنجش
پیام نهایی آن را میتوان اینگونه صورتبندی کرد: معماری نه طراحی یک ساختار، بلکه طراحی قواعد تکامل یک سیستم است.
Building Evolutionary Architectures, with Neal Ford
What are Microservices _ redhat
این مطلب، بخشی از تمرینهای درس معماری نرمافزار در دانشگاه شهیدبهشتی است
#معماری_نرم_افزار_بهشتی
