3.6 پرانے نظاموں کی جدید کاری

جائزہ اور محرکات

پرانے نظام وہ نظام ہیں جو دنیا کو چلاتے ہیں۔ بنیادی بینکاری کے کھاتے، ٹیکس اور فوائد کے انجن، فضائی ٹریفک اور دفاعی نظام، بیمہ پالیسی کا انتظام، اور سرکاری رجسٹریاں جن پر معاشرے انحصار کرتے ہیں اکثر دہائیوں پرانے ہیں۔ بہت سے COBOL (Common Business-Oriented Language) یا دیگر پرانی ٹیکنالوجیز میں لکھے ہیں، اور وہ اب بھی نازک ٹرانزیکشنز کی اکثریت پروسیس کرتے ہیں۔ “Legacy” کوئی توہین نہیں۔ اس کا مطلب ہے کہ نظام اتنا قیمتی ہے کہ بچ گیا، اتنا نازک ہے کہ ناکامی تباہ کن ہو، اور اتنا پرانا ہے کہ اسے محفوظ طریقے سے بدلنا مشکل ہے۔ پرانے نظاموں کی جدید کاری ان نظاموں کو بہتر بنانے، منتقل کرنے، یا بدلنے کا نظم و ضبط ہے بغیر اس کے کہ وہ جو ضروری خدمات دیتے ہیں وہ ٹوٹیں۔

یہ غیر متناسب طور پر انٹرپرائز اور حکومت کا مسئلہ ہے، اور یہیں سب سے بڑی، سب سے عوامی IT ناکامیاں ہوتی ہیں۔ دنیا بھر کی بڑی ٹرانزیکشنز کا وسیع حصہ اب بھی مین فریم نظاموں کو چھوتا ہے۔ بڑے اداروں میں پروڈکشن کوڈ کا بڑا حصہ پرانی زبانوں میں ہے جسے ماہرین کا عمر رسیدہ، سکڑتا گروہ برقرار رکھتا ہے۔ حکومتوں پر سب سے بھاری بوجھ ہے: دہائیوں میں انکوڈ ہوئی قانونی ذمہ داریاں، خریداری اور بجٹ کے چکر جو انتظامیہ سے زیادہ جیتے ہیں، اور شہری خدمات جن میں رکاوٹ نہیں آ سکتی۔ بنیادی خطرہ یہ نہیں کہ یہ نظام پرانے ہیں، کیونکہ بہت سے شاندار چلتے ہیں۔ یہ ہے کہ انہیں برقرار رکھنے کا علم ریٹائر ہو رہا ہے، پلیٹ فارمز تیزی سے مہنگے اور محدود ہو رہے ہیں، اور “بس دوبارہ لکھ دو” کی ترغیب میدان کی تاریخ کی کچھ مہنگی ترین ناکامیوں تک لے جاتی ہے۔

یہ باب بتدریج جدید کاری کے وہ نمونے کا احاطہ کرتا ہے جو دراصل کام کرتے ہیں (اسٹرینگلر فِگ اور تجرید کے ذریعے شاخ)، پرانے نظاموں کے خطرے کا جائزہ اور ترجیح کیسے طے کریں، مین فریم اور COBOL کی جائیدادوں کی نگہبانی، ڈیٹا کی منتقلی اور دوہری چلت کا نظم و ضبط، اور سب سے بڑھ کر بڑی دوبارہ تحریر کی ترغیب کی مزاحمت کیسے کریں۔ مرکزی یقین یہ ہے کہ کامیاب جدید کاری تقریباً ہمیشہ بتدریج، شہادت پر مبنی، اور مسلسل قدر پہنچانے والی ہوتی ہے۔ یہ کبھی کئی سالہ بڑا دھماکہ نہیں۔

بنیادی اصول

• Legacy کا مطلب قیمتی اور بنیادی ہے، محض پرانا نہیں۔ نظام کو چھونے سے پہلے اس کے کام کا احترام کریں؛ یہ دہائیوں کے مشکل سے حاصل کیے کاروباری قواعد انکوڈ کرتا ہے۔
• بتدریج تقریباً ہمیشہ بڑے دھماکے سے بہتر ہے۔ مستحکم انٹرفیس کے پیچھے ٹکڑا ٹکڑا بدلیں؛ مسلسل قدر پہنچائیں اور خطرہ چھوٹا رکھیں۔
• بڑی دوبارہ تحریر ڈیفالٹ ناکامی کا انداز ہے۔ مکمل دوبارہ تحریریں معمول سے حد سے بڑھتی ہیں، کم پہنچاتی ہیں، اور منسوخ ہوتی ہیں؛ اس خواہش کو گہرے شک سے دیکھیں۔
• جسے آپ سمجھتے نہیں اسے جدید نہیں کر سکتے۔ بدلنے سے پہلے رویے (بشمول غیر دستاویزی قواعد) کو ریورس انجینئر اور دستاویزی کریں۔
• ڈیٹا کی منتقلی وہ جگہ ہے جہاں منصوبے مرتے ہیں۔ ڈیٹا کسی کی توقع سے پرانا، گندا، اور الجھا ہوا ہے؛ اسے اولین درجے کی کوشش سمجھ کر منصوبہ بنائیں۔
• اعتماد بنانے کے لیے پرانا اور نیا متوازی چلائیں۔ دوہری چلت اور موازنہ کٹ اوور سے پہلے تضادات پکڑتے ہیں۔
• عمر کی بجائے خطرے اور قدر سے ترجیح دیں۔ جو سب سے خطرناک اور قیمتی ہے اسے پہلے جدید کریں، جو محض سب سے پرانا ہے اسے نہیں۔
• انجن بدلتے ہوئے بتیاں جلتی رکھیں۔ سروس پورے وقت چلتی رہنی چاہیے؛ نازک شہری یا مالیاتی نظاموں کے لیے کوئی قابل قبول بندش نہیں۔

سفارشات

اسٹرینگلر فِگ کے نمونے سے بتدریج جدید کاری کریں

اسٹرینگلر فِگ (اس بیل کے نام پر جو درخت کے گرد اگتی اور بتدریج اس کی جگہ لیتی ہے) محفوظ جدید کاری کا کام کا گھوڑا ہے۔ پرانے نظام کے سامنے روٹنگ کی تہہ (API گیٹ وے، سامنے کا حصہ، یا پراکسی) رکھیں۔ پھر صلاحیت بہ صلاحیت، جدید نظام میں متبادل بنائیں اور ٹریفک کا وہ ٹکڑا اس کی طرف موڑیں، باقی کو پرانے نظام پر چھوڑتے ہوئے۔ وقت کے ساتھ نیا نظام بڑھتا اور پرانا سکڑتا ہے، یہاں تک کہ اسے ریٹائر کیا جا سکے۔ یہ مسلسل قدر پہنچاتا ہے، ہر تبدیلی کو چھوٹا اور قابل واپسی رکھتا ہے، خطرناک کٹ اوور سے بچاتا ہے، اور آپ کو کسی بھی نقطے پر رکنے یا ترجیحات بدلنے دیتا ہے۔ یہ بڑے دھماکے کا الٹ ہے۔ پرانا نظام چلتا رہتا اور اپنی روزی کماتا رہتا ہے جبکہ آپ اس کے گرد اسے بدلتے ہیں۔

اندرونی جوڑوں کے لیے تجرید کے ذریعے شاخ استعمال کریں

جہاں آپ کو ایسا جزو بدلنا ہو جس پر نظام کے بہت سے حصے انحصار کرتے ہیں، تجرید کے ذریعے شاخ استعمال کریں۔ موجودہ نفاذ پر تجرید کی تہہ (انٹرفیس) متعارف کروائیں، کال کرنے والوں کو تجرید پر منحصر ہونے کے لیے منتقل کریں، اسی تجرید کے پیچھے نیا نفاذ بنائیں، (اکثر فیچر فلیگ کے پیچھے، بتدریج) سوئچ کریں، اور آخر میں پرانا نفاذ ہٹا دیں۔ یہ بڑے جزو کو ترقی کی مرکزی لائن پر لمبی عمر کی شاخ کے بغیر بتدریج بدلنے دیتا ہے، پورے وقت نظام کو ریلیز کے قابل رکھتے ہوئے۔ یہ اسٹرینگلر فِگ کے ساتھ فطری طور پر جوڑ بناتا ہے: سامنے کا حصہ بیرونی جوڑ سنبھالتا ہے، تجرید کے ذریعے شاخ اندرونی۔

پرانے نظاموں کے خطرے کا جائزہ لیں اور جان بوجھ کر ترجیح دیں

جدید کاری سے پہلے جائیداد کی واضح نظر والی فہرست اور خطرے کا جائزہ بنائیں۔ ہر نظام کو کاروباری اہمیت، تکنیکی خطرے (متروک ہونا، غیر سپورٹ شدہ پلیٹ فارمز، سلامتی کی نمائش)، تبدیلی کی تعدد، اور، اہم ترین، علم کے خطرے (کتنے لوگ اسے اب بھی برقرار رکھ سکتے ہیں، اور وہ ریٹائرمنٹ سے کتنے قریب ہیں) پر اسکور کریں۔ نظاموں کو خطرے بمقابلہ قدر کے گرڈ پر رکھیں۔ جو اعلیٰ خطرے اور اعلیٰ قدر دونوں ہو اسے پہلے جدید کریں۔ مستحکم، کم تبدیلی والے، اچھی طرح سمجھے نظاموں کو پرانے ہونے کے باوجود چھوڑنے پر غور کریں، کیونکہ کام کرتا نظام جسے کسی کو بدلنے کی ضرورت نہیں ہنگامی صورت نہیں۔ یہ جائزہ “سب کچھ پرانا اور ڈراؤنا ہے” کو قابل دفاع، ترتیب شدہ روڈ میپ میں بدلتا ہے۔

مین فریم اور COBOL کی جائیداد کی نگہبانی کریں، صرف اسے بدلیں نہیں

ہر مین فریم یا COBOL نظام جلد بدلا نہیں جانا چاہیے، یا محفوظ طریقے سے بدلا نہیں جا سکتا۔ قریب مدتی ترجیح اکثر نگہبانی ہے: علم کو ریٹائر ہونے سے پہلے گرفت میں لیں۔ کوڈ کے انکوڈ کردہ کاروباری قواعد دستاویزی کریں (جن کا بڑا حصہ غیر دستاویزی اور ناقابل تلافی ہے)، خودکار ٹیسٹوں میں سرمایہ لگائیں جو موجودہ رویہ پن کریں تاکہ آئندہ تبدیلی محفوظ ہو، نگہبانوں کو بھرتی اور کراس ٹرین کریں، اور گرد کے ترسیلی عمل (سورس کنٹرول، مسلسل انضمام (CI)، خودکار ٹیسٹنگ) جدید کریں چاہے مرکز اپنی جگہ رہے۔ جہاں آپ جدید کریں وہاں پہلے قدم کے طور پر پرانی صلاحیتوں کو جدید APIs کے ذریعے ظاہر کرنے (encapsulation) کو ترجیح دیں۔ COBOL سے جدید زبان کے خودکار ترجمے کو احتیاط سے لیں، کیونکہ یہ ایسا کوڈ پیدا کرتا ہے جو چلتا ہے مگر اکثر ناقابل فہم منطق کو ہو بہو دہراتا ہے۔ سب سے کم یاب وسیلہ فہم ہے، کمپیوٹ نہیں۔

ڈیٹا کی منتقلی اور دوہری چلت کو منصوبے کا مرکز سمجھیں

زیادہ تر جدید کاری کی کوششوں کا سب سے مشکل اور خطرناک حصہ ڈیٹا ہے۔ یہ بڑا، ناقص اور غیر مستقل معیار کا، اور دہائیوں میں جمع ہوئے غیر دستاویزی معنی سے بھرا ہے۔ اسے پروفائل اور صاف کریں، پرانے سے نئے اسکیما کا نقشہ واضح طور پر بنائیں، اور مکمل مصالحت (گنتیاں، چیک سم، کاروباری مجموعے) کے ساتھ قابل تکرار، خودکار منتقلی بنائیں تاکہ آپ ثابت کر سکیں کہ کچھ کھویا یا بدلا نہیں۔ دوہری چلت (متوازی چلت) سے کٹ اوور کا خطرہ کم کریں: پرانے اور نئے نظاموں کو ایک ہی ان پٹس پر ساتھ ساتھ چلائیں اور آؤٹ پٹس کا موازنہ کریں جب تک نیا نظام آپ کے اعتماد کی حد تک پرانے سے میل نہ کھائے۔ صرف تب کٹ اوور کریں، اور واپسی کی صلاحیت برقرار رکھیں۔ واقعی نازک نظاموں کے لیے ایک ساتھ سب کی بجائے ٹکڑوں میں منتقل اور کٹ اوور کریں۔

بڑی دوبارہ تحریر کی ترغیب کو سنبھالیں

گندے پرانے نظام کو پھینک کر شروع سے صاف نیا بنانے کی جبلت طاقتور ہے، اور بڑے، نازک نظاموں کے لیے یہ تقریباً ہمیشہ غلط ہے۔ مکمل دوبارہ تحریریں “بدصورت” کوڈ میں چھپی قدر (کنارے کی صورتیں، ضابطے کے قواعد، بگ سے مطابقت والے رویے جن پر حقیقی صارفین انحصار کرتے ہیں) کم سمجھتی ہیں، اندازے سے کہیں زیادہ وقت لیتی ہیں، آخر تک کوئی قدر نہیں پہنچاتیں، اور بھاری خرچ کے بعد اکثر منسوخ ہوتی ہیں۔ بتدریج جدید کاری کو ڈیفالٹ بنائیں۔ دوبارہ تحریریں ان صورتوں کے لیے رکھیں جہاں پلیٹ فارم واقعی ناقابل برداشت ہو اور بتدریج راستے ختم ہو چکے ہوں۔ تب بھی دوبارہ تحریر کو ایک بڑے دھماکے والی ریلیز کی بجائے اسٹرینگلر پیٹرن سے آزادانہ طور پر قابل ترسیل ٹکڑوں میں تقسیم کریں۔ جب قیادت مکمل دوبارہ تحریر کے لیے دباؤ ڈالے تو سوال پر اصرار کریں: پہلے تین مہینوں میں کون سی قدر پہنچتی ہے، اور اگر پروگرام آدھے راستے میں روک دیا جائے تو کیا ہوتا ہے؟

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات
اسٹرینگلر فِگ (بتدریج)	مسلسل قدر، کم خطرہ، قابل واپسی، سروس کو چلتا رکھتا ہے	مجموعی وقت لمبا، دو نظام متوازی چلانے ہوں گے، انضمام کا اضافی بوجھ
بڑے دھماکے والی دوبارہ تحریر	صاف تختہ، نئے کوڈ میں پرانی پابندیاں نہیں	ناکامی کی بہت اونچی شرح، آخر تک کوئی قدر نہیں، بہت بڑی لاگت، کاروباری قواعد کھو جاتے ہیں
Encapsulate (APIs سے لپیٹنا)	تیز، کم خطرہ، مرکز کو چھوئے بغیر رسائی جدید کرتا ہے	مرکز پرانا رہتا ہے؛ بنیادی خطرے کو ٹالتا ہے، حل نہیں کرتا
جیسا ہے چھوڑنا (نگہبانی)	منصوبے کا کوئی خطرہ نہیں؛ مختصر مدت میں سستا	علم اور پلیٹ فارم کا خطرہ جمع ہوتا رہتا ہے؛ آخرکار مجبور عمل

بنیادی سمجھوتا تبدیلی کی رفتار بمقابلہ ناکامی کے خطرے کا ہے، اور پرانے نظاموں کی جدید کاری وہ میدان ہے جہاں یہ سودا سب سے زیادہ یک طرفہ ہے۔ “تیز، صاف” بڑے دھماکے والی دوبارہ تحریر سراب ہے جو بار بار سب سے سست اور مہنگا نتیجہ پیدا کرتی ہے: منسوخ پروگرام اور اب بھی ناجدید نظام۔ بتدریج طریقے سست لگتے ہیں اور دو نظام متوازی چلانا مانگتے ہیں، مگر وہ پورے وقت قدر پہنچاتے ہیں، خطرہ چھوٹا اور قابل واپسی رکھتے ہیں، اور تجرباتی طور پر قابل اعتماد راستہ ہیں۔ حقیقی فیصلے کا کام مستحکم پرانے نظام کی تھوڑی دیر اور نگہبانی کرنے اور ابھی بتدریج تبدیلی شروع کرنے کے درمیان ہے۔ اس فیصلے کو پرانی ٹیکنالوجی سے بے آرامی کی بجائے خطرے کی سمت، خاص طور پر علم کے خطرے، سے چلنے دیں۔

اپنی ٹیم کے ساتھ بحث کے سوالات

1. کیا آپ کے پاس اپنے پرانے نظام کے سامنے روٹنگ کی تہہ رکھنے کی جگہ ہے، اور اگر نہیں تو اسے بنانے کے لیے کیا درکار ہے؟ اسٹرینگلر فِگ جوڑ پر منحصر ہے: API گیٹ وے، سامنے کا حصہ، یا پراکسی جس کے ذریعے آپ ایک وقت میں ایک صلاحیت نئے نفاذ کی طرف موڑ سکیں۔ بہت سے پرانے نظاموں میں ایسا کوئی جوڑ نہیں، اس لیے پہلا جدید کاری کا اضافہ اکثر محض روکنے کا نقطہ بنانا ہے، اور اس کام کا کم اندازہ لگانا آسان ہے۔ موجودہ انضمام کا نقشہ لائیں اور پوچھیں کہ بڑے دھماکے والے کٹ اوور کے بغیر ٹریفک فی صلاحیت کہاں روکا جا سکتا ہے۔ اگر کہیں نہیں تو اندرونی جوڑ پر تجرید کے ذریعے شاخ شروعاتی قدم ہو سکتا ہے۔ روٹنگ کی تہہ کے بغیر آپ کے پاس بتدریج راستہ نہیں، اور اسی طرح ادارے اس دوبارہ تحریر کی طرف واپس دھکیلے جاتے ہیں جو عموماً ناکام ہوتی ہے۔

2. کیا آپ نے واقعی اپنی جائیداد کو خطرے بمقابلہ قدر کے گرڈ پر رکھا ہے، یا آپ کا روڈ میپ اس سے چلتا ہے کہ کون سا نظام سب سے پرانا لگتا ہے؟ باب اصرار کرتا ہے کہ آپ پہلے اعلیٰ خطرے اور اعلیٰ قدر والے نظام جدید کریں، اور مستحکم، کم تبدیلی والے، اچھی طرح سمجھے نظاموں کو ان کے قدیم ہونے کے باوجود جان بوجھ کر چھوڑ دیں۔ واضح گرڈ کے بغیر توجہ سب سے زور دار شکایت یا کم از کم فیشن کی ٹیکنالوجی کی طرف بہتی ہے، اور حقیقی ٹائم بم (ایسا نازک نظام جس کے دو نگہبان ریٹائرمنٹ کے قریب ہوں) انتظار کرتے ہیں۔ ہر نظام کو کاروباری اہمیت، تکنیکی خطرے، تبدیلی کی تعدد، اور علم کے خطرے پر اسکور کریں، پھر اوپر دائیں کونے سے ترتیب دیں۔ وہ گرڈ اجلاس میں مشترک نقشے کے طور پر لائیں۔ علم کے خطرے کو سب سے بھاری وزن دیں، کیونکہ یہ واحد ان پٹ ہے جو صرف بدتر ہوتا ہے اور لوگوں کے جانے کے بعد خریدا نہیں جا سکتا۔

3. جب آپ کٹ اوور کریں گے تو آپ کیسے ثابت کریں گے کہ ایک بھی ریکارڈ نہیں کھویا یا بدلا، اور اس شہادت پر دستخط کون کرتا ہے؟ ڈیٹا کی منتقلی وہ جگہ ہے جہاں یہ منصوبے مرتے ہیں، اور اعتماد مصالحت سے آتا ہے: قطاروں کی گنتی، چیک سم، اور کاروباری کنٹرول کے مجموعے جو پرانے اور نئے میں میل کھائیں، ساتھ دوہری چلت جو ایک ہی ان پٹس پر آؤٹ پٹس کا موازنہ کرتی ہے جب تک وہ اونچی حد تک متفق نہ ہوں۔ فوائد یا کھاتے کے نظام کے لیے تضاد کا مطلب کم ادا شدہ شہری یا کھویا ہوا سینٹ ہے، اس لیے شہادت کو انجینئر کی نہیں آڈیٹر کی تسلی کرنی ہوگی۔ ابھی فیصلہ کریں کہ آپ کون سے مجموعے مصالحت کریں گے، کون سی اعتماد کی حد کٹ اوور چلائے گی، اور آپ پرانا اور نیا کتنی دیر متوازی چلائیں گے۔ پورے وقت واپسی دستیاب رکھیں، اور ایک ساتھ سب کی بجائے ٹکڑوں میں کٹ اوور کریں۔ دوہری چلت کے دوران جو تضادات آپ پاتے ہیں وہ عموماً غیر دستاویزی پرانے قواعد ہیں جنہیں آپ کو محفوظ رکھنا ہے، اس لیے ہر ایک کو محض نقص نہیں بلکہ دریافت سمجھیں۔

4. آپ کے کون سے پرانے نظاموں کی آپ نگہبانی کر رہے ہیں بمقابلہ فعال طور پر بدل رہے ہیں، اور کس نے طے کیا کہ کون سا کون سا ہے؟ باب ان نظاموں کے درمیان جان بوجھ کر لکیر کھینچتا ہے جو اپنی جگہ مستحکم کرنے کے قابل ہیں (قواعد دستاویزی کرنا، خصوصیات متعین کرنے والے ٹیسٹ جوڑنا، نگہبانوں کو کراس ٹرین کرنا) اور جو بتدریج بدلنے کے قابل ہیں، اور دونوں بہت مختلف فنڈنگ اور عملہ مانگتے ہیں۔ بڑے ادارے کے لیے خطرہ بھٹکاؤ ہے: “ابھی نگہبانی کریں” کا لیبل لگا نظام خاموشی سے “ہمیشہ نگہبانی” بن جاتا ہے جب تک آخری نگہبان ریٹائر نہ ہو اور انتخاب بحران میں آپ کے لیے ہو جائے۔ متصادم غور نگہبانی کی لاگت اور پلیٹ فارم کا متروک ہونا ایک طرف اور بدلنے کا خطرہ اور خلل دوسری طرف ہیں، اور علم کے خطرے کو پلڑا جھکانا چاہیے کیونکہ یہ صرف بدتر ہوتا ہے۔ خطرے بمقابلہ قدر کا گرڈ، ہر نظام کے نگہبانوں کی تعداد اور ریٹائرمنٹ کا افق، اور نگہبانی-یا-تبدیلی کے فیصلے کا واضح مالک لائیں۔ انٹرپرائز اور سرکاری جائیدادوں میں ہر نظام کے لیے ریویو کی تال اور جوابدہ افسر کا نام لیں، کیونکہ وہ درجہ بندی جس پر کوئی نظر ثانی نہ کرے وہ فیصلہ ہے جو کوئی نہیں کر رہا۔

5. جب قیادت مکمل دوبارہ تحریر مانگے تو آپ کا مستقل جواب کیا ہے، اور کیا آپ دکھا سکتے ہیں کہ بتدریج راستہ پہلے تین مہینوں میں کیا پہنچاتا ہے؟ بڑے دھماکے والی دوبارہ تحریر ڈیفالٹ ناکامی کا انداز ہے، پھر بھی اسے فنڈ ملتا رہتا ہے کیونکہ صاف تختہ بیچنا آسان ہے اور اسٹرینگلر فِگ نہیں۔ بڑی ٹیم کو مشق شدہ جواب چاہیے تاکہ دلیل شہادت سے جیتی جائے نہ کہ کمرے میں سب سے سینئر کی بات سے۔ حقیقی کھنچاؤ یہ ہے کہ کچھ پلیٹ فارمز واقعی ناقابل برداشت ہیں اور دوبارہ تحریر جائز ہے، اس لیے جواب مکمل انکار نہیں ہو سکتا: اسے تولنا چاہیے کہ بتدریج جوڑ ابھی موجود ہیں یا پرانا پلیٹ فارم زندہ رکھنے کی حقیقی لاگت۔ وہ قدر لائیں جو بتدریج پہلا اضافہ پہنچائے گا، قابل موازنہ دوبارہ تحریروں کی تاریخی ناکامی کی شرح، اور کسی بھی مجوزہ دوبارہ تحریر کی آزادانہ طور پر ترسیل کے قابل ٹکڑوں میں تقسیم۔ حکومت میں، جہاں منسوخ شدہ کئی سالہ پروگرام سب کی نظر کے سامنے عوامی پیسہ جلاتا ہے، اصرار کریں کہ کوئی بھی دوبارہ تحریر جلد قدر پہنچائے اور آدھے راستے میں روکے جانے پر کل نقصان کے بغیر بچ سکے۔

6. آپ اپنے قدیم ترین کوڈ میں بند کاروباری قواعد کو ان لوگوں کے جانے سے پہلے کیسے گرفت میں لیں گے جو انہیں سمجھتے ہیں؟ پرانے نظام کی بہت سی قدر غیر دستاویزی رویہ ہے جو دہائیوں کے کنارے کی صورتوں، ضابطوں، اور بگ سے مطابقت والی اصلاحات نے جمع کیا، اور یہ کسی تحریری ریکارڈ میں نہیں بلکہ ریٹائر ہوتے ماہرین کے سکڑتے گروہ میں رہتا ہے۔ بڑے ادارے کے لیے یہ وہ خطرہ ہے جو لوگوں کے جانے کے بعد خریدا نہیں جا سکتا، اس لیے یہ زیادہ نظر آنے والے پلیٹ فارم کے کام سے پہلے فنڈ کا مستحق ہے۔ متصادم کھنچاؤ یہ ہے کہ علم کی گرفت (دستاویزات، خصوصیات متعین کرنے والے ٹیسٹ، ریورس انجینئرنگ، کراس ٹریننگ) ایسا بوجھ لگتا ہے جو کچھ نہیں بھیجتا، اور اسی لیے ٹلتا ہے۔ فہرست لائیں کہ نازک علم کس کے پاس ہے، وہ جانے سے کتنے قریب ہیں، اور آج کون سی ٹیسٹ کوریج موجودہ رویہ پن کرتی ہے۔ ضابطے کے پابند اور عوامی ترتیبوں میں پرانے کوڈ میں انکوڈ قانونی قواعد کو تعمیل کا اثاثہ سمجھیں: انہیں خاموشی سے کھونا تکنیکی قرض نہیں، قانونی خطرہ ہے۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ آپ کا legacy آپ کا اپنا عجلت میں بنایا MVP ہے، مین فریم نہیں: ایسا پروٹوٹائپ جو اب آمدنی لے جاتا ہے اور جسے چھونے سے ہر کوئی ڈرتا ہے۔ اسے دوبارہ نہ لکھیں۔ سب سے ڈراؤنے ماڈیول کو صاف انٹرفیس کے پیچھے لپیٹیں، اس کا رویہ پن کرنے کے لیے خصوصیات متعین کرنے والے ٹیسٹ جوڑیں، اور فعلیت بتدریج نکالیں تاکہ ہر چھوٹی ریلیز قدر پہنچائے اور خطرہ گھٹائے۔ آپ کے پاس شروع سے دوبارہ بنانے کا رن وے نہیں، اس لیے اختیارات کی اہمیت خوبصورتی سے زیادہ ہے۔

چھوٹا کاروبار۔ آپ کے پاس جدید کاری کی ٹیم نہیں اور بجٹ تنگ ہے، اس لیے عملی قدم عموماً کام کرتے نظام کو کام کرتا رکھنا ہے: اس ایک شخص کا علم گرفت میں لیں جو اسے سمجھتا ہے، اسے چند خودکار ٹیسٹوں کے ساتھ سورس کنٹرول میں لائیں، اور حسب ضرورت دوبارہ بنانے کی بجائے فروخت کنندہ یا پیکیج شدہ پروڈکٹ پر انحصار کریں۔ فیصلے کو خریدنے بمقابلہ بنانے کے طور پر پیش کریں، اور جب صلاحیت عام شے ہو تو خریدنے کو ترجیح دیں۔ اپنی محدود کوشش اس ایک نظام پر لگائیں جس کی ناکامی کاروبار روک دے، اس پر نہیں جو محض سب سے پرانا لگتا ہو۔

بڑا ادارہ۔ مسئلہ پورٹ فولیو کا پیمانہ ہے: درجنوں نظام، بہت سی ٹیمیں، اور پوری جائیداد میں علم کا خطرہ۔ مشترک خطرے بمقابلہ قدر کا جائزہ چلائیں، بتدریج نمونوں (اسٹرینگلر فِگ اور تجرید کے ذریعے شاخ) پر معیاری بنائیں، اور ڈیٹا کی منتقلی اور دوہری چلت کو اولین درجے کے نظم و ضبط سمجھیں جن کی مصالحت پر سب بھروسہ کریں۔ جدید کاری کو بہادرانہ منصوبوں کے بکھراؤ کی بجائے خطرے کی سمت کے مقابل مسلسل پورٹ فولیو کے طور پر منظم کریں، اور نگہبانی اور علم کی گرفت کا بجٹ واضح طور پر رکھیں تاکہ کوئی نازک نظام ایک ریٹائر ہوتے نگہبان پر منحصر نہ ہو۔

حکومت۔ دہائیوں میں انکوڈ قانونی ذمہ داریاں، خریداری کے قواعد، اور شہری خدمات جن میں رکاوٹ نہیں آ سکتی بڑے دھماکے والی تبدیلی کو خاص طور پر خطرناک بناتی ہیں۔ ٹکڑے بہ ٹکڑے کٹ اوور کے ساتھ بتدریج اسٹرینگلر فِگ کی منتقلی کو ترجیح دیں، مصالحت اور لمبی متوازی چلت سے ثابت کریں کہ ایک بھی شہری کا ریکارڈ نہ کھویا نہ غلط حساب ہوا، اور پورے وقت واپسی دستیاب رکھیں۔ خریداری کو مبہم ترجمے کی بجائے ڈیٹا کی منتقلی کی اہلیت اور کاروباری قواعد کے افشا کا تقاضا کرنا چاہیے، اور کوئی بھی کئی سالہ پروگرام جلد قابل آڈٹ قدر پہنچائے اور آدھے راستے میں رکنے پر عوامی جانچ پڑتال سے بچ سکے۔

مثالیں

اسٹارٹ اپ۔ تین سال پرانے اسٹارٹ اپ کا اصل MVP اپنی طرح کا legacy بن گیا ہے: عجلت میں بنایا پروٹوٹائپ جو اب حقیقی آمدنی سنبھالتا ہے اور جسے چھونے سے ہر کوئی ڈرتا ہے۔ دوبارہ تحریر کی بجائے ٹیم بدترین ماڈیول کو صاف انٹرفیس کے پیچھے لپیٹتی ہے، اس کا موجودہ رویہ پن کرنے کے لیے خصوصیات متعین کرنے والے ٹیسٹ جوڑتی ہے، اور کئی مہینوں میں فعلیت اس میں سے ٹکڑا ٹکڑا نکالتی ہے۔ ہر چھوٹی ریلیز قدر پہنچاتی اور ڈراؤنا حصہ گھٹاتی ہے، اس لیے اسٹارٹ اپ کو قابل دیکھ بھال نظام ملتا ہے بغیر کمپنی کو اس دوبارہ تعمیر پر داؤ پر لگائے جو وہ برداشت نہیں کر سکتی۔

بڑا ادارہ۔ ایک بڑا بیمہ کار مین فریم COBOL نظام پر پالیسی کا انتظام چلاتا ہے جو قابل اعتماد مگر بدلنے میں مہنگا ہے اور ریٹائرمنٹ کے قریب مٹھی بھر انجینئر اسے برقرار رکھتے ہیں۔ دوبارہ تحریر کی بجائے بیمہ کار مین فریم کو جدید APIs سے لپیٹتا اور اسٹرینگلر فِگ لاگو کرتا ہے: نئی quote-and-buy اور خود خدمتی کی صلاحیتیں جدید پلیٹ فارم پر بنتی اور سامنے کے حصے سے روٹ ہوتی ہیں، جبکہ بنیادی پالیسی کے ریکارڈ مین فریم پر رہتے ہیں۔ متوازی طور پر ٹیم کاروباری قواعد دستاویزی کرتی اور COBOL کے گرد خصوصیات متعین کرنے والے ٹیسٹ جوڑتی ہے۔ کئی سالوں میں صلاحیت در صلاحیت مین فریم سے ہٹتی ہے، ہر ریلیز قدر پہنچاتی ہے، یہاں تک کہ باقی مرکز بحران کے بجائے بیمہ کار کی شرائط پر ریٹائر ہو سکتا ہے۔

حکومت۔ سماجی تحفظ کی ایجنسی کو دہائیوں پرانے فوائد کے حساب کے نظام کو جدید کرنا ہے جو لاکھوں شہریوں کو ادائیگی کرتا ہے اور جس میں رکاوٹ یا غلط ادائیگی نہیں ہو سکتی۔ قابل موازنہ ناکام پروگراموں کا مطالعہ کرنے کے بعد وہ بڑے دھماکے والی تبدیلی مسترد کرتی ہے۔ اس کی بجائے وہ ڈیٹا کو پروفائل اور صاف کرتی ہے، کنٹرول کے مجموعوں کے مقابل مکمل مصالحت کے ساتھ خودکار منتقلی بناتی ہے، اور نئے فوائد کے انجن کو پرانے کے ساتھ کئی مہینے متوازی چلاتی ہے، دونوں کو ایک ہی دعوے کھلاتے ہوئے اور ہر حساب کا موازنہ کرتے ہوئے، ہر تضاد کی تحقیق کرتی ہے (اکثر غیر دستاویزی پرانے قواعد دریافت کرتے ہوئے جنہیں محفوظ رکھنا ہے)۔ صرف جب نیا نظام پرانے سے بہت اونچے اعتماد تک میل کھائے وہ فائدے کی قسم بہ قسم کٹ اوور کرتی ہے، پورے وقت واپسی برقرار رکھتے ہوئے۔ اسٹرینگلر کا سامنے کا حصہ شہریوں کو منتقلی کے پار ایک مسلسل سروس دیکھنے دیتا ہے۔

کاروباری جواز: محرکات، ROI اور TCO

پرانے نظاموں کی جدید کاری کا غیر معمولی کاروباری جواز ہے، کیونکہ سب سے بڑی لاگت اکثر عدم عمل کی لاگت ہے اور سب سے بڑا خطرہ خود جدید کاری کا منصوبہ ہے۔ جدید نہ کرنے کی بڑھتی لاگتیں ٹھوس ہیں: متروک پلیٹ فارمز پر بڑھتی دیکھ بھال اور لائسنسنگ، تیزی سے کم یاب اور مہنگی ہوتی ماہر افرادی قوت، نئے ضابطے یا خدمت کے تقاضے جلد پورے کرنے کی نااہلی، اور ایسی تباہ کن ناکامی کی بڑھتی نمائش جس میں نظام کو سمجھنے والا کوئی باقی نہ رہے۔ اس کے مقابل جدید کاری کی لاگت زیادہ ہے، اور بڑے دھماکے کے طور پر ہو تو ناکامی کا واقعی اونچا امکان رکھتی ہے۔ اسی لیے بتدریج طریقہ ROI کے لیے اہم ہے: یہ ایک بڑے داؤ کو چھوٹے داؤ کے سلسلے میں بدلتا ہے جو ہر ایک قدر لوٹاتا ہے اور روکا جا سکتا ہے۔

قیادت کے سامنے دلیل انتخاب کو نئے سرے سے بیان کر کے رکھیں۔ سوال “جدید کریں یا نہیں” نہیں ہے۔ یہ ہے “اب بتدریج جدید کریں، یا بڑھتی نگہبانی کی لاگتیں ادا کریں اور بحران میں بعد کی مجبور، زیادہ خطرناک جدید کاری کا سامنا کریں۔” جوں کی توں حالت کی TCO کی مقدار بتائیں (پلیٹ فارم اور لائسنس کی لاگتیں، کم یاب مہارتوں کا پریمیم، ناقابل بحالی بندش کی خطرے سے وزنی لاگت) اور اس کا موازنہ مرحلہ وار پروگرام سے کریں جو سروس چلاتے ہوئے ہر اضافے کے ساتھ خطرہ اور لاگت گھٹاتا ہے۔ فیصلہ کن طور پر اصرار کریں کہ کوئی بھی مجوزہ دوبارہ تحریر قدر جلد اور بار بار پہنچانے کے لیے ترتیب دی جائے۔ ایسا پروگرام جو تین سال کچھ نہ پہنچائے اور کل نقصان کے ساتھ منسوخ ہو سکے سرمایہ کاری نہیں؛ جوا ہے۔ اسٹرینگلر طریقے کے لیے ROI کی سب سے مضبوط دلیل اختیارات ہے: قدر مسلسل پہنچتی ہے اور ادارہ کسی بھی نقطے پر سمت بدل سکتا ہے۔

ضد نمونے اور خامیاں

• بڑے دھماکے والی دوبارہ تحریر۔ کئی سالہ، سب یا کچھ نہیں تبدیلی جو آخر تک کوئی قدر نہیں پہنچاتی اور بڑی لاگت پر اکثر منسوخ ہوتی ہے۔
• سمجھے بغیر دوبارہ تحریر۔ ایسا کوڈ بدلنا جس کے کاروباری قواعد کبھی دستاویزی نہ ہوئے، حقیقی صارفین اور قوانین کے انحصار والی کنارے کی صورتیں خاموشی سے گرانا۔
• ڈیٹا کا کم اندازہ۔ ڈیٹا کی منتقلی کو بعد کا خیال سمجھنا جب وہ منصوبے کا مشکل ترین، خطرناک ترین حصہ ہے۔
• دوہری چلت چھوڑنا۔ متوازی موازنے کے بغیر نئے نظام پر کٹ اوور، تضادات تب دریافت کرنا جب وہ حقیقی لوگوں کو متاثر کر چکے ہوں۔
• خودکار ترجمہ بطور حل۔ COBOL کو جدید زبان میں مشینی ترجمہ کرنا اور سمجھنا کہ کام ہو گیا، ناقابل فہم کوڈ پیدا کرنا جو پرانی منطق لفظ بہ لفظ دہراتا ہے۔
• عمر کے لحاظ سے جدید کاری، خطرے کے نہیں۔ پرانے مگر مستحکم نظاموں پر محنت لگانا جبکہ اعلیٰ خطرے، اعلیٰ تبدیلی کے نظام انتظار کرتے ہیں۔
• علم کھونا۔ آخری نگہبانوں کو کاروباری قواعد گرفت میں لیے اور خصوصیات متعین کرنے والے ٹیسٹ جوڑے بغیر ریٹائر ہونے دینا۔
• واپسی نہیں۔ ایسا کٹ اوور جس میں نیا نظام حقیقی بوجھ اور حقیقی ڈیٹا کے تحت غلط برتاؤ کرے تو پیچھے جانے کا راستہ نہ ہو۔

پختگی کا ماڈل

• سطح 1: آغاز۔ پرانے نظاموں سے ڈرا اور انہیں منجمد کیا جاتا ہے؛ تبدیلی سے بچا جاتا ہے۔ نہ فہرست ہے نہ خطرے کا جائزہ۔ جدید کاری، اگر کوشش ہو بھی، مایوسی سے چلنے والی فی البدیہہ سب یا کچھ نہیں دوبارہ تحریر ہے۔ علم چند ریٹائر ہوتے ذہنوں میں ہے اور کچھ لکھا نہیں۔
• سطح 2: ترقی۔ کچھ ٹیموں کے پاس فہرست اور خطرے کا موٹا اندازہ ہے، اور چند پرانے نظام رسائی کے لیے APIs سے لپیٹے گئے ہیں۔ بتدریج نمونے معلوم ہیں مگر ناہموار لاگو ہوتے ہیں، اور سوچ اب بھی بڑے دھماکے والی دوبارہ تحریر کی طرف بھٹکتی ہے۔ ڈیٹا کی منتقلی کی کوشش ہوتی ہے مگر کم اندازہ لگایا جاتا ہے، اور عمل ٹیم سے ٹیم بہت مختلف ہے۔
• سطح 3: معیار بندی۔ نظام دستاویزی، ادارے بھر کے طریقے کے مطابق خطرے اور قدر سے ترجیحی ہیں۔ بتدریج نمونے (اسٹرینگلر فِگ، تجرید کے ذریعے شاخ) نافذ ڈیفالٹ ہیں، اور ہر جدید کاری معیاری پلے بک پر چلتی ہے۔ ڈیٹا کی منتقلی کٹ اوور سے پہلے دوہری چلت کے ساتھ منصوبہ بند، مصالحت شدہ کوشش ہے، اور علم کی گرفت اور خصوصیات متعین کرنے والے ٹیسٹ اختیاری کی بجائے لازمی عمل ہیں۔
• سطح 4: انتظام۔ جدید کاری ڈیٹا سے ناپی اور کنٹرول کی جاتی ہے۔ جائیداد بنیادی خطوط رکھتی ہے: فی نظام نگہبانوں کی تعداد اور ریٹائرمنٹ کا افق، خصوصیات متعین کرنے والے ٹیسٹ کی کوریج، منتقلی کی مصالحت کی کامیابی کی شرحیں، دوہری چلت کے تضادات کی گنتی، اور فی اضافہ پہنچائی گئی قدر، سب اہداف کے مقابل ٹریک ہوتے ہیں۔ نگہبانی-یا-تبدیلی کے فیصلے اور کٹ اوور کے آگے بڑھنے یا نہ بڑھنے کے فیصلے اس شہادت پر ہوتے ہیں، اور علم کے خطرے کی حد سے آگے بڑھتا نظام بحران کا انتظار کرنے کے بجائے عمل چلاتا ہے۔
• سطح 5: ہم آہنگی۔ جدید کاری مسلسل، کاروباری اور خطرے کی منصوبہ بندی سے مربوط، اور موافق ہے۔ پورٹ فولیو خطرے کی سمت (خاص طور پر علم کے خطرے) بدلنے کے ساتھ دوبارہ متوازن ہوتا ہے، بتدریج تبدیلی معمول اور کم ڈرامے والی ہے، ہر اضافہ قدر پہنچاتا اور قابل واپسی ہے، اور ادارہ رفتار جان بوجھ کر چلاتا ہے۔ ہر منتقلی کے اسباق مشترک پلے بک میں واپس جاتے ہیں تاکہ پوری جائیداد وقت کے ساتھ بہتر ہو۔

بحث کے لیے خیالات

1. اپنے سب سے نازک پرانے نظام کے لیے، کتنے لوگ اسے اب بھی برقرار رکھ سکتے ہیں، اور وہ جانے سے کتنے قریب ہیں؟
2. آپ کہاں بڑے دھماکے والی دوبارہ تحریر کی طرف مائل ہیں، اور بتدریج طریقہ پہلے تین مہینوں میں اس کی بجائے کون سی قدر پہنچا سکتا ہے؟
3. آپ کے قدیم ترین نظاموں کے کاروباری قواعد کتنی اچھی طرح دستاویزی ہیں، اور کوڈ بدلنے پر ان کے ساتھ کیا ہوتا ہے؟
4. کیا آپ نے اس ڈیٹا کو پروفائل کیا ہے جسے آپ کو منتقل کرنا ہوگا، اور کیا آپ جانتے ہیں کہ وہ واقعی کتنا گندا اور الجھا ہوا ہے؟
5. آپ جدید کاری کی توانائی کن پرانے مگر مستحکم نظاموں پر لگا رہے ہیں جنہیں محفوظ طریقے سے چھوڑا جا سکتا ہے؟
6. کیا آپ اپنا نیا نظام پرانے کے ساتھ متوازی چلا کر ثابت کر سکتے ہیں کہ کٹ اوور سے پہلے وہ متفق ہیں؟

اہم نکات

• Legacy کا مطلب قیمتی اور بنیادی ہے؛ بدلنے سے پہلے نظام کا احترام کریں اور اسے سمجھیں۔
• اسٹرینگلر فِگ اور تجرید کے ذریعے شاخ سے بتدریج جدید کاری کریں، مسلسل قدر پہنچاتے ہوئے اور ہر تبدیلی کو چھوٹا اور قابل واپسی رکھتے ہوئے۔
• بڑے دھماکے والی دوبارہ تحریر کو ڈیفالٹ ناکامی کا انداز سمجھیں؛ اسے واقعی ناقابل برداشت پلیٹ فارمز کے لیے رکھیں اور تب بھی تقسیم کریں۔
• عمر کی بجائے خطرے اور قدر (خاص طور پر علم کے خطرے) سے ترجیح دیں؛ کچھ پرانے نظام بدلنے کی بجائے نگہبانی کے قابل ہیں۔
• ڈیٹا کی منتقلی اور دوہری چلت کوشش کا دل ہیں؛ پروفائل کریں، مصالحت کریں، متوازی چلائیں، اور واپسی رکھیں۔
• سب سے مضبوط کاروباری جواز اختیارات ہیں: بتدریج جدید کاری ایک بڑے، خطرناک داؤ کو بہت سے چھوٹے، قدر لوٹانے والے داؤ میں بدلتی ہے۔

حوالہ جات اور مزید مطالعہ

• Michael Feathers, Working Effectively with Legacy Code
• Martin Fowler, “StranglerFigApplication” and “BranchByAbstraction”
• Sam Newman, Monolith to Microservices
• Nicholas Carr / industry studies on mainframe and COBOL dependency (context on the scale of legacy estates)
• Robert Annett, Working with Legacy Systems
• Eric Evans, Domain-Driven Design (anti-corruption layer)
• Gregor Hohpe, Enterprise Integration Patterns and The Software Architect Elevator
• Standish Group CHAOS Report (evidence on large project and rewrite failure rates)