विषय 4.0 — तकनीकी आर्किटेक्चर, क्लाउड और विरासत

स्वास्थ्य और देखभाल में, तकनीकी आर्किटेक्चर वर्षों पहले लिया गया एक क्लिनिकल-सुरक्षा, सुरक्षा, और सार्वजनिक-धन निर्णय है: आप जो प्लेटफ़ॉर्म खड़े करते हैं और जो विरासत आप छोड़ते हैं वे चुपचाप निर्धारित करते हैं कि क्या देखभाल सुरक्षित, जुड़ी हुई, और वहनीय हो सकती है उन लोगों के आगे बढ़ने के बाद भी जिन्होंने उन्हें चुना।

यह स्वास्थ्य और देखभाल में क्यों महत्वपूर्ण है#

आर्किटेक्चर आपकी डिजिटल सेवाओं के नीचे दीर्घजीवी संरचनात्मक विकल्पों का समूह है: क्या कहां चलता है, घटक कैसे जुड़ते हैं, आप क्या बनाते हैं बनाम खरीदते हैं, और आप अतीत से क्या जीवित रखते हैं। ये विकल्प शायद ही कभी रोगियों या क्लिनिशियनों को दिखाई देते हैं, और शायद ही कभी बोर्डों के लिए रोमांचक होते हैं। फिर भी वे ऊपर बैठी हर चीज़ को आकार देते हैं। एक अच्छी तरह से आर्किटेक्ट की गई संपत्ति आपको जल्दी एक नई सेवा जोड़ने, सुरक्षित रूप से डेटा साझा करने, और कुछ टूटने पर तेज़ी से उबरने देती है। एक खराब आर्किटेक्ट की गई हर परिवर्तन को धीमा, हर एकीकरण को नाजुक, और हर घटना को बदतर बनाती है।

स्वास्थ्य और देखभाल में दांव ऊंचे हैं क्योंकि सिस्टम परिणामी हैं। जब एक पुराना रोगी प्रशासन सिस्टम गिर जाता है, तो एम्बुलेंस मुड़ जाती हैं और क्लिनिक रद्द होते हैं। जब एक असमर्थित ऑपरेटिंग सिस्टम का शोषण किया जाता है, तो गोपनीय रिकॉर्ड उजागर होते हैं और सेवाएं रुक जाती हैं — जैसा NHS ने 2017 में सीखा जब WannaCry रैनसमवेयर हमला उन मशीनों में फैला जो ऐसा सॉफ़्टवेयर चला रही थीं जिसे अब पैच नहीं किया जा सकता था। वह व्यवधान एक चतुर, लक्षित हमला नहीं था; यह महत्वपूर्ण सिस्टमों में संचित तकनीकी ऋण का अनुमानित परिणाम था। इसलिए आर्किटेक्चर निर्णय सुरक्षा निर्णय हैं, चाहे कोई उन्हें उस तरह तैयार करे या नहीं।

वे समानता और विश्वास निर्णय भी हैं। विरासत सिस्टम जो डेटा साझा नहीं कर सकते सबसे जटिल रोगियों — जो कई सेवाओं को छूते हैं — को सबसे खंडित रिकॉर्ड के साथ छोड़ देते हैं। बंद प्लेटफ़ॉर्म जो आपको एक एकल आपूर्तिकर्ता में लॉक करते हैं वह पैसा निकाल लेते हैं जो देखभाल को वित्तपोषित कर सकता था। और जनता उचित रूप से अपेक्षा करती है कि NHS आधुनिक, सुरक्षित, अच्छी तरह से बनाए रखी गई प्रौद्योगिकी पर चले; उस अपेक्षा और वास्तविक संपत्ति के बीच का अंतर स्वयं विश्वास के लिए एक जोखिम है।

अंत में, यही वह जगह है जहां बहुत सारा सार्वजनिक धन बहुत लंबे समय के लिए प्रतिबद्ध किया जाता है। एक सिस्टम का सबसे महंगा हिस्सा शायद ही कभी इसकी खरीद है; यह होस्टिंग, लाइसेंसिंग, रखरखाव, और अंतिम प्रतिस्थापन का दशक है जो अनुसरण करता है। जो नेता आर्किटेक्चर को "कुछ ऐसा जो तकनीकी टीम संभालती है" मानते हैं वे संगठन द्वारा किए गए सबसे बड़े और सबसे लंबे समय तक चलने वाले वित्तीय प्रतिबद्धताओं में से कुछ को सौंप रहे हैं। यह विषय इस तरह लिखा गया है ताकि आप एक इंजीनियर हुए बिना उन निर्णयों को जवाबदेह ठहरा सकें।

मुख्य अवधारणाएं#

एंटरप्राइज़ आर्किटेक्चर एक संगठन की व्यावसायिक प्रक्रियाओं, जानकारी, अनुप्रयोगों, और प्रौद्योगिकी को संरेखित करने का अनुशासन है ताकि वे संयोग से बढ़ने के बजाय सुसंगत रूप से रणनीति का समर्थन करें। यह पूरे-संगठन दृश्य लेता है: आपको किन क्षमताओं की आवश्यकता है, कौन से सिस्टम उन्हें प्रदान करते हैं, और अंतराल और दोहराव कहां हैं। समाधान आर्किटेक्चर यह डिज़ाइन करने का संकीर्ण, परियोजना-स्तरीय अनुशासन है कि एक विशिष्ट सेवा कैसे बनाई जाएगी और व्यापक संपत्ति में कैसे फिट होगी। दोनों सिस्टम आर्किटेक्चर के व्यापक विचार के भीतर बैठते हैं — यह संरचनात्मक मॉडल कि घटक, इंटरफ़ेस, और व्यवहार एक कामकाजी संपूर्ण में कैसे संयोजित होते हैं। नेताओं को इन अनुशासनों का अभ्यास करने की आवश्यकता नहीं है, लेकिन उन्हें यह सुनिश्चित करना चाहिए कि वे मौजूद हैं, क्योंकि उनकी अनुपस्थिति ही है कि कैसे संपत्तियां अप्रबंधनीय बन जाती हैं।

आर्किटेक्चर आर्किटेक्चर सिद्धांतों द्वारा निर्देशित होता है: बयानों का एक छोटा, सहमत समूह — जैसे "खरीदने से पहले पुनः उपयोग करें, बनाने से पहले खरीदें" या "खुले मानकों के अनुसार बनाएं" — जो हर विकल्प को बढ़ाए बिना सुसंगत निर्णय संभव बनाते हैं। सिद्धांत हल्के ढंग से, एक डिज़ाइन प्राधिकरण द्वारा लागू किए जाते हैं: एक छोटा समूह जो महत्वपूर्ण तकनीकी निर्णयों की समीक्षा करता है। एक डिज़ाइन प्राधिकरण का स्वस्थ संस्करण अवरुद्ध करने के बजाय सक्षम बनाता है; यह बचने योग्य नुकसान और दोहराव को रोकने के लिए मौजूद है, टीमों को धीमा करने या अपने लिए गेटकीप करने के लिए नहीं।

क्लाउड कंप्यूटिंग कंप्यूटिंग — सर्वर, स्टोरेज, डेटाबेस, नेटवर्किंग — को अपनी खुद की इमारत में स्वामित्व वाले हार्डवेयर के बजाय इंटरनेट पर एक ऑन-डिमांड सेवा के रूप में देना है। एक सार्वजनिक क्लाउड एक तीसरे-पक्ष प्रदाता द्वारा चलाया जाता है और कई ग्राहकों में साझा किया जाता है; एक निजी क्लाउड एक संगठन के लिए समर्पित है; एक हाइब्रिड क्लाउड दोनों को जोड़ता है, अक्सर कुछ कार्यभार को मौजूदा बुनियादी ढांचे पर रखते हुए दूसरों को बाहर ले जाना। यूके सहित कई सरकारों ने एक "क्लाउड-पहले" नीति अपनाई है, जिसका अर्थ है कि टीमों को अन्य विकल्पों से पहले सार्वजनिक क्लाउड पर विचार करना चाहिए और इसका उपयोग न करने को उचित ठहराना चाहिए। क्योंकि क्लाउड को एक बार खरीदने के बजाय खपत द्वारा बिल किया जाता है, उस खर्च को नियंत्रित करना अपना खुद का अनुशासन बन गया है — FinOps, इंजीनियरिंग और वित्त को एक साथ लाने का अभ्यास ताकि टीमों को उनके क्लाउड उपयोग की वास्तविक लागत की दृश्यता और जवाबदेही हो। एप्लिकेशन परत पर, software as a service (SaaS) वेब पर एक तैयार एप्लिकेशन देता है जिसे आपूर्तिकर्ता होस्ट और बनाए रखता है, इसलिए आप इसे चलाने के बजाय इसे कॉन्फ़िगर करते हैं। बुनियादी ढांचा और होस्टिंग — आपके सिस्टम भौतिक रूप से कहां और कैसे चलते हैं — इस सबके नीचे बैठते हैं, और तेज़ी से एक कार्बन लागत उठाते हैं जो निर्णय का हिस्सा है (देखें विषय 8.5 — स्थिरता और नेट ज़ीरो)।

एक विरासत सिस्टम एक पुराना लेकिन अभी भी निर्भर सिस्टम है जिसे बदलना कठिन है, अक्सर असमर्थित सॉफ़्टवेयर चलाता है जिसके लिए सुरक्षा पैच अब जारी नहीं किए जाते। विरासत तकनीकी ऋण के रूप में जमा होती है — अतीत में किए गए सुविधाजनक विकल्पों की भविष्य की लागत। थोड़ा ऋण सामान्य और यहां तक कि समझदार है; पैमाने पर अप्रबंधित ऋण एक सुरक्षा और सुरक्षा दायित्व बन जाता है, क्योंकि जिन सिस्टमों पर अधिकांश लोग निर्भर करते हैं वे वे सिस्टम बन जाते हैं जिन्हें कोई छूने की हिम्मत नहीं करता। इसे प्रबंधित करना एप्लिकेशन पोर्टफोलियो प्रबंधन का काम है: हर एप्लिकेशन, इसकी लागत, स्थिति, और व्यावसायिक मूल्य की एक स्पष्ट सूची रखना, ताकि आप संपत्ति को तर्कसंगत बना सकें — सिस्टमों को रिटायर करना, बदलना, या समेकित करना — और पुरानी चीज़ को चुपचाप चलते रहने देने के बजाय सुरक्षित रूप से बंद करना।

आधुनिक संपत्तियां application programming interfaces (APIs) द्वारा एक साथ रखी जाती हैं: परिभाषित इंटरफ़ेस जिनके माध्यम से एक सिस्टम दूसरे को एक क्षमता प्रदान करता है। अच्छी तरह से डिज़ाइन किए गए API आपको प्लेटफ़ॉर्म — पुनः उपयोग करने योग्य सेवाएं जिन पर कई टीमें बनती हैं — इकट्ठा करने देते हैं जबकि घटकों को ढीले-युग्मित और प्रतिस्थापन योग्य रखते हुए। यहां एक उपयोगी अनुशासन "सबसे पतला व्यावहार्य प्लेटफ़ॉर्म" है: केवल वह साझा क्षमता बनाएं जो वास्तव में दूसरों का काम कम करती है, इससे अधिक नहीं। सुरक्षित डिज़ाइन को आधार देना डिज़ाइन द्वारा सुरक्षित है, यह सिद्धांत कि सुरक्षा शुरुआत से बनाई जाती है, बाद में जोड़ी नहीं जाती। और इस सबका वित्तीय ढांचा स्वामित्व की कुल लागत (TCO) है: एक सिस्टम की पूरी जीवनकाल लागत, इसकी खरीद कीमत नहीं — वह लेंस जिसके माध्यम से बनाएं/खरीदें/कॉन्फ़िगर विकल्प, और आपूर्तिकर्ता लॉक-इन के जोखिम का न्याय किया जाना चाहिए।

सर्वोत्तम प्रथाएं#

1. आर्किटेक्चर सिद्धांतों का एक छोटा समूह सहमत करें और उनका उपयोग निर्णय लेने के लिए करें। कुछ स्पष्ट, याद रखने योग्य सिद्धांत लिखें — बनाने से पहले खरीदने से पहले पुनः उपयोग करें, खुले मानकों के अनुसार बनाएं, जहां समझ आए वहां क्लाउड, डिज़ाइन द्वारा सुरक्षित, पूरे देखभाल मार्ग के लिए डिज़ाइन करें — और टीमों को उन्हें लागू करके अधिकांश निर्णय स्वयं लेने दें। सिद्धांत केवल तभी काम करते हैं जब उनका वास्तव में हां और नहीं कहने के लिए उपयोग किया जाता है, और केवल तभी जब याद रखने के लिए पर्याप्त कम हों। यह सीधे विषय 1.1 — संचालन मॉडल और विषय 1.2 — डिजिटल रणनीति और रोडमैपिंग से जुड़ता है, जो वह दिशा निर्धारित करते हैं जिसकी सिद्धांत सेवा करते हैं।

2. एक डिज़ाइन प्राधिकरण चलाएं जो अवरुद्ध करने के बजाय सक्षम बनाता है। महत्वपूर्ण तकनीकी निर्णयों की समीक्षा करने के लिए एक छोटा, वरिष्ठ, क्रॉस-अनुशासनात्मक समूह स्थापित करें — जो महंगे, उलटने में कठिन, कई सेवाओं को प्रभावित करने वाले, या सुरक्षा और सुरक्षा जोखिम उठाने वाले हैं। इसे एक तेज़, हल्का मार्ग दें ताकि नियमित विकल्पों को इसके माध्यम से न घसीटा जाए, और इसे एक सेवा मानक तक रखें: इसे टीमों को एक अच्छा उत्तर खोजने में मदद करनी चाहिए, केवल मना नहीं करना चाहिए। एक डिज़ाइन प्राधिकरण जो एक अड़चन बन जाता है उसके आसपास रूट किया जाएगा, और शैडो आर्किटेक्चर किसी से भी बदतर है।

3. क्लाउड को सोच-समझकर अपनाएं, कार्यभार दर कार्यभार, एक नारे के रूप में नहीं। "क्लाउड-पहले" को तर्क करने योग्य डिफ़ॉल्ट मानें, सब कुछ स्थानांतरित करने का निर्देश नहीं। उपयुक्तता, डेटा निवास, लचीलापन, पैमाने पर लागत, और माइग्रेट करने के प्रयास के लिए हर कार्यभार का आकलन करें, और ईमानदार रहें कि एक अपरिवर्तित विरासत एप्लिकेशन का लिफ्ट-एंड-शिफ्ट अक्सर बस समस्या को उच्च लागत पर स्थानांतरित करता है। कार्बन आयाम को स्पष्ट रूप से तौलें, क्योंकि आप कहां और कैसे होस्ट करते हैं उत्सर्जन को प्रभावित करता है (देखें विषय 8.5 — स्थिरता और नेट ज़ीरो), और पोर्टेबिलिटी के लिए डिज़ाइन करें ताकि प्रदाताओं के बीच एक भविष्य का बदलाव संभव रहे।

4. एक लाइव एप्लिकेशन पोर्टफोलियो बनाए रखें और तकनीकी ऋण को एक नामित जोखिम के रूप में प्रबंधित करें। हर एप्लिकेशन, इसके व्यावसायिक स्वामी, लागत, समर्थन-योग्यता, और इसके द्वारा उठाए गए जोखिम की एक सटीक सूची रखें, और इसे नियमित रूप से समीक्षा करें। तकनीकी ऋण और असमर्थित सॉफ़्टवेयर को क्लिनिकल या वित्तीय जोखिम के समान गंभीरता के साथ कॉर्पोरेट जोखिम रजिस्टर पर रखें, क्योंकि यह वही है। जो आप नहीं देख सकते, आप उसे वित्तपोषित, प्राथमिकता, या सुरक्षित रूप से रिटायर नहीं कर सकते, और जो संपत्तियां कभी सूचीबद्ध नहीं की जातीं वे ठीक वही हैं जो बिना चेतावनी के विफल होती हैं।

5. संपत्ति को तर्कसंगत बनाएं और सुरक्षित रूप से बंद करें। दोहराए गए, अप्रचलित, और जीवन-अंत सिस्टमों को "बस मामले में" बने रहने देने के बजाय सक्रिय रूप से रिटायर करें, क्योंकि हर लाइव सिस्टम एक हमला सतह, एक लाइसेंस लागत, और एक रखरखाव भार है। बंद करना अपने आप में एक परियोजना है: स्पष्ट प्रतिधारण नियमों के तहत डेटा माइग्रेट या संग्रहीत करें, पुष्टि करें कि कुछ भी अब सिस्टम पर निर्भर नहीं करता, उपयोगकर्ताओं से संवाद करें, और बंद करने से पहले सत्यापित करें। अच्छी तरह से किया गया, तर्कसंगतीकरण पैसा मुक्त करता है और जोखिम कम करता है; लापरवाही से किया गया, यह रिकॉर्ड नष्ट करता है या एक निर्भरता तोड़ता है जिसे किसी ने दस्तावेज़ीकृत नहीं किया।

6. खुले मानकों, API, और ढीले-युग्मित घटकों को प्राथमिकता दें। इस तरह डिज़ाइन करें कि क्षमताएं दस्तावेज़ीकृत, संस्करणित API के माध्यम से उजागर हों, ताकि एक घटक को इसके चारों ओर सब कुछ फिर से बनाए बिना बदला जा सके। यह विषय 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 और डेटा-निष्कर्षण अधिकारों के साथ ताकि ट्रस्ट फिर से लॉक न हो। उपयुक्त कार्यभार सार्वजनिक क्लाउड में जाते हैं, नारे के बजाय एक समय में एक का आकलन किया गया, लागत के साथ-साथ कार्बन और पोर्टेबिलिटी को तौला गया। एक छोटा डिज़ाइन प्राधिकरण महत्वपूर्ण निर्णयों की समीक्षा करता है और नियमित लोगों को जल्दी साफ़ करता है। बारह ओवरलैपिंग विभागीय एप्लिकेशन तीन में समेकित किए जाते हैं, और रिटायर किए गए सिस्टम ठीक से बंद किए जाते हैं — स्पष्ट प्रतिधारण नियमों के तहत डेटा माइग्रेट किया गया, निर्भरताएं जांची गईं, उपयोगकर्ताओं को बताया गया, और तभी बंद किया गया।

इनमें से कुछ भी हेडलाइन नहीं बनाता। लेकिन अठारह महीने बाद, ट्रस्ट जानता है कि यह क्या चलाता है, इसका सबसे खतरनाक ऋण आशा किए जाने के बजाय एक वित्तपोषित योजना पर चुकाया जा रहा है, और एक नया साझा देखभाल रिकॉर्ड एकीकरण हफ्तों में दिया जाता है क्योंकि प्रतिस्थापन सिस्टम खुले API उजागर करते हैं। निकट-चूक वह क्षण बन गया जब ट्रस्ट ने इसके द्वारा प्रबंधित होने के बजाय अपने आर्किटेक्चर को प्रबंधित करना शुरू किया।

क्षेत्र दृष्टिकोण#

स्टार्टअप#

एक डिजिटल स्वास्थ्य स्टार्टअप के पास कम विरासत की विलासिता है और इसे कठोरता से बचाना चाहिए। शुरू से क्लाउड-नेटिव बनाएं, खुले API उजागर करें, और डिज़ाइन-द्वारा-सुरक्षित को बाद की लागत के बजाय एक मुख्य सुविधा मानें, क्योंकि सावधान NHS खरीदार आपकी सुरक्षा आर्किटेक्चर और डेटा-निष्कर्षण शर्तों की बारीकी से जांच करेंगे। अपने खुद के सबसे पतले व्यावहार्य प्लेटफ़ॉर्म को वास्तव में पतला रखें, उस पैमाने के लिए अत्यधिक-इंजीनियर करने के प्रलोभन का विरोध करते हुए जो आपके पास अभी तक नहीं है। पंगु बनाने वाला तकनीकी ऋण जमा करने का आपका सबसे तेज़ मार्ग निवेशक दबाव में सुविधाजनक कोड शिप करना और इसे कभी वापस न चुकाना है, इसलिए आप कौन सा ऋण लेते हैं इसके बारे में सोच-समझकर, दृश्यमान विकल्प बनाएं। विरोधाभासी रूप से, इस तरह डिज़ाइन करना कि एक ग्राहक अपना डेटा निकाल सके और जा सके ही वह है जो उस विश्वास को अर्जित करता है जो उन्हें बनाए रखता है।

छोटा व्यवसाय#

एक स्थापित छोटा प्रदाता — एक GP प्रैक्टिस, एक सामुदायिक फार्मेसी, एक केयर होम, एक एकल-साइट क्लिनिक, या स्टार्टअप चरण से आगे एक छोटा स्वास्थ्य-तकनीक आपूर्तिकर्ता — एक बड़े ट्रस्ट के समान कर्तव्य उठाता है लेकिन संसाधनों के एक अंश के साथ और शायद ही कभी किसी समर्पित IT क्षमता के साथ। यहां आर्किटेक्चर काफी हद तक अच्छी तरह से खरीदने का अनुशासन है: प्रतिष्ठित software-as-a-service को प्राथमिकता दें ताकि आपूर्तिकर्ता होस्टिंग, पैचिंग, और सुरक्षा उठाए जिसे आप खुद स्टाफ नहीं कर सकते, और हस्ताक्षर करने से पहले डेटा-निष्कर्षण और निकास अधिकारों के लिए अनुबंध पढ़ें, क्योंकि लॉक-इन सबसे कठोरता से काटता है जब आपके पास कोई लाभ नहीं है। उन कुछ सिस्टमों की एक सरल सूची रखें जिन पर आप निर्भर करते हैं और जानें कौन से अभी भी समर्थित हैं, क्योंकि एक छोटी संपत्ति भी एक बिना-पैच मशीन छुपा सकती है जो प्रैक्टिस को रोकती है। इस बात पर ज़ोर दें कि आपूर्तिकर्ता शुरू से सुरक्षा का आकलन करने की कोशिश करने के बजाय Data Security and Protection Toolkit जैसे मान्यता प्राप्त मानकों को पूरा करें। जब नकदी तंग होती है तो प्रलोभन एक बिल से बचने के लिए एक पुराने, असमर्थित सिस्टम को चलते रहने देना है, लेकिन यह एक सुरक्षा निर्णय है जो आपको बहाव से नहीं, सोच-समझकर लेना चाहिए।

बड़ा संगठन#

एक बड़ा ट्रस्ट या आपूर्तिकर्ता दशकों के संचित सिस्टम उठाता है और बस फिर से शुरू नहीं कर सकता। यथार्थवादी रणनीति अनुशासित विकास है: एक लाइव पोर्टफोलियो बनाए रखें, जो बना रहना चाहिए उसके सामने खुली, API-आधारित परतें रखें, और कभी-कभार होने वाली घबराहटों के बजाय एक वित्तपोषित, प्राथमिकता वाली योजना पर सबसे खतरनाक ऋण चुकाएं। एक डिज़ाइन प्राधिकरण चलाएं जिसका सम्मान किया जाता है क्योंकि यह डिलीवरी सक्षम बनाता है, नहीं डरा हुआ क्योंकि यह इसे अवरुद्ध करता है, और तकनीकी ऋण को एक नामित स्वामी के साथ एक स्थायी बोर्ड-स्तरीय जोखिम बनाएं। हर नवीनीकरण पर लॉक-इन के विरुद्ध रक्षा करें, और बंद करने को एक वास्तविक, संसाधित काम के रूप में मानें बाद के विचार के रूप में नहीं। यह वही पुनः उपयोग-और-खुला-इंटरफ़ेस अनुशासन है जो विषय 5.4 — Enterprise Resource Planning (ERP) में मुख्य परिचालन प्लेटफ़ॉर्म को नियंत्रित करता है।

सरकार#

राष्ट्रीय और क्षेत्रीय निकाय वे स्थितियां निर्धारित करते हैं जिनमें पूरा क्षेत्र संचालित होता है, और उनके आर्किटेक्चर विकल्प बाहर की ओर तरंगें फैलाते हैं। सबसे मूल्यवान चीज़ें जो सरकार कर सकती है वे खुले मानक अनिवार्य करना, पुनः उपयोग करने योग्य राष्ट्रीय प्लेटफ़ॉर्म प्रदान करना ताकि स्थानीय संगठन एक बार बनाएं, और क्लाउड, सुरक्षा, और स्थिरता अपेक्षाएं निर्धारित करना है जो हर जगह फर्श उठाती हैं। महत्वपूर्ण रूप से, सरकार को अनाकर्षक राष्ट्रीय काम वित्तपोषित करना चाहिए — विरासत उपचार, शब्दावली रखरखाव, बंद करने का समर्थन — जिसे कोई एक संगठन अकेले वित्तपोषित नहीं करेगा लेकिन जिस पर हर कोई निर्भर करता है। एक दृढ़ता से लागू, पर्याप्त-अच्छा मानक जो व्यापक रूप से पुनः उपयोग किया जाता है असंगत रूप से लागू किए गए एक सैद्धांतिक रूप से बेहतर मानक को हराता है। यह प्रबंधन भूमिका विषय 9.1 — स्थानीय और राष्ट्रीय सरकारों के साथ काम करना और विषय 9.0 — साझेदार संगठनों के साथ सहयोग में साझेदार कैसे सहयोग करते हैं से जुड़ती है।

सामान्य विफलता मोड#

• अदृश्य संपत्ति। बिना सटीक सूची के सैकड़ों एप्लिकेशन चलाना, इसलिए जोखिम अज्ञात है, दोहराव अनदेखा है, और नाजुकता का पहला संकेत एक आउटेज या एक उल्लंघन है।
• बोर्ड से छिपाया गया ऋण। असमर्थित सॉफ़्टवेयर और तकनीकी ऋण को एक नामित कॉर्पोरेट जोखिम के बजाय एक तकनीकी फुटनोट के रूप में रखना, इसलिए यह विफल होने तक कभी वित्तपोषित नहीं होता।
• नारे के रूप में क्लाउड। सिद्धांत पर अपरिवर्तित विरासत को सार्वजनिक क्लाउड में उठाना और स्थानांतरित करना, समस्या को उच्च लागत पर स्थानांतरित करना, या डेटा और टूलिंग को एक प्रदाता में इतनी गहराई से उलझाना कि यह एक नया लॉक-इन बन जाता है।
• अड़चन के रूप में डिज़ाइन प्राधिकरण। आर्किटेक्चर प्रशासन को एक धीमा द्वार बनने देना जिसके आसपास टीमें रूट करती हैं, अदस्तावेज़ीकृत शैडो आर्किटेक्चर उत्पन्न करते हुए जो किसी से भी बदतर है।
• बनाएं जब आपको कॉन्फ़िगर करना चाहिए। स्वामित्व की कुल लागत के बजाय स्टिकर कीमत पर सामान्य वस्तु आवश्यकताओं के लिए कस्टम निर्माण चुनना, और एक दशक का रखरखाव विरासत में लेना जिसका आपने बजट नहीं बनाया।
• कभी बंद न करना। "बस मामले में" अप्रचलित सिस्टमों को चलते रहने देना, हर एक एक हमला सतह, एक लाइसेंस लागत, और एक रखरखाव खपत है जिसका कोई स्वामी नहीं है।
• जोड़ी गई सुरक्षा। सुरक्षा को एक डिज़ाइन इनपुट के बजाय एक लॉन्च-पूर्व द्वार मानना, इसलिए हमला सतह किसी के इसका आकलन करने से बहुत पहले सेट हो जाती है।
• डिफ़ॉल्ट रूप से लॉक-इन। बिना खुले इंटरफ़ेस या डेटा-निष्कर्षण अधिकारों के प्लेटफ़ॉर्म पर हस्ताक्षर करना, और जाल की कीमत केवल तब खोजना जब आप छोड़ने की कोशिश करते हैं।

परिपक्वता मॉडल#

जांच-सूची#

• एक लाइव एप्लिकेशन पोर्टफोलियो हर सिस्टम के स्वामी, लागत, समर्थन-योग्यता, और जोखिम को रिकॉर्ड करता है, और नियमित रूप से समीक्षित होता है।
• असमर्थित और अनपैच करने योग्य महत्वपूर्ण सिस्टम पहचाने गए हैं और कॉर्पोरेट जोखिम रजिस्टर पर बैठे हैं, किसी तकनीकी स्प्रेडशीट में नहीं।
• आर्किटेक्चर सिद्धांतों का एक छोटा, सहमत समूह वास्तव में निर्णय लेने और उचित ठहराने के लिए उपयोग किया जाता है।
• एक डिज़ाइन प्राधिकरण महत्वपूर्ण, उलटने में कठिन निर्णयों की समीक्षा करता है और नियमित लोगों को जल्दी साफ़ करता है, अवरुद्ध करने के बजाय सक्षम बनाता है।
• क्लाउड अपनाना कार्यभार दर कार्यभार आकलित किया जाता है, निवास, लचीलापन, लागत, पोर्टेबिलिटी, और कार्बन को तौलते हुए।
• तकनीकी ऋण का एक नामित स्वामी और एक वित्तपोषित उपचार योजना है, केवल कभी-कभार आग बुझाना नहीं।
• दोहराए गए और अप्रचलित सिस्टमों को तर्कसंगत बनाया जाता है, और बंद करने को डेटा माइग्रेशन, प्रतिधारण, और निर्भरता जांच के साथ संसाधित किया जाता है।
• नई क्षमताएं खुले, संस्करणित API उजागर करती हैं ताकि घटकों को उनके चारों ओर फिर से बनाए बिना बदला जा सके।
• सुरक्षा शुरुआत से डिज़ाइन की गई है — न्यूनतम हमला सतह, न्यूनतम विशेषाधिकार, विभाजन — लॉन्च से पहले जोड़ी नहीं गई।
• बनाएं/खरीदें/कॉन्फ़िगर निर्णय स्वामित्व की कुल लागत और लॉक-इन पर लिए जाते हैं, हस्ताक्षर करने से पहले निकास और डेटा-निष्कर्षण अधिकार सुरक्षित किए गए।

मुख्य स्रोत#

• NHS England — क्लाउड रणनीति, प्रौद्योगिकी मानक, और Data Security and Protection Toolkit।
• National Cyber Security Centre (NCSC) — सुरक्षित डिज़ाइन सिद्धांत और क्लाउड सुरक्षा मार्गदर्शन।
• UK Government (GDS/CDDO) — Technology Code of Practice और क्लाउड-पहले नीति।
• National Audit Office — NHS विरासत सिस्टमों, WannaCry हमले, और IT-सक्षम कार्यक्रमों पर रिपोर्ट।
• The Open Group — TOGAF, एंटरप्राइज़ आर्किटेक्चर ढांचा।
• Government Digital Service — 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