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

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

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

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

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

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

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

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

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

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

दूसरा सिद्धांत है उच्च कार्यात्मक संसक्ति के साथ शिथिल युग्मन। एप्लिकेशनों को इस तरह व्यवस्थित किया जाना चाहिए कि जो चीज़ें एक साथ बदलती हैं वे एक साथ रहें, और जो चीज़ें स्वतंत्र रूप से बदलती हैं वे स्थिर, स्पष्ट इंटरफेस से अलग हों। एक स्वस्थ तंत्र का माप यह नहीं है कि उसमें कितनी कम प्रणालियाँ हैं, बल्कि यह कि वे कितनी स्वतंत्र रूप से बदल सकती हैं। एक ऐसा तंत्र जहाँ एक प्रणाली में बदलाव पाँच अन्य में समन्वित बदलाव के लिए बाध्य करता है, उसमें उच्च युग्मन है चाहे उसके अलग अलग घटक कितने ही आधुनिक क्यों न हों, और युग्मन, न कि उम्र, आमतौर पर उस भावना का असली स्रोत होता है कि परिदृश्य को हिलाना असंभव है।

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

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

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

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

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

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

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

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

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

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

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