معمار خوب همه تصمیم‌ها را نمی‌گیرد؛ دیگران را برای تصمیم‌گیری بهتر توانمند می‌کند

عنوان سخنرانی: Thinking Like an Architect
همایش: QCon London 2024
سخنران: Gregor Hohpe
مدت سخنرانی: ۴۹ دقیقه و ۳۳ ثانیه
لینک ویدئو: https://youtu.be/Oib06l1CHME?si=-Il4q1-8wPLsom0H

وقتی واژه «معمار نرم‌افزار» را می‌شنویم، ممکن است فردی را تصور کنیم که از بقیه اعضای تیم باتجربه‌تر است، همه فناوری‌ها را می‌شناسد و تصمیم‌های مهم پروژه را به‌تنهایی می‌گیرد. مهم‌ترین نکته‌ای که من از سخنرانی Thinking Like an Architect دریافت کردم، رد همین تصور بود. Gregor Hohpe توضیح می‌دهد که معماری بیش از آنکه یک عنوان سازمانی باشد، نوعی شیوه تفکر است. ممکن است فردی عنوان معمار را نداشته باشد، اما مانند یک معمار فکر کند؛ در مقابل، داشتن این عنوان نیز به‌ تنهایی نشان‌دهنده توانایی معماری نیست.

به نظرم، یکی از ماندگارترین مفاهیم این ارائه، معرفی معمار به‌عنوان تقویت‌کننده هوش جمعی یا IQ Amplifier بود. وظیفه معمار این نیست که باهوش‌ترین فرد اتاق باشد و برای همه نسخه آماده بپیچد. او باید به اعضای تیم کمک کند مسئله را از زاویه‌های بیشتری ببینند، پیامد تصمیم‌ها را درک کنند، گزینه‌های پنهان را پیدا کنند و میان مزایا و هزینه‌های هر انتخاب تعادل برقرار سازند. در چنین نگاهی، موفقیت معمار با تعداد تصمیم‌هایی که شخصا گرفته است سنجیده نمی‌شود؛ بلکه با کیفیت تصمیم‌هایی سنجیده می‌شود که دیگران با کمک او گرفته‌اند.

مفهوم مهم بعدی، آسانسور معمار است. سخنران سازمان را به ساختمانی چندطبقه تشبیه می‌کند: مدیران و تصمیم‌گیران کسب‌وکار در طبقات بالا و تیم‌های فنی در موتورخانه قرار دارند. معمار ارزشمند کسی نیست که فقط در یکی از این طبقات حضور داشته باشد؛ بلکه کسی است که بتواند میان آن‌ها رفت‌وآمد کند و ارتباط معناداری میان اهداف کسب‌وکار و واقعیت‌های فنی به وجود آورد. برای مثال، تیم فنی ممکن است درباره خودکارسازی، DevOps، مشاهده‌پذیری و مقیاس‌پذیری صحبت کند، درحالی‌که مدیران بیشتر نگران امنیت، دسترس‌پذیری و هزینه هستند. وظیفه معمار این است که نشان دهد خودکارسازی چگونه به بروزرسانی منظم، کاهش آسیب‌پذیری، بازیابی سریع‌تر و مدیریت بهتر هزینه منجر می‌شود.

این بخش برای من اهمیت زیادی داشت، زیرا نشان داد ارتباط معماری فقط ساده‌ کردن اصطلاحات فنی نیست. سخنران تأکید می‌کند که هنگام صحبت با مدیران نباید موضوع را بیش‌ از حد سطحی کرد؛ آن‌ها ممکن است جزئیات فنی را ندانند، اما در زمینه کسب‌ و کار و تصمیم‌گیری سازمانی تخصص دارند. معمار باید جزئیاتی را انتخاب کند که برای تصمیم موردنظر معنادار باشند. استفاده از استعاره‌های مرتبط با حوزه فعالیت سازمان نیز می‌تواند مخاطب را وارد فرایند فکرکردن کند. در غیر این صورت، توضیح مجموعه‌ای از اصطلاحات مانند Kubernetes، معماری رویدادمحور یا Serverless عملاً به این جمله تبدیل می‌شود: «به من اعتماد کنید و بودجه را در اختیارم بگذارید.»

موضوع دیگر تفاوت میان یک نمودار شلوغ و یک مدل مفید بود. گاهی تصور می‌کنیم هرچه نمودار معماری جزئیات و جعبه‌های بیشتری داشته باشد، حرفه‌ای‌تر است. اما Hohpe توضیح می‌دهد که قدرت مدل در حذف آگاهانه جزئیات غیرضروری و برجسته‌کردن بخش‌های مهم است. یک مدل خوب قرار نیست نسخه کاملی از واقعیت باشد؛ بلکه باید به سؤال مشخصی پاسخ دهد. همان‌طور که برای یک منطقه می‌توان نقشه جاده‌ای، سیاسی، توپوگرافی یا تراکم جمعیت تهیه کرد، برای یک سیستم نیز نمی‌توان فقط یک نمودار را پاسخ‌گوی تمام نیازها دانست. پیش از رسم معماری باید پرسید این مدل قرار است چه مسئله‌ای را روشن کند و مخاطب آن چه کسی است.

یکی دیگر از ویژگی‌های تفکر معماری، توانایی مشاهده ابعاد بیشتر یک مسئله است. بسیاری از اختلاف‌های فنی به این دلیل ایجاد می‌شوند که مسئله فقط در یک محور دیده می‌شود؛ مثلا سرعت در برابر کیفیت، استانداردسازی در برابر نوآوری یا استفاده از خدمات ابری در برابر وابستگی به فروشنده. معمار می‌تواند با افزودن یک بعد جدید، این تضاد ظاهری را تغییر دهد. برای نمونه، تست خودکار می‌تواند سرعت و کیفیت را هم‌زمان افزایش دهد و یک پلتفرم مشترک می‌تواند با استانداردکردن زیرساخت، امکان تنوع و نوآوری بیشتری را در سطح محصول فراهم کند. این بخش به من نشان داد که گاهی پاسخ معماری انتخاب یکی از دو طرف نیست؛ بلکه تغییر مدل مسئله و پیداکردن راهی برای دستیابی به هر دو هدف است.

در بخش دیگری از سخنرانی، تصمیم‌های معماری به «خریدوفروش اختیار» تشبیه می‌شوند. با استاندارد کردن یک رابط یا پروتکل، برخی آزادی‌ها محدود می‌شوند، اما در مقابل، گزینه‌های ارزشمند دیگری مانند استفاده از زبان‌های برنامه‌نویسی مختلف یا جایگزینی پیاده‌سازی‌ها به دست می‌آیند. همچنین به‌تعویق‌انداختن یک تصمیم، در محیط‌های غیرقابل‌پیش‌بینی می‌تواند ارزشمند باشد. برای مثال، زیرساخت کشسان این امکان را فراهم می‌کند که ظرفیت سیستم بعدا و متناسب با میزان واقعی تقاضا افزایش یابد. هرچه عدم‌قطعیت بیشتر باشد، ارزش چنین گزینه‌هایی نیز بیشتر می‌شود. از همین منظر، سخنران معماری و چابکی را مخالف یکدیگر نمی‌داند؛ هر دو برای مواجهه با تغییر و ناشناخته‌ها به کار می‌روند.

توانایی بزرگ‌نمایی و کوچک‌نمایی نیز بخش مهمی از نقش معمار است. وقتی فقط روی یک کامپوننت یا تیم تمرکز می‌کنیم، ممکن است عملکرد آن مناسب به نظر برسد؛ اما با نگاه‌ کردن به کل سیستم، مشکلات مربوط به ارتباط میان اجزا، انتقال تغییرات، افزایش تاخیر یا ناهماهنگی تیم‌ها آشکار می‌شوند. گاهی هر تیم به‌ صورت محلی عملکرد خوبی دارد، اما مجموع این بهینه‌سازی‌های محلی، نتیجه مطلوبی برای کل سازمان ایجاد نمی‌کند. برداشت من این است که معمار باید هم جزئیات فنی را بفهمد و هم بتواند چند قدم عقب‌تر بایستد و رفتار کل سیستم را بررسی کند؛ زیرا بسیاری از مشکلات واقعی نه داخل جعبه‌ها، بلکه در ارتباط میان آن‌ها شکل می‌گیرند.

آخرین نکته مهم سخنرانی، پرهیز از تصمیم‌های مطلق و سیاه‌وسفید بود. عبارت‌هایی مانند «همه‌چیز باید میکروسرویس باشد»، «همیشه از کانتینر استفاده کنید» یا «تمام ارتباطات باید رویدادمحور باشند»، بیشتر از آنکه نشان‌دهنده تفکر معماری باشند، نشانه نادیده‌ گرفتن شرایط مسئله هستند. دنیای معماری از طیف‌های خاکستری و Trade-off ها تشکیل شده است. یک انتخاب ممکن است برای سیستمی مناسب و برای سیستم دیگری کاملا اشتباه باشد. بنابراین معمار باید به‌جای تکرار فناوری‌های محبوب، محدودیت‌ها، هزینه‌ها، ریسک‌ها و پیامدهای هر انتخاب را بررسی کند.

در مجموع، این سخنرانی نگاهم را نسبت به نقش معمار نرم‌افزار تغییر داد. پیش از آن، بیشتر تصور می‌کردم معمار کسی است که فناوری مناسب را انتخاب و ساختار نهایی سیستم را طراحی می‌کند. اما اکنون فکر می‌کنم بخش مهم‌تر این نقش، ایجاد زبان مشترک، ارائه مدل‌های قابل‌فهم، آشکارکردن گزینه‌ها، مشخص‌کردن مصالحه‌ها و مرتبط‌ساختن تصمیم‌های فنی با اهداف سازمان است. معمار خوب جواب تمام سؤال‌ها را از قبل نمی‌داند؛ بلکه به تیم کمک می‌کند سؤال‌های بهتری بپرسد و با آگاهی بیشتری تصمیم بگیرد.

منابع

• ویدئوی رسمی سخنرانی در کانال GOTO Conferences :
  https://youtu.be/Oib06l1CHME?si=-Il4q1-8wPLsom0H

• ویدئو و متن کامل سخنرانی در InfoQ :
  https://www.infoq.com/presentations/architect-lessons

• صفحه رسمی سخنرانی در QCon London 2024 :
  https://qconlondon.com/presentation/apr2024/thinking-architect

• مقاله Thinking Like an Architect در InfoQ :
  https://www.infoq.com/articles/thinking-like-architect

اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيدبهشتی است 🌱