Free Ham for $6 Per Pound (and Other Oracle Marketing Ploys)

News from last week’s Oracle OpenWorld is still flying fast and furious. My fellow industry analysts and consultants look forward to Oracle OpenWorld because it gives them material to write about: new products, client case studies, new ideas, and so forth. With all the press releases emitted from OpenWorld, Larry Ellison’s $10 million IBM challenge stands out.

For Oracle product fans, this is exciting. I’ve been accused of getting into the weeds (and analyzing the specific details) when I should just appreciate the creativity and  impact of these types of visibility ploys, but I think Larry’s challenge requires some weeding.

I credit the creativity of the Oracle folks for establishing a performance challenge. Oracle has actually come up with a way of generating revenue from current customers AND prospects.  They’ve actually figured out a way to generate revenue from situations where Oracle isn’t necessarily the optimal solution.

When the worlds of marketing and the legal collide, the outcome is always interesting.   It’s been some time since I reviewed an Oracle software license, but as I recall, the company prohibits anyone from documenting and publicizing performance metrics about their product.

But what if someone is able to take on Ellison’s challenge and refute the “twice as fast” metric?  They’ve done their diligence, used the appropriate hardware settings, configured the DBMS environment, and loaded their real-world data in a pristine fashion, and run an exhaustive set of tests.  And, let’s say, just for argument’s sake, the Redwood Shores solution doesn’t meet expectations. Ostensibly Oracle comes and inspects them the results and—if the product has indeed underperformed, pays out the award money.

Unfortunately, there’s no way for someone to document and publicize their findings without breaking their obligations under Oracle’s license agreement.  So, Oracle not only doesn’t have to pay the $10 million prize – they may actually be able to go after the prospect for financial damages for breaking the licensing agreement.

This is marketing, legal, and sales brilliance.  If you’re Oracle, you are providing incentive for every programmer with time on his/her hands to download Oracle software, load data, and run some tests to win $10 million. The worst that happens is that someone challenges, wins, and Oracle encourages the challenger to pay for software instead of paying for breaking the license.   That’s clearly a win-win if you’re Oracle. But prospective customers may not see things quite the same way.

Maybe Oracle will modify its licensing to allow customers and prospects to document and publish performance results.  Or maybe this is just a minor oversight.   I’m sure whatever the outcome—everything is always in the best interests of their customers.  What other explanation could there be?

Improving BI Development Efficiency: Standard Data Extracts

A few years ago, a mission to Mars failed because someone forgot to convert U.S. measurement units to metric measurement units. Miles weren’t converted to kilometers.

I thought of this fiasco when reading a blog post recently that insisted that the only reasonable approach for moving data into a data warehouse was to position the data warehouse as the “hub” in a hub-and-spoke architecture. The assumption here is that data is formatted differently on diverse source systems, so the only practical approach is to copy all this data onto the data warehouse, where other systems can retrieve it

I’ve written about this topic in the past, but I wanted to expand a bit. I think it’s time to challenge this paradigm for the sake of BI expediency.

The problem is that the application systems aren’t responsible for sharing their data. Consequently little or no effort is paid to pulling data out of an operational system and making it available to others. This then forces every data consumer to understand the unique data in every system. This is neither efficient nor scale-able.

Moreover, the hub-and-spoke architecture itself is also neither efficient nor scalable. The way manufacturing companies address their distribution challenges is by insisting on standardized components. Thirty-plus years ago, every automobile seemed to have a set of parts that were unique to that automobile. Auto manufacturers soon realized that if they established specifications in which parts could be applied across models, they could reproduce parts, giving them scalability not only across different cars, but across different suppliers. 

It’s interesting to me that application systems owners don’t aren’t measured on these two responsibilities:

• Business operation processing—ensuing that business processes are automated and supported effectively
• Supplying data to other systems

No one would argue that the integrated nature of most companies requires data to be shared across multiple systems. That data generated should be standardized: application systems should extract data and package it in a consistent and uniform fashion so that it can be used across many other systems—including the data warehouse—without the consumer struggling to understand the idiosyncrasies of the system it came from.

Application systems should be obligated to establish standard processes whereby their data is availed on a regular basis (weekly, daily, etc.). Since most extracts are column-record oriented, the individual values should be standardized—they should be formatted and named in the same way.

Can you modify every operational system to have a clean, standard extract file on Day 1? Of course not. But as new systems are built, extracts should be built with standard data. For every operational system, a company can save hundreds or even thousands of hours every week in development and processing time. Think of what your BI team could do with the resulting time—and budget money!

photo by jason b42882