शेयर्ड डेटा लेयर पॉइंट-टू-पॉइंट इंटीग्रेशन को क्यों हरा देती है

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

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

गणित तेज़ी से बदसूरत हो जाता है

पॉइंट-टू-पॉइंट एक शुद्ध कॉम्बिनेटोरियल वजह से खराब तरीके से स्केल करता है। n सिस्टम के साथ, संभावित डायरेक्ट कनेक्शन की संख्या है n(n-1)/2। तीन टूल्स को ज़्यादा से ज़्यादा तीन इंटीग्रेशन चाहिए, जो कुछ भी नहीं है। दस टूल्स को ज़्यादा से ज़्यादा पैंतालीस चाहिए। और हर इंटीग्रेशन एक पाइप नहीं है। यह फील्ड मैपिंग का एक सेट, एक सिंक शेड्यूल, एक ट्रांसफॉर्मेशन, और एक फेलियर मोड है। इसे पैंतालीस से गुणा करें और आपके पास एक मेंटेनेंस सतह है जिसे कोई भी टीम साफ नहीं रख सकती।

एक शेयर्ड लेयर गणित बदल देती है। हर सिस्टम हब के साथ एक बार इंटीग्रेट होता है, तो n सिस्टम को n कनेक्शन चाहिए। ग्रोथ क्वाड्रेटिक से लीनियर हो जाती है। ज़्यादा महत्वपूर्ण, सिमैंटिक्स एक जगह रहते हैं। "MQL" या "एक्टिव अपॉर्चुनिटी" का मतलब क्या है इस पर पैंतालीस थोड़ी अलग राय के बजाय, एक कैनोनिकल परिभाषा है जिसे हर टूल विरासत में पाता है।

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

"शेयर्ड डेटा लेयर" का असल में क्या मतलब है

एक शेयर्ड डेटा लेयर एक डेटाबेस से ज़्यादा है जिसे सब क्वेरी कर सकते हैं। तीन गुण इसे एक शेयर्ड डंपिंग ग्राउंड से अलग करते हैं।

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

एक स्पष्ट स्कीमा। हर कंज़्यूमिंग सिस्टम एक डॉक्यूमेंटेड, वर्ज़न्ड स्कीमा के खिलाफ पढ़ता है। जब स्कीमा बदलती है, कंज़्यूमर को बताया जाता है। वे इसे प्रोडक्शन में खोजते नहीं।

द्विदिशीय प्रवाह। लेयर सिर्फ रीड-ओनली नहीं है। केंद्रीय रूप से कंप्यूट किए गए इनसाइट्स एक अनुशासित राइट-बैक लेयर के ज़रिए एक्शन सिस्टम में वापस लिखे जाते हैं, ताकि हब दोनों दिशाओं में सोर्स ऑफ ट्रुथ हो।

इन तीनों के बिना, आपके पास जो है वह एक डेटा लेक है जो बीच में बैठा है, और यह अतिरिक्त कदमों के साथ पॉइंट-टू-पॉइंट गड़बड़ी को दोहराता है।

एक परिदृश्य में यह कैसा दिखता है

एक मिड-मार्केट SaaS कंपनी एक CRM, एक मार्केटिंग ऑटोमेशन प्लेटफॉर्म, एक प्रोडक्ट एनालिटिक्स टूल, एक बिलिंग सिस्टम, और एक वेयरहाउस चलाती है। टीम चाहती है लीड स्कोरिंग जो मार्केटिंग एंगेजमेंट, प्रोडक्ट यूसेज, और अकाउंट फर्मोग्राफिक्स को मिलाए।

पॉइंट-टू-पॉइंट: मार्केटिंग ऑटोमेशन CRM में सिंक होता है। प्रोडक्ट एनालिटिक्स एंगेजमेंट स्कोरिंग के लिए मार्केटिंग ऑटोमेशन में सिंक होता है। बिलिंग रिन्यूअल फ्लैग के लिए CRM में सिंक होता है। वेयरहाउस इन तीनों से अलग शेड्यूल पर खींचता है। लीड स्कोर मार्केटिंग ऑटोमेशन में एक आंशिक व्यू से कंप्यूट होता है, फिर CRM में कंप्यूट किए गए एक अलग स्कोर से ओवरराइट हो जाता है। दो स्कोर मौजूद हैं, वे असहमत हैं, और रेप्स एक महीने के भीतर दोनों पर भरोसा करना बंद कर देते हैं।

शेयर्ड लेयर: सभी चार सिस्टम हब को फीड करते हैं। एंटिटी रिज़ॉल्यूशन प्रोडक्ट अकाउंट, बिलिंग अकाउंट, और CRM अकाउंट को एक कैनोनिकल अकाउंट में सिलाई करता है। स्कोर एक बार, पूरी तस्वीर पर कंप्यूट होता है, और CRM और मार्केटिंग प्लेटफॉर्म में समान रूप से वापस लिखा जाता है। एक स्कोर, और यह समझाने योग्य है क्योंकि हर इनपुट एक जगह है।

दूसरा सेटअप ही इकलौता है जहां कोई भी स्कोर पर भरोसा कर सकता है, क्योंकि किसी मेट्रिक में भरोसा इस बात पर निर्भर करता है कि उसके पीछे एक ही लाइनेज हो।

पॉइंट-टू-पॉइंट कब ठीक है

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

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

उलझन सुलझाना

अगर आपके पास पहले से उलझन है, तो आप इसे रातोंरात नहीं उखाड़ते। जो रास्ता काम करता है:

1. हर मौजूदा इंटीग्रेशन और जिन फील्ड्स को यह छूता है उन्हें इन्वेंटरी करें। ज़्यादातर टीमें उम्मीद से ज़्यादा पाती हैं, कभी-कभी बहुत ज़्यादा।
2. शेयर्ड लेयर खड़ी करें और पहले सबसे ज़्यादा वैल्यू वाले सिस्टम ऑफ रिकॉर्ड को कनेक्ट करें। आमतौर पर यह CRM है।
3. एक बार में एक फ्लो को हब के ज़रिए रीडायरेक्ट करें, और हब वर्ज़न वैलिडेट होने के बाद ही डायरेक्ट लिंक को रिटायर करें।
4. पॉलिसी के ज़रिए नए पॉइंट-टू-पॉइंट लिंक को फ्रीज़ करें, ताकि आप इसे सुलझाते समय उलझन बढ़ना बंद हो जाए।

यह वही इंक्रीमेंटल अनुशासन है जो स्प्रेडशीट से माइग्रेट करना को टिकाऊ बनाता है। पानी बंद किए बिना प्लंबिंग बदलें।

मुख्य बातें

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

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