सॉफ्टवेयर टीमें Fabric Workload Dev Kit को देखते समय एक ही श्रेणी की गलती (category error) करती रहती हैं। वे एक पब्लिशिंग पाइपलाइन, एक सर्टिफिकेशन चेकलिस्ट और एक पार्टनर पोर्टल देखते हैं। दूसरे शब्दों में, वे एक मार्केटप्लेस देखते हैं। वे एक ऐसे ऐड-इन की कल्पना करते हैं जिसे ग्राहक अपने Microsoft स्टैक के साथ खोजते हैं, डाउनलोड करते हैं और चलाते हैं।
यह गलत नजरिया है। एक Fabric वर्कलोड कोई एक्सेसरी नहीं है। यह एक नेटिव सरफेस (native surface) है। एक बार तैनात (deploy) होने के बाद, आपका एप्लिकेशन Lakehouse, Power BI और Notebook के समान ही एक ही शेल के भीतर रहता है। वर्कस्पेस में इसका अपना अलग आइटम टाइप होता है। जब कोई यूजर "New" पर क्लिक करता है, तो यह दिखाई देता है। आपका UI Fabric क्रोम (chrome) के भीतर रेंडर होता है, न कि किसी पॉप-आउट टैब में। आपका फीचर सेट ठीक वहीं स्थित होता है जहाँ डेटा टीमें पहले से ही अपने काम के घंटे बिताती हैं। यह कोई डिस्ट्रीब्यूशन साइडबार नहीं है। यह Microsoft के डेटा ऑपरेटिंग सिस्टम के प्रति एक संरचनात्मक प्रतिबद्धता (structural commitment) है। यदि आप इसे केवल एक लिस्टिंग के रूप में देखते हैं, तो आप खुद को एक ऐसे प्लेटफॉर्म के भीतर फंसा हुआ पा सकते हैं जिसे आप नियंत्रित नहीं करते हैं।
नेटिव एडवांटेज
जब आप Fabric के लिए निर्माण करते हैं, तो आपको होस्ट एनवायरनमेंट का भरोसा और संदर्भ (context) विरासत में मिलता है। आपके वर्कलोड को OneLake तक रीड और राइट एक्सेस मिलता है, जिसका अर्थ है कि आपका एप्लिकेशन दर्जनों ETL पाइपलाइनों के माध्यम से डेटा कॉपी किए बिना सीधे Delta टेबल्स को क्वेरी कर सकता है। ऑथेंटिकेशन Microsoft Entra ID के माध्यम से होता है, इसलिए आपका एप्लिकेशन साइन-इन किए हुए यूजर के रूप में कार्य करता है। प्रबंधित करने के लिए कोई अलग क्रेडेंशियल वॉल्ट नहीं है, बनाए रखने के लिए कोई SSO ब्रिज नहीं है, और सुरक्षा टीम के लिए चिंता करने हेतु कोई फिशिंग-संभावित पासवर्ड प्रॉम्प्ट नहीं है।
तकनीकी हुक्स (technical hooks) की तरह ही ऑपरेशनल ग्रेविटी (operational gravity) भी महत्वपूर्ण है। क्योंकि ग्राहक का डेटा उनके अपने टेनेंट (tenant) के भीतर रहता है, आप उस प्रोक्योरमेंट थिएटर (procurement theater) से बच जाते हैं जो अधिकांश एंटरप्राइज SaaS सौदों को खत्म कर देता है। एक CISO को डेटा रेजिडेंसी पर बहस करने की आवश्यकता नहीं होती है। एक प्रोक्योरमेंट ऑफिसर को एग्रेस चार्जेस (egress charges) का मॉडल बनाने की आवश्यकता नहीं होती है। आपका सॉफ्टवेयर बस उन्हीं दीवारों के भीतर काम करता है जिनके वे पहले से ही मालिक हैं। विनियमित उद्योगों (regulated industries)—जैसे हेल्थकेयर नेटवर्क, वित्तीय सेवाएं, सरकारी एजेंसियां—में बेचने वाले विक्रेताओं के लिए, यह एक अकेला गुण बारह सप्ताह की सुरक्षा समीक्षा को कुछ दिनों तक चलने वाली बातचीत में समेट सकता है।
जाल कहाँ छिपे हैं
नेटिव स्टेटस के साथ नेटिव डिपेंडेंसीज़ (dependencies) भी आती हैं, और वे बाधाओं (constraints) में बदल सकती हैं।
पहला, कंप्यूट मैथ (compute math) है। आपके मार्जिन अब Microsoft Capacity Units पर निर्भर हैं। आपका वर्कलोड जो भी ऑपरेशन करता है, वह उसी CU पूल का उपयोग करता है जो ग्राहक के Spark जॉब्स, Semantic मॉडल्स और Power BI रिफ्रेश को शक्ति देता है। यदि Microsoft कीमतों को समायोजित करता है, बर्न मल्टीप्लायर (burn multipliers) बदलता है, या नए कैपेसिटी टियर पेश करता है, तो आपकी यूनिट इकोनॉमिक्स आपकी सहमति के बिना बदल जाती है। आप इंफ्रास्ट्रक्चर लेयर को नियंत्रित नहीं करते हैं, जिसका अर्थ है कि आप इसे ऑप्टिमाइज़ नहीं कर सकते। आप केवल इसका मॉडल बना सकते हैं और उम्मीद कर सकते हैं।
दूसरा, रोडमैप जोखिम (roadmap risk) वास्तविक है। Microsoft के पास उपयोगी वर्टिकल फीचर्स को देखने और फिर उनके हॉरिजॉन्टल समकक्षों को कोर प्लेटफॉर्म में शामिल करने का एक अच्छी तरह से प्रलेखित पैटर्न है। यदि आपका वैल्यू प्रपोज़िशन सामान्य डेटा कार्यों पर एक पतला UI रैपर है, तो आप उस जमीन पर निर्माण कर रहे हैं जिस पर Redmond अंततः दावा कर सकता है। एकमात्र बचाव गहराई और डोमेन विशिष्टता (domain specificity) हैं। जेनेरिक डेटा क्लीनिंग या सरल विज़ुअलाइज़ेशन टूल के सामने समय की कमी का खतरा बना रहता है। प्रोप्रायटरी मशीन लर्निंग मॉडल, उद्योग-विशिष्ट गणनाएं, या कस्टम टेलीमेट्री स्कीमा के माध्यम से तर्क करने वाला ऑब्जर्वेबिलिटी लॉजिक (observability logic) अनिवार्य बने रहने की बेहतर संभावना रखता है।
तीसरा, इंजीनियरिंग प्रयास को अक्सर कम करके आंका जाता है। क्विकस्टार्ट ट्यूटोरियल और सैंपल रिपॉजिटरी इसे ऐसा दिखाते हैं जैसे आप एक दोपहर में वर्कलोड खड़ा कर सकते हैं। आप ऐसा कर सकते हैं, यदि आपका लक्ष्य केवल एक डेमो दिखाना है। प्रोडक्शन अलग है। आपको पूरा बैकएंड कॉन्ट्रैक्ट लागू करना होगा, आइटम लाइफसाइकिल इवेंट्स को संभालना होगा, अपने कंट्रोल प्लेन और Fabric के बीच स्टेट सिंक्रोनाइज़ेशन को प्रबंधित करना होगा, और जब कैपेसिटी रुकती है या फिर से जुड़ती है तो कुशलतापूर्वक रिकवर करना होगा। यूजर जिस सतह को छूता है वह सरल हो सकती है। लेकिन उसके नीचे का कॉन्ट्रैक्ट सरल नहीं है।
इसे बनाएं, या छोड़ दें?
निर्णय इस बात पर निर्भर होना चाहिए कि आपका मूल्य कहाँ से उत्पन्न होता है, न कि Microsoft के इकोसिस्टम के प्रति आपके उत्साह पर।
बनाएं यदि आपका उत्पाद अधिक मूल्यवान हो जाता है जैसे-जैसे यह ग्राहक के डेटा के करीब आता है। ऑब्जर्वेबिलिटी प्लेटफॉर्म, उद्योग-विशिष्ट एनालिटिक्स इंजन और गवर्नेंस टूल सभी इसमें फिट बैठते हैं। बनाएं यदि आपके खरीदार पहले से ही Microsoft स्टैक में गहराई से जुड़े हुए हैं और दूसरे वेंडर को जोड़ने के बजाय खर्च को समेकित (consolidate) करना पसंद करते हैं। बनाएं यदि आपकी बौद्धिक संपदा (intellectual property) स्टोरेज लेयर के ऊपर रहती है—जैसे प्रोप्रायटरी डोमेन लॉजिक, कस्टम ML इन्फरेंस, या अद्वितीय एनरिचमेंट पाइपलाइन—क्योंकि उस IP को Microsoft के लिए जेनेरिक रूप से कॉपी करना कठिन है।
Skip करें यदि आपके मूल्य का डेटा लोकैलिटी (data locality) से कोई संबंध नहीं है। एक प्रोजेक्ट मैनेजमेंट सुइट या जनरल-पर्पस API गेटवे को वर्कस्पेस के अंदर रहने की आवश्यकता नहीं है। Skip करें यदि आपके लक्षित ग्राहक मल्टी-क्लाउड न्यूट्रल (multi-cloud neutral) होने पर गर्व करते हैं; उन्हें Fabric के अंदर डिप्लॉय करने के लिए कहना उनकी आर्किटेक्चरल स्वतंत्रता से समझौता करना होगा। Skip करें यदि मार्जिन की रक्षा के लिए आपको इंफ्रास्ट्रक्चर लागत पर सूक्ष्म नियंत्रण (granular control) की आवश्यकता है। माइक्रोसॉफ्ट के कंप्यूट ओपेक पूल (compute opaque pool) को किराए पर लेना कॉस्ट इंजीनियरिंग के साथ असंगत है।
90-दिनों का रियलिटी चेक
जब तक आप यह तीन-चरणीय प्रयोग नहीं कर लेते, तब तक किसी पूर्ण रोडमैप के लिए प्रतिबद्ध न हों।
दिन 1 से 30: सबसे कठिन हिस्से का प्रोटोटाइप बनाएं। एक 'थिन वर्टिकल स्लाइस' (thin vertical slice) बनाएं, लेकिन इसे सरल और वास्तविक रखें। एक आइटम प्रकार चुनें, 'create' और 'delete' लागू करें, और एक ऐसा यूजर इंटरेक्शन करें जो वास्तव में OneLake से डेटा पढ़े या उसमें लिखे। लक्ष्य एक सुंदर स्क्रीनशॉट लेना नहीं है। लक्ष्य आपके बैकएंड और Fabric के लाइफसाइकिल कॉन्ट्रैक्ट के बीच घर्षण (friction) को मापना है।
दिन 31 से 60: लाइव लोड के साथ लागत का मॉडल तैयार करें। एक ट्रायल कैपेसिटी (trial capacity) शुरू करें और उस पर वास्तविक लोड पैटर्न चलाएं। प्रति यूजर एक्शन CU बर्न (CU burn) को मापें। अपनी अपेक्षित कंकरेंसी (concurrency) के आधार पर इसका अनुमान लगाएं। अपने मार्जिन का अनुमान न लगाएं। याद रखें कि ट्रायल कैपेसिटी अक्सर पेड कैपेसिटी से अलग व्यवहार करती हैं, इसलिए सीमाओं का परीक्षण करें। यदि संख्याएं आपके पायलट स्केल के दस गुना पर टिक नहीं पाती हैं, तो वे प्रोडक्शन में विफल हो जाएंगी।
दिन 61 से 90: डिजाइन पार्टनर्स के साथ सत्यापन करें। ऐसे दो या तीन ग्राहकों को लाएं जो वास्तव में माइक्रोसॉफ्ट का उपयोग करते हैं, न कि केवल पूछताछ करने वाले। सटीक प्रश्न पूछें। क्या नेटिव डिप्लॉयमेंट ने उनकी सुरक्षा समीक्षा (security review) को छोटा कर दिया? क्या उनके टेनेंट एडमिन इसे स्टैंडअलोन SaaS एप्लिकेशन की तुलना में तेजी से मंजूरी देंगे? क्या Fabric के अंदर होने से आपके टूल के लिए उनके बजट बनाने के तरीके में बदलाव आता है? यदि उत्तर अस्पष्ट हैं, तो आप एक मार्केटिंग इंटीग्रेशन देख रहे हैं, डिस्ट्रीब्यूशन चैनल नहीं।
इंफ्रास्ट्रक्चर बनना
इस प्लेटफॉर्म का भविष्य ह्यूमन डैशबोर्ड नहीं है। यह एजेंट्स (agents) हैं। AI ऑर्केस्ट्रेटर चार्ट प्राप्त करने के लिए स्टैंडअलोन SaaS पोर्टल्स में लॉग इन नहीं करेंगे। वे उन वर्कलोड्स को कॉल करेंगे जिनके पास डेटा एस्टेट (data estate) तक नेटिव, ऑथेंटिकेटेड एक्सेस है। यदि आप सही ढंग से निर्माण करते हैं, तो आप वह कंप्यूट लेयर बन जाते हैं जिसे एक एजेंट कॉल करता है—न कि केवल एक और डैशबोर्ड जिसे कोई इंसान खोलता है।
Fabric को एक मार्केटप्लेस की तरह मानें, तो आप एक डिस्पोजेबल विजेट बनकर रह जाएंगे। इसे ग्राहक के डेटा आर्किटेक्चर के केंद्र में एक डिस्ट्रीब्यूशन चैनल के रूप में मानें, और आप उनके ऑपरेशन्स में इतनी गहराई से समा जाएंगे कि वहां से निकलना महंगा हो जाएगा। उस रास्ते को चुनें जहां आपका लॉजिक, न कि केवल आपका लॉगिन बॉक्स, एस्टेट का हिस्सा बन जाए।