सॉफ्टवेयर विकास के जटिल माहौल में, संचार अक्सर मुख्य बाधा बन जाता है। टीमें अक्सर जटिल प्रणालियों में घूमती हैं जहां तकनीकी देनदारी केवल कोड में ही नहीं, बल्कि दस्तावेज़ीकरण में भी जमा होती है। सिस्टम संरचना का वर्णन करते समय एक साझा भाषा की कमी एक सबसे लंबे समय तक रहने वाली चुनौती है। एक मानक शब्दावली के बिना, डायग्राम व्यक्तिगत व्याख्याएँ बन जाते हैं, संगठनात्मक संपत्ति नहीं। यह गाइड यह जांचता है कि सॉफ्टवेयर आर्किटेक्चर डायग्राम्स के लिए एक संगत शब्दावली कैसे स्थापित की जाए, विशेष रूप से C4 मॉडल के सिद्धांतों का उपयोग करके स्पष्टता और दीर्घायु को सुनिश्चित करने के लिए।
जब आर्किटेक्ट्स और डेवलपर्स बात करते हैं, तो उन्हें एक ही अर्थ में एक ही अवधारणाओं को संदर्भित करना चाहिए। अस्पष्टता असंगति का कारण बनती है। यदि एक व्यक्ति एक “कंटेनर” को माइक्रोसर्विस के रूप में परिभाषित करता है जबकि दूसरा इसे डेटाबेस के रूप में देखता है, तो परिणामस्वरूप आर्किटेक्चर दस्तावेज़ीकरण शोर हो जाता है। इस शब्दावली को मानकीकृत करके टीमें मानसिक भार को कम कर सकती हैं और निर्णय लेने की प्रक्रिया को तेज कर सकती हैं। लक्ष्य रचनात्मकता को सीमित करना नहीं है, बल्कि अभिव्यक्ति के लिए एक ठोस ढांचा प्रदान करना है।
📉 आर्किटेक्चर दस्तावेज़ीकरण में अस्पष्टता की कीमत
एक ऐसे परिदृश्य को ध्यान में रखें जहां एक नया इंजीनियर एक प्रोजेक्ट में शामिल होता है। उसे सिस्टम को समझने के लिए डायग्राम्स का एक सेट दिया जाता है। यदि इन डायग्राम्स में असंगत शब्दावली का उपयोग किया जाता है, तो ओनबोर्डिंग प्रक्रिया काफी धीमी हो जाती है। नए कर्मचारी को एक विशिष्ट बॉक्स का अर्थ समझने में समय बिताना होता है, जबकि वह सिस्टम के काम करने के तरीके को सीखने के बजाय उसे समझने में लगाता है। यह बाधा गति और मनोबल को प्रभावित करती है।
ओनबोर्डिंग के बाहर, अस्पष्टता रखरखाव में जोखिम पैदा करती है। जब प्रोडक्शन में कोई बग दिखाई देता है, तो टीम को डेटा के प्रवाह का पता लगाने की आवश्यकता होती है। यदि डायग्राम एक दृश्य में किसी सेवा को “पेमेंट हैंडलर” कहता है और दूसरे दृश्य में “बिलिंग मॉड्यूल” कहता है, तो जांच एक खोज का खेल बन जाती है। मानकीकरण टीम सदस्यों के बीच एक संविदा के रूप में काम करता है। यह सुनिश्चित करता है कि दस्तावेज़ीकरण सच्चाई का स्रोत बना रहे, भ्रम का स्रोत नहीं।
खराब शब्दावली से उत्पन्न मुख्य समस्याएँ इस प्रकार हैं:
- असंगत अपेक्षाएँ:स्टेकहोल्डर्स को उपलब्ध विवरण के स्तर से अलग स्तर की अपेक्षा हो सकती है।
- आवर्ती कार्य:डेवलपर्स ऐसे फीचर बना सकते हैं जिन्हें वे मौजूदा मॉड्यूल का हिस्सा समझते हैं, लेकिन फिर फंक्शनैलिटी की दोहराव होती है।
- दस्तावेज़ीकरण का अपमान:यदि मानकों की अस्पष्टता के कारण डायग्राम्स को अपडेट करने में बहुत अधिक प्रयास करना पड़ता है, तो दस्तावेज़ तेजी से अप्रचलित हो जाते हैं।
- संचार का विघटन:मीटिंग्स तकनीकी समाधानों के बजाय परिभाषाओं पर चर्चा के रूप में बन जाती हैं।
🧩 C4 मॉडल एक आधारभूत ढांचे के रूप में
इन चुनौतियों को दूर करने के लिए, बहुत सी संगठन C4 मॉडल को अपनाते हैं। यह मॉडल डायग्रामिंग के लिए एक पदानुक्रमिक दृष्टिकोण प्रदान करता है, जिससे टीमें अपनी प्रणालियों में बिना संदर्भ खोए जूम इन और आउट कर सकती हैं। यह एक कठोर नियमों का सेट नहीं है, बल्कि जानकारी के संरचना के लिए दिशानिर्देशों का सेट है। मॉडल चार स्तरों के अमूर्तीकरण के बीच अंतर करता है: संदर्भ, कंटेनर, घटक और कोड।
इस मॉडल को अपनाने से शब्दावली स्थापित करने में मदद मिलती है क्योंकि यह टीम को यह परिभाषित करने के लिए मजबूर करता है कि एक “प्रणाली” क्या है और एक “कंटेनर” क्या है। यह चर्चा को “मॉड्यूल” या “लेयर” जैसे अस्पष्ट शब्दों से दूर ले जाता है और विशिष्ट आर्किटेक्चरल तत्वों की ओर ले जाता है। इस संरचना के कारण डायग्राम्स का निर्माण होता है जो एग्जीक्यूटिव्स के लिए उच्च स्तरीय होते हैं और इंजीनियर्स के लिए पर्याप्त विस्तार से भी होते हैं।
इस पदानुक्रमिक दृष्टिकोण के लाभ इस प्रकार हैं:
- संगतता:प्रत्येक डायग्राम एक ही संरचनात्मक तर्क का पालन करता है।
- स्केलेबिलिटी:आप प्रणाली बढ़ने के साथ नए डायग्राम जोड़ सकते हैं बिना मूल परिभाषाओं को बदले।
- स्पष्टता: प्रत्येक स्तर एक विशिष्ट दर्शक वर्ग के लिए एक विशिष्ट प्रश्न का उत्तर देता है।
🔍 मूल शब्दावली को परिभाषित करना: प्रणालियाँ और कंटेनर
C4 मॉडल के केंद्र में “प्रणाली” और “कंटेनर” शब्द हैं। इन्हें अक्सर गलती से एक दूसरे से भ्रमित किया जाता है, फिर भी ये आर्किटेक्चरल शब्दावली में अलग-अलग उद्देश्यों के लिए काम करते हैं।
🏢 एक प्रणाली क्या है?
संदर्भ डायग्राम (स्तर 1) के संदर्भ में, “प्रणाली” का अर्थ विवरण की जा रही पूरी सॉफ्टवेयर समाधान है। यह शीर्ष स्तर की सीमा है। उदाहरण के लिए, यदि आप एक ई-कॉमर्स प्लेटफॉर्म बना रहे हैं, तो पूरा प्लेटफॉर्म “प्रणाली” है। इसमें व्यवसाय के काम करने के लिए आवश्यक सभी सेवाएँ, डेटाबेस और इंटरफेस शामिल हैं।
एक प्रणाली को परिभाषित करते समय, शब्दावली का ध्यान इसके उद्देश्य और उपयोगकर्ताओं पर होना चाहिए। प्रणाली बाहरी दुनिया के लिए एक काला बॉक्स है। यह लोगों या अन्य प्रणालियों से इनपुट स्वीकार करती है और आउटपुट उत्पन्न करती है। इस चरण में इसे आंतरिक कार्यान्वयन विवरणों के बारे में चिंता नहीं करनी है।
📦 कंटेनर क्या है?
लेवल 2 पर, कंटेनर डायग्राम में, हम सिस्टम को विभाजित करते हैं। एक “कंटेनर” एक स्पष्ट डेप्लॉयमेंट इकाई है। यह कोड चलाने वाली कोई चीज है। उदाहरणों में वेब एप्लिकेशन, मोबाइल एप्लिकेशन, माइक्रोसर्विसेज या डेटाबेस शामिल हैं।
एक कंटेनर एक भौतिक या तार्किक रनटाइम वातावरण है। इसे एक “कंपोनेंट” से अलग करना महत्वपूर्ण है। एक कंटेनर वह स्थान है जहां कोड निष्पादित होता है। एक कंपोनेंट उस कोड के अंदर का एक तार्किक हिस्सा है। उदाहरण के लिए, एक वेब एप्लिकेशन एक कंटेनर है। उस वेब एप्लिकेशन के अंदर स्थित प्रमाणीकरण मॉड्यूल एक कंपोनेंट है।
नीचे दी गई तालिका 1 अंतर का सारांश प्रस्तुत करती है:
| शब्द | परिभाषा | उदाहरण | डायग्राम स्तर |
|---|---|---|---|
| सिस्टम | पूरी सॉफ्टवेयर समाधान | ई-कॉमर्स प्लेटफॉर्म | लेवल 1 (संदर्भ) |
| कंटेनर | एक स्पष्ट डेप्लॉयमेंट इकाई | वेब सर्वर, API गेटवे, डेटाबेस | लेवल 2 (कंटेनर) |
| कंपोनेंट | कार्यक्षमता का तार्किक समूह | ऑर्डर सेवा, उपयोगकर्ता प्रबंधक | लेवल 3 (कंपोनेंट) |
🧱 कंपोनेंट्स और कोड को समझना
जैसे हम और गहराई में जाते हैं, शब्दावली इंजीनियरिंग टीम के लिए अधिक विशिष्ट हो जाती है। कंपोनेंट डायग्राम (लेवल 3) एक कंटेनर की आंतरिक संरचना का वर्णन करता है। यहां हम “कंपोनेंट” शब्द का उपयोग संबंधित कार्यक्षमता के तार्किक समूह को दर्शाने के लिए करते हैं।
कंपोनेंट्स भौतिक वस्तुएं नहीं हैं। उनका सीधे डेप्लॉयमेंट का निशान नहीं होता है। आप एक कंपोनेंट को अकेले डेप्लॉय नहीं कर सकते। आप उन कंपोनेंट्स को धारण करने वाले कंटेनर को डेप्लॉय करते हैं। इस अंतर का ध्यान रखना इंफ्रास्ट्रक्चर योजना में भ्रम से बचने के लिए बहुत महत्वपूर्ण है। कंपोनेंट्स के बारे में बात करते समय, ध्यान चिंता के विभाजन और संगठन पर होता है।
उदाहरण के लिए, एक “ऑर्डर प्रोसेसिंग” कंटेनर के भीतर, आपके पास “इन्वेंट्री चेक,” “कर की गणना,” और “भुगतान प्रोसेसिंग” के लिए कंपोनेंट्स हो सकते हैं। इन कंपोनेंट्स को मिलकर कंटेनर के उद्देश्य को पूरा करने में मदद मिलती है। उनके नामकरण को एक समान रखने से डेवलपर्स को विशिष्ट व्यावसायिक नियमों के लिए जिम्मेदार कोड को ढूंढने में अनुमान लगाने की आवश्यकता नहीं होती है।
📝 कंपोनेंट्स के लिए नामकरण प्रणाली
मानक शब्दावली बनाए रखने के लिए, नामकरण प्रणाली अत्यंत महत्वपूर्ण है। एक कंपोनेंट का नाम उसकी जिम्मेदारी का वर्णन करना चाहिए। “मॉड्यूल A” या “लॉजिक 1” जैसे सामान्य नामों से बचें। बजाय इसके, वर्णनात्मक संज्ञाओं का उपयोग करें।
- बुरा:डेटा हैंडलर
- अच्छा:ग्राहक डेटा प्रोसेसर
- बुरा: सेवा1
- अच्छा: सूचना सेवा
इस अभ्यास में कोडबेस या दस्तावेज़ों के माध्यम से खोज करते समय मदद मिलती है। यह स्वचालित दस्तावेज़ उत्पादन में भी सहायता करता है, क्योंकि बहुत से उपकरण क्लास नामों पर निर्भर करते हैं ताकि आरेखों को भरा जा सके।
🎨 दृश्य व्याकरण और संबंध अर्थशास्त्र
एक शब्दावली केवल शब्दों के बारे में नहीं है; यह प्रतीकों के बारे में भी है। आरेख में बॉक्स को जोड़ने वाली रेखाएँ अर्थ लिए होती हैं। इन संबंधों को मानक बनाने से यह सुनिश्चित होता है कि दृश्य भाषा बोली गई भाषा के अनुरूप हो।
🔗 संबंधों के प्रकार
विभिन्न प्रकार की रेखाएँ विभिन्न प्रकार के बातचीत को दर्शाती हैं। संबंधों के लिए एक मानक शब्दावली में शामिल है:
- उपयोग करता है:एक निर्भरता को दर्शाता है। एक प्रणाली दूसरी प्रणाली को कॉल करती है, लेकिन जरूरी नहीं कि दूसरी प्रणाली का मालिक हो।
- संचार करता है:डेटा प्रवाह को दर्शाता है। सूचना दो प्रणालियों के बीच आती-जाती है।
- डेटा को रखता है:एक स्थायी संबंध को दर्शाता है। एक प्रणाली डेटाबेस में लिखती है।
- साक्ष्य प्रदान करता है:सुरक्षा संबंध को दर्शाता है।
जब अपनी शब्दावली में इन संबंधों को परिभाषित करते हैं, तो यह सुनिश्चित करें कि तीर की दिशा संगत हो। क्या तीर कॉलर की ओर या कॉली की ओर इशारा करता है? एक सामान्य प्रथा यह है कि तीर उस चीज़ की ओर इशारा करता है जिसे कॉल किया जा रहा है। इसे अपने शैली गाइड में दर्ज करना चाहिए ताकि सभी टीम सदस्य एक ही नियम का पालन करें।
🎨 रंग कोडिंग रणनीति
जबकि काला और सफेद प्रिंटिंग के लिए मानक है, रंग डिजिटल फॉर्मेट में पठनीयता को बढ़ा सकता है। हालांकि, रंग का अनियमित उपयोग नहीं करना चाहिए। रंगों के लिए अर्थ निर्धारित करें और उस पर टिके रहें।
- लाल:महत्वपूर्ण प्रणालियाँ या बाहरी निर्भरताएँ।
- नीला:आंतरिक कंटेनर या मुख्य सेवाएँ।
- हरा:वैकल्पिक या पृष्ठभूमि सेवाएँ।
- ग्रे:लोग या बाहरी प्रणालियाँ।
रंग का अत्यधिक उपयोग न करें। यदि प्रत्येक बॉक्स अलग-अलग रंग का है, तो आरेख एक विचलन बन जाता है। विशिष्ट अवस्थाओं या श्रेणियों को उजागर करने के लिए रंग का उपयोग करें, जैसे कि “अप्रचलित”, “बीटा”, या “उत्पादन के लिए केवल”। इससे दृश्य प्रतिनिधित्व में एक अर्थवाचक परत जोड़ी जाती है।
🔄 सारांश स्तर और दर्शक संरेखण
आर्किटेक्चर दस्तावेज़ीकरण में सबसे आम गलतियों में से एक एक ही आरेख में सभी जानकारी को फिट करने की कोशिश करना है। एक मानक शब्दावली प्रत्येक आरेख प्रकार की सीमाओं को परिभाषित करने में मदद करती है। प्रत्येक स्तर विशिष्ट आवश्यकताओं वाले विशिष्ट दर्शकों के लिए होता है।
👥 स्तर 1: संदर्भ आरेख
दर्शक समूह:हितधारक, उत्पाद प्रबंधक, नए कर्मचारी।
केंद्रित बिंदु:प्रणाली क्या करती है? इसका उपयोग कौन करता है? यह पारिस्थितिकी तंत्र में कहाँ फिट होती है?
शब्दावली:व्यापार क्षमताओं और बाहरी प्रणालियों पर ध्यान केंद्रित करें। तकनीकी जार्गन जैसे “API गेटवे” का उपयोग तब तक न करें जब तक यह व्यापार प्रवाह के लिए महत्वपूर्ण न हो।
🏗️ स्तर 2: कंटेनर आरेख
दर्शक समूह:सीनियर इंजीनियर, डेवोप्स, आर्किटेक्ट।
केंद्रित बिंदु:प्रणाली कैसे बनाई गई है? कौन सी तकनीकों का उपयोग किया गया है? डेटा प्रवाह का प्रबंधन कैसे किया जाता है?
शब्दावली:डेप्लॉयमेंट इकाइयों पर ध्यान केंद्रित करें। “सेवा”, “डेटाबेस”, “एप्लिकेशन”, और “फाइल स्टोर” जैसे शब्दों का उपयोग करें। HTTP, SQL या GraphQL जैसे प्रोटोकॉल के बारे में चर्चा करें।
🧩 स्तर 3: घटक आरेख
दर्शक समूह:विकास टीम, कोड मालिक।
केंद्रित बिंदु:कंटेनर के अंदर क्या है? कोड की संरचना कैसी है?
शब्दावली:वर्गों, मॉड्यूलों और फंक्शन्स पर ध्यान केंद्रित करें। आंतरिक तर्क और डेटा संरचनाओं के बारे में चर्चा करें। यहीं वास्तविक कार्यान्वयन विवरण स्थित होते हैं।
🛠️ मानक शब्दावली के लिए कार्यान्वयन चरण
इस शब्दावली को स्थापित करना एक बार का कार्य नहीं है। इसके लिए जानबूझकर प्रक्रिया की आवश्यकता होती है। नीचे एक चरणबद्ध दृष्टिकोण दिया गया है जिससे टीम के भीतर इन मानकों को लागू किया जा सकता है।
- वर्तमान स्थिति का मूल्यांकन करें:मौजूदा आरेखों का समीक्षा करें। नामकरण और प्रतीकों में असंगतियों को पहचानें। जहाँ भ्रम उत्पन्न होता है, उसके बारे में नोट करें।
- स्टाइल गाइड को परिभाषित करें:एक दस्तावेज़ बनाएं जिसमें सिस्टम, कंटेनर और घटक की परिभाषाएं शामिल हों। संबंध रेखाओं और रंग योजनाओं को परिभाषित करें। इसे सभी के लिए उपलब्ध बनाएं।
- टीम को प्रशिक्षित करें:कार्यशालाएं आयोजित करें। उदाहरणों के माध्यम से चलें। एक अच्छे आरेख और एक खराब आरेख के बीच अंतर दिखाएं।
- कार्यप्रवाह में एकीकृत करें: डायग्राम अपडेट को पुल रिक्वेस्ट प्रक्रिया का हिस्सा बनाएं। यदि कोई फीचर आर्किटेक्चर को बदलता है, तो डायग्राम को अपडेट किया जाना चाहिए।
- नियमित समीक्षाएं: तिमाही समीक्षाओं की योजना बनाएं। जांचें कि शब्दावली का पालन किया जा रहा है या नहीं। नए पैटर्न की पहचान करें जिन्हें परिभाषित करने की आवश्यकता है।
⚠️ बचने के लिए सामान्य त्रुटियां
यहां तक कि योजना होने पर भी टीमें अक्सर गलती करती हैं। सामान्य त्रुटियों के बारे में जागरूक होने से उन्हें बचने में मदद मिल सकती है।
- अत्यधिक डिज़ाइन करना: हर एक कोड लाइन के लिए डायग्राम न बनाएं। अबस्ट्रैक्शन के स्तर को उचित रखें। यदि एक डायग्राम बनाने में एक घंटा लगता है, तो यह संभवतः बहुत विस्तृत है।
- दर्शकों के ध्यान में न रखना: एक उत्पाद प्रबंधक को कंपोनेंट डायग्राम न दिखाएं। उन्हें आंतरिक तर्क देखने की आवश्यकता नहीं है। शब्दावली को पाठक के अनुसार ढालें।
- स्थिर दस्तावेज़ीकरण: जिन डायग्रामों को कभी अपडेट नहीं किया जाता है, वे झूठ बन जाते हैं। यदि कोड बदलता है लेकिन डायग्राम नहीं बदलता है, तो शब्दावली का अर्थ खो जाता है। डायग्रामों को जीवंत दस्तावेज़ों के रूप में लें।
- उपकरण पर निर्भरता: अपनी शब्दावली को किसी विशिष्ट सॉफ्टवेयर उत्पाद से न बांधें। यदि आप उपकरण बदलते हैं, तो “कंटेनर” का अर्थ वही रहना चाहिए। विशेषताओं के बजाय अवधारणाओं पर ध्यान केंद्रित करें।
🌱 लंबे समय तक सुसंगतता बनाए रखना
रखरखाव दस्तावेज़ीकरण का सबसे कठिन हिस्सा है। समय के साथ, प्रणालियां विकसित होती हैं। नए फीचर जोड़े जाते हैं और पुराने फीचर बंद कर दिए जाते हैं। शब्दावली को प्रणाली के साथ विकसित होना चाहिए।
एक प्रभावी रणनीति यह है कि शब्दावली को कोडबेस से जोड़ें। यदि किसी कंपोनेंट का नाम कोड में दिया गया है, तो डायग्राम में उसी नाम का उपयोग करना चाहिए। इससे डायग्राम को कोड से मैप करने के लिए मस्तिष्क के बोझ को कम किया जा सकता है। जब डेवलपर किसी क्लास का नाम बदलते हैं, तो उन्हें डायग्राम के नाम को भी अपडेट करने की याद दिलाई जानी चाहिए।
एक अन्य रणनीति यह है कि जहां संभव हो, स्वचालित उपकरणों का उपयोग करें। बहुत से आधुनिक प्लेटफॉर्म कोड अनोटेशन से डायग्राम बना सकते हैं। इससे शब्दावली को कार्यान्वयन के साथ समान रखने के लिए आवश्यक मैनुअल प्रयास को कम किया जा सकता है। हालांकि, स्वचालन मानव समीक्षा को बदल नहीं सकता है। वास्तुकारों को अभी भी यह सत्यापित करना होगा कि उत्पन्न डायग्राम इच्छित आर्किटेक्चर का सही प्रतिनिधित्व करते हैं।
🤝 स्पष्टता की संस्कृति बनाना
अंततः, मानक शब्दावली स्थापित करना एक सांस्कृतिक पहल है। इसके लिए नेतृत्व का समर्थन और इंजीनियरिंग टीम की भागीदारी की आवश्यकता होती है। जब सभी भाषा पर सहमत होते हैं, तो संचार बिना रुकावट के हो जाता है।
जब टीम सदस्य किसी अस्पष्ट शब्द से निपटते हैं, तो उन्हें प्रश्न पूछने के लिए प्रोत्साहित करें। यदि कोई शब्द अस्पष्ट है, तो उसकी परिभाषा लिखें। यदि परिभाषा गलत है, तो उसे सुधारें। इस चक्रीय प्रक्रिया से समय के साथ शब्दावली मजबूत होती है। यह दस्तावेज़ीकरण को एक ब्यूरोक्रेटिक आवश्यकता से इंजीनियरिंग उत्कृष्टता के लिए मूल्यवान उपकरण में बदल देती है।
इन सिद्धांतों का पालन करके, टीमें ऐसे आर्किटेक्चर डायग्राम बना सकती हैं जो प्रभावी संचार माध्यम के रूप में काम करें। वे विकास, रखरखाव और स्केलिंग को मार्गदर्शन करने वाले ब्लूप्रिंट बन जाते हैं। मानकीकरण में निवेश का लाभ कम त्रुटियों, तेजी से ओनबोर्डिंग और स्पष्ट निर्णय लेने में दिखाई देता है।
🚀 उत्तम व्यवहार का सारांश
सारांश के लिए, यहां अपनी मानक शब्दावली स्थापित करने के मुख्य बिंदु हैं:
- C4 मॉडल का उपयोग करें: संदर्भ, कंटेनर और कंपोनेंट के पदानुक्रम का लाभ उठाएं।
- शब्दों को स्पष्ट रूप से परिभाषित करें: अपने विशिष्ट संदर्भ में “कंटेनर” का क्या अर्थ है, उसे लिखें।
- दृश्यों को मानकीकृत करें: लाइन शैलियों और रंगों पर सहमति बनाएं।
- कोड को दस्तावेजों से मेल खाएं: सुनिश्चित करें कि आरेख के नाम कोड संरचनाओं के साथ मेल खाते हों।
- इसे अपडेट रखें: आरेखों को जीवंत सामग्री के रूप में लें।
- दर्शकों पर ध्यान केंद्रित करें: पाठक के लिए सही स्तर की विस्तार सुनिश्चित करें।
इन दिशानिर्देशों का पालन करने से आप स्थायी सॉफ्टवेयर आर्किटेक्चर के लिए आधार तैयार करते हैं। आप एक ऐसा वातावरण बनाते हैं जहां ज्ञान को कुशलतापूर्वक साझा किया जाता है और प्रणालियों को गहराई से समझा जाता है। यह प्रभावी तकनीकी संचार की आत्मा है।