যে দশটা ঝুঁকি পুরোনো বিজনেস সিস্টেমকে বিপজ্জনক করে তোলে, সেগুলোর কারণে প্রতিদিনের ঝামেলা, সম্ভাবনা আর প্রভাব মিলিয়ে একটা সহজ হিট ম্যাপ, আর strangler fig প্যাটার্নে একটা একটা করে কাজ সরিয়ে লিগ্যাসি সিস্টেম বদলানোর পদ্ধতি।
Author
Anichur Rahaman
পুরোনো সফটওয়্যার সাধারণত হুট করে ভেঙে পড়ে না, ধীরে ধীরে অকেজো হয়। একটা রিপোর্ট প্রতি মাসে আগের চেয়ে একটু বেশি সময় নেয়। নতুন একটা পেমেন্ট মেথড যোগ করতে বলা হয় "কয়েক সপ্তাহ লাগবে"। স্টক মডিউলটা বোঝেন এমন একমাত্র ডেভেলপার ছুটিতে গেলে পুরো টিম তাঁর ফেরার অপেক্ষায় বসে থাকে।
সমস্যার নাম কেউ বলার অনেক আগেই মালিকেরা এই লক্ষণগুলো টের পান। পুরোনো কোনো বিজনেস সিস্টেম রিভিউ করার সময় একজন আর্কিটেক্ট হিসেবে আমার কাজ হলো সেই অস্পষ্ট অস্বস্তিকে নির্দিষ্ট ঝুঁকির একটা তালিকায় রূপ দেওয়া, প্রতিটার স্কোর করা, আর ব্যবসা না থামিয়ে বেরিয়ে আসার একটা পথ দেখানো। এই লেখায় সেই পদ্ধতিটাই শেয়ার করছি।
এখানে পাবেন যাচাই করার মতো দশটা ঝুঁকি, প্রতিটার কারণে প্রতিদিন কী ভোগান্তি হয়, ঝুঁকি মাপার একটা সহজ heat map, আর আধুনিক করার একটা কৌশল — strangler fig প্যাটার্ন — যেখানে পুরো সিস্টেম নতুন করে লেখার জুয়া না খেলে পুরোনো সিস্টেমের একেকটা অংশ ধাপে ধাপে বদলে ফেলা হয়।
লিগ্যাসি মানে পুরোনো নয়। পাঁচ বছরের একটা সিস্টেমও আধুনিক হতে পারে, যদি তাতে টেস্ট থাকে, ডকুমেন্টেশন থাকে, আর সেটা সাপোর্ট পাওয়া সফটওয়্যারের ওপর চলে। আবার দুই বছরের সিস্টেমও লিগ্যাসি হতে পারে, যদি কেউ সেটায় হাত দেওয়ার সাহস না পায়। কাজের একটা সংজ্ঞা:
লিগ্যাসি সফটওয়্যার হলো এমন যেকোনো সিস্টেম, যার ওপর ব্যবসা নির্ভর করে, অথচ যেটা নিরাপদে, দ্রুত বা সাশ্রয়ে বদলানো যায় না।
তাই প্রশ্নটা "সিস্টেমটা কত পুরোনো?" নয়। প্রশ্ন হলো, "এটা বদলানো কতটা ঝুঁকির, আর না বদলে রেখে দেওয়া কতটা ঝুঁকির?" দুটোরই একটা দাম আছে।
প্রোগ্রামিং ভাষার ভার্সন বা framework-এর মেয়াদ শেষ হলে সিকিউরিটি আপডেট আসা বন্ধ হয়ে যায়। এরপর প্রতি মাসে জানা দুর্বলতা আর আপনার সুরক্ষার মধ্যে ফাঁক বাড়তে থাকে। পরে আপগ্রেড করাও কঠিন হয়ে পড়ে, কারণ লাইব্রেরিগুলো এগিয়ে যায় আর আপনার ভার্সনকে আর সমর্থন করে না।
রোজকার ভোগান্তি: "ওই পেমেন্ট গেটওয়ে যোগ করা যাবে না, ওটার লাইব্রেরির জন্য নতুন PHP লাগবে।"
সিস্টেমটা কীভাবে চলে, সেটা জানেন শুধু একজন ডেভেলপার বা একজন কন্ট্রাক্টর। কোথাও কিছু লেখা নেই, তিনি চলে গেলে জ্ঞানও তাঁর সঙ্গে চলে যায়। প্রভাবের দিক থেকে এটা প্রায়ই সবচেয়ে বড় ঝুঁকি — অথচ মালিকেরা এটা খেয়াল করেন সবার শেষে।
রোজকার ভোগান্তি: রিলিজ, বাগ ফিক্স, এমনকি সামান্য ডেটা ঠিক করাও একজন মানুষের সময়ের অপেক্ষায় পড়ে থাকে।
টেস্ট না থাকলে প্রতিটা পরিবর্তনই জুয়া, তাই টিম যতটা সম্ভব কম বদলায়। সমস্যার গোড়ায় না গিয়ে চারপাশে জোড়াতালি দেওয়া হয়, আর বছর বছর কোড বদলানো আরও কঠিন হয়ে ওঠে।
রোজকার ভোগান্তি: "ইনভয়েসের রাউন্ডিং ঠিক করলাম, এখন ডিসকাউন্টের রিপোর্ট ভুল দেখাচ্ছে।"
শত শত টেবিল, যেগুলো অ্যাপের প্রতিটা অংশ পড়ে আর লেখে — কখনো বাইরের স্ক্রিপ্টও। একটা কলাম বদলালে এমন কোনো স্ক্রিন ভেঙে যেতে পারে, যেটার অস্তিত্বই কারও মনে নেই।
রোজকার ভোগান্তি: সাধারণ একটা ফিল্ড বদলাতে গিয়ে এক সপ্তাহ চলে যায় কোথায় কী প্রভাব পড়বে সেটা খুঁজতে।
পুরোনো পদ্ধতিতে রাখা পাসওয়ার্ড, কোডের ভেতরে লেখা API key, টু-ফ্যাক্টর ছাড়া অ্যাডমিন প্যানেল, এরর পেজে ডাটাবেসের তথ্য ফাঁস, লগইনে বারবার চেষ্টার কোনো সীমা নেই। আলাদাভাবে প্রতিটা ছোট মনে হয়, কিন্তু সব মিলিয়ে এটা একটা খোলা দরজা।
রোজকার ভোগান্তি: বড় কোনো ক্লায়েন্ট সিকিউরিটির প্রশ্নপত্র পাঠালে কেউ সেটার উত্তর দিতে চায় না।
গ্রাহকের তথ্য শপে, CRM-এ আর একটা স্প্রেডশিটে; স্টকের হিসাব সিস্টেমে আর গুদাম ম্যানেজারের খাতায়। সংখ্যাগুলো না মিললে মানুষ শেষমেশ কোনোটাকেই আর বিশ্বাস করে না।
রোজকার ভোগান্তি: কোন রিপোর্ট সঠিক, সেই তর্কেই মিটিংয়ের সময় শেষ।
রাতে FTP দিয়ে CSV ফাইল পাঠানো, সাপ্লায়ারের ওয়েবসাইট থেকে তথ্য তুলে আনার স্ক্রিপ্ট, পাসওয়ার্ডের মেয়াদ ফুরালে নিঃশব্দে থেমে যাওয়া ইন্টিগ্রেশন। যতদিন চলে চলে — তারপর থেমে গেলে কয়েক দিন কেউ টেরই পায় না।
রোজকার ভোগান্তি: "মঙ্গলবারের পর থেকে কুরিয়ারের স্ট্যাটাস আর আপডেট হয়নি।"
লুপের ভেতরে একটা একটা করে রেকর্ড টেনে আনা কোয়েরি, কোনো cache নেই, পুরো টেবিল ঘেঁটে বানানো রিপোর্ট। হাজার অর্ডারে সব ঠিক, দশ লাখে গিয়ে যন্ত্রণা।
রোজকার ভোগান্তি: মাস শেষের রিপোর্ট সারারাত চলে, আর সে সময় স্টোরও ধীর হয়ে যায়।
কে দাম, বেতন বা স্টকের সংখ্যা বদলেছেন, তার কোনো রেকর্ড নেই। গ্রাহক চাইলে তাঁর ব্যক্তিগত ডেটা এক্সপোর্ট বা মুছে ফেলার উপায় নেই। সম্মতি নেওয়ার কোনো রেকর্ড রাখা হয় না। অনেক দেশের ডেটা সুরক্ষা আইনে এগুলো আইনি বাধ্যবাধকতা, ঐচ্ছিক সুবিধা নয়।
রোজকার ভোগান্তি: অডিটরের একটা প্রশ্নের উত্তর জোগাড় করতে এক সপ্তাহ লেগে যায়।
এমন একটা বন্ধ সিস্টেম, যেখানে আপনার ডেটা এক্সপোর্ট নিয়ন্ত্রণ করে ভেন্ডর, নবায়নের সময় দাম বাড়ায়, বা প্রোডাক্টটাই বন্ধ করে দেয়। কখনো কখনো চুক্তিটাই সবচেয়ে বড় ঝুঁকি।
রোজকার ভোগান্তি: "আমরা অন্য সিস্টেমে যেতে চাই, কিন্তু কাজে লাগানোর মতো অবস্থায় ডেটা বের করতে পারছি না।"
শুরু করতে কনসালট্যান্টের দরকার নেই। যাঁরা সিস্টেমটা ব্যবহার করেন আর রক্ষণাবেক্ষণ করেন, তাঁদের নিয়ে বসুন। প্রতিটা ঝুঁকিকে দুটো মাপকাঠিতে ১ থেকে ৫ নম্বর দিন:
দুটো নম্বর গুণ করুন। ১৫ বা তার বেশি পেলে সেটা এই কোয়ার্টারেই সমাধান করতে হবে। ৮ থেকে ১৪ রোডম্যাপে রাখুন। ৮-এর নিচে হলে নজরে রাখুন। ওপরের heat map এই টেবিলেরই ছবি — আর আধুনিকীকরণের বাজেট পেতে বোর্ডকে রাজি করানোর জন্য আমার জানা সবচেয়ে কার্যকর স্লাইড এটাই।
| ঝুঁকি | সম্ভাবনা (১–৫) | প্রভাব (১–৫) | স্কোর | করণীয় |
|---|---|---|---|---|
| সাপোর্টহীন runtime | ৫ | ৫ | ২৫ | এই কোয়ার্টারে |
| একজন মানুষের ওপর নির্ভরতা | ৪ | ৫ | ২০ | এই কোয়ার্টারে |
| নিরাপত্তার দেনা | ৪ | ৫ | ২০ | এই কোয়ার্টারে |
| অটোমেটেড টেস্ট নেই | ৪ | ৪ | ১৬ | এই কোয়ার্টারে |
| ভঙ্গুর ইন্টিগ্রেশন | ৩ | ৩ | ৯ | রোডম্যাপে |
| ভেন্ডরের ফাঁদ | ২ | ৪ | ৮ | রোডম্যাপে |
ওপরের স্কোরগুলো উদাহরণ, মানদণ্ড নয়। আপনার নিজের আলোচনায় অন্য স্কোর আসবে — আর সেই আলোচনাটাই অর্ধেক কাজ।
ঝুঁকিগুলো চোখের সামনে এলে সবচেয়ে লোভনীয় উত্তর হলো, "চলো, এবার ঠিকঠাক করে নতুন করে বানাই।" কিন্তু পুরো রিরাইট সফল হওয়ার চেয়ে ব্যর্থ হয় অনেক বেশি, আর কারণগুলো আগেই বলে দেওয়া যায়:
strangler fig (বটজাতীয় এক ধরনের লতানো গাছ) একটা গাছকে জড়িয়ে বেড়ে ওঠে, যতক্ষণ না নিজের পায়ে দাঁড়াতে পারে। সফটওয়্যারেও নতুন সিস্টেম পুরোনোটাকে ঘিরে বড় হয়, একেকবারে একেকটা কাজের দায়িত্ব নিয়ে নেয় — যতক্ষণ না পুরোনো কোর বন্ধ করে দেওয়া যায়।
পুরোনো সিস্টেমের সামনে একটা routing স্তর বসান — একটা API gateway বা হালকা একটা proxy। শুরুতে এটা ১০০% ট্রাফিক পুরোনো সিস্টেমেই পাঠায়। একই সময়ে:
এমন একটা অংশ বেছে নিন যেটা গুরুত্বপূর্ণ আর যার সীমানা পরিষ্কার: ক্যাটালগ ও স্টক, অথবা অর্ডার। নতুন মডিউল বানান বা প্রস্তুত মডিউল নিন, তারপর ওই কাজটা সেদিকে পাঠান।
শেষ অংশটাও সরে গেলে পুরোনো ডেটা শুধু-পড়া যায় এমন স্টোরেজে আর্কাইভ করুন, বাকি পুরোনো স্ক্রিনগুলো বন্ধ করুন, আর পুরোনো কোড মুছে ফেলুন। ডেটা রেখে দিন, ঝুঁকিটা বিদায় করুন।
পুরোনো সিস্টেমের সব অংশের সঙ্গে একই আচরণ করার দরকার নেই। প্রতিটা অংশের পথ ঠিক করে দেয় তিনটা প্রশ্ন:
কিছু শিক্ষা বই থেকে নয়, অভিজ্ঞতা থেকেই আসে:
StoreConsole তৈরি হয়েছে একগুচ্ছ স্বাধীন মডিউল দিয়ে — ক্যাটালগ, ইনভেন্টরি, অর্ডার, ডেলিভারি, অ্যাকাউন্টিং, HR, বেতন, CRM এবং আরও অনেক কিছু — যারা শুধু event-এর মাধ্যমে একে অপরের সঙ্গে কথা বলে। তাই "প্রতিস্থাপন" পথের জন্য এটা স্বাভাবিক পছন্দ: facade-এর আড়ালে একটা মডিউল বসান, পুরোনো সিস্টেমের outbox থেকে তাকে ডেটা দিন, আর প্রথমটা স্থির হলে পরেরটায় যান। প্রতিটা মডিউলে আছে অ্যাক্টিভিটি লগ, রোলভিত্তিক অনুমতি আর টু-ফ্যাক্টর সাইন-ইন — ফলে ওপরের কয়েকটা ঝুঁকি প্রথম দিনেই কমে যায়। নিচের ছোট ভিডিওতে রোল, টু-ফ্যাক্টর সাইন-ইন আর অডিট ট্রেইল দেখানো হয়েছে।
আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।
About the Author
Anichur Rahaman
Continue Reading
