पिछले दो दशकों के अधिकांश समय में, enterprise architecture का अभ्यास प्रौद्योगिकी से ऊपर की ओर किया जाता रहा। टीमों ने applications की सूची बनाई, integrations को मैप किया, infrastructure को युक्तिसंगत बनाया, और ऐसे roadmap तैयार किए जिनका तर्क IT के भीतर ही सीमित था। यह तब तक काम करता रहा जब तक किसी व्यवसाय पर मुख्य बाधा उसकी प्रणालियों की लागत और जटिलता थी। अधिकांश संगठनों के लिए अब यह बाधक बाधा नहीं रह गई है। अब बाधा वह गति और सुसंगतता है जिसके साथ कोई व्यवसाय अपने कार्य को पुनर्गठित कर सकता है: किसी निकटवर्ती बाजार में प्रवेश करना, किसी अधिग्रहण को आत्मसात करना, किसी नए नियमन का अनुपालन करना, या किसी मौजूदा सेवा में machine-learning क्षमता को इस तरह जोड़ना कि उसे स्पर्श करने वाली अन्य तीन क्षमताएँ न टूटें।

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

business architecture अभी, विशेष रूप से, इसलिए महत्वपूर्ण है क्योंकि माँगे गए परिवर्तन की गति उस मौन समझ से आगे निकल गई है जो पहले किसी संगठन को एक साथ बाँधे रखती थी। जब कोई व्यवसाय धीरे-धीरे बदलता था, तो वह मानचित्र कुछ दीर्घकालिक सेवारत लोगों के मस्तिष्क में पर्याप्त रूप से जीवित रहता था। जब वह निरंतर बदलता है, तो वह मौन मानचित्र एक दायित्व बन जाता है: वह विभागों के बीच असंगत होता है, नवागंतुकों के लिए अदृश्य होता है, और किसी निर्णय से पहले उसका निरीक्षण नहीं किया जा सकता। business architecture उस मानचित्र को बाह्य रूप देती है और उसे एक साझा, टिकाऊ परिसंपत्ति बना देती है। यह उस उद्यम के बीच का अंतर है जो स्वयं को देख सकता है और उस उद्यम के बीच जो केवल अंधकार में टटोल सकता है।

business architecture की आधारभूत रचना है क्षमता (capability): किसी ऐसी चीज़ का स्थिर कथन जिसे संगठन करने में सक्षम है, जिसे क्रिया के बजाय संज्ञा के रूप में व्यक्त किया जाता है। Underwriting, मूल्य निर्धारण, order fulfilment, ग्राहक onboarding, माँग पूर्वानुमान। एक क्षमता जानबूझकर इससे अमूर्त हो जाती है कि उसे कैसे निष्पादित किया जाता है, कौन उसे निष्पादित करता है, या कौन सी प्रणाली उसका समर्थन करती है। यही अमूर्तन ही संपूर्ण उद्देश्य है। प्रक्रियाएँ निरंतर बदलती हैं, संगठनात्मक संरचनाएँ प्रत्येक कुछ वर्षों में पुनर्व्यवस्थित होती हैं, applications प्रतिस्थापित की जाती हैं, परंतु यह तथ्य कि किसी बीमाकर्ता को जोखिम का underwrite करने में सक्षम होना चाहिए, इन सबके पार टिका रहता है। चूँकि क्षमताएँ स्थिर होती हैं, इसलिए वे एक निर्देशांक प्रणाली बनाती हैं जिसके सापेक्ष प्रत्येक अस्थिर वस्तु को स्थित किया जा सकता है।

क्षमताओं को एक capability map में संगठित किया जाता है: उद्यम जो कुछ कर सकता है उसका एक संरचित, प्रायः दो या तीन स्तरीय विघटन, जो इस आधार पर संगठित होता है कि क्षमता क्या है, न कि इस आधार पर कि उसका स्वामी कौन है। एक अच्छा मानचित्र प्रत्येक स्तर पर परस्पर अपवर्जी और सामूहिक रूप से संपूर्ण होता है, और स्पष्ट रूप से संगठनात्मक चार्ट का प्रतिबिंब नहीं होता। यदि दो प्रभाग दोनों ग्राहकों का onboard करते हैं, तो यह दो स्थानों पर प्रयुक्त एक क्षमता है, दो क्षमताएँ नहीं। इस एकल तथ्य को उजागर करना प्रायः संपूर्ण मानचित्रण अभ्यास के मूल्य के बराबर होता है।

जहाँ क्षमताएँ स्थिर योग्यता का वर्णन करती हैं, वहीं value streams यह वर्णन करती हैं कि किसी हितधारक को मूल्य वास्तव में आद्योपांत कैसे प्रदान किया जाता है, किसी उद्दीपक घटना से लेकर किसी साकार परिणाम तक। एक value stream संगठन के आर-पार क्षैतिज रूप से जाती है और क्रमबद्ध रूप से अनेक क्षमताओं का आह्वान करती है। ये दोनों रचनाएँ एक-दूसरे की पूरक हैं और एक साथ आधारभूत हैं: value stream आपको यात्रा और दाँव पर लगे हितधारक मूल्य के बारे में बताती है, capability map आपको बताता है कि उस यात्रा के सफल होने के लिए क्या अच्छा होना चाहिए। value streams के नीचे व्यावसायिक प्रक्रियाएँ (business processes) स्थित होती हैं, जो किसी विशेष संदर्भ में किसी क्षमता को साकार करने वाले गतिविधि के मूर्त, क्रमबद्ध, मापनीय अनुक्रम हैं। business architecture क्षमता और value stream की ऊँचाई पर कार्य करती है और जानबूझकर नीचे प्रक्रिया तक जुड़ती है, बजाय इसके कि आरंभ से ही प्रक्रिया के विवरण में डूब जाए।

अंतिम प्रथम सिद्धांत है आधार-निर्धारण। प्रत्येक अन्य architecture क्षेत्र capability model से संलग्न होता है। Applications को उन क्षमताओं से मैप किया जाता है जिनका वे समर्थन करती हैं, data entities को उन क्षमताओं से जो उनकी स्वामी हैं, पहलों और लागतों को उन क्षमताओं से जिन्हें वे बदलती हैं। यही वह चीज़ है जो असंबद्ध मॉडलों के समूह को एक enterprise architecture में बदल देती है: एक साझा रीढ़ जिसका संदर्भ प्रत्येक अन्य वस्तु देती है।

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

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

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

इन तीनों के नीचे एक शांत परिपक्वता चल रही है: business architecture से अब यह अपेक्षा बढ़ती जा रही है कि वह एक ओर रणनीति निर्माण से और दूसरी ओर portfolio वितरण से जुड़े, बजाय इसके कि वह एक स्वयं-निहित मॉडलिंग अभ्यास के रूप में स्थित रहे। मूल्य इस संबंध में है, और इस अनुशासन का मूल्यांकन इस बात पर किया जा रहा है कि वह संबंध कितनी अच्छी तरह टिकता है।

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

दूसरा सिद्धांत है क्या को कैसे से स्वच्छ रूप से पृथक करना। capability map यह बताता है कि उद्यम क्या कर सकता है। value streams और प्रक्रियाएँ यह बताती हैं कि इसे कैसे किया जाता है। इन दोनों को धुँधला करने से ऐसा मानचित्र बनता है जो वास्तव में एक प्रच्छन्न प्रक्रिया सूची है, जो अस्थिर, विशाल, और निवेश संबंधी बातचीत के लिए बेकार है। यहाँ रेखा को बनाए रखना ही सबसे सामान्य निर्धारक है कि कोई मॉडल टिकेगा या नहीं।

तीसरा सिद्धांत यह है कि मानचित्र को संगठन का प्रतिबिंब नहीं होना चाहिए। क्षमताओं को प्रभाग के अनुसार संरचित करना यह सुनिश्चित करता है कि दोहराव छिपा रहे और अंतर-अनुभागीय क्षमताएँ खंडित हो जाएँ। अंतर्निहित प्रकृति के अनुसार संगठित एक capability model किसी क्षमता को एक बार रखेगा और फिर मानचित्रण के माध्यम से उजागर करेगा कि वह हर स्थान पर कहाँ प्रयुक्त होती है। इससे उत्पन्न असुविधा नैदानिक है, कोई दोष नहीं।

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

पाँचवाँ सिद्धांत यह है कि मॉडल केवल संरचना के लिए नहीं, बल्कि निर्णय-बुद्धि वहन करने के लिए मौजूद है। एक capability map तब heat map बन जाता है जब प्रत्येक क्षमता का मूल्यांकन उन आयामों पर किया जाता है जो रणनीति के लिए महत्वपूर्ण हैं: आवश्यक परिपक्वता के सापेक्ष वर्तमान परिपक्वता, रणनीतिक महत्व, लागत, जोखिम, और माँगे गए परिवर्तन की मात्रा। यह स्थिर संरचना पर निर्णय-बुद्धि का अध्यारोपण ही है जो एक वर्गीकरण को एक निर्णय उपकरण में बदल देता है। यहीं पर target operating model भी जुड़ता है: target operating model वास्तव में क्षमताओं, value streams, संगठन और सूचना के भविष्य-स्थिति विन्यास का एक कथन है, और heat map वह अंतराल विश्लेषण है जो उसकी ओर बढ़ने को उचित ठहराता है।

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

प्रच्छन्न संगठनात्मक चार्ट दूसरा है: मानचित्र विभागों के इर्द-गिर्द संरचित होता है, इसलिए वह मौजूदा संरचना को मान्य करता है, हर दोहराव को छिपाता है, और संगठन को ऐसा कुछ नहीं सिखाता जो वह पहले से न मानता हो। यह कार्यशाला में आरामदायक लगता है और उसके बाद हमेशा के लिए निष्क्रिय रहता है।

समुद्र को उबालना तीसरा है: टीम कोई भी मूल्य प्रदान करने से पहले प्रत्येक क्षमता को एक समान गहराई तक विघटित करने और प्रत्येक application, प्रक्रिया और data entity को मैप करने का प्रयास करती है। यह प्रयास अपने ही भार तले ढह जाता है, प्रायः ठीक उससे पहले जब वह उपयोगी बन जाता। business architecture को उन निर्णयों से जो उत्तर की माँग करते हैं बाहर-से-भीतर की ओर बनाया जाना चाहिए, न कि संपूर्णता की आकांक्षा से नीचे-से-ऊपर की ओर।

क्षमता के रूप में स्वाँग रचती प्रक्रिया चौथा और सर्वाधिक तकनीकी है: क्रियाएँ मानचित्र में घुस आती हैं, ऊँचाई फिसल जाती है, और capability model एक अस्थिर प्रक्रिया सूची बन जाता है जो अगले पुनर्गठन पर टूट जाती है। यही वह विफलता है जो चुपचाप मॉडल के स्थिरता के मूल वादे को कमज़ोर कर देती है।

बिना स्वामी की कलाकृतियाँ पाँचवाँ है: मॉडल का कोई जवाबदेह व्यावसायिक स्वामी नहीं होता, इसलिए उसके मूल्यांकन कभी ताज़ा नहीं किए जाते, application और पहल portfolio से उसके संबंध पुराने पड़ जाते हैं, और अठारह महीनों के भीतर वह एक ऐसे उद्यम का वर्णन करता है जो अब अस्तित्व में नहीं है। इन पाँचों में समान सूत्र एक ही है: एक ऐसी business architecture जिसे किसी दस्तावेज़ के रूप में माना जाता है, न कि इस बात के एक शासित, सजीव घटक के रूप में कि संगठन स्वयं के बारे में कैसे तर्क करता है। उपचार कभी कोई बेहतर आरेखण उपकरण नहीं होता। वह है स्वामित्व, वास्तविक निर्णयों से संबंध, और केवल उतना ही मॉडल बनाने का अनुशासन जितना उन निर्णयों की आवश्यकता हो।

Nashua business architecture को एक ऐसे उपकरण के रूप में देखता है जिसे नियुक्त किया जाना है, न कि एक ऐसे दस्तावेज़ के रूप में जिसे सुपुर्द किया जाना है। यह कार्य उन निर्णयों से आरंभ होता है जो संगठन को वास्तव में लेने की आवश्यकता है: उचित ठहराने योग्य कोई रूपांतरण, एकीकृत करने योग्य कोई अधिग्रहण, युक्तिसंगत बनाने योग्य कोई portfolio, अभिकल्पित करने योग्य कोई target operating model। हम उन निर्णयों से पीछे की ओर उस न्यूनतम व्यवहार्य capability model की ओर काम करते हैं जो उन्हें सूचित कर सके, बजाय इसके कि किसी रिक्त वर्गीकरण से आगे की ओर काल्पनिक संपूर्णता की ओर बढ़ें। यह प्रयास को समानुपातिक रखता है और यह सुनिश्चित करता है कि जिस दिन मॉडल पूरा हो, उसी दिन उसके पास करने के लिए कोई कार्य हो।

हम capability map को व्यवसाय के साथ बनाते हैं, उसके लिए नहीं। जो मानचित्र टिकता है, वह वही है जिसकी परिभाषाओं पर क्षमताओं के लिए जवाबदेह लोगों द्वारा बहस की गई और सहमति दी गई, क्योंकि उनका स्वामित्व ही उसे बाद में जीवित रखता है। हमारे architect संरचन अनुशासन लाते हैं: क्या और कैसे के बीच रेखा को बनाए रखना, मानचित्र को संगठनात्मक चार्ट से दूर रखना, क्षमताओं को ऐसी ऊँचाई पर बनाना जो पुनर्गठन के पार टिके, और विघटन को वहीं रोकना जहाँ निर्णय रुकते हैं। इसके बाद हम निर्णय-बुद्धि का अध्यारोपण करते हैं, परिपक्वता, महत्व, लागत और जोखिम का मूल्यांकन करके एक heat map तैयार करते हैं जो ईमानदारी से दिखाता है कि संगठन की योग्यता और उसकी महत्वाकांक्षा कहाँ विचलित होती हैं।

वहाँ से हम शेष संपदा को मॉडल से आधारबद्ध करते हैं। Applications, सूचना और पहलों को उन क्षमताओं से मैप किया जाता है जिनका वे समर्थन करती हैं, ताकि व्यवसाय परत वह रीढ़ बन जाए जो एक ओर रणनीति को दूसरी ओर application, data और प्रौद्योगिकी architecture से जोड़ती है। यहीं पर एक target operating model एक slide होना बंद कर देता है और एक अनुरेखणीय अभिकल्पना बन जाता है: क्षमताओं और value streams का एक भविष्य-स्थिति विन्यास, जिसमें वर्तमान स्थिति से एक बचाव-योग्य मार्ग हो। पूरे कार्य में, हम उन दो चीज़ों पर बल देते हैं जो यह निर्धारित करती हैं कि इनमें से कुछ भी संगठन के संपर्क में आकर टिकता है या नहीं: मॉडल के लिए एक जवाबदेह व्यावसायिक स्वामी, और कुछ थोड़े से सजीव निर्णय जो उसे उपयोग में बनाए रखें। हम एक छोटा मॉडल सुपुर्द करना पसंद करेंगे जो शासित हो और जिससे परामर्श लिया जाए, बजाय एक व्यापक मॉडल के जो वॉलपेपर बन जाए।

Nashua जो अंतर लाता है, वह कोई स्वामित्व वाली संकेतन प्रणाली या कोई मोटी सुपुर्दगी नहीं है। वह यह आग्रह है कि business architecture जुड़ी रहे: अपने ऊपर की रणनीति से, अपने नीचे के application, data और प्रौद्योगिकी क्षेत्रों से, और अपने चारों ओर के वास्तविक निवेश और परिवर्तन निर्णयों से। एक capability model जो अलग-थलग रहता है, वह एक अकादमिक अभ्यास है। एक capability model जो इस बात से जुड़ा है कि कोई संगठन अपने परिवर्तन को कैसे तय करता है, वित्तपोषित करता है और शासित करता है, वह एक टिकाऊ रणनीतिक परिसंपत्ति है, और पहले के बजाय दूसरे प्रकार का निर्माण करना ही वह क्षेत्र है जहाँ हमारा अभ्यास अपने प्रयास को केंद्रित करता है।

इसके साथ एक व्यावहारिक परिणाम भी है जो यह बदल देता है कि कार्य को क्या मान लेने की अनुमति है। जब किसी कार्य के लिए ऐसी क्षमता की आवश्यकता होती है जो अभी अस्तित्व में नहीं है, तो उसे किसी खरीद चक्र या किसी विक्रेता के roadmap की प्रतीक्षा करने की आवश्यकता नहीं होती। enterprise platform को इस प्रकार बनाया गया है कि वह लगभग किसी भी सुविधा को तीव्र गति से समायोजित कर सके, agentic engineering के माध्यम से: जो आवश्यक है उसका सरल भाषा में वर्णन किया जाता है और शीघ्रता से उत्पन्न किया जाता है, परंतु सदैव दृढ़ architecture सिद्धांतों के भीतर और कठोर गुणवत्ता आश्वासन के अधीन, ताकि गति कभी सुसंगतता, सुरक्षा या नियंत्रण की कीमत पर न आए। इसका प्रभाव मात्र सुविधाजनक न होकर रणनीतिक है। यह make-or-buy रेखा को हिला देता है, विकल्प-योग्यता को सस्ता रखता है, और architecture को रणनीति का अनुसरण करने देता है, बजाय इसके कि रणनीति उसके आगे झुके जो संयोगवश किसी शेल्फ पर उपलब्ध था।

इससे किसी संगठन को जो प्राप्त होता है, वह एक ऐसा व्यवसाय है जो स्वयं को इतनी स्पष्टता से देख सकता है कि स्वयं को जानबूझकर बदल सके। दोहराव दृश्य बन जाता है और इसलिए संबोधित करने योग्य। निवेश को उन क्षमताओं के सापेक्ष जाँचा जा सकता है जिन्हें रणनीति विभेदक बताती है। किसी अधिग्रहण का मूल्यांकन इस आधार पर किया जा सकता है कि वह वास्तव में क्या जोड़ता है, न कि इस आधार पर कि वह क्या दोहराता है। एक target operating model को उन क्षमताओं तक एक अनुरेखणीय रेखा के साथ अभिकल्पित किया जा सकता है जिन्हें वह पुनराकार देता है। इसमें से किसी के लिए भी संगठन से यह अपेक्षा नहीं की जाती कि वह कोई नई शब्दावली अपनाए या किसी ऐसे मॉडल पर भरोसा करे जिसे बनाने में उसने सहायता नहीं की। इसके लिए केवल यह आवश्यक है कि व्यवसाय परत को वैसा ही माना जाए जैसी वह है: संपूर्ण architecture का आधार, और वह बिंदु जहाँ रणनीति या तो क्रियान्वयन से जुड़ती है या चुपचाप विफल हो जाती है। Nashua की भूमिका उस संबंध को बनाना और बनाए रखना है, और पीछे कोई आरेख नहीं, बल्कि एक ऐसा उपकरण छोड़ना है जिसका उपयोग संगठन हमारे चले जाने के लंबे समय बाद भी करता रहे।