২০ নভে, ২০২৫·5 মিনিট
লারি এলিসন ও ওরাকল: ডাটাবেস, লক-ইন, এবং এন্টারপ্রাইজ সেলস
সহজ ভাষায় ব্যাখ্যা—কিভাবে ওরাকল ও ল্যারি এলিসন ডাটাবেস, সুইচিং খরচ, লাইসেন্সিং এবং এন্টারপ্রাইজ সেলস ব্যবহার করে দীর্ঘস্থায়ী অর্থ উপার্জন তৈরি করেছিলেন।
সহজ ভাষায় ব্যাখ্যা—কিভাবে ওরাকল ও ল্যারি এলিসন ডাটাবেস, সুইচিং খরচ, লাইসেন্সিং এবং এন্টারপ্রাইজ সেলস ব্যবহার করে দীর্ঘস্থায়ী অর্থ উপার্জন তৈরি করেছিলেন।
লারি এলিসনের টেকসই-অর্থের সূত্রটি এক বাক্যে করা যায় এভাবে: একটি মিশন-ক্রিটিক্যাল ডাটাবেস বিক্রি করুন, সেটি বার্ষিক চুক্তিতে আবদ্ধ করুন, এবং এমন একটি এন্টারপ্রাইজ সেলস মেশিন তৈরি করুন যা অবস্থান বদলানোকে ঝুঁকিপূর্ণ মনে করায়।
এটি একটি ব্যবসায়িক কাহিনী—কিভাবে ওরাকল প্রতিস্থাপন করা কঠিন হয়ে উঠল—আর এটা ডাটাবেস ইন্টারনালের গভীর টেকনিক্যাল টিউটোরিয়াল নয়। SQL অপটিমাইজার কিভাবে কাজ করে জানার দরকার নেই এইটি বুঝতে যে কেন ওরাকল বহু দশক ধরে নগদ প্রবাহের ইঞ্জিন হয়ে উঠল।
“টেকসই” মানে গ্রাহকরা প্রতিটি রিনিউয়ালে উৎসাহিত ছিলেই না—বরং ওরাকল এমনভাবে নিজেকে স্থাপন করেছিল যাতে রাজস্ব পুনরায় আগমন করতেই থাকে।
টেকসইতা এইভাবে প্রকাশ পায়:
যখন একটি ডাটাবেস বিলিং, ইনভেন্টরি, HR, বা ট্রেডিং সিস্টেমের নিচে বসে, তখন এটি আর শুধুই একটি IT টুল নয়। এটি একটি নির্ভরতায় পরিণত হয়, আর নির্ভরতা সহজে ছাড়ানো যায় না।
1) ডাটাবেস—ভিত্তি হিসাবে। ওরাকল “সিস্টেম অফ রেকর্ড” স্তরের ওপর মনোযোগ দেয়—যেখানেই সবচেয়ে মূল্যবান অপারেশনাল ডেটা থাকে।
2) লক-ইন (যখনও কখনও অনিচ্ছাকৃত)। শুধু টেকনিক্যাল সামঞ্জস্য নয়, বরং প্রক্রিয়া, ইন্টিগ্রেশন, প্রশিক্ষণ, এবং ভেন্ডর-নির্দিষ্ট ফিচার যেগুলো বছরের পর বছর জমতে থাকে।
3) এন্টারপ্রাইজ সেলস। ওরাকল ভোক্স-অ্যাপে জয় অর্জন করেনি। এটি জিতেছে প্রোকিউরমেন্ট সাইকেল, নির্বাহী সম্পর্ক, এবং এমন চুক্তির মাধ্যমে যা সম্পর্ক বাড়ায়।
এই তিনটি একত্রে একটি সংযোজক প্রভাব তৈরি করে: প্রতিটি নতুন ডিল কেবল একবারের বিক্রি ছিল না—এটি বহু ভবিষ্যত পেমেন্টের সম্ভাবনা বাড়ায়।
লারি এলিসন শুরুতে কোনও সফটওয়্যার সেলিব্রিটি ছিলেন না। তার প্রাথমিক ক্যারিয়ার ছিল প্রোগ্রামিং কাজ আর বড় প্রতিষ্ঠানগুলি প্রযুক্তি কীভাবে কিনে—ধীর, সাবধানে, এবং স্থিতিশীল ভেন্ডার পছন্দ করে—সেটা শেখার একটি ব্যবহারিক মিশ্রণ।
ওরাকল 1977 সালে শুরু করে (Software Development Laboratories নামে) একটি স্পষ্ট ধারনার সঙ্গে: সফটওয়্যারের সবচেয়ে বড় অর্থ ইনফ্রাস্ট্রাকচার বিক্রি করে বড় প্রতিষ্ঠানগুলোকে দেওয়াই, একবারের কাস্টম সিস্টেম নির্মাণ নয়। এলিসন ও তাঁর সহপ্রতিষ্ঠাতা হবি বা কনজিউমার মার্কেট না নেভে, কোম্পানি ও সরকারি সংস্থাগুলোর দিকে লক্ষ্য করে যারা পে-রোল, ইনভেন্টরি, বিলিং, ও অ্যাকাউন্টিং চালানোর জন্য সিস্টেম প্রয়োজন।
তৎকালীন সময়ে কম্পিউটিং শাসিত ছিল মেইনফ্রেম ও কেন্দ্রীয়ভাবে পরিচালিত ডেটার মাধ্যমে। ক্লায়েন্ট-সার্ভার সেটআপগুলো দেখা দিলেও, বড় কোম্পানিগুলোর মধ্যে ডিফল্ট ধারণা ছিল যে সিস্টেমগুলোকে নির্ভরযোগ্য, অডিটেবল, এবং বছরের পর বছর সমর্থনযোগ্য হতে হবে।
এই পরিবেশ সেসব সফটওয়্যারকে পুরস্কৃত করত যেগুলো একটি স্ট্যান্ডার্ড উপাদান হয়ে উঠতে পারে—যেটার চারপাশে IT দলগুলো আর্কিটেকচার গড়ে তুলতে পারে। ডাটাবেস ঠিক এই ভূমিকায় ফিট করে: অনেক অ্যাপ্লিকেশনের নিচে বসে, গুরুত্বপূর্ণ ডেটা স্পর্শ করে, এবং চলমান রক্ষণাবেক্ষণ ও সাপোর্টকে যৌক্তিক করে তোলে।
এন্টারপ্রাইজ গ্রাহকরা ব্যক্তিদের মত করে কিনে না। তারা কমিটি, প্রোকিউরমেন্ট প্রসেস, এবং বহু-বছরের পরিকল্পনার মাধ্যমে কেনে। এতে ভেন্ডারকে জোর দিতে হয়:
এটি আর্থিক প্রোফাইলও পরিবর্তন করে। একটি বড় ডিল একাধিক বছরের প্রোডাক্ট কাজকে অর্থায়ন করতে পারে, কিন্তু এর জন্য সম্পর্ক ও প্রুফ ও ঝুঁকি হ্রাস করার ওপর ভিত্তি করে একটি সেলস মোশন দরকার।
ওরাকলের শুরুতি বাজি সরল ছিল: এন্টারপ্রাইজ অপারেশনের কোরে একটি স্থান অর্জন করুন, এবং আপনি কেবল সফটওয়্যার বিক্রি করছেন না—আপনি আপডেট, সাপোর্ট, ও আপগ্রেডের মাধ্যমে ধারাবাহিকতা বিক্রি করছেন, যা নির্ভরতা বাড়ার সঙ্গে গ্রাহকরা পরিশোধ করে যেতে থাকে।
একটি ডাটাবেস হল কোম্পানির সিস্টেম অফ রেকর্ড: যেখানে “প্রধান সত্য” থাকে। কাস্টমার অ্যাকাউন্ট, ইনভয়েস, ইনভেন্টরি গণনা, পে-রোল এন্ট্রি, শিপমেন্ট স্ট্যাটাস—এইগুলো কেবল ফাইল নয়। এগুলো এমন তথ্য যেগুলোর ওপর ব্যবসা দারা-পাওয়া, আনুগত্য, এবং দৈনন্দিন অপারেশন নির্ভর করে।
যত বেশি এন্টারপ্রাইজ সফটওয়্যার তৈরি করা হয়—ERP, CRM, বিলিং, সাপ্লাই চেইন—এই অ্যাপ্লিকেশনগুলো ক্রমশ একই অধস্তন “সূত্র”-কে শেয়ার করে। যদি ডাটাবেস অনুপলব্ধ থাকে, তাহলে যে অ্যাপগুলো রেকর্ড পড়ে ও লেখে সেগুলোই তাদের কাজ করতে পারবে না। তাই ডাটাবেসটি একটি কেন্দ্রীয় নির্ভরতায় পরিণত হয়, কেবল আরেকটি IT পিস নয়।
ডাটাবেসগুলো স্টিকি হয়ে যায় কারণ অ্যাপ্লিকেশনগুলো তাদের চারপাশে লেখা হয়। সময়ের সঙ্গে আপনি জমা করেন:
পরিবর্তন করা স্প্রেডশিট টুল বদলানোর মত সহজ নয়। আপনাকে প্রচুর পরিমাণ ডেটা মাইগ্রেট করতে হবে, ইতিহাস সংরক্ষণ করতে হবে, গুরুত্বপূর্ণ ওয়ার্কফ্লো পুনরায় পরীক্ষা করতে হবে, এবং প্রায়ই অ্যাপ্লিকেশনের কিছু অংশ পুনরায় লিখতে হবে। নতুন অপশন সস্তা হলেও প্রকল্প ঝুঁকি সাশ্রয়কে ছাপিয়ে যেতে পারে।
মিশন-ক্রিটিক্যাল সিস্টেমের জন্য, ভয়টি নয় “এই সপ্তাহে একটু ধীর হবে।” ভয় হল এমন এক দিন যখন অর্ডার প্রসেসিং বন্ধ হয়ে যায়, অথবা ডেটা লস এমন রিকোয়েস্ট বাধ্য করে যা রিকনসিলিয়েশন, রিফান্ড, ও নিয়ন্ত্রক ঝামেলা তৈরি করে।
যখন একটি খারাপ দিনের খরচ মিলিয়ন হতে পারে—বা বিশ্বাস ক্ষতিগ্রস্ত হতে পারে—ক্রেতারা কনজার্ভেটিভ হয়ে ওঠে। “বিশ্বস্তভাবে কাজ করে” সাধারণত “নতুন ও সম্ভাবনাময়” এর চেয়ে জিতবে।
IT বিভাগের বিচার স্থিতিশীলতার আধার। তাই তারা দীর্ঘ ট্র্যাক-রেকর্ড, পরিণত টুলিং, এবং যে সাপোর্ট টিমগুলো প্রতিটি ব্যর্থতার মোড দেখেছে এমন ভেন্ডারের দিকে ঝেুঁকে পড়ে।
একবার সেই সিদ্ধান্ত নেওয়া হলে, ডাটাবেস বাকী স্ট্যাকের জন্য অ্যাঙ্কর হয়ে ওঠে—অ্যাপ, প্রক্রিয়া, এবং বাজেটগুলোকে নিজের কক্ষপথে টেনে নিয়ে যায়।
রিলেশনাল ডাটাবেস হল ব্যবসায়িক ডেটা—কাস্টমার, ইনভয়েস, শিপমেন্ট—টেবিলে (স্প্রেডশিট ভাবেই) রাখার একটি পদ্ধতি যা পরস্পরের সাথে লিঙ্ক করা যায়। ফাইল খুঁজে বেড়ানোর পরিবর্তে আপনি প্রশ্ন করতে পারেন: “সব অনিপেইড ইনভয়েসগুলো দেখাও যেগুলো ৩০ দিন বা বেশি” এবং দ্রুত ও নির্ভুলভাবে উত্তর পাবেন।
SQL (Structured Query Language) রিলেশনাল ডাটাবেসের সাথে কথা বলার সাধারণ ভাষা। যেহেতু SQL ব্যাপকভাবে শেখানো হয় এবং বিস্তৃতভাবে সমর্থিত, তাই মনে করা সহজ যে ডাটাবেস পণ্যগুলো বিনিমেয়।
কিন্তু বাস্তব কোম্পানিতে, যা গুরুত্বপূর্ণ তা কেবল সিস্টেম SQL বুঝে কিনা তা নয়। পার্থক্য দেখা যায় চারপাশের সবকিছুর মধ্যে: ডাটাবেস বড় লোডে কিভাবে আচরণ করে, ক্র্যাশের পর কিভাবে পুনরুদ্ধার করে, ব্যাকআপ কিভাবে কাজ করে, অনুমতি কীভাবে ম্যানেজ করা হয়, এবং দলগুলো কিভাবে পারফরম্যান্স মনিটর ও টিউন করে।
ওরাকল “SQL” বিক্রি করত না। ওরাকল বিক্রি করত মিশন-ক্রিটিক্যাল সিস্টেমগুলো চলতেই থাকবে—এই প্রতিশ্রুতি।
এমনকি যদি প্রতিদ্বন্দ্বী ফিচার মেলে, একটি ডাটাবেসে স্ট্যান্ডার্ডাইজ করার সিদ্ধান্ত বিস্তৃত দলের, বাজেট এবং বছরের অপারেশনাল অভ্যাস জুড়ে ছড়িয়ে পড়ে। একবার একটি ডাটাবেস রিপোর্টিং, ইন্টিগ্রেশন, এবং কমপ্লায়েন্সের কেন্দ্র হয়ে গেলে “ভালো পর্যাপ্ত” প্রযুক্তি জেতা কঠিন হয়ে পড়ে।
বাজার আধিপত্য সাধারণত পণ্য গুণমান, ঝুঁকি ব্যবস্থাপনা, এবং সেলস কার্যকরী কৌশলের মিশ্রণ প্রতিফলিত করে—কোনও একক কিলার ফিচার নয়।
ওরাকল বিক্রি করে নি ডেভেলপারদের ক্রেডিট কার্ড স্বয়ংক্রিয়ভাবে টেনে নিয়ে। তারা শিখেছিল কিভাবে বড় কোম্পানিগুলি আসলে কেনে: ধীর, সাবধানে, এবং বহু মানুষ জড়িত।
এন্টারপ্রাইজ প্রোকিউরমেন্ট একটি দলীয় খেলা। একটি সাধারণ ডিলে IT লিড, সিকিউরিটি, ফাইন্যান্স, লিগ্যাল, এবং যে বিজনেস ইউনিট সিস্টেমটি চালাবে—এসব মানুষ জড়ায়। এর মানে দীর্ঘ টাইমলাইন, আনুষ্ঠানিক দাবি, এবং অভ্যন্তরীণ রাজনীতি।
ওরাকল এই বাস্তবতায় ঢুকে পড়ে প্রুফ অফ কনসেপ্ট (PoC), রেফারেন্স কাস্টমার, এবং বিস্তারিত সামঞ্জস্য দাবির মাধ্যমে। একটি PoC কেবল টেকনিক্যাল টেস্ট নয়—এটি এমন একটি উপায় যাতে একটি স্পনসর ক্রয়কাজটা বাকি সবাইকে ন্যায্যতা দেখাতে পারে।
ওরাকল ক্লাসিক অ্যাকাউন্ট-ভিত্তিক সেলিং তৈরি করে: ডেডিকেটেড রেপ, নামক অ্যাকাউন্ট, এবং কোয়ার্টারলি বিজনেস রিভিউ—এবং এটি ABM ট্রেন্ডি হওয়ার অনেক আগেই ছিল।
লক্ষ্য কেবল প্রথম চুক্তি নয়; লক্ষ্য ছিল পরবর্তী প্রকল্পের জন্য ডিফল্ট ডাটাবেস হওয়া, এবং তার পরেরটাও। CIO বা ডাটাবেস টিমের সঙ্গে আস্থাটা বাজেট, রিওর্গ, এবং এমনকি স্বল্প-মেয়াদি প্রোডাক্ট অসন্তোষ থেকেও টিকে থাকতে পারে।
সাপোর্ট কন্ট্র্যাক্ট, সার্টিফিকেশন (DBA, ডেভেলপার), এবং সিস্টেম ইন্টিগ্রেটররা গতি তৈরি করে। একবার একটি কোম্পানি প্রশিক্ষিত কর্মী, অনুমোদিত আর্কিটেকচার, এবং এমন একটি পার্টনার পেয়ে গেলে যিনি ওরাকল ভালোভাবে জানেন, ভেন্ডার পরিবর্তন করা ঝুঁকিপূর্ণ মনে হয়।
পার্টনাররা RFP-তে কী সুপারিশ করা হবে, কোন দক্ষতা পাওয়া যায়, এবং কোন প্ল্যাটফর্মগুলো “নিরাপদ” বিবেচিত হবে—এসবকেও প্রভাবিত করে।
রিনিউয়ালগুলো নতুন লোগো-এর চেয়ে বেশি গুরুত্বপুর্ন হতে পারে। যদি ওরাকল কোর সিস্টেমে এমবেডেড হয়ে যায়, বার্ষিক রিনিউয়াল হয়ে ওঠে একটি ব্যবসায়িক-অবিরততা সিদ্ধান্ত—নতুন মূল্যায়ন নয়। তখনই মূল্য নির্ধারণ, অডিট শর্ত, এবং চুক্তির কাঠামো আচরণ গঠনে পণ্য ফিচারের মতোই প্রভাব ফেলে।
(লক-ইন মেকানিক্স সম্পর্কে বিস্তারিত দেখতে /blog/how-lock-in-works দেখুন।)
ভেন্ডর লক-ইন নৈতিক অভিপ্রায়ের উপর নির্ভর করে না। এটি সরলভাবে সময়ের সঙ্গে একটি ভেন্ডরের পণ্যের ওপর বাড়তে থাকা নির্ভরতা এবং সময়ের সঙ্গে পরিবর্তনের খরচ বৃদ্ধির সমন্বয়। কোর সিস্টেমের মতো ডাটাবেসের ক্ষেত্রে, এই সমন্বয় শক্তিশালী হয়ে উঠে কারণ ডাটাবেস অ্যাপ্লিকেশন, রিপোর্টিং, সিকিউরিটি, এবং দৈনন্দিন অপারেশনের নিচে অবস্থান করে।
আপনার সিস্টেমগুলো যদি এমন ক্ষমতার ওপর নির্ভরশীল হয় যা সহজে অন্যত্র পুনরায় সৃষ্টি করা যায় না, তা হল প্রযুক্তিগত লক-ইন। ডাটাবেসে, এটি সাধারণত দেখা যায় মালিকানাধীন ফিচার (বিশেষ SQL এক্সটেনশন, পারফরম্যান্স হিন্ট, ক্লাস্টারিং পদ্ধতি), ভেন্ডর-নির্দিষ্ট টুলিং, এবং অ্যাপ ও মিডলওয়্যারের গভীর ইন্টিগ্রেশনের মাধ্যমে।
এমনকি যখন “এটি কেবল SQL,” বাস্তব-জগতের ডিপ্লয়মেন্টগুলো স্টোরড প্রসিডিউর, ট্রিগার, ব্যাকআপ স্ক্রিপ্ট, মনিটরিং এজেন্ট, এবং কাস্টম কানেক্টরের মত জিনিস জমায়। স্ট্যাকের যত বেশি অংশ একটি ডাটাবেসের জন্য টিউন করা থাকে, তত ক্লিন মাইগ্রেশন কঠিন হয়।
অপারেশনাল লক-ইন মানুষ ও প্রক্রিয়া সম্বন্ধীয়। দলগুলো একটি নির্দিষ্ট প্ল্যাটফর্মে প্রশিক্ষিত হয়, একটি নির্দিষ্ট সার্টিফিকেশন পাথ অনুসরণ করে কর্মী নিয়োগ করে, এবং নির্দিষ্ট আচরণের ওপর ভিত্তি করে রুনবুক তৈরি করে—কিভাবে ফেইলওভার কাজ করে, কিভাবে আপগ্রেড করা হয়, কী “সাধারণ” পারফরম্যান্স মনে হয়।
সময়ের সঙ্গে কমপ্লায়েন্স ও অডিট ডকুমেন্টেশনও ডাটাবেস-নির্দিষ্ট হয়ে ওঠে: অ্যাক্সেস কন্ট্রোল, এনক্রিপশন কনফিগারেশন, রিটেনশন পলিসি, এবং ইনসিডেন্ট রেসপন্স ধাপগুলো। তখন ভেন্ডার পরিবর্তন মানে হবে পুনঃপ্রশিক্ষণ, প্রক্রিয়া পুনরায় লেখা, এবং কন্ট্রোলগুলো পুনঃভ্যালিডেট করা।
চুক্তিগত লক-ইন পরিবর্তনের খরচকে ক্যালেন্ডারে রূপান্তর করে। বহু-বছরের মেয়াদ, বান্ডেলড সাপোর্ট স্ট্রাকচার, রিনিউয়াল সাইকেল, এবং এন্টারপ্রাইজ-ওয়াইড এগ্রিমেন্টগুলো “আমরা পরের কোয়ার্টারে পরিবর্তন করব”কে অবাস্তব করে তোলে।
সাপোর্ট একটি বড় হাতিয়ার: একবার ক্রিটিক্যাল সিস্টেমগুলো ভেন্ডর সাপোর্টের ওপর নির্ভর করতে শুরু করলে, ছেড়ে চলে যাওয়া যেন নতুন অপারেশনাল ঝুঁকি গ্রহণ করা—বিশেষত যদি চুক্তিতে কঠোর ব্যবহার সংজ্ঞা এবং দণ্ড থাকে যা আংশিক মাইগ্রেশন জটিল করে।
ওরাকলের মোয়াট শুধুই প্রযুক্তিগত ছিল না। এটি আর্থিকও ছিল—লাইসেন্সিং মডেলের মাধ্যমে তৈরি, যাতে ডাটাবেস বাজেটে যেমন এমবেডেড লাগে তেমনি সিস্টেমে।
ওরাকল লাইসেন্সিং প্রায়ই কয়েকটি সাধারণ ইউনিটে বিক্রি করা হয়েছে:
মূল ধারণা সরল: একবার ডাটাবেস কেন্দ্রীয় হয়ে গেলে, বৃদ্ধির সাথে সেই মিটারের কোনো না কোনোটি বাড়ে—বেশি কোর, বেশি ইউজার, বা বেশি ফিচার।
যখন প্রাইসিংয়ে অনেক নোব আছে—মেট্রিক, ব্যতিক্রম, প্রডাক্ট-ইউজ রাইটস, বান্ডলড অপশন—তখন আলোচনাগুলো সেই পক্ষের অনুকূলে যেতে থাকে যারা নিয়মগুলো ভালো জানে।
জটিলতাও গ্রাহকদের জন্য কয়েক বছরের মোট খরচ মডেল করা কঠিন করে তোলে, যা বিকল্পগুলোর সঙ্গে তুলনা বা নিশ্চিতভাবে মাইগ্রেশনে বাধা সৃষ্টি করে।
ওরাকল (অনেক বড় ভেন্ডারের মতো) লাইসেন্স রিভিউ ব্যবহার করে গ্রাহকদের নিশ্চিত করতে যে তারা চুক্তির শর্তের মধ্যে ব্যবহার করছে। ন্যায়সঙ্গতভাবে করা হলে, অডিট উভয় পক্ষকেই রক্ষা করে।
কার্যত, অডিট আর্থিক ঝুঁকি তৈরি করে: যদি ব্যবহার অতিরিক্ত হিসেবে ব্যাখ্যা করা হয়, গ্রাহককে দ্রুত ট্রু-আপ লাইসেন্স নিতে হতে পারে।
বার্ষিক সাপোর্ট রিনিউয়াল—অften লাইসেন্সের একটি শতাংশের সাথে যুক্ত—নতুন বিক্রয় ধীর হলেও স্থির রাজস্ব তৈরি করে। আপগ্রেড ও নতুন এডিশন একটি দ্বিতীয় হাতিয়ার: গ্রাহকরা আপডেট থাকা, সামঞ্জস্য বজায় রাখা, এবং সাপোর্ট পেতে পরিশোধ করে, যা পুনরাবৃত্তি চক্রকে শক্ত করে।
ওরাকলের কখনও প্রতিযোগিতা ঘাটত না। অদ্ভুত হচ্ছে কতবার গ্রাহকরা বিকল্পগুলো মূল্যায়ন করেও—তারপরও রিনিউয়াল করেছিল।
শুরুতে IBM ছিল স্পষ্ট প্রতিদ্বন্দ্বী: DB2 ইতোমধ্যেই অনেক এন্টারপ্রাইজে তাদের সবচেয়ে গুরুত্বপূর্ণ ওয়ার্কলোডে থাকার কারণে। ওরাকলের পিচ ছিল হার্ডওয়্যার প্ল্যাটফর্ম জুড়ে পোর্টেবিলিটি ও পারফরম্যান্স, যা গুরুত্বপূর্ন হয়ে উঠল কারণ কোম্পানিগুলো IBM মেইনফ্রেমের বাইরে বৈচিত্র্য আনছিল।
1990 ও 2000-এর দশকে, Microsoft SQL Server দ্রুত বাড়ে—বিশেষ করে ডিপার্টমেন্টাল ও মিড-মার্কেট সিস্টেমের জন্য যাদের সরলতা ও কম দামের ট্যাগ দরকার ছিল। এটি প্রায়ই “ভালো-পর্যাপ্ত” ছিল, এবং বহু নতুন অ্যাপ্লিকেশনের জন্য সত্যিই তাই ছিল।
তারপর ওপেন সোর্স গুরুতর কাজে বিশ্বাসযোগ্য হয়ে উঠল। MySQL ওয়েব ওয়ার্কলোড দখল করে; PostgreSQL যেসব টিম এন্টারপ্রাইজ-গ্রেড ফিচার চেয়েছিল কিন্তু এন্টারপ্রাইজ লাইসেন্স ছাড়াই চেয়েছিল তাদের মধ্যে জনপ্রিয় হয়ে উঠল।
ডাটাবেসগুলো আলাদাভাবে কেনা হয় না। সেগুলো ব্যবসায়িক প্রসেস, রিপোর্টিং, সিকিউরিটি রিভিউ, কমপ্লায়েন্স সাইন-অফ, এবং ভেন্ডর সম্পর্কের মধ্যে জড়িয়ে থাকে।
লাইসেন্স ফিতে সাশ্রয় বাস্তব হতে পারে, কিন্তু প্রায়ই অ্যাপ্লিকেশন পুনঃপরীক্ষা, কর্মী পুনঃপ্রশিক্ষণ, ও অপারেশনাল ঝুঁকি শোষণ করার খরচ তাকে ছাপিয়ে দেয়। বহু কোম্পানির জন্য ডাটাবেস কাজ করলে অদৃশ্য থাকে—যখন এটি ভাঙে তখনই দোষারোপ হয়। তাই সিদ্ধান্ত-নির্যায়করা সাধারণত কনজার্ভেটিভ হন: তাঁরা বেশি টাকা দিতে রাজী থাকেন, বরং সেই দলে হতে চান না যারা “বিলিং ভেঙে দিয়েছে।”
“টেকসই” মানে এমন একটি ব্যবসায়িক গঠন যার ফলে রাজস্ব নিয়মিতভাবে পুনরাবৃত্তি হয়—এমনকি গ্রাহকরা সবসময় সন্তুষ্ট না হলেও।
ওরাকলের ক্ষেত্রে টেকসইতা এসেছে নিচের কারণে:
কারণ ডাটাবেসই সেই সিস্টেম যেখানে ব্যবসার কাজ চালায়: বিলিং, পে-রোল, ইনভেন্টরি, ট্রেডিং, আনুগত্য রিপোর্টিং।
যখন ডাটাবেসটি system of record হয়, তখন আউটেজ বা ডেটা লস অস্তিত্বশীল অপারেশন ও নিয়ন্ত্রক ঝুঁকি তৈরি করে—তাই ক্রেতারা নতুনত্বের চেয়ে স্থিরতা ও প্রমাণিত সাপোর্টকে অগ্রাধিকার দেয়।
আসলে SQL মানক, কিন্তু প্রতিষ্ঠানগুলো “সিনট্যাক্স” কেনা না—তারা ফলাফল কেনে: আপটাইম, ক্র্যাশ পরবর্তী পুনরুদ্ধার, লোডে পারফরম্যান্স, সিকিউরিটি কন্ট্রোল, টুলিং ও সাপোর্ট।
দুইটি পণ্যই “SQL জানে” কিন্তু তবুও ভিন্ন হতে পারে:
সময়ের সঙ্গে পরিবর্তনের খরচ বাড়ে—এগুলো যোগ হওয়ার ফলে লক-ইন তৈরি হয়।
সাধারণ উৎসগুলো:
এমনকি বিকল্পটি সস্তা হলে ও, মাইগ্রেশন ঝুঁকি সঞ্চিত সাশ্রয়কে ছাপিয়ে যেতে পারে।
ওরাকল কমিটির কাছে বিক্রি করত এবং দীর্ঘ ক্রয় চক্রগুলোকে কাজে লাগিয়েছিল।
স্বাভাবিক কৌশলগুলো ছিল:
কারণ এটি সাধারণত যেখানে সবচেয়ে বেশি কার্যকরতা থাকে—সেই মুহূর্তটিই লিভারেজ সবচেয়ে বেশি।
যদি একটি ডাটাবেস কোর অপারেশন সমর্থন করে, তখন রিনিউয়াল হয়ে ওঠে ব্যবসায়িক ধারাবাহিকতার সিদ্ধান্ত, নতুন মূল্যায়ন নয়। এতে আলোচনা হয় “আমরা কি নিরাপদে পরিবর্তন করতে পারি?”—যা অনেক বেশি কঠিন।
এখানেই মূল্য নির্ধারণ, অডিট ধার্যাবলি, এবং সাপোর্ট নীতিগুলো বড় প্রভাব ফেলে।
তিনটি স্তর একে অপরকে পরস্পর শক্তিশালী করে:
এই তিনটি মিলিয়ে লক-ইন চলমান প্রক্রিয়া ও বাস্তব ঝুঁকি দুটোই গড়ে তোলে।
ওরাকলের লাইসেন্সিং প্রায়ই একাধিক “মিটার” রাখে, এবং বৃদ্ধির সাথে সেই মিটারের কোনো না কোনোটি বাড়ে।
সাধারণ হাতিয়ারগুলো:
কার্যকর ঝুঁকি হলো জটিলতা দীর্ঘমেয়াদে মোট ব্যয় নির্ধারণকে কঠিন করে তোলে এবং অনিচ্ছাকৃতভাবে কমপ্লায়েন্সের বাইরে চলে যাওয়ার সম্ভাবনা বাড়ায়।
একটি অডিট (অথবা লাইসেন্স রিভিউ) চুক্তির শর্ত অনুযায়ী ব্যবহার যাচাই করার একটা পরীক্ষা।
বাস্তবে এটি করতে পারে:
দলেরা ঝুঁকি কমাতে ডেপ্লয়মেন্ট ট্র্যাক করে, মেট্রিক সংজ্ঞা (ভার্চুয়ালাইজেশন, DR, ডেভ/টেস্ট) বোঝে, এবং পরিষ্কার অভ্যন্তরীণ ব্যবহার রিপোর্ট রাখে।
স্বয়ংক্রিয়ভাবে না—ক্লাউড লক-ইনের আকৃতি বদলে দেয়, কিন্তু মুছিয়ে দেয় না।
ম্যানেজড ডাটাবেস অপারেশনাল বোঝা কমাতে পারে (প্যাচিং, ব্যাকআপ, HA), কিন্তু আপনাকে এখনও দেখতে হবে:
অনেকে বহু বছরের জন্য হাইব্রিড অবস্থায় থাকে—অনপ্রিমে ক্রিটিক্যাল ওরাকল ও ক্লাউড-নেটিভ সিস্টেম মিশ্রভাবে চলতে পারে—এবং ওরাকল লক্ষ্য রাখে সর্বত্রই ডিফল্ট হিসেবে থাকতে।