Database support license = unfair trade practice… ??

The other day, I used the Oracle transportable tablespace mechanism at a customer site to rapidly copy a schema from one database to another. The customer DBA working with me stared in awe and said “This is slick! I have never used this new feature before...” Now it was my turn to be awe-struck. I gently reminded him that Oracle had released the transportable tablespace feature in Oracle8i back in 1999! And this was 2006 and we were working with Oracle10g… the transportable tablespace mechanism was not a new feature anymore – unless one has been hanging with Rip Van Winkle for the last 7 years.

That little incident made me wonder... Many of our customers rely on multiple database platforms, tools and applications. Some of these applications use older database versions. Often even the applications that use the newest database version pretend the database is an older version. In other words, the apps rarely use any newer feature/functionality from the latest releases. In such situations, I always wonder what advantage did the customer gain by upgrading their database version?

When I ask the customer this question, they say “Oh, we had no choice, the vendor has desupported the earlier version.” I naively ask “Were you using their support pretty regularly then and that’s what prompted you to upgrade since you were at risk of not being supported any more?”. Pat comes the answer from their DBA – “We were already on the terminal release for that version; it was stable in our environment, so we weren’t really calling their support line at all. But then, we were anyway paying them support fees, the upgrade didn’t cost us anything, so we went ahead and upgraded.”

An upgrade didn’t cost anything? Yeah right! When asked how long and how many resources it took them to upgrade, the answer is usually in several man-months to provision new machines, perform installation, configuration, testing of the newer database release and all the related apps to ensure those apps can function in the new release without any kind of degradation. So now I’m even more confounded. If you weren’t using the vendor’s support services, why would you care if you were de-supported or not? Then again comes the answer “oh, it’s our corporate policy that we can’t have un-supported software”. Policy made by who? Does this so-called policy-maker understand the ramifications of upgrading the database without a clear business need? Does this person really understand the ROI on the support fees your company has been paying the software vendor?

It seems somewhat of a catch-22. If you don’t upgrade your already stable release, then you are at risk of running on a de-supported release. So you spend lots of time and resources upgrading and then move to a newer release that may not be as stable as the prior release you were on. And on top of that, you barely use any (read zero!) of the newer features available in the new release. So besides having the peace of mind that you are running on a “supported” platform, what else do you gain? Nothing but the problems that are introduced with the newer release…

Oracle, Microsoft and IBM have all released newer versions of their databases in the last couple of years. They charge an average of 20% (an arm and a leg!) for support. I say, given that very few newer functionality is being utilized, customers should just stop paying for support. If there are bugs in the product, the vendor should provide a patch regardless of whether the customer has purchased support or not. After all, didn’t the customer pay for the software expecting it to work? If it doesn’t work, whose fault is it? Why does the vendor provide a solution to that bug only if the customer has paid an extra 20% for this so-called support?

Imagine what would happen if the average retailer operated like the average software company… You pick up a book at Borders and find that it’s missing a couple of pages. You take it back asking for another copy and they ask you if you have purchased a support license…

If this scenario is not acceptable in retail, why is it the norm in the software industry? Is it because in the former case, people are dealing with their “own money” whereas in the latter, it’s just their “company’s resources”??

I say, it’s time for companies to rally together and file a class action suit against the software monoliths asking for support fees to be refunded back to them. If the software is buggy, then the software vendor needs to get it fixed and supply a patch pronto regardless of whether the customer has a support license or not! After all, they have paid for that software expecting it to be functional. No sane person pays for anything expecting it to be buggy.

As far as support fees funding “future innovation” goes, newer releases/upgrades could be chargeable separately and customers at their discretion can look at the new release and see if it has value for them and if their apps would run on it, etc. and accordingly make the decision to upgrade (or not!). They shouldn’t have to upgrade because the older version is going to be “de-supported”. If the vendor is going to de-support an older release, the vendor should then provide the newer release at no additional charge to the customer that doesn’t have a business need for upgrading otherwise.

I don’t know if customers would be willing to go through the pain of litigation. But maybe they can just stop paying for support. Unless they put their foot down, the software vendors have no motivation to change and it’s business as usual all around where the customer shells out gobs of money for “support” that they sparingly use. The returns are just not there for the customer.

Software vendors should charge for the software or charge for the support; but charging for both given the above circumstance resorts to an unfair trade practice in my book. What am I missing?

Commoditization of Database Administration - Will DBAs and IT Managers "Get it"?

Over the last 5 years, database administration is slowly but steadily turning into a commodity exposing numerous niches that need creative input and hard work by the DBAs whose bandwidth has suddenly increased. There are three primary market forces working together to make this happen:
(i) Advances in DBMS technology from IBM, Microsoft, Oracle and open-source databases (in that order) ;
(ii) DBA outsourcing and offshoring;
(iii) Automation and virtualization technologies that create a layer of abstraction over DBA tasks ranging from simple ones like database server provisioning to relatively complex ones such as error-free nightly load process management.

The first stems from the effect of databases themselves turning into commodities. For instance, DBMS software is being given away for free not only from open source DB support hawkers such as MySQL but also the big 3 (Oracle, IBM and M$). IBM announced a free version of DB2 back in Jan '06 (http://www.varbusiness.com/article/showArticle.jhtml?articleId=177105213) . Likewise, Oracle has been offering its free Express Edition for a little while now (http://www.crn.com/showArticle.jhtml?articleID=172901482).

As databases turn into commodities, what is the impact on database administration? Rather than being thought of as something intrinsic to the company, it is being rightfully seen as a regular IT function - a necessary evil that is not necessarily a core competency of the business. Database administration has increasingly been separated from data management with the need for specialists in each area being felt by the business. This separation has resulted in the DBA not having to deal directly with the data within the database. DBAs used to be viewed as someone with the keys to the kingdom - in terms of their promixity and access to business-critical data. But with newer audit capabilities and security models offered by Oracle (sysdba versus sysoper, etc.) and other vendors, it is easy to separate the Systems DBA role from data-centric responsibilities. This commoditization and separation has further made it conceivable for companies to entertain going after boutique/best of breed outsourcers and hand over support for the traditional Systems DBA role in a cost effective and secure manner driven by metrics and service level agreements.

Many of these DBA outsourcing specialists have managed to add value via strong process models such as ITIL and monitoring/automation tools and integrated themselves within the companies they provide services to - further adding credibility to the fact that database administration is something that can be successfully separated and outsourced by astute IT managers.

The state of automation and virtualization frameworks and supporting sub-technologies have matured over the years - making automation of many mundane yet labor-intensive areas a reality. DBMS and tools vendors have largely shed their inhibitions about supporting solely their proprietary platform and have taken on support for competiting platforms - starting with basic monitoring support. For instance, Oracle has recently added support for SQL Server and DB2 databases within their OEM/Grid Control monitoring tool. This was plain inconceivable just a few years ago! But as the industry evolves, mainstream DBMS vendors have no choice but to lean more and more towards offering better editions of their databases for free and include support for competing databases within their own tools.

While these events bode well for the average customer due to lowered product costs and higher administrative efficiency and quality, how does this impact the individuals themselves - the DBAs who have been depending on the various DBMSs and assorted tools for their livelihood? Do they have reason to start looking at alternative careers as mail-carriers or petting zoo attendants?

My opinion is, the commoditization of database administration is a golden opportunity for DBAs to finally separate the mundane administrative areas, outsource and/or automate them and elevate themselves up the food chain to focus on areas that they previously never had the time to work on. The more user-visible stuff that if worked on, will yield measurable results in terms of reduced # of SLA violations, performance dips and outages. Areas such as quantitative performance management, service level management, data management, application/database interplay management, database/infrastructure optimization, new DBMS feature evaluation and other proactive management areas. In other words, the optimal career movement for the successful DBA needs to be "management" related (not necessarily people management, but managing performance and related areas indicated above.)

It will be interesting to see in the coming years how many DBAs actually "get" this, embrace the change and position themselves at the forefront of this once-in-two-decades kind of revolution versus how many continue to sit in their temporary trenches with arcane tools and scripts, fight progress and eventually miss the boat.

DBA Job Growth Statistics are Encouraging; the Insecure DBA's Attitude Towards Automation is Not!

I saw a report from InfoWorld today that showed database administration being in the top 5 fastest growing IT positions. I have seen similar reports in the recent past ranging from the US Dept of Labor to independent/private reports. They all peg database administration to be growing anywhere from 33% to 66% - by the year 2014. In spite of this growth, the biggest concern is lack of quality DBAs (database administrators). Sure there are lots of bodies around the planet, but there just aren't enough qualified professionals to meet the growing requirements. People that not only can handle part of the job load, but those that can also communicate well with their users and peers. People that not only know the mechanics behind a task, but also what needs to be done and when to a database to meet user requirements and business growth.

If these job growth statistics aren't a clarion call for leveraging automation, I don't know what is!

Yet I often encounter DBAs that shrivel up at the mere sound of the word "automation" or go on the defensive. (Let's call these folks the "insecure DBAs".) They claim database administration cannot be automated in THEIR environment due to the complexity of the tasks they do and/or due to the constantly changing underlying environment. News flash: database administration isn't rocket science... and btw, even rocket science leverages automation in more ways than one can imagine. Any task that comprises a specific sequence of steps (and last I checked, most if not all tasks in database administration can be boiled down to such sequences) can be automated.

Some DBAs agree that yes, some of their tasks can be automated, however they will end up forgetting how to carry out those tasks manually. And when (note their use of "when" and not "if") the automation system fails, then the business would be in a conundrum since they would have forgotten how to do the task manually. Boo hoo... Wake up guys and smell the coffee. IT automation is happening in a big way. The companies that don't embrace it will be relegated to the dark ages. They just won't be able to compete effectively. Job loss is a natural effect of companies going under... regardless of industry job growth statistics.

Instead of running around in their firefighters' personas and conjuring up excuses as to why automation is not an option in "their" environment, it's time DBAs started working together to build standard operating procedures and leveraging those procedures as blue prints for automation. Hiding underneath a stack of manual tasks and looking busy used to guarantee employment. Now in the evolving technology landscape, it's a sureshot way to keep oneself and one's company stuck in the annals of old world IT (aka "luddite-dom"), replete with a plethora of one-off tools, commands and actions.

It's time to revel in the inherent job security provided by the growth in demand for quality DBAs. Using standardization and automation to handle those lower level tasks, it's time to polish up those communication skills, move up the food chain and work on the exciting big projects that truly give competitive advantage to your company and propel it into the 21st century! That more than anything, will assure the insecure DBA of continued employment.