جیف ٹائری اور آرٹ اکرمین کا فیصلہ ریکارڈ سانچہ

یہ آرکیٹیکچر فیصلے کی وضاحت کا وہ سانچہ ہے جو "Architecture Decisions: Demystifying Architecture" by Jeff Tyree and Art Akerman, Capital One Financial میں شائع ہوا۔

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

• فیصلہ (Decision): آرکیٹیکچر کی سمت، یعنی آپ کا منتخب کردہ مؤقف، واضح طور پر بیان کریں۔

• حالت (Status): فیصلے کی حالت، مثلاً pending, decided یا approved۔

• گروپ (Group): فیصلوں کے مجموعے کو منظم کرنے کے لیے آپ سادہ گروہ بندی استعمال کر سکتے ہیں — جیسے انضمام، پیشکش، ڈیٹا وغیرہ۔ آپ زیادہ نفیس آرکیٹیکچر اونٹولوجی بھی استعمال کر سکتے ہیں، جیسے John Kyaruzi اور Jan van Katwijk کی، جس میں ایونٹ، کیلنڈر اور مقام جیسی زیادہ تجریدی زمرے شامل ہیں۔ مثلاً اس اونٹولوجی کو استعمال کرتے ہوئے آپ ان فیصلوں کو ایونٹ کے تحت گروپ کریں گے جو ان واقعات سے متعلق ہوں جہاں سسٹم کو معلومات درکار ہوں۔

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

• پابندیاں (Constraints): ماحول پر کوئی بھی اضافی پابندیاں سمیٹیں جو منتخب متبادل (فیصلہ) عائد کر سکتا ہے۔

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

• دلیل (Argument): بیان کریں کہ آپ نے مؤقف کیوں چنا، بشمول نفاذ کی لاگت، ملکیت کی کل لاگت، مارکیٹ تک پہنچنے کا وقت، اور مطلوبہ ڈویلپمنٹ وسائل کی دستیابی جیسے نکات۔ یہ غالباً اتنا ہی اہم ہے جتنا خود فیصلہ۔

• مضمرات (Implications): جیسا کہ REMAP میٹا ماڈل بتاتا ہے، فیصلے کے بہت سے مضمرات ہوتے ہیں۔ مثلاً فیصلہ دوسرے فیصلے کرنے کی ضرورت پیدا کر سکتا ہے، نئے تقاضے بنا سکتا ہے یا موجودہ تقاضے بدل سکتا ہے؛ ماحول پر اضافی پابندیاں عائد کر سکتا ہے؛ صارفین کے ساتھ دائرہ کار یا شیڈول پر دوبارہ مذاکرات کا متقاضی ہو سکتا ہے؛ یا اضافی عملے کی تربیت کا تقاضا کر سکتا ہے۔ اپنے فیصلے کے مضمرات کو واضح طور پر سمجھنا اور بیان کرنا حمایت حاصل کرنے اور آرکیٹیکچر کے نفاذ کا روڈ میپ بنانے میں بہت مؤثر ہو سکتا ہے۔

• متعلقہ فیصلے (Related decisions): ظاہر ہے کہ بہت سے فیصلے آپس میں جڑے ہوتے ہیں؛ آپ انہیں یہاں درج کر سکتے ہیں۔ تاہم ہم نے پایا ہے کہ عملی طور پر ٹریس ایبلٹی میٹرکس، فیصلوں کے درخت یا میٹا ماڈلز زیادہ مفید ہیں۔ پیچیدہ تعلقات کو خاکوں کی صورت میں دکھانے کے لیے میٹا ماڈلز مفید ہیں (جیسے Rose ماڈلز)۔

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

• متعلقہ آرٹیفیکٹس (Related artifacts): متعلقہ آرکیٹیکچر، ڈیزائن یا دائرہ کار کی دستاویزات کی فہرست دیں جن پر یہ فیصلہ اثر انداز ہوتا ہے۔

• متعلقہ اصول (Related principles): اگر انٹرپرائز کے پاس اصولوں کا متفقہ مجموعہ ہے تو یقینی بنائیں کہ فیصلہ ان میں سے ایک یا زیادہ کے مطابق ہو۔ یہ شعبوں یا سسٹمز کے درمیان ہم آہنگی یقینی بنانے میں مدد کرتا ہے۔

• نوٹس (Notes): چونکہ فیصلہ سازی کے عمل میں ہفتے لگ سکتے ہیں، ہم نے ان نوٹس اور مسائل کو سمیٹنا مفید پایا جن پر ٹیم سماجی کاری کے عمل کے دوران بحث کرتی ہے۔