قسمت دوم: آمادگی برای سفر مدرن سازی معماری نرم‌افزار - بخش اول

1. مقدمه:

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

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

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

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

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

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

2. آیا رهبری وجود دارد؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. برقراری ارتباط با انتقالِ ارزش‌های معماری:

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

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

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

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

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

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

با اینکه حدود 6 سال از انتشار کتاب Accelerate در سال 2018 می‌گذر، اما مفاهیم و مطالب آن کماکان کاربردی است. در حقیقت سیستم‌ها دائم در حال رشد هستند و این رشد دائمی باعث ایجاد پیچیدگی‌های روزافزون در آن‌ها می‌شود و در این شرایط داشتنِ یک معماریِ خوب و خوش تعریف از جنبه‌های مختلف بسیار حیاتی است. این روزها تکنولوژی، جنبه‌های مختلف از زندگی انسان را تحت تاثیر قرار داده است و طبق آمار به طور میانگین هر نفر روزانه 4 ساعت از زمان خود را صرف استفاده از ابزارهای مختلف مثل لپتاپ یا موبایل می‌کند. سیستم‌هایی که می‌سازیم هم دائما در حال تغییر و ارتقا هستند. مثلا اینترنت اشیا را در نظر بگیرید. در سال 2019 حدودا 8.6 میلیارد دستگاه به اینترنت متصل بود در حالی که برای سال 2023 این عدد به 15.14 میلیارد رسیده و پیش‌بینی می‌شود تا سال 2030 این عدد به حدود 30 میلیارد برسد. رهبران فناوری اطلاعات باید دائما شرایط آینده و تغییراتی که در صنایع آن‌ها رخ خواهد داد را رصد کنند.

هرچه عمر سیستم افزایش پیدا میکند و پیچیدگی آن زیادتر می‌شود، اهمیت داشتن یک معماری خوب نیز بالاتر می‌رود. هرچه جلوتر برویم، تغییر و نوسازی معماری گران‌تر و پیچیده‌تر خواهد شد. در کنار افزایش پیچیدگی و هزینه، احتمال ایجاد مشکلات بنیادی و ایجادِ مخاطرات برای کسب و کار نیز بیشتر می‌شود.برای مثال در سال 2017 شرکت هواپیمایی British Airways یک قطعی در سیستم فناوری اطلاعات خود داشت که موجب زمین‌گیر شدنِ ناوگان هوایی شد. در سرتاسر دنیا نزدیک به 75 هزار مسافر سرگردان شدند و شرکت متحمل ضرری 80 میلیون پوندی شد. سال بعد سیستم‌های شرکت هک شده و اطلاعات نیم میلیون مشتری نشت پیدا کرد و این بار شرکت متحمل ضرری 183میلیون پوندی شد. کار به همین‌جان ختم نشد. در سال 2019 باز هم خطا در سامانه‌های قدیمی موجب لغو بیش از 100 پرواز و سرگردانی مجدد مسافران شد و این بار هم 8 میلیون پوند دیگر ضرر به شرکت تحمیل گردید.

3.3. کاهش ناکارمدی‌ها:

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

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

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

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

4. اجتماعی کردنِ یک دیدگاه کل‌نگر از معماری:

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

4.1. معماری روی مدلسازی دامنه تاثر دارد:

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

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

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

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

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

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

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

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

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

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

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

4.4. آماده‌ی سوار شدن به آسانسور معماری باشید:

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

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

5. جمع بندی:

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

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