इंटीग्रेशन टैक्स: टूल्स को जोड़ने की असल कीमत क्या है

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

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

यह आता कहां से है

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

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

बिल किस चीज़ का बना होता है

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

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

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

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

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

यह क्यों कंपाउंड करता है

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

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

टूल्स सिर्फ हटाए बिना इसे घटाना

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

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

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

मुख्य बातें

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

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