লারি এলিসন ও ওরাকল: ডাটাবেস, লক-ইন, এবং এন্টারপ্রাইজ সেলস

এক বাক্যে টেকসই-অর্থের সূত্র

লারি এলিসনের টেকসই-অর্থের সূত্রটি এক বাক্যে করা যায় এভাবে: একটি মিশন-ক্রিটিক্যাল ডাটাবেস বিক্রি করুন, সেটি বার্ষিক চুক্তিতে আবদ্ধ করুন, এবং এমন একটি এন্টারপ্রাইজ সেলস মেশিন তৈরি করুন যা অবস্থান বদলানোকে ঝুঁকিপূর্ণ মনে করায়।

এটি একটি ব্যবসায়িক কাহিনী—কিভাবে ওরাকল প্রতিস্থাপন করা কঠিন হয়ে উঠল—আর এটা ডাটাবেস ইন্টারনালের গভীর টেকনিক্যাল টিউটোরিয়াল নয়। SQL অপটিমাইজার কিভাবে কাজ করে জানার দরকার নেই এইটি বুঝতে যে কেন ওরাকল বহু দশক ধরে নগদ প্রবাহের ইঞ্জিন হয়ে উঠল।

এখানে “টেকসই” মানে কী

“টেকসই” মানে গ্রাহকরা প্রতিটি রিনিউয়ালে উৎসাহিত ছিলেই না—বরং ওরাকল এমনভাবে নিজেকে স্থাপন করেছিল যাতে রাজস্ব পুনরায় আগমন করতেই থাকে।

টেকসইতা এইভাবে প্রকাশ পায়:

• পুনরাবৃত্ত রাজস্ব—সাপোর্ট, মেইনটেন্যান্স, এবং চলমান লাইসেন্স থেকে
• উচ্চ রিনিউয়াল রেট—কারণ সফটওয়্যারটি কোর অপারেশন চালায়
• গ্রাহক ইননার্টিয়া—ঝুঁকি, খরচ, এবং সংগঠনগত অভ্যাসের কারণে

যখন একটি ডাটাবেস বিলিং, ইনভেন্টরি, HR, বা ট্রেডিং সিস্টেমের নিচে বসে, তখন এটি আর শুধুই একটি IT টুল নয়। এটি একটি নির্ভরতায় পরিণত হয়, আর নির্ভরতা সহজে ছাড়ানো যায় না।

তিনটি মূল স্তম্ভ যার ওপর আমরা বারবার আসব

1) ডাটাবেস—ভিত্তি হিসাবে। ওরাকল “সিস্টেম অফ রেকর্ড” স্তরের ওপর মনোযোগ দেয়—যেখানেই সবচেয়ে মূল্যবান অপারেশনাল ডেটা থাকে।

2) লক-ইন (যখনও কখনও অনিচ্ছাকৃত)। শুধু টেকনিক্যাল সামঞ্জস্য নয়, বরং প্রক্রিয়া, ইন্টিগ্রেশন, প্রশিক্ষণ, এবং ভেন্ডর-নির্দিষ্ট ফিচার যেগুলো বছরের পর বছর জমতে থাকে।

3) এন্টারপ্রাইজ সেলস। ওরাকল ভোক্স-অ্যাপে জয় অর্জন করেনি। এটি জিতেছে প্রোকিউরমেন্ট সাইকেল, নির্বাহী সম্পর্ক, এবং এমন চুক্তির মাধ্যমে যা সম্পর্ক বাড়ায়।

এই তিনটি একত্রে একটি সংযোজক প্রভাব তৈরি করে: প্রতিটি নতুন ডিল কেবল একবারের বিক্রি ছিল না—এটি বহু ভবিষ্যত পেমেন্টের সম্ভাবনা বাড়ায়।

ল্যারি এলিসন এবং ওরাকলের শুরুতেই এন্টারপ্রাইজ সফটওয়্যারে বাজি

লারি এলিসন শুরুতে কোনও সফটওয়্যার সেলিব্রিটি ছিলেন না। তার প্রাথমিক ক্যারিয়ার ছিল প্রোগ্রামিং কাজ আর বড় প্রতিষ্ঠানগুলি প্রযুক্তি কীভাবে কিনে—ধীর, সাবধানে, এবং স্থিতিশীল ভেন্ডার পছন্দ করে—সেটা শেখার একটি ব্যবহারিক মিশ্রণ।

ওরাকল 1977 সালে শুরু করে (Software Development Laboratories নামে) একটি স্পষ্ট ধারনার সঙ্গে: সফটওয়্যারের সবচেয়ে বড় অর্থ ইনফ্রাস্ট্রাকচার বিক্রি করে বড় প্রতিষ্ঠানগুলোকে দেওয়াই, একবারের কাস্টম সিস্টেম নির্মাণ নয়। এলিসন ও তাঁর সহপ্রতিষ্ঠাতা হবি বা কনজিউমার মার্কেট না নেভে, কোম্পানি ও সরকারি সংস্থাগুলোর দিকে লক্ষ্য করে যারা পে-রোল, ইনভেন্টরি, বিলিং, ও অ্যাকাউন্টিং চালানোর জন্য সিস্টেম প্রয়োজন।

এন্টারপ্রাইজ কম্পিউটিং প্রসঙ্গ

তৎকালীন সময়ে কম্পিউটিং শাসিত ছিল মেইনফ্রেম ও কেন্দ্রীয়ভাবে পরিচালিত ডেটার মাধ্যমে। ক্লায়েন্ট-সার্ভার সেটআপগুলো দেখা দিলেও, বড় কোম্পানিগুলোর মধ্যে ডিফল্ট ধারণা ছিল যে সিস্টেমগুলোকে নির্ভরযোগ্য, অডিটেবল, এবং বছরের পর বছর সমর্থনযোগ্য হতে হবে।

এই পরিবেশ সেসব সফটওয়্যারকে পুরস্কৃত করত যেগুলো একটি স্ট্যান্ডার্ড উপাদান হয়ে উঠতে পারে—যেটার চারপাশে IT দলগুলো আর্কিটেকচার গড়ে তুলতে পারে। ডাটাবেস ঠিক এই ভূমিকায় ফিট করে: অনেক অ্যাপ্লিকেশনের নিচে বসে, গুরুত্বপূর্ণ ডেটা স্পর্শ করে, এবং চলমান রক্ষণাবেক্ষণ ও সাপোর্টকে যৌক্তিক করে তোলে।

বড় প্রতিষ্ঠানকে বিক্রি করার কারণে ব্যবসায়িক মডেল কিভাবে বদলে যায়

এন্টারপ্রাইজ গ্রাহকরা ব্যক্তিদের মত করে কিনে না। তারা কমিটি, প্রোকিউরমেন্ট প্রসেস, এবং বহু-বছরের পরিকল্পনার মাধ্যমে কেনে। এতে ভেন্ডারকে জোর দিতে হয়:

• বিদ্যমান সিস্টেম ও ওয়ার্কফ্লো-র সাথে সামঞ্জস্যতা
• ডকুমেন্টেশন, প্রশিক্ষণ, ও সাপোর্ট
• পূর্বানুমানযোগ্য রোডম্যাপ ও দীর্ঘমেয়াদি চুক্তি

এটি আর্থিক প্রোফাইলও পরিবর্তন করে। একটি বড় ডিল একাধিক বছরের প্রোডাক্ট কাজকে অর্থায়ন করতে পারে, কিন্তু এর জন্য সম্পর্ক ও প্রুফ ও ঝুঁকি হ্রাস করার ওপর ভিত্তি করে একটি সেলস মোশন দরকার।

ওরাকলের শুরুতি বাজি সরল ছিল: এন্টারপ্রাইজ অপারেশনের কোরে একটি স্থান অর্জন করুন, এবং আপনি কেবল সফটওয়্যার বিক্রি করছেন না—আপনি আপডেট, সাপোর্ট, ও আপগ্রেডের মাধ্যমে ধারাবাহিকতা বিক্রি করছেন, যা নির্ভরতা বাড়ার সঙ্গে গ্রাহকরা পরিশোধ করে যেতে থাকে।

কেন ডাটাবেস এন্টারপ্রাইজ স্তরের কেন্দ্র হয়ে উঠল

একটি ডাটাবেস হল কোম্পানির সিস্টেম অফ রেকর্ড: যেখানে “প্রধান সত্য” থাকে। কাস্টমার অ্যাকাউন্ট, ইনভয়েস, ইনভেন্টরি গণনা, পে-রোল এন্ট্রি, শিপমেন্ট স্ট্যাটাস—এইগুলো কেবল ফাইল নয়। এগুলো এমন তথ্য যেগুলোর ওপর ব্যবসা দারা-পাওয়া, আনুগত্য, এবং দৈনন্দিন অপারেশন নির্ভর করে।

সেই এক উপাদান যার ওপর সবকিছু নির্ভর করে

যত বেশি এন্টারপ্রাইজ সফটওয়্যার তৈরি করা হয়—ERP, CRM, বিলিং, সাপ্লাই চেইন—এই অ্যাপ্লিকেশনগুলো ক্রমশ একই অধস্তন “সূত্র”-কে শেয়ার করে। যদি ডাটাবেস অনুপলব্ধ থাকে, তাহলে যে অ্যাপগুলো রেকর্ড পড়ে ও লেখে সেগুলোই তাদের কাজ করতে পারবে না। তাই ডাটাবেসটি একটি কেন্দ্রীয় নির্ভরতায় পরিণত হয়, কেবল আরেকটি IT পিস নয়।

ডাটাবেস কেন স্টিকি হয়ে যায়

ডাটাবেসগুলো স্টিকি হয়ে যায় কারণ অ্যাপ্লিকেশনগুলো তাদের চারপাশে লেখা হয়। সময়ের সঙ্গে আপনি জমা করেন:

• ব্যবসায়িক প্রসেস অনুযায়ী কৃত স্কিমা ও স্টোরড লজিক
• রিপোর্টিং, ফাইন্যান্স, ডেটা এক্সপোর্ট, ও পার্টনার সিস্টেমে ইন্টিগ্রেশন
• অপারেশনাল রুনবুক, মনিটরিং, ব্যাকআপ রুটিন, এবং একটি নির্দিষ্ট প্রোডাক্ট-এ ফিট হওয়া পারফরম্যান্স টিউনিং

পরিবর্তন করা স্প্রেডশিট টুল বদলানোর মত সহজ নয়। আপনাকে প্রচুর পরিমাণ ডেটা মাইগ্রেট করতে হবে, ইতিহাস সংরক্ষণ করতে হবে, গুরুত্বপূর্ণ ওয়ার্কফ্লো পুনরায় পরীক্ষা করতে হবে, এবং প্রায়ই অ্যাপ্লিকেশনের কিছু অংশ পুনরায় লিখতে হবে। নতুন অপশন সস্তা হলেও প্রকল্প ঝুঁকি সাশ্রয়কে ছাপিয়ে যেতে পারে।

ডাউনটাইম ও ডেটা লস কেন ক্রয়ের আচরণ বদলে দেয়

মিশন-ক্রিটিক্যাল সিস্টেমের জন্য, ভয়টি নয় “এই সপ্তাহে একটু ধীর হবে।” ভয় হল এমন এক দিন যখন অর্ডার প্রসেসিং বন্ধ হয়ে যায়, অথবা ডেটা লস এমন রিকোয়েস্ট বাধ্য করে যা রিকনসিলিয়েশন, রিফান্ড, ও নিয়ন্ত্রক ঝামেলা তৈরি করে।

যখন একটি খারাপ দিনের খরচ মিলিয়ন হতে পারে—বা বিশ্বাস ক্ষতিগ্রস্ত হতে পারে—ক্রেতারা কনজার্ভেটিভ হয়ে ওঠে। “বিশ্বস্তভাবে কাজ করে” সাধারণত “নতুন ও সম্ভাবনাময়” এর চেয়ে জিতবে।

প্রমাণিত ভেন্ডাররা কোর জিতে কেন যায়

IT বিভাগের বিচার স্থিতিশীলতার আধার। তাই তারা দীর্ঘ ট্র্যাক-রেকর্ড, পরিণত টুলিং, এবং যে সাপোর্ট টিমগুলো প্রতিটি ব্যর্থতার মোড দেখেছে এমন ভেন্ডারের দিকে ঝেুঁকে পড়ে।

একবার সেই সিদ্ধান্ত নেওয়া হলে, ডাটাবেস বাকী স্ট্যাকের জন্য অ্যাঙ্কর হয়ে ওঠে—অ্যাপ, প্রক্রিয়া, এবং বাজেটগুলোকে নিজের কক্ষপথে টেনে নিয়ে যায়।

রিলেশনাল ডাটাবেস, SQL, এবং ওরাকল আসলে কী বিক্রি করত

রিলেশনাল ডাটাবেস হল ব্যবসায়িক ডেটা—কাস্টমার, ইনভয়েস, শিপমেন্ট—টেবিলে (স্প্রেডশিট ভাবেই) রাখার একটি পদ্ধতি যা পরস্পরের সাথে লিঙ্ক করা যায়। ফাইল খুঁজে বেড়ানোর পরিবর্তে আপনি প্রশ্ন করতে পারেন: “সব অনিপেইড ইনভয়েসগুলো দেখাও যেগুলো ৩০ দিন বা বেশি” এবং দ্রুত ও নির্ভুলভাবে উত্তর পাবেন।

SQL মানক ছিল—তাহলে কীভাবে এজটা তৈরি হত?

SQL (Structured Query Language) রিলেশনাল ডাটাবেসের সাথে কথা বলার সাধারণ ভাষা। যেহেতু SQL ব্যাপকভাবে শেখানো হয় এবং বিস্তৃতভাবে সমর্থিত, তাই মনে করা সহজ যে ডাটাবেস পণ্যগুলো বিনিমেয়।

কিন্তু বাস্তব কোম্পানিতে, যা গুরুত্বপূর্ণ তা কেবল সিস্টেম SQL বুঝে কিনা তা নয়। পার্থক্য দেখা যায় চারপাশের সবকিছুর মধ্যে: ডাটাবেস বড় লোডে কিভাবে আচরণ করে, ক্র্যাশের পর কিভাবে পুনরুদ্ধার করে, ব্যাকআপ কিভাবে কাজ করে, অনুমতি কীভাবে ম্যানেজ করা হয়, এবং দলগুলো কিভাবে পারফরম্যান্স মনিটর ও টিউন করে।

এন্টারপ্রাইজগুলো ফলাফল কেন কিনত, সিনট্যাক্স নয়

ওরাকল “SQL” বিক্রি করত না। ওরাকল বিক্রি করত মিশন-ক্রিটিক্যাল সিস্টেমগুলো চলতেই থাকবে—এই প্রতিশ্রুতি।

• নির্ভরযোগ্যতা mattered—কারণ পে-রোল দেরি করে চলতে পারে না এবং অর্ডার প্রসেসিং বন্ধ হতে পারে না।
• পারফরম্যান্স mattered—কারণ ধীর ডাটাবেস প্রতিটি অ্যাপকে ভাঙা মনে করায়।
• টুলিং mattered—বড় সংস্থাগুলোকে পূর্বানুমানযোগ্য আপগ্রেড, ডায়াগনোস্টিক্স, রেপ্লিকেশন, সিকিউরিটি কন্ট্রোল, এবং রাত ২টার সময় স্কেল-আপ করার মতো উচ্চ-স্তরের সাপোর্ট দরকার।

আধিপত্য কেবল প্রযুক্তিগত না কেন

এমনকি যদি প্রতিদ্বন্দ্বী ফিচার মেলে, একটি ডাটাবেসে স্ট্যান্ডার্ডাইজ করার সিদ্ধান্ত বিস্তৃত দলের, বাজেট এবং বছরের অপারেশনাল অভ্যাস জুড়ে ছড়িয়ে পড়ে। একবার একটি ডাটাবেস রিপোর্টিং, ইন্টিগ্রেশন, এবং কমপ্লায়েন্সের কেন্দ্র হয়ে গেলে “ভালো পর্যাপ্ত” প্রযুক্তি জেতা কঠিন হয়ে পড়ে।

বাজার আধিপত্য সাধারণত পণ্য গুণমান, ঝুঁকি ব্যবস্থাপনা, এবং সেলস কার্যকরী কৌশলের মিশ্রণ প্রতিফলিত করে—কোনও একক কিলার ফিচার নয়।

ওরাকলের এন্টারপ্রাইজ সেলস প্লেবুক

ওরাকল বিক্রি করে নি ডেভেলপারদের ক্রেডিট কার্ড স্বয়ংক্রিয়ভাবে টেনে নিয়ে। তারা শিখেছিল কিভাবে বড় কোম্পানিগুলি আসলে কেনে: ধীর, সাবধানে, এবং বহু মানুষ জড়িত।

কমিটির কাছে বিক্রি—একজন ব্যক্তির কাছে নয়

এন্টারপ্রাইজ প্রোকিউরমেন্ট একটি দলীয় খেলা। একটি সাধারণ ডিলে IT লিড, সিকিউরিটি, ফাইন্যান্স, লিগ্যাল, এবং যে বিজনেস ইউনিট সিস্টেমটি চালাবে—এসব মানুষ জড়ায়। এর মানে দীর্ঘ টাইমলাইন, আনুষ্ঠানিক দাবি, এবং অভ্যন্তরীণ রাজনীতি।

ওরাকল এই বাস্তবতায় ঢুকে পড়ে প্রুফ অফ কনসেপ্ট (PoC), রেফারেন্স কাস্টমার, এবং বিস্তারিত সামঞ্জস্য দাবির মাধ্যমে। একটি PoC কেবল টেকনিক্যাল টেস্ট নয়—এটি এমন একটি উপায় যাতে একটি স্পনসর ক্রয়কাজটা বাকি সবাইকে ন্যায্যতা দেখাতে পারে।

অ্যাকাউন্ট-ভিত্তিক সেলিং ও বহু-বছরের সম্পর্ক

ওরাকল ক্লাসিক অ্যাকাউন্ট-ভিত্তিক সেলিং তৈরি করে: ডেডিকেটেড রেপ, নামক অ্যাকাউন্ট, এবং কোয়ার্টারলি বিজনেস রিভিউ—এবং এটি ABM ট্রেন্ডি হওয়ার অনেক আগেই ছিল।

লক্ষ্য কেবল প্রথম চুক্তি নয়; লক্ষ্য ছিল পরবর্তী প্রকল্পের জন্য ডিফল্ট ডাটাবেস হওয়া, এবং তার পরেরটাও। CIO বা ডাটাবেস টিমের সঙ্গে আস্থাটা বাজেট, রিওর্গ, এবং এমনকি স্বল্প-মেয়াদি প্রোডাক্ট অসন্তোষ থেকেও টিকে থাকতে পারে।

সাপোর্ট, সার্টিফিকেশন, ও পার্টনারদের ভূমিকা সিদ্ধান্ত গ্রহণে

সাপোর্ট কন্ট্র্যাক্ট, সার্টিফিকেশন (DBA, ডেভেলপার), এবং সিস্টেম ইন্টিগ্রেটররা গতি তৈরি করে। একবার একটি কোম্পানি প্রশিক্ষিত কর্মী, অনুমোদিত আর্কিটেকচার, এবং এমন একটি পার্টনার পেয়ে গেলে যিনি ওরাকল ভালোভাবে জানেন, ভেন্ডার পরিবর্তন করা ঝুঁকিপূর্ণ মনে হয়।

পার্টনাররা RFP-তে কী সুপারিশ করা হবে, কোন দক্ষতা পাওয়া যায়, এবং কোন প্ল্যাটফর্মগুলো “নিরাপদ” বিবেচিত হবে—এসবকেও প্রভাবিত করে।

রিনিউয়াল: যেখানে বাস্তব লিভারেজ থাকে

রিনিউয়ালগুলো নতুন লোগো-এর চেয়ে বেশি গুরুত্বপুর্ন হতে পারে। যদি ওরাকল কোর সিস্টেমে এমবেডেড হয়ে যায়, বার্ষিক রিনিউয়াল হয়ে ওঠে একটি ব্যবসায়িক-অবিরততা সিদ্ধান্ত—নতুন মূল্যায়ন নয়। তখনই মূল্য নির্ধারণ, অডিট শর্ত, এবং চুক্তির কাঠামো আচরণ গঠনে পণ্য ফিচারের মতোই প্রভাব ফেলে।

(লক-ইন মেকানিক্স সম্পর্কে বিস্তারিত দেখতে /blog/how-lock-in-works দেখুন।)

লক-ইন কিভাবে কাজ করে: প্রযুক্তিগত, অপারেশনাল, ও চুক্তিগত

ভেন্ডর লক-ইন নৈতিক অভিপ্রায়ের উপর নির্ভর করে না। এটি সরলভাবে সময়ের সঙ্গে একটি ভেন্ডরের পণ্যের ওপর বাড়তে থাকা নির্ভরতা এবং সময়ের সঙ্গে পরিবর্তনের খরচ বৃদ্ধির সমন্বয়। কোর সিস্টেমের মতো ডাটাবেসের ক্ষেত্রে, এই সমন্বয় শক্তিশালী হয়ে উঠে কারণ ডাটাবেস অ্যাপ্লিকেশন, রিপোর্টিং, সিকিউরিটি, এবং দৈনন্দিন অপারেশনের নিচে অবস্থান করে।

প্রযুক্তিগত লক-ইন

আপনার সিস্টেমগুলো যদি এমন ক্ষমতার ওপর নির্ভরশীল হয় যা সহজে অন্যত্র পুনরায় সৃষ্টি করা যায় না, তা হল প্রযুক্তিগত লক-ইন। ডাটাবেসে, এটি সাধারণত দেখা যায় মালিকানাধীন ফিচার (বিশেষ SQL এক্সটেনশন, পারফরম্যান্স হিন্ট, ক্লাস্টারিং পদ্ধতি), ভেন্ডর-নির্দিষ্ট টুলিং, এবং অ্যাপ ও মিডলওয়্যারের গভীর ইন্টিগ্রেশনের মাধ্যমে।

এমনকি যখন “এটি কেবল SQL,” বাস্তব-জগতের ডিপ্লয়মেন্টগুলো স্টোরড প্রসিডিউর, ট্রিগার, ব্যাকআপ স্ক্রিপ্ট, মনিটরিং এজেন্ট, এবং কাস্টম কানেক্টরের মত জিনিস জমায়। স্ট্যাকের যত বেশি অংশ একটি ডাটাবেসের জন্য টিউন করা থাকে, তত ক্লিন মাইগ্রেশন কঠিন হয়।

অপারেশনাল লক-ইন

অপারেশনাল লক-ইন মানুষ ও প্রক্রিয়া সম্বন্ধীয়। দলগুলো একটি নির্দিষ্ট প্ল্যাটফর্মে প্রশিক্ষিত হয়, একটি নির্দিষ্ট সার্টিফিকেশন পাথ অনুসরণ করে কর্মী নিয়োগ করে, এবং নির্দিষ্ট আচরণের ওপর ভিত্তি করে রুনবুক তৈরি করে—কিভাবে ফেইলওভার কাজ করে, কিভাবে আপগ্রেড করা হয়, কী “সাধারণ” পারফরম্যান্স মনে হয়।

সময়ের সঙ্গে কমপ্লায়েন্স ও অডিট ডকুমেন্টেশনও ডাটাবেস-নির্দিষ্ট হয়ে ওঠে: অ্যাক্সেস কন্ট্রোল, এনক্রিপশন কনফিগারেশন, রিটেনশন পলিসি, এবং ইনসিডেন্ট রেসপন্স ধাপগুলো। তখন ভেন্ডার পরিবর্তন মানে হবে পুনঃপ্রশিক্ষণ, প্রক্রিয়া পুনরায় লেখা, এবং কন্ট্রোলগুলো পুনঃভ্যালিডেট করা।

চুক্তিগত লক-ইন

চুক্তিগত লক-ইন পরিবর্তনের খরচকে ক্যালেন্ডারে রূপান্তর করে। বহু-বছরের মেয়াদ, বান্ডেলড সাপোর্ট স্ট্রাকচার, রিনিউয়াল সাইকেল, এবং এন্টারপ্রাইজ-ওয়াইড এগ্রিমেন্টগুলো “আমরা পরের কোয়ার্টারে পরিবর্তন করব”কে অবাস্তব করে তোলে।

সাপোর্ট একটি বড় হাতিয়ার: একবার ক্রিটিক্যাল সিস্টেমগুলো ভেন্ডর সাপোর্টের ওপর নির্ভর করতে শুরু করলে, ছেড়ে চলে যাওয়া যেন নতুন অপারেশনাল ঝুঁকি গ্রহণ করা—বিশেষত যদি চুক্তিতে কঠোর ব্যবহার সংজ্ঞা এবং দণ্ড থাকে যা আংশিক মাইগ্রেশন জটিল করে।

লাইসেন্সিং ও প্রাইসিং: মোয়াটের পেছনের অর্থনীতি

ওরাকলের মোয়াট শুধুই প্রযুক্তিগত ছিল না। এটি আর্থিকও ছিল—লাইসেন্সিং মডেলের মাধ্যমে তৈরি, যাতে ডাটাবেস বাজেটে যেমন এমবেডেড লাগে তেমনি সিস্টেমে।

সরল কথায় লাইসেন্সিং

ওরাকল লাইসেন্সিং প্রায়ই কয়েকটি সাধারণ ইউনিটে বিক্রি করা হয়েছে:

• কোরস (প্রসেসর-ভিত্তিক): আপনি যেটা চালাচ্ছেন তার কম্পিউটিং পাওয়ারের ওপর ভিত্তি করে পে করেন। বেশি সার্ভার বা বড় CPU মানে বড় বিল।
• ইউজার (নেমড ইউজার প্লাস): আপনি প্রতি ব্যক্তির ওপর অর্থ দেন যিনি সিস্টেমে অ্যাক্সেস পায়, প্রায়ই প্রতি সার্ভারে ন্যূনতম সহ।
• এডিশন: বিভিন্ন স্তর (বিভিন্ন সীমা ও ফিচার) যা “আপগ্রেড করে আনলক” সিদ্ধান্তকে উৎসাহ দেয়।
• অ্যাড-অন ও প্যাক: অতিরিক্ত ফিচার—সিকিউরিটি, পারফরম্যান্স টিউনিং, হাই অ্যাভেলেবিলিটি, ম্যানেজমেন্ট টুলস—যা আলাদাভাবে মূল্য নির্ধারিত হতে পারে এবং একবার গ্রহণ করলে খুলে ফেলতে কঠিন হয়।

মূল ধারণা সরল: একবার ডাটাবেস কেন্দ্রীয় হয়ে গেলে, বৃদ্ধির সাথে সেই মিটারের কোনো না কোনোটি বাড়ে—বেশি কোর, বেশি ইউজার, বা বেশি ফিচার।

জটিলতা কেন ভেন্ডারের পক্ষে সহায়ক

যখন প্রাইসিংয়ে অনেক নোব আছে—মেট্রিক, ব্যতিক্রম, প্রডাক্ট-ইউজ রাইটস, বান্ডলড অপশন—তখন আলোচনাগুলো সেই পক্ষের অনুকূলে যেতে থাকে যারা নিয়মগুলো ভালো জানে।

জটিলতাও গ্রাহকদের জন্য কয়েক বছরের মোট খরচ মডেল করা কঠিন করে তোলে, যা বিকল্পগুলোর সঙ্গে তুলনা বা নিশ্চিতভাবে মাইগ্রেশনে বাধা সৃষ্টি করে।

অডিট ও কমপ্লায়েন্স চেক

ওরাকল (অনেক বড় ভেন্ডারের মতো) লাইসেন্স রিভিউ ব্যবহার করে গ্রাহকদের নিশ্চিত করতে যে তারা চুক্তির শর্তের মধ্যে ব্যবহার করছে। ন্যায়সঙ্গতভাবে করা হলে, অডিট উভয় পক্ষকেই রক্ষা করে।

কার্যত, অডিট আর্থিক ঝুঁকি তৈরি করে: যদি ব্যবহার অতিরিক্ত হিসেবে ব্যাখ্যা করা হয়, গ্রাহককে দ্রুত ট্রু-আপ লাইসেন্স নিতে হতে পারে।

সাপোর্ট রিনিউয়াল ও আপগ্রেড

বার্ষিক সাপোর্ট রিনিউয়াল—অften লাইসেন্সের একটি শতাংশের সাথে যুক্ত—নতুন বিক্রয় ধীর হলেও স্থির রাজস্ব তৈরি করে। আপগ্রেড ও নতুন এডিশন একটি দ্বিতীয় হাতিয়ার: গ্রাহকরা আপডেট থাকা, সামঞ্জস্য বজায় রাখা, এবং সাপোর্ট পেতে পরিশোধ করে, যা পুনরাবৃত্তি চক্রকে শক্ত করে।

প্রতিযোগিতা এবং কেন গ্রাহকরা থাকতেই চাইলেন

ওরাকলের কখনও প্রতিযোগিতা ঘাটত না। অদ্ভুত হচ্ছে কতবার গ্রাহকরা বিকল্পগুলো মূল্যায়ন করেও—তারপরও রিনিউয়াল করেছিল।

বড় প্রতিযোগিতামূলক যুগসমূহ

শুরুতে IBM ছিল স্পষ্ট প্রতিদ্বন্দ্বী: DB2 ইতোমধ্যেই অনেক এন্টারপ্রাইজে তাদের সবচেয়ে গুরুত্বপূর্ণ ওয়ার্কলোডে থাকার কারণে। ওরাকলের পিচ ছিল হার্ডওয়্যার প্ল্যাটফর্ম জুড়ে পোর্টেবিলিটি ও পারফরম্যান্স, যা গুরুত্বপূর্ন হয়ে উঠল কারণ কোম্পানিগুলো IBM মেইনফ্রেমের বাইরে বৈচিত্র্য আনছিল।

1990 ও 2000-এর দশকে, Microsoft SQL Server দ্রুত বাড়ে—বিশেষ করে ডিপার্টমেন্টাল ও মিড-মার্কেট সিস্টেমের জন্য যাদের সরলতা ও কম দামের ট্যাগ দরকার ছিল। এটি প্রায়ই “ভালো-পর্যাপ্ত” ছিল, এবং বহু নতুন অ্যাপ্লিকেশনের জন্য সত্যিই তাই ছিল।

তারপর ওপেন সোর্স গুরুতর কাজে বিশ্বাসযোগ্য হয়ে উঠল। MySQL ওয়েব ওয়ার্কলোড দখল করে; PostgreSQL যেসব টিম এন্টারপ্রাইজ-গ্রেড ফিচার চেয়েছিল কিন্তু এন্টারপ্রাইজ লাইসেন্স ছাড়াই চেয়েছিল তাদের মধ্যে জনপ্রিয় হয়ে উঠল।

কেন “ভালো-পর্যাপ্ত + সস্তা” সবসময় জিতে না

ডাটাবেসগুলো আলাদাভাবে কেনা হয় না। সেগুলো ব্যবসায়িক প্রসেস, রিপোর্টিং, সিকিউরিটি রিভিউ, কমপ্লায়েন্স সাইন-অফ, এবং ভেন্ডর সম্পর্কের মধ্যে জড়িয়ে থাকে।

লাইসেন্স ফিতে সাশ্রয় বাস্তব হতে পারে, কিন্তু প্রায়ই অ্যাপ্লিকেশন পুনঃপরীক্ষা, কর্মী পুনঃপ্রশিক্ষণ, ও অপারেশনাল ঝুঁকি শোষণ করার খরচ তাকে ছাপিয়ে দেয়। বহু কোম্পানির জন্য ডাটাবেস কাজ করলে অদৃশ্য থাকে—যখন এটি ভাঙে তখনই দোষারোপ হয়। তাই সিদ্ধান্ত-নির্যায়করা সাধারণত কনজার্ভেটিভ হন: তাঁরা বেশি টাকা দিতে রাজী থাকেন, বরং সেই দলে হতে চান না যারা “বিলিং ভেঙে দিয়েছে।”