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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

मानकीकरण अपने लिए। संगति का पीछा उस बिंदु से आगे किया जाता है जहाँ वह किसी काम आती है, ताकि टीमों को एक साझा उपकरण पर मजबूर किया जाए जो किसी के लिए भी ठीक से उपयुक्त नहीं, और एकरूपता की लागत चुपचाप उस विविधता की लागत से अधिक हो जाती है जिसे वह प्रतिस्थापित करती है। मानकों की वकालत उस चीज़ के मूल्य से होनी चाहिए जिसे साझा बनाया गया है, न कि उन्हें स्वयं में एक गुण मानकर थोपा जाना चाहिए।

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

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

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

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

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

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

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

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

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

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