به هر سازمانی که وارد شویم به احتمال زیاد با سیستم‌های نرم‌افزاری قدیمی‌ای روبرو خواهیم شد که سال‌های متمادی از آن‌ها در سازمان استفاده شده است و به بخشی از بدنهٔ اصلی کاری و فرایند‌ها و روند‌های آن در سازمان بدل شده است. سیستم‌هایی که هر‌چند انگار جزء دارایی‌های سازمان به حساب می‌آیند و حس تعلق عمیقی را در بین نیروها و بدنهٔ سازمان ایجاد می‌کند اما دیگر نه پاسخ‌گوی نیازهای جدید کسبوکار (به خصوص در دورانی که کسب‌و‌کار‌ها در صنایع مختل باید خود را با الزامات جدید دنیای دیجیتالی تطبیق دهند) هستند و نه نگهداری و پشتیبانی از چنین سیستم‌هایی مقرون به صرفه و منطقی است. اگر باید اپلیکیشن‌های سازمانی قدیمی خود را مدرن کنید، انتخاب بهترین رویکرد برای این کار به مشکلی بستگی دارد که شما سعی در حل آن دارید. تحول دیجیتال به عنصری ضروری برای رهبران کسبوکار تبدیل شده که آن‌ها باید آن را در یافتن روش‌های موثر در نوسازی نرمافزارهای سازمانی خود مورد توجه قرار دهند. و پیش از هر چیز دیگری بزرگ‌ترین چالش آن‌ها در این مسیر آگاهی از نسبت ریسک به پاداش در نوسازی سیستم‌های قدیمی پیش از هرگونه اقدامی است.
استفان فن زیدن، تحلیلگر گارتنر، می‌گوید: «برای بسیاری از سازمان‌ها، سیستم‌های قدیمی مانعی بر سر ابتکارات تجاری و فرایند‌های کسبوکار لازم برای پیشبرد این ابتکار‌ها هستند. هنگامی که سازمان به یک نقطعهٔ عطف و حیاتی می‌رسد رهبران تصمیم‌گیرنده در سازمان باید به دنبال نوسازی برنامه‌های قدیمی باشندتا بتوانند موانع را از سر راه کسبوکار خود برطرف سازند.»
گارتنر برای جهت‌دهی به رویکرد‌های مختلف در چگونگی مدرن‌سازی سیستم‌های قدیمی یک روند ارزیابی سه مرحله‌ای را پیشنهاد می‌دهد. روندی که بهترین روش در آن بسته به مشکلی که باید حل شود می‌تواند متفاوت باشد.
بیشتر بخوانید: گرایش‌های برتر فناوری در سال ۲۰۲۱ به انتخاب گارتنر
مرحله ۱: ارزیابی سیستم‌های قدیمی با استفاده از شش محرک
شش محرک اصلی برای نوسازی برنامه‌های نرم‌افزاری وجود دارد. این شش محرک مشکلات، نگرانی‌ها یا موانعی هستند، که به واسطهٔ جنبه‌های مساله‌ساز در فناوری، معماری یا کاربردی در استفاده از سیستم‌های نرم‌افزاری قدیمی در سازمان به وجود آمده‌اند.
خاستگاه سه مورد از این محرک‌ها خود کسبوکار هستند. این سه محرک، تناسب نرم‌افزار با کسبوکار، ارزش‌آفرینی آن برای کسبوکار و چابکی هستند. اگر نرمافزارهای قدیمی‌شدهٔ سازمان پاسخ‌گوی نیازهای جدید کسبوکار در دوران دیجیتال نباشند، باید برای ایجاد تناسب نرم‌افزار با نیازهای جدید دست به مدرن‌سازی آن زد. علاوه بر این چنین سیستمی باید برای ارزش‌آفرینی بیشتر برای کسبوکار ارتقا یابد. همچنین نرم‌افزارهایی که فاقد چابکی لازم برای تطابق کسبوکار با نیازهای دیجیتال آن هستند، ممکن است منجر به هزینه‌زایی و افزایش ریسک سازمان شوند.
سه محرک دیگر از جایگاه فناوری اطلاعات سازمان بیرون می‌آیند. این سه محرک هزینه، پیچیدگی و ریسک هستند. اگر هزینه کل مالکیت نرم‌افزار بسیار بالا باشد، فناوری آن بیش از حد پیچیده باشد، یا امنیت، انطباق‌پذیری، پشتیبانی یا مقیاس‌پذیری آن در خطر افتاده باشد، زمان نوسازی آن برنامه رسیده است.
بهترین فرصت‌های نوسازی متعلقق به سازمان‌هایی است که درگیر چندین محرک اشاره شده از هر دو دستهٔ محرک‌های با خاستگاه خود کسبوکار و محرک‌های مرتبط با فناوری اطلاعات باشند.
بهترین فرصت‌های نوسازی متعلقق به سازمان‌هایی است که درگیر چندین محرک اشاره شده از هر دو دستهٔ محرک‌های با خاستگاه خود کسبوکار و محرک‌های مرتبط با فناوری اطلاعات باشند.
مرحله ۲: ارزیابی گزینه‌های نوسازی نرمافزارهای سازمانی قدیمی
هنگامی که مشکل شناسایی شد و فرصت نوسازی پیش آمد؛ باید به گزینه‌های مختلفی که در مورد این نوسازی پیش رو داریم بیاندیشیم. گارتنر هفت گزینه را به ترتیب سهولت پیاده‌سازی و اجرا انتخاب کرده است (ترتیب این ۷ گزینه به این شکل است که از گزینه‌های آسان‌تر، کم‌ریسک‌تر و کم‌اثر‌تر بر روی سیستم‌ها و فرایند‌های کسبوکار شروع می‌شود و هر چه پیش‌تر می‌رود به تناسب ریسک و اثرگذاری آن گزینه نیز بیشتر می‌شود.)
۷ گزینه نوسازی سیستم‌های نرم‌افزاری قدیمی سازمان گارتنر
- کپسوله‌سازی* (Encapsulate): با کپسوله‌سازی داده‌ها و عملکرد‌های یک برنامهٔ نرم‌افزاری و در دسترس قرار دادن آن‌ها به عنوان سرویس‌های API اقدام به گسترش و توانمند‌سازی قابلیت‌های سیستم کنید.
- میزبانی مجدد (Rehost): بدون ایجاد هرگونه تغییری در کدها و قابلیت‌های نرم‌افزار مجدداً آن برنامه را به زیرساختی دیگر (فیزیکی ، مجازی یا ابری) منتقل کنید.
- تغییر پلتفرم (Replatform): بدون انجام هرگونه تغییری در ساختار کدها و ویژگی‌های نرم‌افزار و با اعمال کم‌ترین تغییرات در کدها به یک پلتفرم زمان اجرای (Runtime Platform) جدید مهاجرت کنید.
- بازسازی کدها** (Refactor): کد‌های موجود را بازسازی و بهینه سازی کنید (بدون تغییر رفتار خارجی آن) تا بدهی فنی (بدهی کد)*** و ویژگی‌های غیر کارکردی برطرف شوند.
- بازمعماری (Rearchitect): کدها را از اساس تغییر دهید و آن را به سمت یک معماری نرم‌افزاری جدید سوق دهید تا از قابلیت‌های جدید‌تر و بهتری بهره‌برداری کنید.
- بازسازی (Rebuild): اجزای برنامه را از صفر مجدداً بازطراحی یا بازنویسی می‌کنید در حالی که دامنه و مشخصات برنامه را حفظ می‌کنید.
- جایگزینی (Replace): اجزای محتلف برنامهٔ قدیمی را به صورت کامل حذف می‌کنید و آن‌ها را با درنظر گرفتن توامان ملزومات و نیاز‌مندی‌های جدید با برنامهٔ جدید جایگزین می‌کنید.
بیشتر بخوانید: شورای فناوری فوربز و ۱۴ شاخص کلیدی عملکرد برای ارزیابی موفقیت تحول دیجیتال
مرحله ۳: انتخاب یک روش نوسازی با بالاترین میزان اثر و ارزش‌آفرینی
در مرحلهٔ سوم و آخر با بررسی دقیق هفت گزینه نوسازی سیستم‌های قدیمی سازمانی از حیثث اثرگذاری آن‌ها بر بر فناوری، معماری، عملکرد، هزینه و ریسک یک گزینهٔ نوسازی را انتخاب کنید که بالاترین اثربخشی و ارزش‌آفرینی را برای سازمان شما به دنبال داشته باشد.
در پایان، نوسازی برنامه‌های سازمانی به معنی انتخاب بین گزینه‌های «بازمعماری»، «بازسازی» یا جایگزینی است. «بازمعماری سیستم‌های قدیمی» هزینه و ریسکی متوسط را به شما تحمیل خواهد کرد؛ در حالی که «بازسازی» یا «جایگزینی»، بهترین نتایج را با هزینه‌ها و ریسک‌های بیشتر برای شما ممکن خواهد کرد. کلید موفقیت در نوسازی اما این است که تمام گزینه‌ها را مورد سنجش قرار دهید تا میزان تاثیر هر کدام بر کسبوکار را با حدقل تلاش و حداکثر اثربخشی را ارزیابی کنید.
پانویس
* کپسوله‌سازی (Encapsulation) یا پوشاندن یا لفافه‌بندی، در علم رایانه مخفی‌سازی مکانیزم داخلی و ساختار داده‌های اجزای نرم‌افزار در پشت یک رابط کاربری است. بدین طریق کاربر یک نرم‌افزار نیازمند آن است که بداند آن قطعه نرم‌افزاری چه می‌کند و نمی‌تواند آن‌ها را منوط به چگونگی اجرای آن‌ها بکند.
**بازسازی کد (code refactoring) یک فرایند می‌باشد که طی آن، یک کدِ نوشته شده بدون آن که رفتار خارجی‌اش عوض شود، بازسازی می‌شود. به عبارتی دیگر، بازسازی کد به معنای تغییر یک سیستم نرم افزاری به منظور ارتقا و بهبود ساختار داخلی آن به صورتی که رفتار بیرونی آن تحت تأثیر قرار نگیرد، می‌باشد. اگر بخواهم دقیق تر بگوییم، بازسازی کد را می‌توان راهی برای منظم و تمیز کردن ساختار کد دانست. این کار برای جلوگیری از ایجاد باگ‌های نرم افزاری انجام می‌شود.
*** بدهی فنی (technical debt) (همچنین به عنوان بدهی طراحی یا بدهی کد شناخته می‌شود) مفهومی در توسعه نرم‌افزار است که نشان دهنده هزینه ضمنی کار اضافی ناشی از انتخاب یک راه حل آسان (محدود) در زمان حال به جای استفاده از یک رویکرد بهتر است که طولانی‌تر خواهد بود.
