روش های مدرن سازی معماری نرم افزار

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

استفاده از تکنیک ها و روش های مدرن سازی معماری نرم افزار

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

نام ICE سرنام International Copyright Enterprise Services است که به‌عنوان یک ارائه‌دهنده‌ پیشرو در خدمات پردازش حق امتیاز و کپی رایت در صنعت موسیقی فعالیت می‌کند. ICE با موانعی در سیستم‌ها و زیرساخت‌های فناوری اطلاعات روبه‌رو بود. در دنیای جدید، پخش آنلاین موسیقی و کسب‌وکارهای مربوط به آن به‌طور قابل ملاحظه‌ای زیاد شد و این افزایش حجم داده‌ها، موجب کند شدن فرآیند پردازش آن‌ها شد. در کنار این افزایش حجم درخواست، کسب‌وکار با مشکل دیگری نیز مواجه بود. در فرآیندها و معماری قدیمی، بخش زیادی از کار به‌صورت دستی انجام می‌شد؛ این موضوع موجب افزایش ریسک ایجاد خطا و پیچیدگی بیش از حد در فرآیندهای کاری بود. در چنین شرایطی، هنگامی که ویژگی‌ جدیدی درخواست می‌شد، فرآیند کاری در پروژه‌ای مستقل انجام می‌پذیرفت. ادامه این فرآیند موجب شد ترویج روش های مدرن سازی معماری نرم افزار و شیوه‌های مهندسی مدرن و توسعه پایدار دشوار شود. باتوجه به این شرایط و اینکه ICE می‌خواست جایگاه خود را در بازار رقابتی حفظ کند، در سال ۲۰۲۰ سفر مدرن‌سازی معماری را شروع کرد. هدف ICE این بود که درحالی‌که به‌سوی یک رویکردِ محصول‌محور (Product Centric) حرکت می‌کند، سرعت، دقت و مقیاس‌پذیری سیستم‌های فناوری اطلاعات را نیز افزایش دهد.

در ابتدای سفر مدرن‌سازی و برای اصلاح زیرساخت IT پردازش حق امتیاز، از روش های مدرن سازی معماری نرم افزار به شکل استراتژیک مختلفی استفاده کردیم. از Domain-Driven Design (DDD) و Event Storming به‌عنوان ابزارهایی برای درک دامنه و رفتارهای خاص آن استفاده کردیم. در طول جلسات Big Picture Event Storming، ما روی ثبت روابط و تعاملات بین ذی‌نفعان مختلف، سیستم‌ها و رویدادهایی که در دامنه‌ پردازش حق امتیاز اتفاق می‌افتند، تمرکز کردیم. جلسات شامل مخاطبان وسیعی بود تا از دیدگاه‌ها و دانش‌های مختلف که در این دامنه وجود دارند، مطلع شویم؛ زیرا می‌خواستیم یک دید کلی جامع از حوزه کسب‌وکار به‌دست آوریم.

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

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

نتایج استفاده از روش های مدرن سازی معماری نرم افزار

ما شروع به پیاده‌سازیِ روش های مدرن سازی معماری نرم افزار جدید کاری در تیم‌های توسعه کردیم. ما روال‎‌های یکپارچه‌سازی مستمر / استقرار مستمر (CI/CD) و زیرساخت به‌‌عنوان کد (Infrastructure as a code) را مورداستفاده قرار دادیم. با این کار، ما توانستیم به‌طور خودکار تغییرات کد را چندین بار در روز Build، تست کنیم و درنهایت به جریان کاری منتقل کنیم. علاوه‌بر این، ما شروع به استفاده از Pair Programming کردیم که این تکنیک های مدرن سازی معماری نرم افزار منجر به افزایش اشتراک دانش و همکاری در تیم‌ها شد. همچنین ما مطمئن شدیم که تیم‌های توسعه و کسب‌وکار از نزدیک باهم همکاری می‌کنند و این موضوع، موجب افزایش درک همه از محصولات شد و قدرت کسب‌وکاری را ارتقا بخشید. با ادامه کار به این روش، توانایی ما در گسترش تیم بیشتر شد و توانستیم تیم‌های بیشتری تشکیل دهیم و سازمان خود را تبدیل به سازمانی کنیم که با نقشه‌ راه محصول به‌صورت فصلی و سالانه کار می‌کند و ارزش‌هایی را به‌صورت مکرر و با افزایش‌های کوچک ارائه می‌دهد.

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

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

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

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

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

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

روش های مدرن سازی معماری نرم افزار : شناسایی امکان تغییر عمیق

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

1. اجتناب از ساختار و فرایند اشتباه

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

2. پذیرش رویکردهای معماری مشترک

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

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

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

3. دور شدن از ساختارهای سیلویی در سازمان

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

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

4. سرمایه‌گذاری روی شیوه‌های باکیفیت فنی

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

من یکی از طرفداران Test Driven Development و pair/mob programming هستم. این تکنیک‌ها و روش های مدرن سازی معماری نرم افزار، رویِ طراحیِ نرم‌افزارهای باکیفیت و تست‌شده بااستفاده از طراحی‌های دقیق و بازسازی (refactoring) مداوم تمرکز می‌کنند. هنگامی که در جستجوی راه‌حل‌های ساده و قابل نگهداری برای پیاده‌سازی یک عملکرد جدید هستید، این تکنیک‌ها بسیار راهگشا هستند. ممکن است به‌نظر برسد استفاده از این تکنیک‌ها زمان زیادی می‌برد و موجب افزایش هزینه‌ها می‌شود، اما زمانی که به‌طور مؤثر از آن‌ها استفاده شود، متوجه می‌شویم که آن‌ها در کوتاه‌مدت، میان‌مدت و به‌ویژه بلندمدت، بازدهی عالی خواهند داشت. با این حال، مانند بسیاری از تکنیک‌های دیگر، این تکنیک‌ها نیز می‌توانند بسیار تفرقه‌انگیز باشند. همه‌ی تیم‌های برنامه‌نویسی TDD و pair/mob programming را دوست ندارند؛ بنابراین مهم است که آنچه را که برای شما مناسب‌تر است، پیدا کنید.

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

روش های مدرن سازی معماری نرم افزار : اجتناب از مدرن سازی های سطحی

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

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

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

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

روش های مدرن سازی معماری نرم افزار : توسعه‌ رهبران در تمامی سطوح

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

الگوها و رهبرانِ مدرن‌سازی وظایف زیادی دارند، ازجمله:

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

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

برای استفاده از روش های مدرن سازی معماری نرم افزار لازم است بدانید که بسته به اینکه سازمان شما از کجا شروع می‌کند، احتمالاً از روز اول همه‌ این افراد کاملاً خبره نخواهند بود. این بدان معناست که برای رسیدن به هدف خود، به یک راه حل کوتاه‌مدت و یک برنامه بلند‌مدت نیاز دارید. این هدف، یک تیم توانمند‌سازِ نوسازی معماری یا Architecture Modernization Enabling Team (AMET)(AMET) است.

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

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

• مدیر فنی (CTO)
• معمار ارشد نرم‌افزار
• معمار نرم‌افزار
• مدیران ستادی
• معمار سازمانی
• معمار داده
• معاون فنی و مهندسی

جمع‌ بندی

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