সরকারি খাতের সফটওয়্যার প্রকৌশল ও প্ল্যাটফর্ম

কেন এটি জনমূল্যে গুরুত্বপূর্ণ

আজ একজন নাগরিক যে প্রায় প্রতিটি সরকারি সেবা স্পর্শ করেন — একটি জন্ম নিবন্ধন, একটি সুবিধার দাবি, একটি কর বিল পরিশোধ, একটি আদালতের তারিখ বুক করা — তা কাউন্টার বা পর্দার পেছনে কোথাও সফটওয়্যারে চলে। সেই সফটওয়্যার খুব কমই একবারের ক্রয়; এটি রাষ্ট্রের স্থায়ী অবকাঠামোর অংশ হয়ে ওঠে, প্রায়ই যে প্রশাসন এটি কমিশন করেছিল, যে সরবরাহকারী এটি গড়েছিল এবং যে প্রোগ্রামিং ভাষায় এর প্রকৌশলীরা প্রশিক্ষিত ছিলেন তাদের সবাইকে ছাড়িয়ে যায়। একটি সরকারি সংস্থা সফটওয়্যারকে সেভাবে অনুভব করে না যেভাবে একটি ভবন বা সড়ক অনুভব করে, যেখানে সম্পদের অবস্থা দৃশ্যমান; সফটওয়্যার অদৃশ্যভাবে ক্ষয় পায়, এবং সেই ক্ষয়ের বিল বছর পরে একটি জরুরি অবস্থা হিসেবে আসে।

এই বিষয়কে চালানো টানাপোড়েনটি কাঠামোগত। সফটওয়্যার সহজাতভাবে পুনরাবৃত্তিমূলক — ব্যবহারকারীরা একটি কার্যকর ব্যবস্থার সঙ্গে মিথস্ক্রিয়া করলে চাহিদা আরও পরিষ্কার হয়, এবং সেরা প্রকৌশল চর্চা হলো ছোট কিছু গড়া, শেখা এবং অভিযোজিত হওয়া। সরকারি ক্রয় ও জবাবদিহি চক্র (দেখুন বিষয় 3.7 — সরকারি ক্রয় ও কমিশনিং), বিপরীতে, মূলধন-কাজ ও প্রতিরক্ষা চুক্তির জন্য গড়া: একটি নির্দিষ্ট বিনির্দেশ, একটি একক বড় পুরস্কার, মাইলফলক পরিশোধ, এবং সরবরাহ শুরুর বছর আগে অনুমোদিত একটি ব্যবসায়িক যুক্তি। যখন একটি আইনসভা বা নিরীক্ষক একটি নির্দিষ্ট-মূল্য, নির্দিষ্ট-পরিধির চুক্তি প্রত্যাশা করে এবং একটি প্রকৌশল দলকে প্রথম প্রকাশের পরে গতিপথ বদলাতে হয়, অসামঞ্জস্যটি পরিধি-বৃদ্ধি, বাজেট-অতিক্রম, বা 2019 সালে সঠিকভাবে বিনির্দিষ্ট এবং এটি জাহাজে ওঠার সময় অপ্রচলিত একটি ব্যবস্থা হিসেবে দেখা দেয়।

এই বিষয়ের প্রকৌশল চর্চা যে প্ল্যাটফর্ম গড়তে বিদ্যমান — ভাগাভাগি করা পরিচয় ব্যবস্থা, পরিশোধ রেল, বিভাগ জুড়ে পুনর্ব্যবহৃত কেস-ব্যবস্থাপনা হাতিয়ার — সেগুলো আগের বিষয়ের আলোচ্য (দেখুন বিষয় 5.1 — ডিজিটাল সরকার ও ডিজিটাল রূপান্তর); এই বিষয় সেই সফটওয়্যার গড়া ও কেনার শৃঙ্খলা নিয়ে যা যেকোনো এমন প্ল্যাটফর্ম, বা যেকোনো একক সেবাকে নির্ভরযোগ্য, প্রতিস্থাপনযোগ্য এবং যে সরকারি সংস্থা এর ওপর নির্ভর করে তার মালিকানাধীন করে, যে সরবরাহকারী প্রথমে এটি লিখেছিল তার নয়।

মূল ধারণা

গড়া-বনাম-কেনার সিদ্ধান্ত হলো একটি প্রতিষ্ঠানের একটি প্রয়োজনের জন্য লেখা বিশেষভাবে নির্মিত সফটওয়্যার কমিশন করা এবং অনুরূপ ক্রেতাদের একটি বাজারের জন্য ইতিমধ্যে গড়া কনফিগারযোগ্য পণ্য সফটওয়্যার গ্রহণ করার মধ্যে পছন্দ। কেনা সাধারণত সস্তা এবং এমন প্রয়োজনের জন্য কম-ঝুঁকিপূর্ণ যা সত্যিই স্বতন্ত্র নয় — বেতন, ইমেইল, মানসম্মত কেস ব্যবস্থাপনা — যখন গড়া কেবল সেখানেই যথার্থ যেখানে প্রয়োজনীয়তা এতটা ভিন্ন যে কোনো কনফিগারযোগ্য পণ্য মেলে না, বা যেখানে সামর্থ্যটি নিজেই একটি কৌশলগত সম্পদ যা প্রতিষ্ঠানের নিজের মালিকানায় রাখা ও বিকশিত করা দরকার।

কারিগরি ঋণ একটি রূপক, সফটওয়্যার প্রকৌশলী ওয়ার্ড কানিংহ্যাম 1992 সালে চালু করেছিলেন, এখনই সফটওয়্যার জাহাজে তোলার একটি সুবিধাজনক উপায় এমন আরও পুঙ্খানুপুঙ্খ উপায়ের ওপর বেছে নেওয়ার সংগৃহীত ব্যয়ের জন্য যা বেশি সময় নিত। কারিগরি ঋণ, আর্থিক ঋণের মতো, নিতে সহজাতভাবে ভুল নয় — কানিংহ্যামের নিজস্ব বক্তব্য ছিল দ্রুত কার্যকর কোড জাহাজে তুলে পরে রিফ্যাক্টর করা সঠিক সিদ্ধান্ত হতে পারে — কিন্তু যে ঋণ কখনও পরিশোধ হয় না তা ধীরতর সরবরাহ, বেশি ত্রুটি এবং ক্রমবর্ধমান ঝুঁকি হিসেবে সুদ জমায়, এবং যে সরকারি সংস্থা তার ঋণ দেখতে পায় না সে সিদ্ধান্ত নিতে পারে না এটি পরিশোধ করবে নাকি চক্রবৃদ্ধি হতে দেবে।

একটি উত্তরাধিকার ব্যবস্থা (লিগ্যাসি সিস্টেম) হলো একটি পুরোনো প্রযুক্তি, অ্যাপ্লিকেশন বা প্ল্যাটফর্ম যা অপ্রচলিত হওয়া সত্ত্বেও সক্রিয় ব্যবহারে রয়ে গেছে, প্রায়ই কারণ এটি প্রতিস্থাপন ব্যয়বহুল বা সংস্থায় এখন কেউ এটি আসলে কী করে তা পুরোপুরি বোঝেন না। উত্তরাধিকার ব্যবস্থা সরকারে বিশেষভাবে স্থায়ী: দশক আগে COBOL — Common Business-Oriented Language, 1960 সালে প্রশাসনিক কম্পিউটিংয়ের জন্য নকশা করা — এর মতো ভাষায় লেখা মূল কর, সুবিধা এবং সামাজিক-বিমা ব্যবস্থা এখনও লক্ষ লক্ষ নাগরিকের জন্য লেনদেন প্রক্রিয়া করে, কারণ ব্যবস্থাগুলো কাজ করে এবং এগুলো নিরাপদে অবসর দিতে প্রয়োজনীয় প্রাতিষ্ঠানিক জ্ঞান প্রায়ই নিজেই আগে অবসর নিয়েছে।

সফটওয়্যার আধুনিকীকরণ হলো একটি উত্তরাধিকার ব্যবস্থাকে একটি বর্তমান স্থাপত্য, ভাষা বা প্ল্যাটফর্মে রূপান্তর, পুনর্লিখন বা স্থানান্তরের সাধারণ শব্দ। সফটওয়্যার আধুনিকীকরণ একটি পূর্ণ পুনর্লিখন থেকে আধুনিক অবকাঠামোতে একই কোড পুনঃহোস্টিংয়ের মতো আরও রক্ষণশীল বিকল্প পর্যন্ত একটি বর্ণালী বিস্তৃত করে, এবং তাদের মধ্যে পছন্দ কারিগরির মতোই একটি ঝুঁকি-ব্যবস্থাপনা সিদ্ধান্ত।

স্ট্র্যাংলার ফিগ প্যাটার্ন একটি ক্রমবর্ধমান আধুনিকীকরণ পদ্ধতি, একটি লতার নামে নামকরণ যা একটি আশ্রয়দাতা গাছের চারপাশে বেড়ে ধীরে ধীরে তা প্রতিস্থাপন করে, যেখানে নতুন কার্যকারিতা একটি উত্তরাধিকার ব্যবস্থার পাশাপাশি গড়া হয় এবং ট্র্যাফিক একটি একক কাটওভারে সমগ্র ব্যবস্থা প্রতিস্থাপনের বদলে টুকরো টুকরো করে এতে পুনর্নির্দেশিত হয়। স্ট্র্যাংলার ফিগ প্যাটার্ন গুরুত্বপূর্ণ কারণ এটি প্রতিটি বৃদ্ধিকে সমগ্র সেবা বন্ধ না করে পরীক্ষা, পূর্বাবস্থায় ফেরানো বা বিরতি দিতে দেয় — বিগ-ব্যাং প্রতিস্থাপনের বিপরীত, যেখানে পুরোনো ব্যবস্থা বন্ধ ও নতুনটি একটি মুহূর্তে চালু করা হয় কিছু ভুল হলে ফেরার কোনো উপায় ছাড়াই।

বিক্রেতা-আবদ্ধতা (ভেন্ডর লক-ইন) ঘটে যখন একজন গ্রাহক একটি সরবরাহকারীর মালিকানাধীন প্রযুক্তি, উপাত্ত ফরম্যাট বা চুক্তিগত শর্তের ওপর এতটা নির্ভরশীল হয়ে পড়ে যে অন্য সরবরাহকারীতে স্থানান্তর নিষিদ্ধ ব্যয় বা ঝুঁকি বহন করে। বিক্রেতা-আবদ্ধতা সরকারি-খাতের সফটওয়্যারে একটি বিশেষ বিপদ কারণ ক্রেতা একজন পুনরাবৃত্ত গ্রাহক যার একটি সংকটপূর্ণ সেবা চালানো ব্যবস্থা থেকে সরে আসার সীমিত ব্যবহারিক সামর্থ্য আছে, যা প্রতিটি পরবর্তী নবায়নে তার আলোচনার অবস্থান দুর্বল করে।

মুক্ত ও উন্মুক্ত-উৎস সফটওয়্যার হলো এমন লাইসেন্সের অধীনে বিতরিত সফটওয়্যার যা ব্যবহারকারীদের সোর্স কোড ব্যবহার, অধ্যয়ন, পরিবর্তন ও পুনর্বিতরণের স্বাধীনতা দেয়। মুক্ত ও উন্মুক্ত-উৎস সফটওয়্যার একটি উন্মুক্ত-উৎস-ডিফল্ট নীতির ভিত্তি, যার অধীনে একটি সরকারি সংস্থা যে সোর্স কোড কমিশন করে তা ডিফল্টভাবে প্রকাশ করে যতক্ষণ না একটি নির্দিষ্ট কারণ — নিরাপত্তা সংবেদনশীলতা, তৃতীয় পক্ষের অধিকার — এটি আটকে রাখা যথার্থ করে; যুক্তিটি সাধারণত সংক্ষেপে বলা হয় "জনগণের অর্থ, জনগণের কোড": জনঅর্থে একবার পরিশোধিত সফটওয়্যারের জন্য আবার, একটি ভিন্ন এখতিয়ারে, একই সমস্যা সমাধানকারী একটি ভিন্ন সরকারি সংস্থার দ্বারা অর্থ দিতে হওয়া উচিত নয়।

একটি ডিজিটাল জনপণ্য হলো উন্মুক্ত লাইসেন্সের অধীনে প্রকাশিত উন্মুক্ত সফটওয়্যার, উপাত্ত বা বিষয়বস্তু, একটি বাণিজ্যিক প্রতিদান তৈরির বদলে একটি জন উন্নয়ন বা শাসন উদ্দেশ্য পূরণে সাহায্য করতে নকশা করা। ডিজিটাল জনপণ্য একটি সরকারের উন্মুক্ত-উৎস প্রকাশকে একটি বৃহত্তর, ভাগাভাগি করা অবকাঠামোর অংশ হিসেবে পুনঃকাঠামো করে যা অন্যান্য সরকার ও নাগরিক-সমাজ সংগঠন সরাসরি আঁকতে পারে, কেবল একটি অভ্যন্তরীণ স্বচ্ছতা ইঙ্গিত নয়।

চটপটে সফটওয়্যার উন্নয়ন (এজাইল) হলো সফটওয়্যার গড়ার পুনরাবৃত্তিমূলক পদ্ধতির একটি সমষ্টিগত শব্দ যা আগে সম্মত একটি নির্দিষ্ট পরিকল্পনা অনুসরণের চেয়ে কার্যকর সফটওয়্যার, ঘন ঘন সরবরাহ এবং পরিবর্তনে সাড়া দেওয়াকে অগ্রাধিকার দেয়। চটপটে সফটওয়্যার উন্নয়ন ওয়াটারফল মডেল-এর বিপরীতে দাঁড়ায়, একটি ক্রমিক পদ্ধতি যেখানে চাহিদা, নকশা, নির্মাণ ও পরীক্ষা প্রতিটি পরেরটি শুরুর আগে সম্পূর্ণ শেষ হয়; সরকারি সংস্থার কাছে ওয়াটারফলের আবেদন সবসময় ছিল যে এর মাইলফলক একটি নির্দিষ্ট-মূল্য চুক্তি ও একটি বার্ষিক বাজেট চক্রের সঙ্গে পরিষ্কারভাবে মেলে, যে কারণে এত ক্রয় আইন এখনও এটি ধরে নেয়, এমনকি যেখানে সরবরাহ সত্যিই চটপটে।

একটি ন্যূনতম কার্যকর পণ্য (MVP) হলো একটি সেবার ক্ষুদ্রতম সংস্করণ যা এটি কাজ করে কি না পরীক্ষা করতে এবং পরবর্তীতে কী গড়তে হবে শিখতে বাস্তব ব্যবহারকারীদের কাছে প্রকাশ করা যায়। ন্যূনতম কার্যকর পণ্য ধারণা, সরকারি-খাতের ডিজিটাল-সেবা প্লেবুকে অভিযোজিত, একটি পুনরাবৃত্তিমূলক দলকে পূর্ণ পরিধি সম্পূর্ণ হওয়ার অনেক আগে একজন অর্থদাতা বা নিরীক্ষকের কাছে প্রকৃত ও কার্যকর কিছু দেখানোর একটি প্রতিরক্ষাযোগ্য উপায় দেয় — শর্ত হলো জবাবদিহি প্রক্রিয়া একটি প্রকৃতপক্ষে ন্যূনতম প্রকাশ গ্রহণ করে, এটিকে ভিন্ন নামে সম্পূর্ণ পণ্য হিসেবে না দেখে।

সেরা অনুশীলন

1. অস্বতন্ত্র প্রয়োজনের জন্য কেনায় ডিফল্ট করুন, এবং প্রকৃতপক্ষে স্বতন্ত্রগুলোর জন্য গড়া সংরক্ষণ করুন। বেতন, ইমেইল এবং সাধারণ কেস-ব্যবস্থাপনা প্রয়োজন খুব কমই যেকোনো অন্য প্রতিষ্ঠানের থেকে বিশেষভাবে নির্মিত সফটওয়্যার যথার্থ করার মতো যথেষ্ট ভিন্ন; কেবল সেখানেই গড়ুন যেখানে প্রয়োজনীয়তা, মাপ, বা কয়েক দশক ধরে সামর্থ্য নিজের মালিকানায় রাখা ও বিকশিত করার প্রয়োজন বাজারের দেওয়া থেকে সত্যিই ভিন্ন।
2. কতটা বহন করবেন তা স্থির করার আগে কারিগরি ঋণ দৃশ্যমান করুন। সেবায় থাকা প্রতিটি ব্যবস্থার জন্য পরিচিত শর্টকাট, স্থগিত সংশোধন এবং অসমর্থিত নির্ভরতার একটি নিবন্ধন রক্ষণাবেক্ষণ করুন, একটি নির্দিষ্ট চক্রে পর্যালোচিত, যাতে আরেক বছর ঋণ বহন করা কেউ না তাকানোর বদলে একটি সুচিন্তিত বিনিময় হয়।
3. একটি সংকটপূর্ণ উত্তরাধিকার ব্যবস্থা থেকে বেরোনোর একমাত্র পথ হিসেবে একটি একক, অপ্রত্যাবর্তনযোগ্য কাটওভার কখনও পরিকল্পনা করবেন না। স্ট্র্যাংলার ফিগ প্যাটার্নের মতো ক্রমবর্ধমান পদ্ধতি পছন্দ করুন যা প্রতিটি অংশ পরীক্ষা, পূর্বাবস্থায় ফেরানো এবং ধীরে ধীরে প্রকাশ করতে দেয়; লক্ষ লক্ষ মানুষ যার ওপর নির্ভর করে এমন একটি ব্যবস্থার বিগ-ব্যাং প্রতিস্থাপন কিছু ব্যর্থ হলে ফেরার কোনো উপায় ছাড়াই বছরের ঝুঁকি একটি একক সপ্তাহান্তে কেন্দ্রীভূত করে।
4. আপনার প্রতিষ্ঠান যে সোর্স কোড লেখাতে অর্থ দেয় তা একটি ভাড়া-নেওয়া সেবা নয়, মালিকানাধীন সম্পদ হিসেবে দেখুন। চুক্তির সময়ই সোর্স-কোড এসক্রো বা সরাসরি মালিকানা আলোচনা করুন, বিরোধ শুরুর পরে নয়, কারণ একজন সরবরাহকারী আপনার সংকটপূর্ণ সেবার কোডের একমাত্র কপি ধরে থাকলে তা নকশা-দ্বারা বিক্রেতা-আবদ্ধতা।
5. সোর্স কোড উন্মুক্ত-ডিফল্ট হিসেবে প্রকাশ করুন, এবং আটকে রাখতে একটি নির্দিষ্ট যুক্তি দাবি করুন। সংগতভাবে প্রয়োগ করা একটি উন্মুক্ত-উৎস-ডিফল্ট নীতি প্রতিটি বিভাগের কাস্টম-গড়া সফটওয়্যারকে একবারের ব্যয়ের বদলে একটি ভাগাভাগি করা সরকার-জুড়ে সম্পদে পরিণত করে, এবং বাইরের বিশেষজ্ঞদের এমন নিরাপত্তা ত্রুটি খুঁজে পেতে দেয় যা একা একটি অভ্যন্তরীণ দল মিস করত।
6. এমন সফটওয়্যার চুক্তি লিখুন যা পুনরাবৃত্তিমূলক সরবরাহ কেবল কারিগরিভাবে সম্ভব নয়, আইনত বৈধ করে। যে চুক্তি কেবল স্বাক্ষরের সময় সম্মত একটি নির্দিষ্ট বিনির্দেশের বিপরীতে অর্থ দেয় তা একটি দলকে সৎ চটপটে চর্চা ও চুক্তিগত সম্মতির মধ্যে বেছে নিতে বাধ্য করে; শেষে একটি মাইলফলকের বদলে প্রদর্শিত কার্যকর সফটওয়্যারের সঙ্গে যুক্ত পর্যায়ক্রমিক অর্থায়ন-গেট ব্যবহার করুন।
7. আধুনিকীকরণকে একবারের মূলধন প্রকল্প নয়, একটি চলমান কর্মসূচি হিসেবে অর্থায়ন করুন। একবার আধুনিকীকৃত এবং তারপর আরও বিশ বছরের জন্য রেখে দেওয়া একটি উত্তরাধিকার ব্যবস্থা একই ঝুঁকি জমায় যা দিয়ে শুরু করেছিল; একটি সড়ক কর্তৃপক্ষ যেভাবে পুনঃপৃষ্ঠতলের জন্য বাজেট করে সেভাবে নিরন্তর, ক্রমবর্ধমান নবায়নের জন্য বাজেট করুন, প্রজন্মে একবার একটি মহান প্রতিস্থাপনের জন্য নয়।
8. বাণিজ্যিক সফটওয়্যার কেনার সময়ও উন্মুক্ত মান ও বহনযোগ্য উপাত্ত ফরম্যাট বেছে নিন। একটি সরবরাহকারীর ব্যবস্থাকে উন্মুক্ত, নথিবদ্ধ ফরম্যাটে উপাত্ত সংরক্ষণ ও রপ্তানি করতে দাবি করা সফটওয়্যার নিজে মালিকানাধীন হলেও স্থানান্তর ব্যয় কম রাখে, এবং প্রায়ই প্রতিটি ব্যবস্থাকে উন্মুক্ত-উৎস হতে জোর দেওয়ার চেয়ে বিক্রেতা-আবদ্ধতার বিরুদ্ধে একটি আরও অর্জনযোগ্য নিকট-মেয়াদি সুরক্ষা।
9. একটি ন্যূনতম কার্যকর পণ্য গড়ুন এবং পূর্ণ পরিধিতে দায়বদ্ধ হওয়ার আগে বাস্তব ব্যবহারকারীদের দেখান। একটি প্রকৃতপক্ষে ন্যূনতম সংস্করণ প্রকাশ করে তারপর যা শেখা হলো তার ওপর পুনরাবৃত্তি করা ভুল অনুমান সেগুলোর বিপরীতে একটি পূর্ণ-মাপের ব্যবস্থা গড়ার পরে নয়, ঠিক করা সস্তা থাকতেই ধরে।
10. সরবরাহ বাইরে চুক্তিবদ্ধ হলেও একজন বুদ্ধিমান ক্রেতা হওয়ার জন্য যথেষ্ট অভ্যন্তরীণ প্রকৌশল সামর্থ্য রাখুন। যে সরকারি সংস্থা তার কারিগরি দক্ষতা ফাঁপা করেছে সে একটি সরবরাহকারীর প্রস্তাব মূল্যায়ন করতে, একটি সমস্যাগ্রস্ত প্রকল্পের প্রাথমিক সতর্কতা-চিহ্ন দেখতে, বা আবদ্ধতা থেকে আলোচনা করে বেরোতে পারে না, কাগজে এর ক্রয় নিয়ম যাই বলুক।
11. একটি উত্তরাধিকার ব্যবস্থার ইউজার ইন্টারফেসের আগে এর ঝুঁকি প্রোফাইল অবসর দিন। অসমর্থিত ভাষা, প্যাচহীন অবকাঠামো এবং অনথিবদ্ধ সংহতি প্রতিস্থাপনকে — যে ব্যর্থতা বিভ্রাট ও লঙ্ঘন ঘটায় — অনেক কম পরিচালনাগত ঝুঁকি বহনকারী দৃশ্যমান আধুনিকীকরণের আগে অগ্রাধিকার দিন।
12. কেবল বাজেট ও সময়সূচি বিচ্যুতি নয়, প্রকৌশল সূচক দিয়ে সরবরাহ স্বাস্থ্য মাপুন। মোতায়েনের ঘনত্ব, ত্রুটি হার এবং সবচেয়ে পুরোনো অসম্বোধিত কারিগরি-ঋণ আইটেমের বয়স একটি শাসন পর্ষদকে একটি কর্মসূচি সফল হবে কি না সে সম্পর্কে এটি বর্তমানে বাজেটে আছে কি না তার চেয়ে বেশি বলে, যা প্রায়ই নড়ার শেষ সূচক।

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

আমরা কি সত্যিই জানি ব্যবস্থা অনুযায়ী আমরা কতটা কারিগরি ঋণ বহন করছি? বেশির ভাগ সরকারি সংস্থা বছরের জন্য তাদের মূলধন বাজেট বলতে পারে কিন্তু তাদের সফটওয়্যার পরিসরের কতটা অসমর্থিত উপাদান, অনথিবদ্ধ যুক্তি, বা কর্মীদের মধ্যে কেউ পুরোপুরি বোঝেন না এমন কোডে চলে তা কোনো আত্মবিশ্বাসের সঙ্গে বলতে পারে না। ঘরে প্রতিটি ব্যবস্থার মালিককে সততার সঙ্গে অনুমান করতে বলতে এই প্রশ্ন ব্যবহার করুন তাঁরা কতটা আত্মবিশ্বাসী যে তাঁদের দল কেউ আশা করেনি এমন কিছু না ভেঙে তাঁদের সবচেয়ে সংকটপূর্ণ ব্যবস্থা নিরাপদে বদলাতে পারত। আলোচনা করুন সেই অনুমানগুলোকে একটি নির্দিষ্ট চক্রে পর্যালোচিত একটি প্রকৃত নিবন্ধনে পরিণত করতে কী লাগবে, একজন মূল প্রকৌশলী চলে গেলে তাঁর সঙ্গে চলে যায় এমন গোষ্ঠীগত জ্ঞানের বদলে। এও ভাবুন, বর্তমানে কত ঋণ বহন করা গ্রহণযোগ্য তা কে স্থির করে, এবং সেই সিদ্ধান্ত সুচিন্তিত নাকি ডিফল্টে।

আমাদের সবচেয়ে সংকটপূর্ণ উত্তরাধিকার ব্যবস্থা আজ থেকে প্রতিস্থাপন করতে হলে, আমরা কি একটি বিগ-ব্যাং কাটওভার নাকি একটি ক্রমবর্ধমান স্থানান্তর পরিকল্পনা করতাম — এবং কেন? একটি পুরোনো ব্যবস্থা একবারে প্রতিস্থাপনের সহজাত প্রবৃত্তি প্রায়ই কারিগরি প্রয়োজনের বদলে বাজেট চক্র ও কর্মসূচি-ব্যবস্থাপনার সুবিধা দ্বারা চালিত, এবং এটি বিপুল ঝুঁকি একটি একক মুহূর্তে কেন্দ্রীভূত করে। আপনার সবচেয়ে সংকটপূর্ণ উত্তরাধিকার ব্যবস্থার একটি স্ট্র্যাংলার-ফিগ-ধরনের ক্রমবর্ধমান স্থানান্তর টুকরো টুকরো করে আসলে দেখতে কেমন হতো তা মূর্তভাবে ধরে এগোতে এই প্রশ্ন ব্যবহার করুন। আলোচনা করুন আজ আপনাকে সেই পথ বেছে নিতে কী বাধা দিচ্ছে — একটি একক গো-লাইভ তারিখের চারপাশে কাঠামোবদ্ধ অর্থায়ন, একটি শাসন প্রক্রিয়া যা একটি পরিষ্কার মাইলফলক চায়, নাকি একটি প্রকৃত কারিগরি সীমাবদ্ধতা যা এই ব্যবস্থার জন্য ক্রমবর্ধমান স্থানান্তর অসম্ভব করে।

আমাদের প্রতিষ্ঠান যে সফটওয়্যার গড়াতে অর্থ দিয়েছে তার সোর্স কোডের মালিক আসলে কে, এবং আমরা কি তা প্রমাণ করতে পারতাম? অনেক সরকারি সংস্থা কেবল একটি সরবরাহকারীর সঙ্গে সম্পর্ক তিক্ত হলে আবিষ্কার করে চুক্তি তাদের সংকটপূর্ণ সেবা যে কোডের ওপর নির্ভর করে তার স্পষ্ট মালিকানা বা এসক্রো নিশ্চিত করেনি। আপনার তিনটি সবচেয়ে গুরুত্বপূর্ণ বিশেষভাবে নির্মিত ব্যবস্থার চুক্তি টেনে বের করতে এবং নির্দিষ্টভাবে যাচাই করতে এই প্রশ্ন ব্যবহার করুন প্রতিটি কোড মালিকানা, এসক্রো এবং কোড অন্য সরবরাহকারীর কাছে নেওয়ার অধিকার সম্পর্কে কী বলে। আলোচনা করুন আগামীকাল ওই তিনটি ব্যবস্থার যেকোনোটির জন্য আপনার প্রাথমিক সরবরাহকারী ব্যবসা বন্ধ করলে বা সম্পর্ক চালিয়ে যেতে অস্বীকার করলে কী ঘটত।

আমরা কোথায় অভ্যাসবশত বদ্ধ, মালিকানাধীন সফটওয়্যারে ডিফল্ট করছি, যখন একটি উন্মুক্ত-উৎস-ডিফল্ট পন্থা আমাদের সমানভাবে বা আরও ভালো সেবা করত? উন্মুক্ত-উৎস-ডিফল্ট নীতি ঠিক এই কারণে বিদ্যমান যে বেশির ভাগ সরকারি সংস্থা স্বাধীনভাবে ওভারল্যাপিং সমস্যা সমাধান করে, প্রত্যেকে অন্য একটি সরকারি সংস্থা ইতিমধ্যে গড়েছে এবং ভাগ করতে পারত এমন সফটওয়্যারের পূর্ণ ব্যয় দেয়। এই মুহূর্তে গড়া বা বিনির্দিষ্ট করা একটি ব্যবস্থা চিহ্নিত করতে এবং জিজ্ঞেস করতে এই প্রশ্ন ব্যবহার করুন সরকারের অন্যত্র উন্মুক্ত-উৎস সফটওয়্যার হিসেবে একটি সমতুল্য ইতিমধ্যে আছে কি না, বা আপনি যেটি গড়ছেন সেটি অন্যদের পুনর্ব্যবহারের জন্য উপযোগীভাবে প্রকাশ করা যায় কি না। আলোচনা করুন কোন নির্দিষ্ট বাধা — নিরাপত্তা উদ্বেগ, ক্রয় অভ্যাস, একটি স্পষ্ট নীতির অভাব — আসলে সেই পুনর্ব্যবহার আটকাচ্ছে, এটি এখানে প্রাসঙ্গিক নয় ধরে না নিয়ে।

আমাদের ক্রয় ও জবাবদিহি প্রক্রিয়া কি আসলে সৎ চটপটে সরবরাহের অনুমতি দেয়, নাকি এটি কেবল ওয়াটারফল মাইলফলককে স্প্রিন্ট বলে নামান্তর করে? একটি দলের নামমাত্র চটপটে অনুষ্ঠান চালানো যখন তখনও চুক্তি স্বাক্ষরের সময় সম্মত একটি নির্দিষ্ট বিনির্দেশের বিপরীতে অর্থায়িত, শাসিত ও প্রতিবেদিত হয় তা সাধারণ, যা একটি চটপটে লেবেলের অধীনে প্রতিটি ওয়াটারফল ব্যর্থতার ধরন পুনঃসৃষ্টি করে। একটি জীবন্ত ডিজিটাল কর্মসূচি এর ব্যবসায়িক যুক্তি থেকে বর্তমান শাসন প্রতিবেদন পর্যন্ত অনুসরণ করতে এবং জিজ্ঞেস করতে এই প্রশ্ন ব্যবহার করুন অর্থায়ন কাঠামো একটি প্রকৃত প্রথম প্রকাশ যা শিখিয়েছে তার ভিত্তিতে কর্মসূচি দিক বদলালে তা সহ্য করত কি না। আলোচনা করুন পুনরাবৃত্তিমূলক সরবরাহ প্রসাধনিকের বদলে বাস্তব হতে কর্মসূচি কীভাবে অর্থায়িত ও প্রতিবেদিত হয় তাতে কী বদলাতে হবে (দেখুন বিষয় 3.7 — সরকারি ক্রয় ও কমিশনিং)।

আমরা যে ব্যবস্থার ওপর সবচেয়ে বেশি নির্ভর করি তার একজন বুদ্ধিমান ক্রেতা হওয়ার জন্য আমাদের কি যথেষ্ট অভ্যন্তরীণ প্রকৌশল সামর্থ্য আছে? যে প্রতিষ্ঠান কেবল তার সরবরাহ সামর্থ্য নয়, তার সব কারিগরি বিচার বাইরে চুক্তিবদ্ধ করেছে সে বলতে পারে না একটি সরবরাহকারীর প্রস্তাব সুস্থ কি না, একটি প্রকল্প নীরবে সমস্যার দিকে যাচ্ছে কি না, বা কাজের ন্যায্য মূল্য আসলে কত। আপনার প্রতিষ্ঠানের কতজন মানুষ আপনার সবচেয়ে গুরুত্বপূর্ণ ব্যবস্থার জন্য একটি কারিগরি স্থাপত্য প্রস্তাব বিশ্বাসযোগ্যভাবে পর্যালোচনা করতে পারতেন, এবং গত পাঁচ বছরে সেই সংখ্যা কীভাবে বদলেছে জিজ্ঞেস করতে এই প্রশ্ন ব্যবহার করুন। আলোচনা করুন যেখানে সেই সামর্থ্য ক্ষয় পেয়েছে সেখানে তা পুনর্গঠনে কী লাগবে, এবং আপনার প্রতিষ্ঠান যে প্রতিটি বছর তা ছাড়া যায় তাতে আলোচনার অবস্থানে যতটা, সরবরাহ ঝুঁকিতেও ততটা কী হারায়।

বাস্তবে: একটি জনমূল্যের উদাহরণ

একটি কাল্পনিক আঞ্চলিক সরকার — কেবল দৃষ্টান্তমূলক, কোনো প্রকৃত এখতিয়ারের বর্ণনা নয় — তার বেকারত্ব-সুবিধার দাবি এমন একটি ব্যবস্থার মাধ্যমে চালাত যা প্রথম ত্রিশ বছরেরও বেশি আগে লেখা হয়েছিল, মূল প্রোগ্রামিং ভাষা বোঝেন এমন ক্রমহ্রাসমান সংখ্যক প্রকৌশলী দ্বারা রক্ষণাবেক্ষিত। দাবির পরিমাণ ব্যবস্থার নকশাকাররা যা প্রত্যাশা করেছিলেন তার বাইরে বেড়ে গিয়েছিল, রাতের প্রক্রিয়াকরণ চালনা ক্রমবর্ধমানভাবে সকালের লেনদেন শুরুর আগে সম্পূর্ণ হতে ব্যর্থ হচ্ছিল, এবং সংস্থার প্রযুক্তি নেতৃত্ব সতর্ক করল যে সুবিধা পরিশোধ প্রভাবিত করা একটি অপরিকল্পিত বিভ্রাট এখন "যদি" নয়, "কখন"-এর বিষয়।

সংস্থার প্রথম সহজাত প্রবৃত্তি ছিল একটি জরুরি মনে হওয়া সমস্যার প্রচলিত সাড়া: একটি আধুনিক প্ল্যাটফর্ম দিয়ে সমগ্র ব্যবস্থা প্রতিস্থাপন করতে একটি একক বড় চুক্তি কমিশন করা, সামনে সম্পূর্ণ বিনির্দিষ্ট, শেষে একটি কাটওভার সপ্তাহান্তসহ একটি নির্দিষ্ট দুই-বছর সময়সীমার বিপরীতে সরবরাহ। সংস্থার নিরীক্ষা কমিটির কমিশন করা একটি প্রাক-বাস্তবায়ন পর্যালোচনা চুক্তি স্বাক্ষরের আগে একটি কঠিন প্রশ্ন তুলল: নতুন ব্যবস্থায় পূর্ণ-মাপের, লাইভ পরিচালনার প্রথম সপ্তাহে একটি অনাবিষ্কৃত ত্রুটি থাকলে, পুরোনো ব্যবস্থা ইতিমধ্যে বন্ধ এবং ফেরার কোনো পথ ছাড়া, কয়েক লক্ষ দাবিদারের সুবিধা পরিশোধের কী হবে।

সংস্থা গতিপথ বদলাল। এটি উত্তরাধিকার ব্যবস্থাকে রেকর্ডের ব্যবস্থা হিসেবে চালু রাখল এবং একটি স্ট্র্যাংলার-ফিগ পদ্ধতি ব্যবহার করে এর পাশাপাশি নতুন দাবি-গ্রহণ ও যোগ্যতা-মূল্যায়ন কার্যকারিতা গড়তে শুরু করল: প্রতিটি নতুন মডিউল প্রথমে নতুন দাবির একটি ছোট শতাংশে প্রকাশ করা হলো, পুরোনো ব্যবস্থার সমান্তরাল আউটপুটের বিপরীতে যাচাই করা হলো, এবং কেবল এর ফল মিললে প্রসারিত করা হলো। আঠারো মাসের মধ্যে, বেশির ভাগ নতুন দাবি আধুনিক উপাদানের মধ্য দিয়ে চলত যখন মূল ব্যবস্থা একটি সঙ্কুচিত অবশিষ্ট কেসলোড সামলাত, কিছু ভুল দেখালে যেকোনো একক ক্ষেত্র পুরোনো পথে ফেরানোর সামর্থ্যসহ। সংস্থা এই কাজের জন্য জারি করা প্রতিটি নতুন চুক্তিতে এও দাবি করল যে সোর্স কোড সংস্থার মালিকানাধীন হবে এবং নিরাপত্তা পর্যালোচনা সম্পূর্ণ হলে উন্মুক্ত-উৎস হিসেবে প্রকাশ করা হবে, যাতে একই বার্ধক্যগ্রস্ত-মেইনফ্রেম সমস্যার মুখোমুখি অন্যান্য আঞ্চলিক সরকার শূন্য থেকে একই নির্মাণ পুনরাবৃত্তির বদলে উপাদানগুলো অভিযোজিত করতে পারে।

উত্তরাধিকার ব্যবস্থার শেষ অবশিষ্ট কার্যকারিতার পূর্ণ প্রতিস্থাপনে প্রায় চার বছর লাগল — কাগজে মূল দুই-বছরের বিগ-ব্যাং পরিকল্পনার প্রতিশ্রুতির চেয়ে বেশি। কিন্তু রূপান্তরের সময় কোনো দাবিদার কখনও অপরিকল্পিত বিভ্রাট অনুভব করেননি, প্রতিটি বৃদ্ধি এত ছোট ছিল যে একটি ত্রুটি পাওয়া গেলে ঘণ্টার মধ্যে পূর্বাবস্থায় ফেরানো যেত, এবং দুটি প্রতিবেশী আঞ্চলিক সরকার সংস্থার প্রকাশিত যোগ্যতা-মূল্যায়ন কোড প্রকাশের প্রথম বছরের মধ্যেই নিজস্ব ব্যবস্থার জন্য অভিযোজিত করতে শুরু করল।

চারটি খাতভিত্তিক দৃষ্টিকোণ

স্থানীয় সরকার

স্থানীয় সরকার সাধারণত অল্প কয়েকটি জাতীয়-মাপের প্ল্যাটফর্মের বদলে অনেক ছোট, বিচ্ছিন্ন ব্যবস্থা চালায়, যার অর্থ কারিগরি ঋণ একটি দৃশ্যমান পতাকাবাহী ব্যবস্থায় নয়, অনেক আলাদাভাবে ক্রয় করা, আলাদাভাবে রক্ষণাবেক্ষিত অ্যাপ্লিকেশন জুড়ে জমে। স্থানীয় কর্তৃপক্ষের সাধারণত সরকারের যেকোনো স্তরের সবচেয়ে কম অভ্যন্তরীণ প্রকৌশল সামর্থ্য আছে, যা বিশেষভাবে নির্মিত গড়ার চেয়ে কনফিগারযোগ্য পণ্য সফটওয়্যার কেনার যুক্তি বিশেষভাবে শক্তিশালী করে, এবং প্রতিটি কর্তৃপক্ষ আলাদাভাবে একই সামর্থ্য পুনর্নির্মাণ এড়াতে ভাগাভাগি করা আঞ্চলিক বা জাতীয় প্ল্যাটফর্মকে — যা আগের বিষয়ের আলোচ্য (দেখুন বিষয় 5.1 — ডিজিটাল সরকার ও ডিজিটাল রূপান্তর) — একটি বিশেষভাবে উচ্চ-মূল্যের পথ করে।

জাতীয় সরকার

জাতীয় সরকার সেই জায়গা যেখানে সবচেয়ে পুরোনো ও সবচেয়ে পরিণামবাহী উত্তরাধিকার ব্যবস্থা থাকে — মূল কর, সামাজিক-বিমা এবং সুবিধা প্রশাসন — কারণ এগুলো প্রায়ই সরকারে প্রথম বৃহৎ-মাপের কম্পিউটারাইজেশন প্রচেষ্টার মধ্যে ছিল এবং এখন যেকোনো আধুনিকীকরণ ব্যর্থতার জন্য সর্বোচ্চ বাজি বহন করে। জাতীয় সরকারের সাধারণত একটি প্রকৃতপক্ষে ক্রমবর্ধমান আধুনিকীকরণ কর্মসূচি চালানোর এবং তার চুক্তিতে প্রকৃত কোড মালিকানা আলোচনা করার বিশেষজ্ঞ বাণিজ্যিক ও প্রকৌশল সামর্থ্য আছে, এবং এটি সাধারণত সরকারের সেই স্তর যা সরকার-জুড়ে পুনর্ব্যবহার সত্যিই ঘটাতে যথেষ্ট মাপসহ একটি উন্মুক্ত-উৎস-ডিফল্ট নীতি স্থির করতে সবচেয়ে ভালো অবস্থানে।

সামাজিক খাত ও অলাভজনক

অলাভজনক ও দাতব্য সংস্থা খুব কমই নিজেরা বড় কাস্টম প্ল্যাটফর্ম গড়ে, কিন্তু তারা প্রায়ই একটি সরকারি অর্থদাতার কমিশন করা বা আদেশ দেওয়া সফটওয়্যারের প্রাপক প্রান্তে থাকে — একটি প্রতিবেদন পোর্টাল, একটি কেস-ব্যবস্থাপনা ব্যবস্থা যা একটি অনুদান বা চুক্তি তাদের ব্যবহার করতে দাবি করে — এর নকশা, কারিগরি ঋণ বা বিক্রেতার ওপর সামান্য প্রভাব নিয়ে। একটি সরকার-আদেশকৃত ব্যবস্থার ওপর নির্ভরশীল সামাজিক-খাতের সংগঠন সেই ব্যবস্থার ব্যর্থতার ধরন উত্তরাধিকারসূত্রে পায় সেগুলো ঠিক করার কোনো লিভারেজ উত্তরাধিকারসূত্রে না পেয়ে, যা ফল-ভিত্তিক অর্থায়ন সম্পর্কগুলোকে কেবল ফল মেট্রিক নয়, আদেশকৃত প্রযুক্তির পরিচালনাগত বোঝার হিসাব রাখার আরও একটি কারণ (দেখুন বিষয় 3.7 — সরকারি ক্রয় ও কমিশনিং)।

বহুপাক্ষিক ও আন্তর্জাতিক

বহুপাক্ষিক সংস্থা ও উন্নয়ন সংস্থা ক্রমবর্ধমানভাবে এক দেশের সরকারি প্রশাসনের জন্য গড়া সফটওয়্যারকে একটি পুনর্ব্যবহারযোগ্য ডিজিটাল জনপণ্য হিসেবে প্রচার করে যা অন্যান্য দেশ অভিযোজিত করতে পারে, প্রতিটি সরকার একটি বেসরকারি সরবরাহকারীর কাছ থেকে পূর্ণ ব্যয়ে একটি সমতুল্য ব্যবস্থা কমিশন করার বদলে। এখানে স্বতন্ত্র ঝুঁকি হলো এক দেশের আইনি ও প্রশাসনিক প্রেক্ষাপটের জন্য গড়া একটি ডিজিটাল জনপণ্য অন্যত্র অতি অল্প অভিযোজনে গৃহীত হতে পারে, পরিচয়, যোগ্যতা বা প্রক্রিয়া সম্পর্কে এমন অনুমান আমদানি করে যা আসলে স্থানান্তরিত হয় না; ভাগাভাগি করা, উন্মুক্ত অবকাঠামোর প্রতিশ্রুতি প্রকৃত, কিন্তু কেবল সেখানেই যেখানে প্রকৃত স্থানীয় অভিযোজন সামর্থ্য কোডের সঙ্গে থাকে।

সাধারণ ব্যর্থতার ধরন

গো-লাইভে ব্যর্থ বিগ-ব্যাং কাটওভার। একটি সংকটপূর্ণ উত্তরাধিকার ব্যবস্থা বছরের পর বছর লাইভ উৎপাদন এক্সপোজার ছাড়া উন্নয়নের পর একটি একক, অপ্রত্যাবর্তনযোগ্য কাটওভারে প্রতিস্থাপিত হয়, এবং একটি ত্রুটি যা কেবল বাস্তব মাপে বা কেউ পরীক্ষা না করা একটি প্রান্তিক ক্ষেত্রে দেখা দেয় তা পূর্ণ পরিচালনার প্রথম দিনে প্রকাশ পায়, পুরোনো ব্যবস্থায় ফেরার কোনো উপায় ছাড়া কারণ এটি ইতিমধ্যে বন্ধ করা হয়েছে। ক্ষতি পরিমাপ করা হয় মিস করা পরিশোধ, অস্বীকৃত সেবা, বা ঠিক সেই নাগরিকদের প্রভাবিত বিভ্রাটে যাদের সেবা করতে ব্যবস্থাটি বিদ্যমান, সবচেয়ে খারাপ সম্ভাব্য মুহূর্তে — যে মুহূর্তে প্রত্যেকে প্রতিস্থাপনটি কাজ করার ওপর নির্ভর করছিল।

নীরব কারিগরি-ঋণ সঞ্চয়। সময়সীমার চাপ বারবার পরিচিত শর্টকাট ঠিক করার জন্য প্রয়োজনীয় সময়ের বিরুদ্ধে যুক্তি জেতে, এবং প্রতিটি স্থগিতাদেশ স্বতন্ত্রভাবে প্রতিরক্ষাযোগ্য, যতক্ষণ না সংগৃহীত ঋণ এমনকি একটি ছোট পরিবর্তনকেও অসমানুপাতিকভাবে ব্যয়বহুল ও ঝুঁকিপূর্ণ করে। ক্ষতি বছর পরে একটি ব্যবস্থা হিসেবে দেখা দেয় যা কেউ নিরাপদে পরিবর্তন করতে পারে না, একটি জনবল যা নীরবে সবচেয়ে জরুরি প্যাচ ছাড়া কিছুই চেষ্টা করা বন্ধ করেছে, এবং একটি চূড়ান্ত আধুনিকীকরণ কর্মসূচি যা নিরন্তর, ছোট নবায়ন হতো তার চেয়ে অনেক বড় ও ব্যয়বহুল।

স্থিতিশীলতা বলে ভুল-বোঝা বিক্রেতা-আবদ্ধতা। একটি সরকারি সংস্থা একই সরবরাহকারীর চুক্তি বারবার নবায়ন করে কারণ স্থানান্তর চেষ্টা করার জন্য অতিরিক্ত বিঘ্নকর মনে হয়, প্রকৃত স্থানান্তর ব্যয় কত হবে তা কখনও পরীক্ষা না করে বা সেই ব্যয় পরিচালনাযোগ্য রাখা কোড মালিকানা ও উন্মুক্ত উপাত্ত ফরম্যাটের জন্য আলোচনা না করে। ক্ষতি মূল্য ও শর্তে একটি স্থায়ীভাবে দুর্বল আলোচনা-অবস্থান, কেবল তখন আবিষ্কৃত হয় যখন সরবরাহকারীর সেবার মান কমে বা এর মূল্য বাড়ে এবং সরকারি সংস্থা দেখে তার কোনো বিশ্বাসযোগ্য বিকল্প নেই।

প্রসাধনিক চটপটে। একটি সরবরাহ দল চটপটে অনুষ্ঠান গ্রহণ করে — স্ট্যান্ড-আপ, স্প্রিন্ট, একটি ব্যাকলগ — যখন অন্তর্নিহিত চুক্তি, অর্থায়ন ও শাসন কাঠামো এখনও একটি নির্দিষ্ট বিনির্দেশ এবং একটি একক গো/নো-গো মাইলফলক ধরে, তাই দল স্প্রিন্ট বেগ প্রতিবেদন করে যখন আসলে নিচে একটি ওয়াটারফল পরিকল্পনার বিপরীতে সরবরাহ করছে। ক্ষতি হলো চটপটের কোনো প্রকৃত সুবিধা — প্রাথমিক ব্যবহারকারী ফিডব্যাক দিক বদলানো, ঝুঁকি আগে প্রকাশ — বাস্তবায়িত হয় না, যখন আধুনিক চর্চার চেহারা তত্ত্বাবধান সংস্থার জন্য অন্তর্নিহিত অনমনীয়তা দেখা ও চ্যালেঞ্জ করা কঠিনতর করে।

টিকিয়ে রাখার পরিকল্পনা ছাড়া উন্মুক্ত-উৎস নীতি। একটি সরকারি সংস্থা একটি উন্মুক্ত-উৎস-ডিফল্ট নীতি পূরণ করতে সোর্স কোড প্রকাশ করে কিন্তু প্রকাশকে একবারের সম্মতি ধাপ হিসেবে দেখে, বাইরের অবদান পর্যালোচনা, দুর্বলতা প্যাচ বা ডকুমেন্টেশন রক্ষণাবেক্ষণের জন্য কোনো সম্পদ ছাড়া। ক্ষতি একটি প্রকাশিত রিপোজিটরি যা খোলা দেখায় কিন্তু একটি অরক্ষণাবেক্ষিত শেষ-পথ হিসেবে কাজ করে, যা বিস্তৃততর উন্মুক্ত-উৎস-ডিফল্ট কর্মসূচির প্রতি আস্থা কখনও না প্রকাশ করার চেয়ে বেশি ক্ষতি করে।

পরিপক্বতা মডেল

চেকলিস্ট

• প্রতিটি সংকটপূর্ণ ব্যবস্থার কারিগরি ঋণ তালিকাভুক্ত করুন এবং নিবন্ধনটি একটি নির্দিষ্ট চক্রে পর্যালোচনা করুন।
• কোনো উল্লেখযোগ্য নতুন সফটওয়্যারে দায়বদ্ধ হওয়ার আগে একটি নথিবদ্ধ গড়া-বনাম-কেনা কাঠামো প্রয়োগ করুন।
• যেকোনো উত্তরাধিকার ব্যবস্থা প্রতিস্থাপনের জন্য একটি ক্রমবর্ধমান স্থানান্তর পদ্ধতিতে ডিফল্ট করুন এবং বিগ-ব্যাং কাটওভারের জন্য একটি স্পষ্ট যুক্তি দাবি করুন।
• স্বাক্ষরের আগে প্রতিটি সফটওয়্যার চুক্তিতে সোর্স-কোড মালিকানা বা এসক্রো শর্ত নিশ্চিত করুন।
• একটি নথিবদ্ধ ব্যতিক্রম প্রক্রিয়াসহ একটি উন্মুক্ত-উৎস-ডিফল্ট নীতির অধীনে সোর্স কোড প্রকাশ করুন।
• সেই নীতির অধীনে প্রকাশিত প্রতিটি রিপোজিটরির জন্য কেবল এর প্রাথমিক প্রকাশ নয়, চলমান রক্ষণাবেক্ষণে সম্পদ দিন।
• অন্তর্নিহিত সফটওয়্যার মালিকানাধীন হলেও উন্মুক্ত, নথিবদ্ধ উপাত্ত ফরম্যাট দাবি করুন।
• অর্থায়ন-গেট একটি একক নির্দিষ্ট-বিনির্দেশ মাইলফলকের বদলে প্রদর্শিত কার্যকর সফটওয়্যারের চারপাশে কাঠামোবদ্ধ করুন।
• পূর্ণ পরিধিতে দায়বদ্ধ হওয়ার আগে বাস্তব ব্যবহারকারীদের সঙ্গে একটি ন্যূনতম কার্যকর পণ্য গড়ুন ও পরীক্ষা করুন।
• মোতায়েনের ঘনত্ব, ত্রুটি হার এবং বকেয়া কারিগরি ঋণ স্থায়ী শাসন সূচক হিসেবে ট্র্যাক করুন।
• একজন বুদ্ধিমান ক্রেতা হওয়ার জন্য যা দরকার তার বিপরীতে অভ্যন্তরীণ প্রকৌশল সামর্থ্য মূল্যায়ন করুন, এবং চিহ্নিত ব্যবধান বন্ধ করুন।
• প্রসাধনিক আধুনিকীকরণের আগে অসমর্থিত অবকাঠামো ও অনথিবদ্ধ সংহতিকে অগ্রাধিকার দিন।

মূল উৎস

• GOV.UK Service Standard, Government Digital Service, United Kingdom — পুনরাবৃত্তিমূলক, ব্যবহারকারী-কেন্দ্রিক সরবরাহ এবং সরকারি সেবার জন্য উন্মুক্ত মান দাবি করা একটি জাতীয় ডিজিটাল-সেবা মান।
• Office of Management and Budget, Federal Source Code Policy (M-16-21), United States — সংস্থাগুলোকে কাস্টম-উন্নত সরকারি সফটওয়্যারের জন্য পুনর্ব্যবহার ও উন্মুক্ত-উৎস প্রকাশ বিবেচনা করতে দাবি করা ফেডারেল নীতি।
• Free Software Foundation Europe, Public Money, Public Code campaign — জনঅর্থায়িত সফটওয়্যারের সোর্স কোড মুক্ত ও উন্মুক্ত-উৎস লাইসেন্সের অধীনে প্রকাশের যুক্তি, ইউরোপীয় দর্শকদের জন্য বিকশিত।
• Ward Cunningham, "The WyCash Portfolio Management System" (OOPSLA 1992 experience report) — কারিগরি-ঋণ রূপকের মূল বিবৃতি।
• Digital Public Goods Alliance — জন উন্নয়ন উদ্দেশ্য সেবা করতে নকশা করা উন্মুক্ত সফটওয়্যার, উপাত্ত ও বিষয়বস্তুর জন্য মান ও নিবন্ধন রক্ষণাবেক্ষণকারী একটি বহু-অংশীজন উদ্যোগ।

তথ্যসূত্র

1. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
2. Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
3. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
4. COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
5. Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
6. Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
9. Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
12. Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
13. Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
14. Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
15. Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
16. "The WyCash Portfolio Management System" (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
17. Digital Public Goods Alliance — https://digitalpublicgoods.net/