چالش های مدرن سازی معماری نرم افزار و راهکارهای آن

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

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

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

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

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

حمایت رهبران از چالش های مدرن سازی معماری نرم افزار

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

1. آیا واقعاً رهبران این آمادگی را دارند تا جریان ارائه ویژگی‌های جدید را برای رسیدن به اهداف مدرن‌سازی کند کنند؟

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

2. آیا رهبران می‌دانند که سیستم‌ها و روش‌های قدیمی، چقدر پیچیده هستند و تغییر در آن‌ها، چقدر کار سختی است؟

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

3. هنگامی که اتفاقات غیرمنتظره‌ای که اجتناب‌ناپذیر هستند، رخ می‌دهد و باعث تأخیرهای زیاد یا افزایش هزینه‌ها می‌شود، چگونه رهبران کسب و کار واکنش نشان خواهند داد؟

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

4. آیا رهبران کسب و کار آمادگی تغییر در نحوه کار خود را دارند؟ آیا تصور می‌کنید که رهبران از تغییرات در مدل‌های بودجه، اولویت‌بندی کارها و فرآیندهای توسعه حمایت کرده و تیم‌ها را برای تصمیم‌گیری و اختیار، بیشتر توانمند می‌کنند؟

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

5. آیا رهبران زمان و بودجه کافی را برای یادگیری و آموزش همه کارکنان سرمایه‌گذاری می‌کنند تا بتوانند مدرن‌سازی را به‌طور ماهرانه‌ و صحیح انجام دهند؟

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

6. آیا فن‌آوران توان بیانِ مزایای تجاری و سازمانیِ ایده‌های خود را به رهبران کسب‌وکار و سایر ذینفعان دارد؟

گاهی اوقات یکی از چالش های مدرن سازی معماری نرم افزار ، حمایت نکردن ازطرف رهبران نیست؛ بلکه مشکل این است که آن‌ها نمی‌دانند که چه خواسته‌هایی از ایشان وجود دارد، برروی چه چیزی باید سرمایه‌گذاری کنند و مزایای این سرمایه‌گذاری چیست؟ به نقل قول زیر از یک مدیرعامل توجه کنید:

توسعه‌دهندگان همه OCD دارند. آن‌ها همیشه درمورد بدهی‌های فنی صحبت می‌کنند و دوست دارند همه چیز را بازنویسی کنند.

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

برقراری ارتباط با انتقال ارزش های معماری در با چالش های مدرن سازی معماری نرم افزار

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

1. بهبود زمان رسیدن به بازار (Time To Market)

در کتاب Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations، نویسنده و همکارانش، یافته‌های تحقیقاتی خود را درمورد تفاوت بین سازمان‌های با عملکرد بالا، متوسط و پایین شرح داده‌اند که شناخت آن‌ها در مقابله با چالش های مدرن سازی معماری نرم افزار بسیار مهم است. سازمان‌های با عملکرد بالا چندین بار در روز، بهبود‌های خود را به محیط عملیاتی منتقل می‌کنند؛ در حالی که سازمان‌های با عملکرد متوسط و پایین، به‌صورت هفتگی یا ماهانه یا حتی فصلی این کار را انجام می‌دهند. علاوه‌بر این، افراد با عملکرد بالا، زمان کوتاه‌تری برای تغییرات دارند، خرابی‌های کمتری ایجاد می‌کنند و درصورت بروز خرابی، سریع‌تر بازیابی می‌شوند. نکته جالب‌تر در این زمینه این است که آن‌ها یک معماری خوب طراحی و پیاده‌سازی شده را شناسایی کردند که مزایای زیر را به‌عنوان بزرگ‌ترین عامل در عملکرد تحویل مداوم ارائه می‌دهد:

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

علاوه‌بر این، نویسندگان این کتاب دریافتند که یک معماری غیروابسته (Loosely Coupled) به سازمان، این امکان را می‌دهد که با حفظ عملکرد کاملِ سیستم، مقیاس آن را افزایش دهد تا با چالش های مدرن سازی معماری نرم افزار مقابله کنند. استخدام مهندسانِ بیشتر برای کار در سیستم‌هایِ قدیمی با وابستگی قوی (Tightly Coupled) معمولاً بهره‌وری را کاهش داده و حتی عملکرد معکوس دارد.

2. مدیریت پیچیدگی روزافزون

با اینکه حدود ۶ سال از انتشار کتاب Accelerate در سال ۲۰۱۸ می‌گذرد، اما مفاهیم و مطالب آن کماکان کاربردی است. در حقیقت سیستم‌ها دائم درحال رشد هستند و این رشد دائمی، باعث ایجاد پیچیدگی‌های روزافزون در آن‌ها می‌شود. در این شرایط، داشتنِ یک معماریِ خوب و خوش‌تعریف از جنبه‌های مختلف، بسیار حیاتی است و از چالش های مدرن سازی معماری نرم افزار به‌حساب می‌آید. این روزها تکنولوژی جنبه‌های مختلف از زندگی انسان را تحت تأثیر قرار داده است و طبق آمار، به طور میانگین، هرنفر روزانه ۴ ساعت از زمان خود را صرف استفاده از ابزارهای مختلف مثل لپ‌تاپ یا موبایل می‌کند. سیستم‌هایی که می‌سازیم نیز دائماً درحال تغییر و ارتقا هستند. مثلاً اینترنت اشیا را در نظر بگیرید. در سال ۲۰۱۹ حدوداً ۸.۶ میلیارد دستگاه به اینترنت متصل بود، در حالی که برای سال ۲۰۲۳ این عدد به ۱۵.۱۴ میلیارد رسیده و پیش‌بینی می‌شود تا سال ۲۰۳۰، این عدد به حدود ۳۰ میلیارد برسد. رهبران فناوری اطلاعات باید دائماً شرایط آینده و تغییراتی که صنایع آن‌ها رخ خواهد داد را رصد کنند.

هرچه عمر سیستم افزایش پیدا می‌کند و پیچیدگی آن زیادتر می‌شود، اهمیت داشتن یک معماری خوب نیز بالاتر می‌رود. هرچه جلوتر برویم، تغییر و نوسازی معماری گران‌تر و پیچیده‌تر خواهد شد. در کنار افزایش پیچیدگی و هزینه، احتمال ایجاد مشکلات بنیادی و ایجادِ مخاطرات برای کسب و کار نیز بیشتر می‌شود که این، خود از چالش های مدرن سازی معماری نرم افزار است. برای مثال، در سال ۲۰۱۷ شرکت هواپیمایی British Airways یک قطعی در سیستم فناوری اطلاعات خود داشت که موجب زمین‌گیر شدنِ ناوگان هوایی شد. در سرتاسر دنیا، نزدیک به ۷۵ هزار مسافر سرگردان شدند و شرکت، متحمل ضرری ۸۰ میلیون پوندی شد. سال بعد سیستم‌های شرکت هک شده و اطلاعات نیم میلیون مشتری نشت پیدا کرد و این بار شرکت متحمل ضرری ۱۸۳میلیون پوندی شد. کار به همین جا ختم نشد. در سال ۲۰۱۹ باز هم خطا در سامانه‌های قدیمی، موجب لغو بیش از ۱۰۰ پرواز و سرگردانی مجدد مسافران شد و این بار هم ۸ میلیون پوند دیگر ضرر به شرکت تحمیل گردید.

3. کاهش ناکارآمدی‌ها

تحقیقات Adam Tornhill و Markus Borg نیز نشان می‌دهد که هنگامی که سازمان‌ها از معماری خود غفلت می‌کنند، چه اتفاقاتی رخ خواهد داد. در مقاله آن‌ها، تحت عنوان Code Red: The Business Impact of Code Quality– A Quantitative Study of 39 Proprietary Production Codebases چالش های مدرن سازی معماری نرم افزار نشان داده شده است که حدود ۴۲ درصد از زمان توسعه‌دهنده‌ها، صرف سروکله زدن با بدهی‌های فنی می‌شود. این زمان بسیار زیاد است و هزینه زیادی را به کسب و کار تحمیل می‌کند؛ در حالی که جلوی جریان سریع ارزش را نیز می‌گیرد.

روشی که موجب تحلیل رفتن سیستم‌های نرم‌افزاری می‌شود، باید موردتوجه همه شرکت‌های فناوری باشد. رخداد این فرآیند، مانند بیماری سرطان است؛ زمانی متوجه هزینه‌های بالای پوسیدگی می‌شوید که هزینه‌های تعمیر آن بسیار بالا رفته و قابل توجه است. در مراحل اولیه تولید یک محصول، نوشتن کد و نادیده گرفتنِ معماری بسیار آسان است. رفته‌رفته و با گذشت زمان، میزان چسبندگی (Coupling) در سیستم افزایش می‌یابد. هربار تغییرات جدید، زمان بیشتری نیاز دارد و خطر آسیب بیشتری را به سیستم وارد می‌کند. همچنین نیاز به تست‌های دستی بیشتر احساس شده و حتی ضروری می‌شود و سرعت انتشار، دائماً کاهش می‌یابد. هرروز باگ‌های بیشتری ظاهر می‌شوند؛ زیرا تغییر در یک قسمت از سیستم، باعثِ ایجاد مشکلاتی در بخش دیگری از سیستم می‌شود که به ظاهر هیچ ارتباطی بین این بخش‌ها وجود ندارد. توسعه‌دهندگان برای ترجمه نیازمندی‌ها و الزامات به کد تلاش زیادی می‌کنند؛ زیرا زبانی که کسب‌وکار استفاده می‌کند، اصلاً در کدها وجود ندارد و در هیچ کجای کد، زبان مشترک با کسب و کار ظهور و بروز ندارد. چندین تیم باهم می‌جنگند تا تغییرات خود را ابتدا انجام دهند. حتی میکروسرویس هم نوش‌داروی این مرض نیست. هنگامی که معماری بد و ساختاری اشتباه را به‌صورت Monolith توسعه داده شده باشد، تبدیل آن به همان شکل به میکروسرویس، فقط چندین برنامه‌ی بد و کوچک ایجاد می‌کند.

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

به‌طور خلاصه، نوسازی معماری، ناکارآمدی‌های تحمیل شده توسط معماری قدیمی را کاهش می‌دهد و توانایی سازمان را برای نوآوری با سرعتی رقابتی را بازیابی می‌کند.

اجتماعی کردن یک دیدگاه کل نگر از معماری در با چالش های مدرن سازی معماری نرم افزار

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

1. معماری روی مدل‌سازی دامنه تأثیر دارد

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

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

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

2. معماری شامل انتخاب های استراتژیک است

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

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

3. معماری و قانون کانوی (Conway)

آشنایی با قانون کانوی از ملزومات کار معماری است. قانون کانوی می‌گوید:

سازمان‌هایی که سیستم‌هایی را طراحی می‌کنند، مجبور به تولید طرح‌هایی هستند که کپی‌هایی از ساختارهای ارتباطی این سازمان‌ها هستند.

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

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

4. آماده سوار شدن به آسانسور معماری باشید

آقای Gregor Hohpe مطلبی درمورد معماری، تحت عنوان Architect Elevator نوشته‌اند که با یک قیاس خوب، دیدگاه مناسبی در مورد نگاه کل‌نگر به معماری شما می‌دهد.

فرض کنید سازمان ما یک برج باشد که طبقات و مسئولیت‌های متفاوتی دارد. از اتاق فنی مهندسی برای تعمیر و نگهداری برج گرفته تا پنت‌هاوسی با دید ابدی. این مطلب بیانگر این ایده است که دیدگاه کل‌نگر در معماری روی همه قسمت‌های برج تأثیرگذار است. مثلاً اگر تصمیمات استراتژیک در پنت‌هاوس گرفته می‌شود و در زیرزمین، کنار موتورخانه کارهای مهندسی عملی (توسعه نرم‌افزار) انجام می‌شود، معماری روی همه این طبقات و بخش‌ها تأثیرگذار است. این قیاس فوق‌العاده از آقای Gregor Hohpe، یک راه عالی برای شماست که بتوانید به افراد در سازمان کمک کنید تا طیف وسیعی از فعالیت‌های مربوط به معماری را ببینند و درک کنند. این قیاس الگوی خوبی برای کارها و بخش‌هایی است که زمان خود را در آن‌ها سپری می‌کنید و حتی می‌توانید مناطقی که ممکن است از آن‌ها غفلت کنید را شناسایی و با چالش های مدرن سازی معماری نرم افزار مقابله کنید.

جمع بندی

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