Technology & Infrastructure Architecture
टेक्नोलॉजी और इन्फ्रास्ट्रक्चर आर्किटेक्चर वह परत है जिस पर अधिकांश लोगों का ध्यान केवल तभी जाता है जब यह विफल होती है, और इसे प्रायः ऐसी बुनियादी व्यवस्था मान लिया जाता है जिसे न्यूनतम रखा जाए और आउटसोर्स कर दिया जाए। यह दृष्टिकोण महंगा पड़ता है, क्योंकि इन्फ्रास्ट्रक्चर की नींव उसके ऊपर की हर चीज़ के लिए सीमा-रेखा तय करती है: एप्लिकेशन जो लेटेंसी हासिल कर सकते हैं, जिन विफलता-स्थितियों में वे टिके रहते हैं, बदलाव की गति और यूनिट-अर्थशास्त्र, ये सब यहीं निर्धारित होते हैं। जब इसे एक प्रथम-श्रेणी की डिज़ाइन अनुशासन के रूप में लिया जाता है, तो यह एक ऐसी परिसंपत्ति बन जाती है जिसका मूल्य समय के साथ बढ़ता जाता है। जब इसे अनकहा छोड़ दिया जाता है, तो यही वह कारण बनती है जिसकी वजह से आर्किटेक्चर का हर दूसरा प्रयास चुपचाप ठहर जाता है।
नींव अब अड़चन क्यों बन गई है
पिछले लगभग दो दशकों तक, इन्फ्रास्ट्रक्चर एक धीमी गति से बदलने वाला आधार था जिसे एप्लिकेशन टीमें बड़े हद तक मान कर चल सकती थीं। सर्वर हफ्तों में प्रावधानित होते थे, क्षमता माँग से पहले खरीद ली जाती थी, और नेटवर्क एक विशेषज्ञ टीम द्वारा अनुरक्षित एक स्थिर टोपोलॉजी होता था। व्यवसाय में बदलाव की गति इतनी कम थी कि यह व्यवस्था टिकी रही। अब ऐसा नहीं है। संगठन अब हर सप्ताह उत्पाद-बदलाव जारी करने, मौसमी उभार के लिए किसी सेवा को दस गुना स्केल करने, और ऐसे क्षेत्रीय पदचिह्न के साथ नए बाज़ार में प्रवेश करने की अपेक्षा रखते हैं जो स्थानीय डेटा-निवास नियमों को पूरा करता हो। इन सभी अपेक्षाओं का अंतिम भार, अंततः, इन्फ्रास्ट्रक्चर परत पर ही आता है।
साथ ही, यह पूरा तंत्र वास्तव में विषमांगी हो गया है। बड़े पैमाने का लगभग कोई भी एंटरप्राइज़ किसी एकल एनवायरनमेंट पर नहीं चलता। सार्वजनिक cloud है, प्रायः अधिग्रहण या सुविचारित रणनीति के कारण एक से अधिक प्रदाताओं वाला। एक निजी तंत्र है जो इसलिए समाप्त नहीं हुआ क्योंकि कोई मेनफ्रेम, कोई विशेष उपकरण या डेटा-गुरुत्व की कोई बाध्यता उसे यथास्थान बनाए रखती है। शाखा-स्थलों, कारखानों और उपकरणों का एक विस्तृत होता एज है। दिलचस्प आर्किटेक्चरल प्रश्न अब इनमें से किसी एक एनवायरनमेंट के भीतर नहीं, बल्कि उनके बीच की जोड़ों में हैं: वर्कलोड कहाँ रखे जाएँ, पहचान और नेटवर्क का विश्वास सीमा के आर-पार कैसे फैले, और एक सुसंगत परिचालन-मॉडल इस विभाजन में कैसे बचा रहे।
दो शक्तियाँ इसे केवल महत्वपूर्ण से आगे बढ़ाकर अनिवार्य बना देती हैं। पहली है लागत। Cloud पर व्यय टेक्नोलॉजी बजट की सबसे बड़ी और सबसे कम समझी जाने वाली मदों में से एक बन गया है, और जिस लचीलेपन को बचत के रूप में बेचा गया था, वह अक्सर एक रिसाव बन जाता है जब कोई भी उसके अर्थशास्त्र का स्वामी नहीं होता। दूसरी है विनियमन और सुदृढ़ता की अपेक्षा। यूरोपीय वित्तीय क्षेत्र में DORA जैसे ढाँचों ने परिचालन-सुदृढ़ता और तृतीय-पक्ष संकेंद्रण जोखिम को वास्तविक परिणामों वाली बोर्ड-स्तरीय बाध्यताओं में बदल दिया है। दोनों शक्तियाँ स्वभाव से आर्किटेक्चरल हैं। इनमें से कोई भी बेहतर उत्पाद खरीदने से हल नहीं होती। ये तभी हल होती हैं जब टेक्नोलॉजी आधार किस प्रकार बनाया, रखा और संचालित किया जाए, इसके लिए सुविचारित मानक हों, जो ठीक इसी अनुशासन का दायरा है।
टेक्नोलॉजी आधार के मूल सिद्धांत
इन्फ्रास्ट्रक्चर आर्किटेक्चर के बारे में तर्क करने का एक उपयोगी तरीका यह है कि इसे उत्पादों की सूची के बजाय तलों (प्लेन) के एक ढेर के रूप में देखा जाए, जहाँ हर तल की अपनी गारंटियाँ हों। सबसे नीचे नींव है: भौतिक और आभासी स्थान, cloud क्षेत्र और उपलब्धता-क्षेत्र, ऑन-प्रिमाइज़ डेटा सेंटर, और वह कनेक्टिविटी जो इन्हें बाँधती है। इसके ऊपर कंप्यूट, स्टोरेज और नेटवर्क का संसाधन-तल है, जो हार्डवेयर के बजाय अधिकाधिक अमूर्तनों के रूप में व्यक्त होता है। उसके ऊपर प्लेटफ़ॉर्म-तल है जहाँ ये संसाधन रनटाइम में संयोजित किए जाते हैं: container ऑर्केस्ट्रेशन, प्रबंधित डेटा सेवाएँ, मैसेजिंग और एकीकरण-फ़ैब्रिक। आपके व्यवसाय के लिए जो एप्लिकेशन और सेवाएँ मायने रखती हैं, वे सबसे ऊपर चलती हैं, और उन गारंटियों का उपभोग करती हैं जिन्हें उन्हें कभी स्वयं जोड़ना नहीं पड़ना चाहिए।
मूल सिद्धांत यह है कि हर तल को अपने ऊपर वाले तल के समक्ष एक छोटा, स्थिर अनुबंध प्रस्तुत करना चाहिए और नीचे की क्रियाविधि को छिपाना चाहिए। एक एप्लिकेशन टीम को यह जाने बिना कि कौन-सी स्टोरेज टेक्नोलॉजी इसे पूरा करती है, एक ऐसा टिकाऊ, एन्क्रिप्टेड, बैकअप-युक्त डेटास्टोर माँगने में सक्षम होना चाहिए जिसका पुनर्प्राप्ति-लक्ष्य निर्धारित हो। यही वह चीज़ है जो आधार को प्रतिस्थापन-योग्य बनाती है: जब अनुबंध स्पष्ट होता है, तो कार्यान्वयन बिना पुनर्कार्य की शृंखला के बदला जा सकता है। जब यह अनकहा होता है, तो नीचे का हर चुनाव ऊपर की ओर रिस जाता है और पूरा तंत्र जड़ हो जाता है।
तीन अनुप्रस्थ सरोकार हर तल में लंबवत रूप से चलते हैं और आरंभ से ही उन्हें बाद में जोड़ने के बजाय प्रथम-श्रेणी मानकर व्यवहार करना चाहिए। पहचान ही असली परिधि है: वर्कलोड, मनुष्य और सेवाएँ, सभी को नेटवर्क टोपोलॉजी का कोई अर्थ होने से पहले सत्यापन-योग्य पहचान की आवश्यकता होती है। ऑब्ज़र्वेबिलिटी वह गुण है जो आपको ऐसी प्रणाली के बारे में तर्क करने देता है जिसे बनते हुए आपने नहीं देखा, और इसे एजेंट के रूप में बाद में जोड़ने के बजाय टेलीमेट्री अनुबंधों के रूप में डिज़ाइन में ही समाहित करना चाहिए। अर्थशास्त्र वह अनुशासन है जो लागत को उसी वस्तु से जोड़ता है जिसने उसे उत्पन्न किया, ताकि कोई डिज़ाइन निर्णय और उसका वित्तीय परिणाम एक ही व्यक्ति को दिखाई दे। जो टेक्नोलॉजी आधार पहचान, ऑब्ज़र्वेबिलिटी और लागत को बाद की सोच मानता है, वह कागज़ पर सुदृढ़ और व्यवहार में नाज़ुक होगा।
अंत में, यहाँ हर चीज़ को टिकटों और मौखिक ज्ञान के बजाय कोड और संदर्भ-पैटर्न के रूप में व्यक्त किया जाना चाहिए। इन्फ्रास्ट्रक्चर एज़ कोड कोई टूलिंग की पसंद नहीं है। यह वह क्रियाविधि है जो आर्किटेक्चर को ऐसी चीज़ में बदल देती है जिसकी समीक्षा, संस्करण-नियंत्रण, परीक्षण और पुनरुत्पादन किया जा सके। जो मानक केवल किसी दस्तावेज़ में मौजूद है, वह एक सुझाव है। जो मानक एक पुन:प्रयोज्य मॉड्यूल के रूप में कूटबद्ध है और जिसे टीमें आरंभित करती हैं, वह एक आर्किटेक्चर है।
तंत्र में क्या बदल रहा है
कई घटनाक्रम इस बात को नया आकार दे रहे हैं कि टेक्नोलॉजी आधार को कैसे डिज़ाइन किया जाए, और टिकाऊ बदलावों को शोर से अलग करना उपयोगी है। सबसे स्पष्ट टिकाऊ बदलाव यह है कि हाइब्रिड और मल्टी-cloud तंत्र अब किसी प्रवासन-चरण के बजाय एक स्थायी स्थिति के रूप में सामान्य बन गया है। उद्योग इस धारणा से आगे निकल आया है कि हर चीज़ अंततः किसी एक सार्वजनिक cloud में जा पहुँचती है। वर्कलोड को कहाँ रखा जाए, यह अब डेटा-गुरुत्व, लेटेंसी, संप्रभुता और लागत से संचालित एक स्पष्ट डिज़ाइन निर्णय बन गया है, जिससे उस आर्किटेक्चर का मूल्य बढ़ जाता है जो प्रति प्रदाता अलग-अलग परिचालन-मॉडल बनाए रखने के बजाय अनेक एनवायरनमेंट को एक साझा परिचालन-मॉडल से संभाल सके।
प्लेटफ़ॉर्म इंजीनियरिंग उस जटिलता का संगठनात्मक उत्तर है। हर एप्लिकेशन टीम से इन्फ्रास्ट्रक्चर परत की पूरी गहराई में महारत की अपेक्षा करने के बजाय, संगठन ऐसे आंतरिक प्लेटफ़ॉर्म बना रहे हैं जो प्रशस्त-पथ प्रस्तुत करते हैं: कंप्यूट, स्टोरेज, पाइपलाइन और एनवायरनमेंट प्राप्त करने के सुविचारित, स्व-सेवा तरीके जो पहले से ही सुरक्षा, सुदृढ़ता और लागत के मानकों को पूरा करते हैं। भली-भाँति किया जाए तो यह ऊपर वर्णित तल-अनुबंधों का परिचालनात्मक मूर्तरूप है। बुरी तरह किया जाए तो यह अनुरक्षण के लिए एक और परत बन जाता है जिसे कोई अपनाता नहीं।
संप्रभुता और नियामक-स्थानीयता किनारे के मामले से बढ़कर डिज़ाइन-चालक बन गई है, विशेषकर यूरोप में। डेटा भौतिक रूप से कहाँ रहता है, कौन-सी कानूनी इकाई कंट्रोल प्लेन का संचालन करती है, और क्या किसी वर्कलोड को विदेशी अधिकार-क्षेत्र से पृथक किया जा सकता है, यह प्रश्न अब एक वास्तविक आर्किटेक्चरल बाध्यता है जो क्षेत्र-रणनीति और प्रदाता-चयन को आकार देता है। यह सुदृढ़ता के एजेंडे से जुड़ता है: किसी एकल प्रदाता पर संकेंद्रण अब वह चीज़ है जिसके बारे में संगठनों को तर्क करने में, और कुछ मामलों में उसे सक्रिय रूप से कम करने में, सक्षम होना चाहिए।
संसाधन-तल पर, अमूर्तन निरंतर ऊपर उठते जा रहे हैं। सर्वरलेस और प्रबंधित सेवाएँ परिचालन-भार का अधिकांश हिस्सा प्रदाता की ओर धकेल देती हैं, जो तब तक आकर्षक है जब तक कि अमूर्तन रिस न जाए और आप पाएँ कि आपने परिचालन-श्रम को आर्किटेक्चरल लॉक-इन से बदल लिया है। मशीन लर्निंग और इन्फरेंस वर्कलोड से संचालित विशेष कंप्यूट की माँग में हालिया उछाल ने उन टीमों के लिए हार्डवेयर-विषमता और क्षमता-नियोजन को फिर से लौटा दिया है जो दोनों को सुखपूर्वक भुला बैठी थीं। इस सब में जो स्थिर सूत्र है वह यह है कि अमूर्तन अंतर्निहित सरोकार को कभी नहीं हटाता। यह उत्तरदायित्व का स्थान बदल देता है, और अच्छा आर्किटेक्चर इस बारे में सुविचारित होता है कि वह उत्तरदायित्व कहाँ रहना चाहिए।
वे डिज़ाइन सिद्धांत जो इसे टिकाए रखते हैं
एक सुदृढ़, प्रेक्षणीय और लागत-प्रभावी आधार किसी एक चतुर निर्णय का परिणाम नहीं होता। यह मुट्ठी भर सिद्धांतों को निरंतर लागू करने से उभरता है। पहला यह है कि विफलता को अपेक्षित स्थिति मानकर डिज़ाइन करें। बड़े पैमाने पर, घटक लगातार विफल होते हैं, और उपयोगी प्रश्न यह नहीं है कि विफलता को कैसे रोका जाए बल्कि यह कि उसके प्रभाव-दायरे को कैसे सीमित किया जाए। इसका अर्थ है स्पष्ट विफलता-क्षेत्र, ऐसी अतिरेकता जो उनमें फैली हो, और ऐसे पुनर्प्राप्ति-लक्ष्य जो प्रति वर्कलोड निर्धारित हों और मान लेने के बजाय वास्तव में परखे जाएँ। जो पुनर्प्राप्ति-योजना कभी अभ्यास में नहीं लाई गई, वह एक परिकल्पना है, कोई सामर्थ्य नहीं।
दूसरा सिद्धांत यह है कि इन्फ्रास्ट्रक्चर अपरिवर्तनीय और पुनरुत्पादनीय होना चाहिए। सर्वर और क्लस्टर को संस्करणित परिभाषाओं से बनाया जाना चाहिए और यथास्थान पैच करने के बजाय प्रतिस्थापित किया जाना चाहिए, ताकि चलता हुआ तंत्र सदैव किसी ऐसे विवरण से मेल खाए जिसका आप निरीक्षण कर सकें। कॉन्फ़िगरेशन ड्रिफ्ट, अर्थात इस बात के बीच धीमा विचलन कि आप क्या तैनात मानते हैं और वास्तव में क्या तैनात है, उत्पादन-घटनाओं के असंगत रूप से बड़े हिस्से का स्रोत है, और अपरिवर्तनीयता इसका संरचनात्मक उपचार है।
तीसरा सिद्धांत है अनुबंध द्वारा ऑब्ज़र्वेबिलिटी। हर सेवा को संकेतों, मेट्रिक्स, लॉग और ट्रेस का एक निर्धारित समुच्चय उत्सर्जित करना चाहिए, जो सुसंगत पहचानकर्ताओं द्वारा सहसंबद्ध हों, ताकि किसी घटना के बाद, आनन-फानन में इंस्ट्रुमेंटेशन किए बिना, प्रश्नों के उत्तर दिए जा सकें। लक्ष्य ऐसे व्यवहार के बारे में तर्क कर पाना है जिसकी आपने अपेक्षा नहीं की थी, जो ज्ञात स्थितियों के एक निश्चित समुच्चय की निगरानी करने की तुलना में एक प्रबल गुण है।
चौथा है न्यूनतम विशेषाधिकार और पहचान-केंद्रित विश्वास। किसी वितरित तंत्र में विश्वास के लिए नेटवर्क-स्थान एक कमज़ोर आधार है। पहुँच को सत्यापित वर्कलोड और उपयोगकर्ता की पहचान का अनुसरण करना चाहिए, ऐसे विभाजन के साथ जो यह मान ले कि परिधि पहले ही लाँघी जा चुकी है। पाँचवाँ है लागत-सचेत डिज़ाइन, जहाँ वित्तीय प्रभाव किसी मासिक आश्चर्य के बजाय किसी आर्किटेक्चर निर्णय का दृश्यमान गुण हो, और इतनी स्वच्छता से आरोपित हो कि चुनाव करने वाली टीम उसके परिणाम को देख सके। मिलकर ये सिद्धांत ऐसे आधार का पक्ष लेते हैं जो सर्वोत्तम अर्थ में नीरस हो: पूर्वानुमेय, निरीक्षण-योग्य और दबाव में अप्रत्याशित न होने वाला। लक्ष्य अधिकतम परिष्कार नहीं है। यह सुदृढ़ता, ऑब्ज़र्वेबिलिटी और आर्थिक लक्ष्यों को पूरा करने वाले सुपरिचित पैटर्नों का सबसे छोटा समुच्चय है, जिसे बिना किसी अपवाद के लागू किया जाए, क्योंकि अपवाद ही वह जगह है जहाँ अगली घटना जन्म लेती है।
नींव कहाँ गड़बड़ाती है
इन्फ्रास्ट्रक्चर आर्किटेक्चर पहचानने योग्य तरीकों से विफल होता है, और उन्हें नाम देना ही पहली रक्षा है। आकस्मिक जटिलता सबसे आम है। एक तंत्र प्रदाताओं, टूलों और एक-बारगी पैटर्नों को जमा करता जाता है, हर एक स्थानीय रूप से न्यायसंगत, जब तक कि कोई एक व्यक्ति उस टोपोलॉजी को अपने मस्तिष्क में धारण नहीं कर पाता और हर बदलाव अज्ञात जोखिम उठाता है। कारण प्रायः किसी प्रवर्तित संदर्भ-समुच्चय की अनुपस्थिति होती है, जिससे हर टीम एक ही समस्या को भिन्न ढंग से हल करती है। उपचार है पैटर्नों का एक सुविचारित रूप से छोटा मानक पुस्तकालय, और उन जोड़ों को ना कहने का अनुशासन जो अपनी जटिलता को अर्जित नहीं करतीं।
बिना पुनर्रचना के लिफ्ट-एंड-शिफ्ट वह विफलता है जो किसी cloud कार्यक्रम को निराशा में बदल देती है। वर्कलोड को उनकी स्थिर-क्षमता की धारणाओं को बनाए रखते हुए, ज्यों-का-त्यों किसी लचीले एनवायरनमेंट में ले जाया जाता है, और संगठन को cloud के लाभ के बिना cloud की कीमत विरासत में मिल जाती है। लागत बढ़ती है, सुदृढ़ता नहीं सुधरती, और प्रवासन को विफल आँका जाता है जबकि वास्तव में जो विफल हुआ वह आर्किटेक्चर न करने का निर्णय था।
बाद की सोच के रूप में ऑब्ज़र्वेबिलिटी ऐसे तंत्र उत्पन्न करती है जो तब तक शांत रहते हैं जब तक कि नहीं रहते। हर घटना के बाद प्रतिक्रियात्मक रूप से टेलीमेट्री जोड़ी जाती है, कवरेज असमान होता है, और संकेत सहसंबद्ध नहीं होते, जिससे निदान उन कुछ लोगों पर निर्भर हो जाता है जिन्हें संयोगवश पता होता है कि किसे कहाँ दबाया गया है। ऐसी प्रणाली के बारे में की गई सुदृढ़ता की दावेदारियाँ असत्यापनीय होती हैं।
मौन लॉक-इन वह विफलता है जो केवल तभी दृश्यमान होती है जब आप उसे छोड़ने का प्रयास करते हैं। किसी प्रदाता की स्वामित्वयुक्त सेवाओं को निकास-लागत के ईमानदार आकलन के बिना गहराई से अपनाना एक वैध चुनाव है, किंतु केवल तभी जब वह एक चुनाव रहा हो। यह तब विफलता बन जाता है जब संकेंद्रण जोखिम, मूल्य-निर्धारण शक्ति और नियामक जोखिम निर्णय के बजाय पूर्वनिर्धारित रूप से जमा हो जाते हैं।
लागत एन्ट्रॉपी ऐसे तंत्र का निरंतर रिसाव है जिसका आर्थिक रूप से कोई स्वामी नहीं होता। निष्क्रिय संसाधन, आवश्यकता से बड़े इंस्टेंस, भुलाए गए एनवायरनमेंट और अनारोपित व्यय इसलिए जमा होते जाते हैं क्योंकि जो लचीलापन ऊपर स्केल करता है वह शायद ही कभी नीचे स्केल करने के लिए जुड़ा होता है, और अपने द्वारा उत्पन्न बिल को कोई महसूस नहीं करता। अंत में, कभी न परखे गए प्रलेखित फेलओवर का सुदृढ़ता का दिखावा संगठन को ठीक वहाँ विश्वास देता है जहाँ उसे संदेह होना चाहिए। इनमें से हर विफलता-स्थिति परिचालनात्मक के बजाय आर्किटेक्चरल है। ये किसी त्रुटिपूर्ण संरचना के भीतर अधिक मेहनत करने से ठीक नहीं होतीं। इन्हें संरचना द्वारा रोका जाता है, और एक बार मौजूद हो जाने पर इन्हें केवल उन मानकों को सुविचारित रूप से पुन: लाकर हटाया जाता है जिन्हें छोड़ दिया गया था।
Nashua इस पर कैसे काम करती है
Nashua टेक्नोलॉजी आधार को पहले एक आर्किटेक्चर समस्या और दूसरे स्थान पर एक टेक्नोलॉजी-चयन समस्या के रूप में देखती है। कार्य-सहभागिताएँ वर्तमान तंत्र के ईमानदार आकलन से आरंभ होती हैं: वास्तव में क्या और कहाँ चल रहा है, वर्कलोड को cloud, हाइब्रिड और ऑन-प्रिमाइज़ एनवायरनमेंट में कैसे रखा गया है, सुदृढ़ता और ऑब्ज़र्वेबिलिटी की खाइयाँ कहाँ हैं, और लागत किससे जुड़ती है। इससे एक साझा चित्र बनता है जो प्रायः संगठन की धारणा से कहीं अधिक विषमांगी होता है, और यही किसी विश्वसनीय लक्ष्य-डिज़ाइन के लिए आवश्यक आधार है। हम आरंभ-बिंदु को समझे बिना कोई गंतव्य निर्धारित करने के प्रलोभन का प्रतिरोध करते हैं।
वहाँ से हम संगठन के साथ मिलकर एक लक्ष्य संदर्भ-आर्किटेक्चर परिभाषित करते हैं: कंप्यूट, स्टोरेज, नेटवर्क, पहचान, ऑब्ज़र्वेबिलिटी और लागत के लिए मानक पैटर्नों का वह छोटा समुच्चय जो पूरे तंत्र में प्रयुक्त होगा, जिसे स्लाइडवेयर के बजाय कोड और पुन:प्रयोज्य मॉड्यूल के रूप में व्यक्त किया गया हो। उद्देश्य है प्रतिस्थापन-योग्यता और संगति। एक टीम को बुनियादों को नए सिरे से गढ़े बिना, किसी प्रशस्त-पथ के माध्यम से एक अनुपालक, सुदृढ़ एनवायरनमेंट प्राप्त करने में सक्षम होना चाहिए, और आर्किटेक्चर को पुनर्कार्य की शृंखला के बिना प्रदाता या प्लेटफ़ॉर्म का कोई बदलाव आत्मसात करने में सक्षम होना चाहिए। जहाँ प्लेटफ़ॉर्म इंजीनियरिंग सामर्थ्य उचित हो, हम उस स्व-सेवा परत को डिज़ाइन करने और खड़ा करने में सहायता करते हैं जो मानकों को न्यूनतम-प्रतिरोध का पथ बना देती है।
हम सुदृढ़ता, ऑब्ज़र्वेबिलिटी और अर्थशास्त्र को इरादों के बजाय इंजीनियरिंग वितरणों के रूप में लेते हैं। इसका अर्थ है ऐसे पुनर्प्राप्ति-लक्ष्य जो प्रति वर्कलोड परिभाषित और परखे गए हों, ऐसे टेलीमेट्री अनुबंध जो तंत्र को निदान-योग्य बनाएँ, सत्यापित पहचान पर निर्मित विभाजन, और इस प्रकार जुड़ा लागत-आरोपण कि निर्णय और उनके वित्तीय परिणाम एक साथ दृश्यमान हों। इस दौरान, हम संगठन के अपने इंजीनियरों को दरकिनार करने के बजाय उनके साथ मिलकर काम करते हैं, क्योंकि एक टेक्नोलॉजी आधार उतना ही टिकाऊ होता है जितना उन मानकों को उसका संचालन करने वाले लोग समझते और उन पर विश्वास करते हैं। हमारी भूमिका ऐसा आर्किटेक्चर पीछे छोड़ जाने की है जिसे संगठन स्वयं विस्तारित और संरक्षित कर सके, साथ ही वे संदर्भ-पैटर्न और वह तर्क भी, जो कार्य-सहभागिता समाप्त होने के लंबे समय बाद तक उसे अनुरक्षण-योग्य बनाए रखते हैं।
Nashua कहाँ अंतर लाती है
Nashua जो अंतर लाती है वह है आर्किटेक्चरल कठोरता का परिचालनात्मक यथार्थ के साथ संयोग। कई संगठन इस लेख के सिद्धांतों को अभिव्यक्त कर सकते हैं। कम ही संगठन पूरे तंत्र को, cloud, हाइब्रिड और ऑन-प्रिमाइज़ सहित, एक एकल सुसंगत डिज़ाइन के रूप में धारण करते हुए भी उन कंप्यूट, स्टोरेज, नेटवर्क और प्लेटफ़ॉर्म चुनावों के बारे में विशिष्ट बने रह सकते हैं जो उसे वास्तविक बनाते हैं। वही संगति, बोर्ड-स्तरीय सुदृढ़ता और संप्रभुता की बाध्यताओं से लेकर उस संदर्भ-मॉड्यूल तक जिसे कोई टीम किसी मंगलवार को आरंभित करती है, वह जगह है जहाँ एक टेक्नोलॉजी आधार या तो मूल्य में संचित होता है या चुपचाप जोखिम जमा करता है।
इसका एक व्यावहारिक उपसिद्धांत भी है जो इस बात को बदल देता है कि यह कार्य क्या मान लेने की अनुमति रखता है। जब कोई कार्य-सहभागिता ऐसी सामर्थ्य की माँग करती है जो अभी तक मौजूद नहीं है, तो उसे किसी क्रय-चक्र या किसी विक्रेता के रोडमैप की प्रतीक्षा नहीं करनी पड़ती। enterprise platform को इस प्रकार बनाया गया है कि यह लगभग किसी भी फ़ीचर को तीव्र गति से समायोजित कर सके, agentic engineering के माध्यम से: जो आवश्यक है उसे सामान्य भाषा में वर्णित किया जाता है और शीघ्रता से उत्पन्न किया जाता है, किंतु सदैव दृढ़ आर्किटेक्चर सिद्धांतों के भीतर और कठोर गुणवत्ता आश्वासन के अधीन, ताकि गति कभी संगति, सुरक्षा या नियंत्रण की कीमत पर न आए। इसका प्रभाव केवल सुविधाजनक होने के बजाय रणनीतिक होता है। यह बनाओ-या-खरीदो की रेखा को खिसका देता है, विकल्प-खुलेपन को सस्ता बनाए रखता है, और आर्किटेक्चर को रणनीति का अनुसरण करने देता है, बजाय इसके कि रणनीति उसके आगे झुके जो संयोगवश किसी शेल्फ़ पर उपलब्ध था।
इससे जो प्राप्त होता है वह एक ऐसी टेक्नोलॉजी नींव है जो बदलाव और दबाव के अधीन पूर्वानुमेय रूप से व्यवहार करती है: सुदृढ़ क्योंकि विफलता डिज़ाइन द्वारा सीमित है, प्रेक्षणीय क्योंकि निदान-योग्यता बाद में जोड़ने के बजाय अंतर्निहित है, और लागत-प्रभावी क्योंकि अर्थशास्त्र किसी मासिक हिसाब के बजाय हर निर्णय का गुण है। उतना ही महत्वपूर्ण यह है कि यह ऐसी नींव है जिसका संगठन स्वयं स्वामी है, जो उन पैटर्नों में व्यक्त है जिन्हें उसके अपने लोग समझते हैं और उनकी रक्षा कर सकते हैं। Nashua का लक्ष्य स्वयं को अपरिहार्य बनाना नहीं है। यह ऐसा टेक्नोलॉजी आधार पीछे छोड़ जाना है जो आकस्मिक के बजाय सुविचारित हो, और संगठन के भीतर एक ऐसी आर्किटेक्चर प्रथा, जो तंत्र, विनियमों और वर्कलोड के निरंतर बदलते रहने पर भी उसे वैसा ही बनाए रखने में सक्षम हो।