AWS-এ আর্কিটেকচার সিদ্ধান্ত রেকর্ডের প্রক্রিয়া

https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html

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

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

দল যখন কোনো ADR গ্রহণ করে, তখন সেটি অপরিবর্তনীয় হয়ে যায়। নতুন অন্তর্দৃষ্টির কারণে ভিন্ন সিদ্ধান্ত নেওয়ার প্রয়োজন হলে দল একটি নতুন ADR প্রস্তাব করে। দল নতুন ADR গ্রহণ করলে সেটি আগের ADR-কে প্রতিস্থাপিত করে।

ADR প্রক্রিয়ার পরিধি

সফটওয়্যার প্রকল্প বা পণ্যকে প্রভাবিত করে এমন প্রতিটি আর্কিটেকচারগতভাবে গুরুত্বপূর্ণ সিদ্ধান্তের জন্য প্রকল্পের সদস্যদের একটি ADR তৈরি করা উচিত, যার মধ্যে রয়েছে নিম্নলিখিতগুলো (Richards and Ford 2020):

• কাঠামো (যেমন মাইক্রোসার্ভিসের মতো প্যাটার্ন)

• অ-কার্যকরী প্রয়োজনীয়তা (নিরাপত্তা, উচ্চ প্রাপ্যতা এবং ত্রুটি সহনশীলতা)

• নির্ভরতা (উপাদানগুলোর মধ্যে সংযুক্তি)

• ইন্টারফেস (API এবং প্রকাশিত চুক্তি)

• নির্মাণ কৌশল (লাইব্রেরি, ফ্রেমওয়ার্ক, টুল ও প্রক্রিয়া)

• কার্যকরী ও অ-কার্যকরী প্রয়োজনীয়তা হলো ADR প্রক্রিয়ার সবচেয়ে প্রচলিত ইনপুট।

ADR-এর বিষয়বস্তু

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

ADR গ্রহণ প্রক্রিয়া

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

দল কোনো আর্কিটেকচার সিদ্ধান্ত ও তার মালিক শনাক্ত করার পর ADR-এর মালিক প্রক্রিয়ার শুরুতে ADR-টি প্রস্তাবিত (Proposed) অবস্থায় উপস্থাপন করেন। প্রস্তাবিত অবস্থার ADR পর্যালোচনার জন্য প্রস্তুত।

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

ADR উন্নত করার জন্য দল কর্মপদক্ষেপ খুঁজে পেলে ADR-এর অবস্থা প্রস্তাবিত থেকে যায়। ADR-এর মালিক কর্মপদক্ষেপগুলো প্রণয়ন করেন এবং দলের সঙ্গে সহযোগিতায় প্রতিটি কাজে একজন দায়িত্বপ্রাপ্ত ব্যক্তি যোগ করেন। প্রতিটি দলীয় সদস্য কর্মপদক্ষেপে অবদান রাখতে ও সেগুলো সমাধান করতে পারেন। পর্যালোচনা প্রক্রিয়ার সময় নতুন করে নির্ধারণ করা ADR-এর মালিকের দায়িত্ব।

দল ADR প্রত্যাখ্যান করার সিদ্ধান্তও নিতে পারে। এ ক্ষেত্রে ভবিষ্যতে একই বিষয়ে আবার আলোচনা এড়াতে ADR-এর মালিক প্রত্যাখ্যানের কারণ যোগ করেন। মালিক ADR-এর অবস্থা প্রত্যাখ্যাত (Rejected) করে দেন।

দল ADR অনুমোদন করলে মালিক একটি টাইমস্ট্যাম্প, সংস্করণ এবং অংশীজনদের তালিকা যোগ করেন। এরপর মালিক অবস্থা গৃহীত (Accepted) করে হালনাগাদ করেন।

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

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

ADR পর্যালোচনা প্রক্রিয়া

দল কোনো ADR গ্রহণ বা প্রত্যাখ্যান করার পর সেটিকে অপরিবর্তনীয় নথি হিসেবে বিবেচনা করা উচিত। বিদ্যমান ADR-এর পরিবর্তনের জন্য একটি নতুন ADR তৈরি করতে হয়, নতুন ADR-এর জন্য পর্যালোচনা প্রক্রিয়া চালু করতে হয় এবং ADR অনুমোদন করতে হয়। দল নতুন ADR অনুমোদন করলে মালিকের উচিত পুরোনো ADR-এর অবস্থা প্রতিস্থাপিত (Superseded) করে দেওয়া।