موضوع 4.0 — تکنیکی فن تعمیر، کلاؤڈ اور پرانے نظام

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

یہ صحت اور نگہداشت میں کیوں اہم ہے#

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

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

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

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

بنیادی تصورات#

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

فن تعمیر کی رہنمائی فن تعمیر کے اصول کرتے ہیں: مختصر، متفقہ بیانات کا مجموعہ — جیسے "خریدنے سے پہلے دوبارہ استعمال، بنانے سے پہلے خریدیں" یا "کھلے معیارات پر بنائیں" — جو ہر انتخاب کو اوپر بھیجے بغیر یکساں فیصلے ممکن بناتے ہیں۔ اصول ہلکے طور پر ڈیزائن اتھارٹی نافذ کرتی ہے: چھوٹا گروہ جو اہم تکنیکی فیصلوں کا جائزہ لیتا ہے۔ صحت مند ورژن روکنے کے بجائے ممکن بناتا ہے؛ وہ قابلِ اجتناب نقصان اور نقل کو روکنے کے لیے ہے، ٹیموں کو سست کرنے یا اپنی خاطر دربانی کرنے کے لیے نہیں۔

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

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

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

بہترین طریقے#

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

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

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

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

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

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

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

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

9. بنانے، خریدنے، یا ترتیب دینے کا فیصلہ کل ملکیت کی لاگت پر کریں، ظاہری قیمت پر نہیں۔ ہر صلاحیت کے لیے مخصوص بنانے، مصنوعہ خریدنے، اور موجودہ پلیٹ فارم ترتیب دینے کا ان کی پوری زندگی کی لاگت پر موازنہ کریں — ہوسٹنگ، لائسنسنگ، انضمام، مدد، اپ گریڈ، اور بالآخر خروج — ابتدائی قیمت نہیں۔ عام ضروریات کے لیے خریدنے یا ترتیب دینے کو ترجیح دیں اور بنانا حقیقی امتیاز کے لیے رکھیں، اور ہر اختیار کی پیدا کردہ پابندی کا وزن کریں۔ اسے تجارتی ساتھیوں کے ساتھ حل کریں (موضوع 6.3 — خریداری اور تجارتی امور)، کیونکہ کھلے انٹرفیس اور خروج کے حقوق محفوظ کرنے کا سب سے سستا وقت دستخط سے پہلے ہے۔

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

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

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

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

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

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

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

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

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

عملی مثال: صحت اور نگہداشت کی ایک مثال#

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

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

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

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

شعبہ جاتی زاویے#

اسٹارٹ اپ#

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

چھوٹا کاروبار#

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

بڑا ادارہ#

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

حکومت#

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

عام ناکامی کے طریقے#

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

پختگی کا ماڈل#

جانچ فہرست#

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

کلیدی ماخذ#

• NHS انگلینڈ — کلاؤڈ حکمت عملی، ٹیکنالوجی کے معیارات، اور ڈیٹا سیکیورٹی اینڈ پروٹیکشن ٹول کٹ۔
• نیشنل سائبر سیکیورٹی سینٹر (NCSC) — محفوظ ڈیزائن کے اصول اور کلاؤڈ سلامتی کی رہنمائی۔
• UK حکومت (GDS/CDDO) — Technology Code of Practice اور کلاؤڈ اول پالیسی۔
• نیشنل آڈٹ آفس — NHS کے پرانے نظاموں، WannaCry حملے، اور IT سے چلنے والے پروگراموں پر رپورٹیں۔
• دی اوپن گروپ — TOGAF، انٹرپرائز فن تعمیر کا فریم ورک۔
• گورنمنٹ ڈیجیٹل سروس — GOV.UK سروس مینوئل اور ڈیزائن کمیونٹی میں "کم از کم قابلِ عمل پلیٹ فارم" کا تصور۔

حوالہ جات#

1. Enterprise architecture — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_architecture
2. Solution architecture — Wikipedia — https://en.wikipedia.org/wiki/Solution_architecture
3. Systems architecture — Wikipedia — https://en.wikipedia.org/wiki/Systems_architecture
4. Cloud computing — Wikipedia — https://en.wikipedia.org/wiki/Cloud_computing
5. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
6. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
7. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
8. Application portfolio management — Wikipedia — https://en.wikipedia.org/wiki/Application_portfolio_management
9. Application programming interface — Wikipedia — https://en.wikipedia.org/wiki/Application_programming_interface
10. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
11. Secure by design — Wikipedia — https://en.wikipedia.org/wiki/Secure_by_design
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. Cloud strategy — NHS England — https://www.england.nhs.uk/long-read/cloud-centre-of-excellence/
14. Secure design principles — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/cyber-security-design-principles
15. Technology Code of Practice — UK Government (CDDO) — https://www.gov.uk/guidance/the-technology-code-of-practice
16. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
17. TOGAF Standard — The Open Group — https://www.opengroup.org/togaf
18. Service Manual: cloud and platforms — Government Digital Service — https://www.gov.uk/service-manual