Steve Trucking का लैंडस्केप

🌐 28 अन्य भाषाओं में भी उपलब्ध

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI से बनाई गई इमेज

AI द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मॉड्यूल 6 (कुल 6 में से) — अध्याय एंटरप्राइज़ डेटा को समझना, Data Architect कोर्स का अध्याय 4। हर मॉड्यूल अपने आप में पूरा है। पिछला: org रणनीति लैंडस्केप का फ़ैसला है · अगला: अगला अध्याय, डेटा गुणवत्ता और गवर्नेंस

यह मॉड्यूल किस सवाल का जवाब देता है: कुछ भी डिज़ाइन करने से पहले एक असली लैंडस्केप हमें क्या बताता है?

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

जो हम जानते हैं, वहीं से शुरू करें

Steve Trucking अमेरिका में एक Salesforce org चलाता है। Service Cloud प्राप्तकर्ताओं (Recipients) और रिटेल पार्टनर्स (Retail Partners) के केस संभालता है; Field Service अपॉइंटमेंट, क्रू और मोबाइल ऐप चलाता है; Experience Cloud रिटेल पार्टनर्स को एक पोर्टल देता है, जो आज सिर्फ़ क्लेम और रिपोर्ट के लिए इस्तेमाल होता है; Sales Cloud पार्टनर कॉन्ट्रैक्ट और नए DC के लिए बोलियाँ ट्रैक करता है। तो Salesforce बीच में आता है।

बाईं ओर लोग: रिटेल पार्टनर्स के DC के अंदर काम करने वाले 45 डिस्पैच कोऑर्डिनेटर, 330 ट्रकों पर लगभग 700 क्रू सदस्य, 60 कस्टमर-केयर एजेंट, ऑपरेशंस, फ़ाइनेंस और सेल्स के 40 कर्मचारी, और रिटेल पार्टनर्स के लगभग 300 यूज़र। इससे हमें पहले ही कुछ पता चलता है: यह किसी एक विभाग का CRM नहीं है। यह ज़्यादातर बिज़नेस के लिए एक ऑपरेशनल प्लेटफ़ॉर्म है। लेकिन फिर भी यह एक ही बॉक्स है। अब देखते हैं कि इसके चारों ओर क्या है।

Click to enlarge

सही इम्प्लीमेंटेशन से पहले, आज का Steve Trucking। हर मैनिफ़ेस्ट RouteDesk में आता है; कोऑर्डिनेटर रूट हाथ से Salesforce में और पूरे हुए स्टॉप वापस टाइप करते हैं; FleetLink का कनेक्शन गायब है।

जो गलत है, उसे चिह्नित करें

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

तीन पार्टनर, तीन इंटीग्रेशन

तीनों रिटेल पार्टनर तीन अलग तरीकों से मैनिफ़ेस्ट भेजते हैं, इसलिए हर एक को अलग बनाएँ।

Keystone हर दोपहर एक SFTP सर्वर पर CSV मैनिफ़ेस्ट डालता है, दो दिन बाद की डिलीवरी के लिए, और हर रात एक स्टेटस फ़ाइल वापस चाहता है। दो तीर: मैनिफ़ेस्ट फ़ाइल से अंदर, जिसे Keystone शुरू करता है, और स्टेटस फ़ाइल से बाहर, जिसे RouteDesk शुरू करता है। एसिंक्रोनस, और समय की चौड़ी गुंजाइश के साथ।

Redrock REST API से मैनिफ़ेस्ट भेजता है और उम्मीद करता है कि स्टेटस अपडेट वेबहुक से उसी समय आएँ जब वे होते हैं। दो तीर, दो तरीके: Redrock API के ज़रिए मैनिफ़ेस्ट लेकर अंदर कॉल करता है, और RouteDesk वेबहुक के ज़रिए स्टेटस लेकर बाहर कॉल करता है। लगभग रियल टाइम।

Brightwave एक थर्ड-पार्टी नेटवर्क के ज़रिए EDI फ़ाइलें भेजता है और बदले में EDI स्टेटस संदेश चाहता है। एक और फ़ॉर्मेट, एक और तरीका।

वही बिज़नेस अवधारणाएँ (मैनिफ़ेस्ट, डिलीवरी, स्टेटस), तीन बिल्कुल अलग इंटीग्रेशन। ड्रॉइंग को इसलिए सरल न बनाएँ कि आप चाहते हैं कि वे एक जैसे हों। वे एक जैसे नहीं हैं। यही मौजूदा स्थिति है।

फिर उन पर चलकर देखें। Keystone: SFTP कनेक्शन कैसे ऑथेंटिकेट होता है, फ़ाइल कहाँ पहुँचती है, उसे कौन उठाता है, हमें कैसे पता चलता है कि पूरी फ़ाइल प्रोसेस हो गई, खराब पंक्ति का क्या होता है, और आज रात की फ़ाइल से पहले Keystone को किसी बदलाव का पता कैसे चलता है? Redrock: API कैसे ऑथेंटिकेट होता है, जब किसी एक तरफ़ का सिस्टम बंद हो तो क्या होता है, सफल वेबहुक किसे माना जाता है, अगर वही स्टेटस दो बार आए तो? Brightwave: EDI नेटवर्क कौन चलाता है, अनुवाद (translation) कहाँ होता है, कौन-सी पावतियाँ (acknowledgments) वापस आती हैं? हम कुछ भी दोबारा डिज़ाइन नहीं कर रहे। हम सवाल खोज रहे हैं। यही लैंडस्केप का काम है।

RouteDesk अब भी वहीं है

RouteDesk पुराना (legacy) डेस्कटॉप डिस्पैच और रूटिंग टूल है, जिससे हर DC में कोऑर्डिनेटर मैनिफ़ेस्ट को रूट में बदलते हैं। इसमें आठ साल का डिलीवरी इतिहास है, और इसे बंद करने की योजना है। फिर भी इसे बनाएँ। एक आम गलती है उस सिस्टम को छोड़ देना “जिससे हम छुटकारा पा रहे हैं।” कब? मान लीजिए जवाब है अठारह महीने। तो कम से कम अठारह महीने यह आर्किटेक्चर का हिस्सा है, और इसका आठ साल का इतिहास, लगभग पाँच मिलियन डिलीवरी, एप्लिकेशन के जाने के साथ गायब नहीं हो जाता। और देखें कि लैंडस्केप क्या उजागर करता है: RouteDesk और Salesforce जुड़े हुए नहीं हैं। क्रू अपने स्टॉप Salesforce के Field Service ऐप में करते हैं, लेकिन रूट RouteDesk में बनते हैं, इसलिए कोऑर्डिनेटर हर शाम उन्हें Salesforce में दोबारा टाइप करते हैं, फिर पूरे हुए स्टॉप वापस RouteDesk में टाइप करते हैं ताकि वह पार्टनर्स को स्टेटस भेज सके। रोज़ लगभग 3,300 स्टॉप, दो बार, हाथ से। ड्रॉइंग पर यह डैश वाला और लाल है। इससे यह भी पता चलता है कि Redrock का “उसी समय” वाला वेबहुक असल में उसी समय नहीं है। आज RouteDesk किस चीज़ का मालिक है? उस पर क्या निर्भर है? कौन-सा इतिहास उसके बाद भी बचा रहना चाहिए, और कहाँ: Salesforce, वेयरहाउस, या कोई आर्काइव? हम अभी जवाब नहीं दे रहे। लैंडस्केप ने बस सवाल उजागर कर दिए।

FleetLink एक टापू है

FleetLink, यानी टेलीमैटिक्स प्लेटफ़ॉर्म, हर ट्रक से GPS लेता है: रोज़ लगभग 200,000 रीडिंग, हर ट्रक से, चलते समय हर मिनट। और यह किसी चीज़ से जुड़ा नहीं है। कोऑर्डिनेटर इसे एक अलग स्क्रीन पर देखते हैं। तो FleetLink को बिना किसी तीर के बनाएँ। कोई जादुई इंटीग्रेशन रेखा नहीं, सिर्फ़ इसलिए कि हमें लगता है कि एक होनी चाहिए।

फिर शून्य गिनें: रोज़ 200,000 का मतलब है साल में 70 मिलियन से ज़्यादा। यह “हमारे पास GPS डेटा है” वाली बात नहीं है। यह बहुत सारे शून्यों वाला एक स्ट्रीमिंग स्रोत है, जो Salesforce के अनुभव से बाहर बैठा है। क्या Salesforce को साल में 70 मिलियन रीडिंग चाहिए? शायद सारी नहीं। यह बाद के लिए एक डिज़ाइन सवाल है।

फ़ाइनेंस का अपना सच है

फ़ाइनेंस ERP हर रिटेल पार्टनर को हर डिलीवरी, इंस्टॉल और पुराना सामान ले जाने (haul-away) का बिल भेजता है, और क्रू के इंसेंटिव चुकाता है। और डिलीवरी की गिनती उस तक एक मासिक स्प्रेडशीट से पहुँचती है। स्प्रेडशीट बनाएँ। उसकी जगह एक साफ़-सुथरा API तीर न लगाएँ, सिर्फ़ इसलिए कि हम आर्किटेक्ट हैं और बेहतर जानते हैं; यह मौजूदा आर्किटेक्चर का हिस्सा है। और एक बार बन जाए, तो सवाल आते हैं: इसे कौन बनाता है, किस सिस्टम से, कौन जाँचता है, भेजने के बाद कोई डिलीवरी बदल जाए तो क्या, और किसका आँकड़ा माना जाएगा? इन जवाबों से पैसा जुड़ा है।

Snowflake को हफ़्ते में एक बार एक्सपोर्ट मिलता है

Snowflake में ऑपरेशंस और फ़ाइनेंस एनालिटिक्स है, जिसे एक साप्ताहिक एक्सपोर्ट से भरा जाता है। Snowflake यह खुद नहीं कर सकता; बीच में कुछ और करता है: एक शेड्यूल्ड एक्सपोर्ट जॉब, जो Salesforce से बाहर चलता है, Bulk API से डेटा खींचता है और Snowflake में लोड करता है। एनालिटिक्स वहीं रहता है जहाँ डेटा रहता है, और Snowflake पहले से एनालिटिक्स का घर है। लेकिन समय भी हमें कुछ बताता है। “पिछले महीने क्या हुआ?” साप्ताहिक फ़ीड ठीक है। “यह डिलीवरी अभी कहाँ है?” वहाँ मैं Snowflake से शुरुआत नहीं करूँगा। वही एंटरप्राइज़, अलग वर्कलोड, अलग ताज़गी, अलग जवाब।

आइडेंटिटी हर किसी तक एक ही तरह नहीं पहुँचती

कॉर्पोरेट आइडेंटिटी प्रोवाइडर Salesforce के ऊपर आता है। ऑफ़िस स्टाफ़ सिंगल साइन-ऑन इस्तेमाल करता है। लेकिन कोऑर्डिनेटर और क्रू Salesforce क्रेडेंशियल से लॉग इन करते हैं। तो IdP से Salesforce तक एक ही भरोसे की रेखा आधी कहानी छिपा देगी। असली सवाल यह है कि कौन-से यूज़र किस रास्ते से साइन इन करते हैं, और यह लैंडस्केप पर होना चाहिए।

प्राप्तकर्ता के अनुभव में एक कमी है

SMS और ईमेल प्रोवाइडर RouteDesk की ओर से प्राप्तकर्ताओं को एक आम “आपकी डिलीवरी कल है” संदेश भेजता है। कोई ट्रैकिंग लिंक नहीं है। इस बीच साल में लगभग 180,000 केस आते हैं, और उनमें से लगभग 60% हैं “मेरी डिलीवरी कहाँ है?”: साल में लगभग 108,000 केस, एक ही सवाल पूछते हुए। अब इसे FleetLink के बगल में रखें। कंपनी जानती है कि उसके ट्रक कहाँ हैं। उसके प्राप्तकर्ता बार-बार फ़ोन करके पूछते हैं। और जो सिस्टम जानता है, वह जवाब देने वाले सिस्टम से जुड़ा नहीं है। मुझे अभी हल डिज़ाइन करने की ज़रूरत नहीं है। लैंडस्केप पहले से कहानी बता रहा है।

शून्य इन्वेंटरी में डालें

अब गिनें कि क्या चलता है। मॉड्यूल 4 की तरह, शून्य तीरों पर नहीं जाते; वे तस्वीर के पीछे की इन्वेंटरी में जाते हैं, जहाँ डिज़ाइन करते समय वे तरीकों को तय करेंगे। साल में लगभग एक मिलियन डिलीवरी, रोज़ लगभग 3,300, हर साल 30% की बढ़त; हर डिलीवरी में लगभग 1.6 लाइन आइटम; हर डिलीवरी के लगभग आठ स्टेटस अपडेट, यानी आज साल में आठ मिलियन स्टेटस अपडेट; साल में चार से पाँच मिलियन फ़ोटो, जो अभी क्रू के अपने फ़ोन पर हैं; रोज़ लगभग 200,000 GPS रीडिंग; साल में लगभग 180,000 केस। “डिलीवरी स्टेटस” लिखा तीर कोई कभी-कभार का संदेश नहीं है। बॉक्स बताते हैं कि क्या मौजूद है। तीर बताते हैं कि क्या चलता है। शून्य बताते हैं कि आपकी धारणाएँ हकीकत के सामने टिकती हैं या नहीं।

Click to enlarge

Steve Trucking के लैंडस्केप के पीछे की इन्वेंटरी: मात्रा उस तरीके के बगल में, जिसे वह तय करेगी।

अभी कोई टारगेट आर्किटेक्चर नहीं, और फिर भी मैं देख सकता हूँ कि ज़रूरी डेटा कहाँ रहता है, वह किस प्रकार का है, कितनी तेज़ी से चलता है और सिस्टम उसे कैसे आपस में लेते-देते हैं।

परीक्षा से आगे: AI क्या बदलता है। मान लीजिए Steve Trucking किसी प्राप्तकर्ता के “मेरी डिलीवरी कहाँ है?” का जवाब देने के लिए एक एजेंट बनाता है। उसे किस सिस्टम से पूछना चाहिए? Salesforce अपॉइंटमेंट जानता है, FleetLink जानता है कि ट्रक कहाँ है, और पार्टनर के मैनिफ़ेस्ट ने डिलीवरी तय की। मौजूदा लैंडस्केप एजेंट का नक्शा है, और इससे पहले कि एजेंट सुरक्षित रूप से जवाब दे सके, आर्किटेक्ट को पता होना चाहिए कि हर तथ्य के लिए कौन-सा सिस्टम आधिकारिक है और वह कितना ताज़ा है। एजेंट को गलत स्रोत की ओर कर दें, और पुराना डेटा एक आत्मविश्वास भरा जवाब बन जाता है।

दर्द को पढ़ें, अभी ठीक न करें

थोड़ा पीछे हटकर देखें। तीन पार्टनर, तीन इंटीग्रेशन शैलियाँ। आठ साल का इतिहास रखने वाला एक पुराना डिस्पैच टूल, और कोऑर्डिनेटर रोज़ 3,300 स्टॉप Salesforce में और वापस दोबारा टाइप करते हुए। रोज़ 200,000 रीडिंग वाला एक टेलीमैटिक्स प्लेटफ़ॉर्म, जो जुड़ा नहीं है। फ़ाइनेंस एक मासिक स्प्रेडशीट से डिलीवरी गिनता हुआ। एनालिटिक्स एक हफ़्ता पीछे। कुछ यूज़र के लिए सिंगल साइन-ऑन, बाकियों के लिए नहीं। कोई ट्रैकिंग लिंक नहीं, और साल में 108,000 केस पूछते हुए कि डिलीवरी कहाँ है। और सब कुछ हर साल 30% बढ़ता हुआ।

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

आर्किटेक्ट यहाँ क्या तय करता है

इस चरण में आर्किटेक्ट टारगेट आर्किटेक्चर तय नहीं कर रहा। फ़ैसला यह है कि क्या मौजूदा स्थिति इतनी अच्छी तरह समझ ली गई है कि उसके आधार पर डिज़ाइन किया जा सके:

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

यह अध्याय एक विचार से शुरू हुआ था: org डिज़ाइन करने से पहले लैंडस्केप बनाएँ। अगर मैंने Steve Trucking के डेटा मॉडल से शुरुआत की होती, तो मैं ऑब्जेक्ट और संबंधों पर घंटों लगा सकता था, जबकि FleetLink रोज़ 200,000 रीडिंग के साथ बाहर बैठा रहता, RouteDesk आठ साल का इतिहास रखे रहता, तीन पार्टनर तीन भाषाएँ बोलते, फ़ाइनेंस स्प्रेडशीट चलाता, और साल में करीब 100,000 केस पूछते कि डिलीवरी कहाँ है। ये ऑब्जेक्ट मॉडल के सवाल नहीं हैं। ये एंटरप्राइज़ डेटा के सवाल हैं। बदसूरत इंटीग्रेशन, स्प्रेडशीट, और वह सिस्टम जिसे आप कथित तौर पर बंद कर रहे हैं, सब बनाएँ। शून्य लिख लें। हर तीर पर चलकर देखें। तब आप उसे बदलने के लिए तैयार हैं।

और जानें

• Steve Trucking का ब्रीफ़, सेक्शन 2–4, और उसका लैंडस्केप डायग्राम।