एक काल्पनिक इंटीग्रेशन बैकलॉग में बारह मांगे हुए फ़ील्ड हैं. पहले स्वीकृत सिंक के चलने के लिए तीन ज़रूरी हैं: ग्राहक की पहचान, डेस्टिनेशन ऑडियंस और मार्केटिंग अनुमति. बाकी नौ बाद में महत्वपूर्ण हो सकते हैं. अगर अभी सभी को बराबर ध्यान मिले, तो टीम हफ़्ता अतिरिक्त विवरण सुधारने में लगा सकती है जबकि पहली सुरक्षित लिखाई अब भी नहीं हो पाएगी.
सीमा बातचीत बदल देती है. पहली रिलीज़ को समीक्षा की पांच जगहें दें और हर फ़ील्ड को एक जगह में रखें. छठा जोड़ने पर बताना होगा कि कौन सा फ़ील्ड बाहर जाएगा.
यह तर्क नहीं कि पांच सही संख्या है. यह एक और अनुरोध की लागत दिखाने का तरीका है.
जब रुकावट लोग न हों, तब भी तरीका चलता है. प्रदाता एक अवधि में सीमित अनुरोध दे सकता है; ऑडिट से पहले माइग्रेशन का समय केवल एक बदलाव दे सकता है; ग्राहक सहायता टीम कुछ ही ग्राहक-विशिष्ट मैपिंग सत्यापित कर सकती है. उपयोगी सीमा वह है जो बाकी सारे संसाधन बहुत हों तब भी परिणाम को रोकेगी.
बैकलॉग अपनी कीमत छिपा सकता है
सीमाओं और रचनात्मक काम पर चर्चा में एक प्रोडक्शन टीम ने सप्ताह के काम को दर्शाने वाले भौतिक चिह्नों से क्षमता दिखायी. किसी छोटे पृष्ठभूमि विवरण को और चमकाने के लिए दूसरे काम से चिह्न हटाने पड़े. इस उपाय ने सुंदरता तय नहीं की, लेकिन समझौते को अनदेखा करना कठिन बनाया.
सॉफ़्टवेयर टीमें आम तौर पर ये चिह्न छिपाए रखती हैं. अनुरोध ट्रैकर में जाता है, प्राथमिकता लेबल पाता है और बीस दूसरे “महत्वपूर्ण” अनुरोधों के पास बैठता है. कोई लेबल नहीं बताता कि इसे पूरा करने के लिए कौन सी समीक्षा, माइग्रेशन या ग्राहक बातचीत देर से होगी.
इंटीग्रेशन में दुर्लभ संसाधन विक्रेता की दर सीमा हो सकती है. वास्तविक टेस्ट अकाउंट की पहुंच हो सकती है. सहमति का अर्थ समझने का समय हो सकता है. दिखाई देने वाली सीमा को परिणाम रोकने वाला संसाधन नामित करना और प्रस्तावित काम उसका कितना उपयोग करता है, यह दिखाना चाहिए.
Tajo की बिज़नेस टूल इंटीग्रेशन गाइड पहले वर्कफ़्लो और सत्य का स्रोत पहचानने को कहती है. इससे हर संभावित फ़ील्ड के आसपास बैकलॉग बढ़ने से रुकता है. पहले सिंक को उसके वास्तविक परिणाम के लिए आवश्यक डेटा चाहिए.
निर्णायक बिंदु चुनें, बाकी टालें
उदाहरण के बारह फ़ील्ड वाले मैप में कुछ निर्णायक बिंदु हैं. पहचान तय करती है कि डेस्टिनेशन का कौन सा रिकॉर्ड बदलेगा. अनुमति तय करती है कि उसका मार्केटिंग में उपयोग हो सकता है या नहीं. ऑडियंस की सदस्यता तय करती है कि वह किस वर्कफ़्लो में जाएगा. ये तीन गलत हों तो बाकी नौ परिणाम नहीं बचा सकते.
योजना बोर्ड उन निर्णायक बिंदुओं और उनकी क्षमता साथ दिखा सकता है. मान लें हर एक के लिए फ़ील्ड परिभाषा, टेस्ट उदाहरण और डेस्टिनेशन जांच चाहिए. इन्हें पहले सुरक्षित रखें. अतिरिक्त पसंद फ़ील्ड को फिर ठोस सवाल का जवाब देना होगा: क्या यह पहले चलने वाले सिंक को बदलता है या इंतज़ार कर सकता है?
इंतज़ार का अर्थ फ़ील्ड को महत्वहीन कहना नहीं. यह आंशिक क्रम है. अगली निर्भरता तय हो गई; बाकी प्रमाण या ग्राहक मांग आने तक उपलब्ध हैं.
टालना स्पष्ट करें. बाकी नौ फ़ील्ड बाद की कतार में रखें और हर एक को ऊपर लाने की शर्त लिखें: नामित उपयोग मामला, वह ग्राहक रिकॉर्ड जिसमें यह फ़ील्ड ज़रूरी हो या विक्रेता अनुबंध की अनिवार्य शर्त. यह अनुरोध को बैकलॉग में खो देने से अलग है. शर्त वाली कतार विकल्प बचाती है और पहले परिणाम को अनुमानित दायरे से बचाती है.
उचित आपत्ति है: “कृत्रिम सीमाएं टीम दबा सकती हैं और उपयोगी विचार छिपा सकती हैं.” सही. खराब प्राथमिकता बचाने वाली सीमा समस्या है. उपाय है सीमा के साथ परिणाम बताना और दोनों को दोबारा देखना. नया फ़ील्ड सहमति के लिए आवश्यक निकले तो वह अतिरिक्त विवरण वाले फ़ील्ड की जगह तुरंत लेता है. सीमा बदलाव रोकने के बजाय उसे स्पष्ट करती है.
क्षमता चिह्न वह असहमति भी दिखाते हैं जिसे प्राथमिकता लेबल छिपाते हैं. एक टीम सोच सकती है कि रुकावट इंजीनियरिंग समय है; दूसरी जान सकती है कि असली इंतज़ार डेस्टिनेशन अकाउंट के एडमिन का है. तब और इंजीनियरिंग जगहें रखने से कुछ नहीं होता. पहले लिखने की स्वीकृति तक काम का रास्ता देखें, फिर सीमा उसी चरण पर रखें जो सच में रास्ता रोकता है.
पहले सिंक में किसे जगह मिलनी चाहिए?
-
पहचान, अनुमति या ऑडियंस के लिए आवश्यक
अभी सत्यापित करें
इसके बिना पहली स्वीकृत लिखाई परिभाषित नहीं है.
-
बाद के नामित उपयोग मामले के लिए आवश्यक
ऊपर लाने की शर्त तय करें
पहले परिणाम को रोके बिना अनुरोध उपलब्ध रखें.
-
परिणाम पर कोई परिभाषित असर नहीं
अनुरोध टालें
अनुमानित दायरे पर दुर्लभ समीक्षा जगह न खर्च करें.
सीमा से मिला परिणाम मापें
बनाने लायक ग्राफ़ “इस महीने बंद हुए अनुरोध” नहीं है. वह अनुरोध से पहले सही परिणाम तक का रास्ता है, जिसमें रास्ता रोकने वाली चीज़ें लिखी हों. क्या समीक्षा का समय वैकल्पिक फ़ील्ड में गया? क्या विक्रेता की गायब परिभाषा ने हर टेस्ट रोका? क्या सक्रिय करने के लिए अनावश्यक डैशबोर्ड टालकर टीम ने समय बचाया?
थ्रूपुट में काल्पनिक वृद्धि न गढ़ें. वास्तविक बैच के पहले और बाद के तथ्य दर्ज करें: स्वीकृत मैपिंग तक दिन, डेस्टिनेशन में जांचे गए फ़ील्ड और सक्रिय करने के बाद मिले मुद्दे. दिखाई देने वाली सीमा तभी उपयोगी है जब ये परिणाम बदलें.
रिवर्स ETL गाइड निर्धारित डेटा स्थानांतरण को उसकी मैपिंग तय करने के काम से अलग करती है. शुरुआती दायरे का सबसे अधिक असर उसी मैपिंग पर है. और डेटा बाद में जोड़ा जा सकता है; पहला अनुबंध अभी सही होना चाहिए.
सूची बताती है कि किसने क्या मांगा. दिखाई देने वाली सीमा बताती है कि अनुरोध की कीमत क्या है.
अक्सर पूछे जाने वाले प्रश्न
दिखाई देने वाली सीमा प्राथमिकता तय करने में कैसे मदद करती है?
वह दिखाती है कि एक चीज़ जोड़ने में दूसरे काम का समय या क्षमता खर्च होगी. तब टीम हर अनुरोध को मुफ़्त मानने के बजाय छूटने वाले परिणामों की तुलना कर सकती है.
टीम को क्या दिखाना चाहिए?
वही सीमित संसाधन जो वास्तव में डिलीवरी रोकता है: समीक्षा का समय, डेस्टिनेशन की दर सीमा, माइग्रेशन क्षमता या सत्यापित की जा सकने वाली ग्राहक-विशिष्ट मैपिंग की संख्या.
क्या सीमाएं मनमानी नौकरशाही बन सकती हैं?
हां. सीमा किसी नामित परिणाम की रक्षा करे और प्रमाण बदलने पर दोबारा देखी जाए. महत्वपूर्ण काम छिपाने वाली सजावटी सीमा भी बर्बादी है.