एक आधुनिक रेवेन्यू प्लेटफॉर्म के लिए रेफरेंस आर्किटेक्चर

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

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

पांच लेयर्स

एक टिकाऊ रेवेन्यू आर्किटेक्चर चिंताओं को पांच लेयर्स में अलग करता है। हर एक का एक संकीर्ण काम और अपने पड़ोसियों के साथ एक साफ इंटरफेस है।

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

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

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

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

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

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

डेटा लेयर ही पूरा खेल है

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

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

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

लेयर्स के बीच कॉन्ट्रैक्ट्स

लेयर्स एक्सप्लिसिट कॉन्ट्रैक्ट्स के ज़रिए बात करते हैं: स्कीमास और सिमैंटिक्स जो चुपचाप नहीं बदलते। एक प्लेटफॉर्म जो एक रीऑर्ग या एक वेंडर स्वैप से बचता है वह इन्हें फर्स्ट-क्लास ट्रीट करता है।

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

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

ताज़गी कॉन्ट्रैक्ट्स समयबद्धता डिफाइन करते हैं। हर मेट्रिक को रियल-टाइम होने की ज़रूरत नहीं है, और इसे मजबूर करना महंगा और अक्सर काउंटरप्रोडक्टिव है। हम रियल-टाइम बनाम बैच: रेवेन्यू डेटा की ताज़गी कब मायने रखती है में कवर करते हैं कि कैसे फैसला करें।

कॉन्ट्रैक्ट्स ही वह हैं जो आपको पूरे प्लेटफॉर्म को फिर से लिखे बिना एक वेंडर बदलने देते हैं। एक एप्लिकेशन कुछ ऐसा बन जाता है जो एक कॉन्ट्रैक्ट को संतुष्ट करता है, और जब कोई बेहतर आता है तो आप इससे दूर जा सकते हैं।

दो टोपोलॉजी फैसले

वेयरहाउस-नेटिव या ऐप-नेटिव। क्या इंटेलिजेंस आपके मौजूदा वेयरहाउस के ऊपर चलती है, या एक वेंडर के ब्लैक बॉक्स के अंदर? यह तय करता है कि कंप्यूट, रॉ डेटा, और एक्स्टेंसिबिलिटी का मालिक कौन है, और इसे उलटना मुश्किल है। हम इस ट्रेड को वेयरहाउस-नेटिव बनाम ऐप-नेटिव रेवेन्यू टूलिंग में बताते हैं।

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

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

यह एंड टू एंड कैसे पढ़ता है

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

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

मुख्य बातें

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

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