यह मॉड्यूल किस सवाल का जवाब देता है: मैं ऐसा लैंडस्केप कैसे बनाऊँ जो दिखाए कि डेटा कहाँ जाता है?
मुझे एक नया परिदृश्य और एक खाली व्हाइटबोर्ड दीजिए, और सबसे पहले जो चीज़ें मैं बनाऊँगा, उनमें से एक है सिस्टम लैंडस्केप। सुंदर नहीं, हर API नहीं, अभी डेटा मॉडल भी नहीं। मैं एंटरप्राइज़ देखना चाहता हूँ: यूज़र कौन हैं, कौन-से सिस्टम शामिल हैं, Salesforce कहाँ बैठता है, उसके आसपास क्या है, डेटा कहाँ से आता है और कहाँ जाता है। और फिर मैं तीरों पर चलकर देखना चाहता हूँ। अच्छा लैंडस्केप बॉक्सों की तस्वीर नहीं होता। यह आर्किटेक्चर के फ़ैसलों को उजागर करने का एक तरीका है।
मैं CTA उम्मीदवारों से इसका अभ्यास करवाता हूँ। परिदृश्य पढ़ें, फिर बनाना शुरू करें। तब तक इंतज़ार न करें जब तक आप सब कुछ दिमाग में हल न कर लें; बनाना ही आपको हल करने में मदद करता है। इसीलिए पहले दिन के बाद का होमवर्क है डेटा मॉडल पर हाथ आज़माने से पहले लैंडस्केप शुरू करना। पहले डेटा मॉडल बनाएँ, और आप पहले ही मान चुके हैं कि Salesforce में क्या होना चाहिए। पहले लैंडस्केप बनाएँ, और आपको वे सिस्टम दिखते हैं जिन्हें उस फ़ैसले को आकार देना चाहिए।
ऊँचाई से शुरू करें, फिर नीचे उतरें: पहले पूरा एंटरप्राइज़, फिर जहाँ ज़रूरी हो वहाँ बारीकी।
सिस्टम लैंडस्केप बनाने के कई तरीके हैं। यह बस मेरा तरीका है, जिसे मैंने कई सालों में निखारा है, और मैं इसे इसलिए साझा कर रहा हूँ ताकि आप देख सकें कि इसे जल्दी कैसे खड़ा करें। मैं इसे हर Salesforce लैंडस्केप के लिए इस्तेमाल करता हूँ, और यह एक वाक्य की तरह पढ़ा जाता है: बाईं ओर के लोग बीच में Salesforce तक पहुँचते हैं, जिस पर भरोसा उसके ऊपर के सिस्टमों से आता है, जो उसके नीचे के चैनलों से सेवा देता है, और जो दाईं ओर बैक ऑफ़िस से जुड़ा है।
बाईं ओर लोग, ऊपर से नीचे: आंतरिक यूज़र, पार्टनर, ग्राहक। अभी हर persona नहीं; बस इतना कि जवाब मिल जाए इस आर्किटेक्चर तक कौन पहुँचना चाहता है? हर समूह उस ओर इशारा करता है जहाँ से वह अंदर आता है: आंतरिक यूज़र Salesforce की ओर, पार्टनर partner community की ओर, ग्राहक customer community की ओर। सिस्टम अपने-आप में मौजूद नहीं होते। कोई न कोई, या कुछ न कुछ, उन्हें इस्तेमाल करने की कोशिश कर रहा होता है।
चरण 2 (कुल 6 में से): इस आर्किटेक्चर तक कौन पहुँचना चाहता है?
बीच में Salesforce। एक सादा बॉक्स। इसलिए नहीं कि Salesforce एंटरप्राइज़ का केंद्र है (हमने अभी तीन मॉड्यूल यही कहने में बिताए कि वह नहीं है), बल्कि इसलिए कि यह वह सिस्टम है जिसके इर्द-गिर्द मैं डिज़ाइन कर रहा हूँ। यह लंगर है।
ठीक उसके नीचे communities, उससे सटी हुई। partner community और customer community अलग-अलग endpoints हैं, इसलिए उन्हें अपने बॉक्स मिलते हैं। लेकिन वे Salesforce से सटकर बैठती हैं, क्योंकि उन तक पहुँचने के लिए कुछ भी इंटीग्रेट नहीं करना पड़ता: वे उसी org में चलती हैं।
चरण 3 (कुल 6 में से): बीच में Salesforce, ठीक उसके नीचे communities।
ऊपर identity। identity providers सबसे ऊपर जाते हैं, वही जिन्हें डेवलपर भूल जाते हैं: एक आंतरिक यूज़र्स के लिए, शायद दूसरा पार्टनर्स के लिए। AppExchange packages भी ऊपर जाते हैं, थोड़ा दाईं ओर खिसके हुए, क्योंकि वे org में लाई गई क्षमताएँ हैं, न कि उसके साथ डेटा का लेन-देन करने वाले बैक ऑफ़िस सिस्टम। पब्लिक वेबसाइटें ऊपर बाईं ओर बैठती हैं।
चरण 4 (कुल 6 में से): ऊपर identity, वह बॉक्स जिसे डेवलपर भूल जाते हैं।
इंटीग्रेशन, फिर बैक ऑफ़िस, दाईं ओर। इंटीग्रेशन लेयर, एक ESB या iPaaS (या MuleSoft, जब उसका नाम लिया गया हो), Salesforce के ठीक दाईं ओर एक लंबी पट्टी है। आंतरिक सिस्टम उसके पीछे बैठते हैं: ERP, फ़ाइनेंस, ऑर्डर मैनेजमेंट, पुराने (legacy) सिस्टम, warehouse। अब पेज बाएँ से दाएँ पढ़ा जाता है: लोग, Salesforce, इंटीग्रेशन, बैक ऑफ़िस।
नीचे चैनल। जो कुछ भी ग्राहकों से सीधे जुड़ा है: email-to-case, web-to-lead, फ़ोन, मैसेजिंग।
नीचे दाईं ओर अंदर-बाहर आने-जाने वाला डेटा। बाहरी डेटा स्रोत, आर्काइव, डेटा लोड।
दाईं ओर, इंटीग्रेशन लेयर के नीचे Data 360। यूज़र कभी उससे नहीं जुड़ते, और उसका tenant बहुत-से back-end सिस्टमों से जुड़ता है, इसलिए वह plumbing के साथ बैठता है, जहाँ वे लाइनें छोटी रहती हैं: आंतरिक सिस्टमों, warehouse और नीचे दाईं ओर के डेटा के बगल में। डेटा टीमें उसकी स्क्रीनें खोलती तो हैं, लेकिन वे स्क्रीनें org में हैं: Data 360 near-core है, core पर मैनेज और core से बाहर होस्ट (मॉड्यूल 1)। Salesforce तक वापस जाती एक लाइन दिखाती है कि उसे कौन मैनेज करता है। आप बॉक्स कहाँ रखते हैं, उससे यह कहानी दिखनी चाहिए कि वह क्या करता है।
इस ज्यामिति में कुछ भी पवित्र नहीं है। किसी परिपाटी का फ़ायदा यह है कि मुझे हर बार दृश्य भाषा नए सिरे से नहीं गढ़नी पड़ती, और जिसने मेरा एक डायग्राम देखा है, वह अगला जल्दी पढ़ लेता है।
संकेत-पद्धति सरल रखें। हर सिस्टम एक कार्ड है: उसका नाम, उसकी भूमिका, और एक छोटा आइकन जो बताता है कि वह किस तरह की चीज़ है: एक ERP, एक डेटाबेस, एक identity provider, लोगों का एक समूह। जिन क्षेत्रों का मैंने अभी वर्णन किया, वे हल्के, लेबल वाले ज़ोन के रूप में बनाए जाते हैं, ताकि लेआउट खुद दिखे। नीचे एक legend बताता है कि हर आइकन और हर लाइन का मतलब क्या है।
किसी बॉक्स के अंदर बहुत कुछ न भरें। सिर्फ़ बहुत पेचीदा लैंडस्केप पर ही मैं Salesforce को उसके हिस्सों में खोलता हूँ (org के अंदर Sales Cloud और Service Cloud, उनके बीच तीरों के साथ)। और पंद्रह आकार तब तक न गढ़ें जब तक हर एक पढ़ने वाले को कुछ न बताए। मैं चाहता हूँ कि कोई तीस सेकंड लैंडस्केप को देखे और आर्किटेक्चर समझने लगे। सजावट मदद नहीं करती। स्पष्टता करती है।
वॉल्यूम के बारे में सोचने के लिए विस्तृत डिज़ाइन का इंतज़ार न करें। रात में 500 प्रोडक्ट ले जाने वाला तीर और रोज़ 200,000 GPS रीडिंग ले जाने वाला तीर लैंडस्केप पर बिल्कुल एक जैसे दिख सकते हैं। वे एक ही समस्या नहीं हैं। इसलिए एक भी तीर बनाने से पहले गिनें कि क्या चलता है। तस्वीर के पीछे की इन्वेंटरी गिनती से शुरू करें: हर अहम डेटा सेट के लिए एक पंक्ति, उसके वॉल्यूम के साथ। शून्य शायद कभी तीरों पर न दिखें, लेकिन आपको पता होना चाहिए कि आप कब बड़ी संख्याओं में दाख़िल होते हैं: एक घंटे में हज़ारों या लाखों, सैकड़ों हज़ार ट्रांज़ैक्शन, या एक सेकंड में दसियों से सैकड़ों ट्रांज़ैक्शन भी।
ये संख्याएँ तरीका तय करती हैं। रात में कुछ सौ रिकॉर्ड एक batch है। जिस कॉल का कोई इंतज़ार करता है, वह synchronous हो सकती है, अगर वॉल्यूम इजाज़त दे। एक सेकंड में दसियों से सैकड़ों के लिए हर रिकॉर्ड पर एक कॉल के बजाय events, जैसे platform events, चाहिए हो सकते हैं। तीर एक जैसा दिखेगा; वॉल्यूम तय करता है कि उसे कौन ले जाता है, इसलिए इसे इन्वेंटरी में दर्ज करें, जहाँ तरीका चुना जाता है।
तरीका तीर की दिशा भी बदल सकता है। एक मिनट में एक-दो रिकॉर्ड भेजें, तो Salesforce सीधे callout कर सकता है: तीर Salesforce से शुरू होता है। कहीं ज़्यादा भेजें, तो Salesforce इसके बजाय event bus पर events प्रकाशित कर सकता है; बाहरी सिस्टम subscribe करता है और उन्हें लेने के लिए अंदर कॉल करता है, तो अब तीर दूसरे सिरे से शुरू होता है। और बड़ा, मान लीजिए लाखों रिकॉर्ड का रात का sync, और यह एक batch प्रोसेस है। इसलिए जैसे ही आप तरीके डिज़ाइन करना शुरू करें, अपनी गिनती जल्दी जान लें, क्योंकि गिनती तीरों को दोबारा बना सकती है।
वॉल्यूम दो जगह, दो वजहों से मायने रखता है। डेटा मॉडल पर, मुझे इसकी ज़रूरत large data volumes पर नज़र रखने और आर्काइविंग की योजना के लिए है; भाग 2 इसमें गहराई से जाता है। सिस्टम लैंडस्केप पर, इन्वेंटरी की बड़ी संख्याएँ इंटीग्रेशन पैटर्न और तरीके का चुनाव तय करती हैं। मॉड्यूल 6 Steve Trucking के लैंडस्केप और उसकी इन्वेंटरी पर असली शून्य रखता है। गिनती हाथ में हो, तो तीर बनाएँ।
सिस्टम अपनी जगह पर हों, तो उन्हें जोड़ें, और लैंडस्केप आर्किटेक्चर बन जाता है। बॉक्स एक सिस्टम है; तीर दिखाता है कि कनेक्शन कौन शुरू करता है। वह उस सिस्टम से शुरू होता है जो कनेक्शन खोलता है और उस सिस्टम की ओर इशारा करता है जिसे वह कॉल करता है: client से server। लेबल बताता है कि क्या चलता है, और किस दिशा में।
यह नियम सिस्टम लैंडस्केप के लिए है, जहाँ सिस्टम सिस्टमों से बात कर रहे हैं। data-flow डायग्राम पर तीर डेटा के पीछे चलता है, जैसी आप उम्मीद करेंगे। लैंडस्केप का नियम दूसरे डायग्रामों में न ले जाएँ; इससे सिर्फ़ उलझन बढ़ती है।
तीर डाल दिए गए। हर बॉक्स वहीं है जहाँ था; हर तीर उस सिस्टम से शुरू होता है जो कनेक्शन खोलता है, और उसका लेबल बताता है कि क्या चलता है और किस दिशा में।
तो अगर इंटीग्रेशन लेयर प्रोडक्ट Salesforce में धकेलती है, तो तीर इंटीग्रेशन लेयर से Salesforce की ओर जाता है, लेबल प्रोडक्ट अंदर। अगर Salesforce उन्हें लाने के लिए बाहर कॉल करता है, तो तीर Salesforce से शुरू होता है, लेबल फिर भी प्रोडक्ट अंदर। वही डेटा, अलग बातचीत, और यही फ़र्क मुझे बताता है कि credentials किसे चाहिए और विफलता किसे संभालनी है। Salesforce ऑर्डर इंटीग्रेशन लेयर के ज़रिए भेजता है: ऑर्डर बाहर। ERP का fulfillment वापस आता है: ऑर्डर स्टेटस अंदर। अब मुझे दिखता है कि हर बातचीत कौन शुरू करता है, डेटा Salesforce में कहाँ आता है और कहाँ से जाता है, कौन-से flow सीमाएँ पार करते हैं, स्वामित्व शायद कहाँ है, और मुझे कहाँ और पूछना है।
और मॉड्यूल 1 याद रखें: जब भी मुझे सिर्फ़ एक flow दिखता है, मुझे चिंता होती है। ऊँचे स्तर पर, ऑर्डर बाहर वाला तीर वापसी वाले flow पर निर्भर है: ग्राहक अंदर, प्रोडक्ट अंदर, कीमतें। और गहराई में देखें तो वापसी की यात्रा है: स्वीकृति, अस्वीकृति, स्टेटस, एक इनवॉइस नंबर, एक रद्दीकरण। तीर मुझे चुनौती देने के लिए कुछ ठोस देते हैं।
यहीं लैंडस्केप PowerPoint की कलाकारी नहीं रह जाता। review board पर कोई भी तीर तीन सवाल खड़े कर सकता है, और मैं चाहता हूँ कि आपके पास जवाब हों:
यह कैसे ऑथेंटिकेट करता है? OAuth, एक सर्टिफ़िकेट, एक named credential, या कुछ और?
यह synchronous है या asynchronous? क्या Salesforce ERP का इंतज़ार करता है, या प्रकाशित करके आगे बढ़ जाता है? बिज़नेस को नतीजा कितनी जल्दी चाहिए?
तरीका क्या है? एक REST कॉल, एक event, एक फ़ाइल, एक message queue, MuleSoft के ज़रिए या सीधे?
और फिर: जब दूसरी तरफ़ का सिस्टम बंद हो तो क्या होता है? हर तीर को एक तरीका चाहिए। अगर आप उसे समझा नहीं सकते, तो वह लाइन बस सजावट है।
और “fire and forget” कोई जवाब नहीं है। आमतौर पर इसका मतलब होता है “मैंने डिज़ाइन नहीं किया कि fire के बाद क्या होता है।” क्या वह पहुँचा? स्वीकार हुआ? विफल हुआ? दोबारा कोशिश होगी? किसे पता है कि वह अटका है? अगर वही संदेश दो बार आए तो? इसमें से कुछ भी लैंडस्केप पर नहीं जाता, वरना वह पढ़ने लायक नहीं रहेगा। लेकिन तीर से आपको पता होना चाहिए कि ये सवाल मौजूद हैं।
किसी भी एक तीर को ज़ूम करके देखें, तो वहाँ एक client और एक server है, और हर एक अपने आधे हिस्से का मालिक है। client कनेक्शन खोलता है: उसे endpoint और port चाहिए, वह पहले authentication server से एक token लेता है, server के तय किए protocol और कॉन्ट्रैक्ट को कॉल करता है, और चुनता है कि इंतज़ार करे या नहीं। पूरा आना-जाना सिर्फ़ client देखता है, इसलिए दोबारा कोशिश सिर्फ़ client कर सकता है। server सुनता है, protocol, कॉन्ट्रैक्ट और payload तय करता है, आने वाली चीज़ को validate करता है, और सिर्फ़ अपना हिस्सा देखता है। जब मैं तीर बनाता हूँ, तो मुझे पहले से पता होता है कि कौन-सा सिरा कौन-सा है, और इससे पता चलता है कि इनमें से हर सवाल का मालिक कौन है।
एक तीर, ज़ूम करके: client संभालता है, server तय करता है। इसमें से कुछ भी लैंडस्केप पर नहीं जाता, लेकिन हर तीर में यह होता है।
अब तीर को पलट दें। जब ERP Salesforce को कॉल करता है, तो Salesforce server है: वह API तय करता है, अपना authorization server चलाता है, और एक External Client App और एक इंटीग्रेशन यूज़र के ज़रिए तय करता है कि कॉल करने वाला क्या कर सकता है। वही सवाल, दूसरी तरफ़।
यहीं आर्किटेक्ट एक अच्छे डायग्राम को बर्बाद कर देते हैं: वे एक ही चीज़ से हर सवाल का जवाब दिलवाना चाहते हैं। लैंडस्केप पर API नाम, payload, retries, error queues, transformations, हर callback आ जाता है, और जल्दी ही कोई उसे पढ़ नहीं पाता। ऐसा न करें। लैंडस्केप बड़ी तस्वीर है: सिस्टम और उनके बीच के अहम flow।
जब मुझे कोई interaction समझाना होता है, तो मैं दूसरा डायग्राम बनाता हूँ, लेकिन हर इंटीग्रेशन के लिए नहीं। अगर सिस्टम A, B को कुछ भेजता है, या पूछकर जवाब भी पाता है, तो लेबल वाला तीर काफ़ी है। मुझे swim lane तब चाहिए जब प्रोसेस एक बातचीत बन जाए: A, B को कॉल करता है, B, C से जाँचता है, C जवाब देता है, B कुछ बनाता है और A को वापस कॉल करता है, कोई व्यक्ति मंज़ूरी देता है, कोई और सिस्टम आगे बढ़ाता है। मेरा मोटा नियम: एक-दो से ज़्यादा बार आगे-पीछे का लेन-देन हो, तो उस क्रम को उसकी अपनी swim lane मिलती है। तीर लैंडस्केप पर; बातचीत swim lane में।
और गौर करें कि वहाँ तीर का मतलब कुछ और है। लैंडस्केप पर तीर एक कनेक्शन है: उसे कौन खोलता है, और क्या चलता है। swim lane में हर तीर बातचीत का एक संदेश है, जिसे क्रम से पढ़ा जाता है: एक अनुरोध एक ओर जाता है, जवाब दूसरी ओर से आता है, और अगला कदम उसके बाद आता है।
जब लैंडस्केप लगभग पूरा लगे, तो उस पर चलें, तीर-दर-तीर। ERP से Salesforce: क्या चल रहा है, इसका मालिक कौन है, यह कैसे ऑथेंटिकेट करता है, तरीका क्या है, sync या async, इसे कितना ताज़ा होना चाहिए? फिर अगला तीर, और उसके बाद वाला। यहीं कमियाँ दिखती हैं। “अरे, हमने कभी तय ही नहीं किया कि पार्टनर असल में वह चीज़ कैसे भेजता है।” “हम ERP को ऑर्डर भेजते हैं, लेकिन हमने डिज़ाइन नहीं किया कि ठुकराए गए ऑर्डर वापस कैसे आते हैं।” अच्छा है। आपने इसे production के बजाय व्हाइटबोर्ड पर पकड़ लिया।
तस्वीर को पढ़ने लायक रहना है, इसलिए बारीकियाँ उसके पीछे की इन्वेंटरी में जाती हैं। आपने इसे गिनती से शुरू किया था; अब इसे पूरा करें, हर अहम डेटा सेट या flow के लिए एक पंक्ति:
इसीलिए मुझे यह चीज़ पसंद है: यह मुझे सोचने में मदद करती है। “हम Salesforce और ERP दोनों पर रिपोर्ट कैसे बनाएँगे?” यह मॉड्यूल 3 वाला सवाल है: मेरा कौन-सा डायग्राम इसे बेहतरीन ढंग से हल करता है? लैंडस्केप। अगर सब कुछ core पर है, तो स्टैंडर्ड रिपोर्ट। अगर डेटा ERP और warehouse में है, तो आपको तुरंत दिख जाता है। “ग्राहक के इस एट्रिब्यूट को कहाँ मास्टर किया जाए?” देखें कि कौन-से सिस्टम इसे इस्तेमाल करते हैं और ग्राहक का मालिक पहले से कौन है। “क्या Salesforce को हर GPS रीडिंग चाहिए?” इसे कौन बनाता है, कौन इस्तेमाल करता है, वर्कलोड क्या है? शायद Salesforce को मौजूदा स्थिति (position) चाहिए और इतिहास कोई और प्लेटफ़ॉर्म रखे। लैंडस्केप आपको जवाब नहीं थमाता। वह आपको समस्या का सही नज़ारा देता है।
एक और अनुशासन। किसी मौजूदा एंटरप्राइज़ में वह बनाएँ जो मौजूद है, वह नहीं जो आप चाहते हैं कि मौजूद होता। हर शुक्रवार ईमेल होने वाली spreadsheet: उसे बनाएँ। SFTP सर्वर पर पार्टनर की CSV: उसे बनाएँ। ऐतिहासिक वजहों से ESB को बायपास करने वाला इंटीग्रेशन: उसे बनाएँ। दो सिस्टमों के बीच हाथ से डेटा दोबारा टाइप करते लोग: उन्हें दिखाएँ। दर्ज करते समय असलियत को साफ़-सुथरा न करें। लक्ष्य वाला लैंडस्केप डिज़ाइन करने से पहले आपको मौजूदा लैंडस्केप चाहिए, और मॉड्यूल 6 में हम Steve Trucking के लिए यही करते हैं।
परीक्षा से आगे: AI क्या बदलता है। लैंडस्केप एक एजेंट मैप बनता जा रहा है। अगर कोई एजेंट “मेरी डिलीवरी कहाँ है?” का जवाब देता है, तो लैंडस्केप को बताना होगा कि जवाब Salesforce से आता है, किसी पार्टनर सिस्टम से, telematics से, ERP से, या इनके मेल से। एजेंट सिस्टमों की सीमाएँ नहीं हटाते; वे यह जानना और भी अहम बना देते हैं कि कौन-सा सिस्टम आधिकारिक है, और उस तक सुरक्षित रूप से कैसे पहुँचें।
लैंडस्केप पर कौन-से सिस्टम और यूज़र समूह होने चाहिए, और उनकी जगह उनकी भूमिका कैसे दिखाती है।
कौन-से flow सिस्टमों की सीमाएँ पार करते हैं, किस दिशा में, और क्या वापस आता है।
हर कनेक्शन कैसे ऑथेंटिकेट करता है, उसे कौन-सा तरीका ले जाता है, और वह synchronous, asynchronous, batch या federated है।
कब लेबल वाला तीर काफ़ी है और कब किसी interaction को उसकी अपनी swim lane चाहिए।
तस्वीर के पीछे की इन्वेंटरी क्या दर्ज करती है: मालिक, वर्कलोड, वॉल्यूम, org, टाइमिंग, ऑथेंटिकेशन, और कॉपी, संदर्भ या federate।
लैंडस्केप ऐसी चीज़ नहीं जिसे मैं आर्किटेक्चर पूरा होने के बाद बनाता हूँ। यह वह तरीका है जिससे मैं आर्किटेक्चर ढूँढता हूँ। और जब आपको लगे कि यह पूरा हो गया, तो इसकी तारीफ़ न करें। इस पर चलकर देखें। हर वह तीर जिसे आप अभी समझा नहीं सकते, आपको दिखाता है कि काम कहाँ बाकी है।
