Jan 15, 2014

FUDsy Oracle tactics on SAP HANA

FUD- Fear, Uncertainty and Doubts
Is a tactic used in sales, marketing, PR and mostly in politics and propaganda.
FUD was first defined with its specific current meaning by Gene Amdahl in 1975, after he left IBM to found his own company, Amdahl Corporation. "FUD is the fear, uncertainty, and doubt that IBM sales people instill in the minds of potential customers who might be considering Amdahl products." The term has also been attributed to veteran Morgan Stanley computer analyst Ulrich Weil. As Eric S. Raymond writes:
The idea, of course, was to persuade buyers to go with safe IBM gear rather than with competitors' equipment. This implicit coercion was traditionally accomplished by promising that Good Things would happen to people who stuck with IBM, but Dark Shadows loomed over the future of competitors' equipment or software. After 1991 the term has become generalized to refer to any kind of erroneous disinformation used as a corrosive competitive weapon"



FUD is generally a strategic attempt to influence perception on the tactics of fear and ignorance - by mostly disseminating dubious and false information as negative. An individual firm, for example, might use FUD to invite unfavorable opinions and speculation about a competitor's product; to increase the general estimation of TCO with prospects or new customers.
The term originated to describe intentional disinformation tactics in the IT industry but has since been used more broadly. FUD is a manifestation of the baser instincts and the overall fear-mongering appeal to C level stakeholders who are looking for their vendors to provide them with professional advice.


As a rule I keep quite far from negative blogging but in the recent months I have been exposed to some interesting FUD statements from Oracle- possibly in their desperation to keep their current SAP customers on Oracle as they rapidly start to migrate to HANA.


All these FUD's relate to BW on HANA migration only that I have personally been exposed to in one single customer. You decide if these are FUDS or not..


FUD 1: BW has Indexes that will not migrate to HANA and Oracle Exadata will be able to do this far more efficiently. Migrating to HANA will mean additional costs for re-indexing and index fixing
FACT 1: To the best of my knowledge there is no index in legacy databases that will not migrate to HANA.
FACT 1a: BW indexes come in 4 types
BWA Index: Once customers move to HANA they do not need BWA any longer
Analytic Index: HANA migrates these indexes transparently during migration
BTree Index: HANA migrates these indexes transparently during migration
BitMap Index: HANA migrates these indexes transparently during migration
CONCLUSION: The author this this is a very high FUDsy claim by Oracle as the statement has zero


FUD 2: Exalytics is only a database change whereas HANA is an appliance and dB change. As Exalytics is one change and HANA two it represents a lower risk for customers.
FACT 2: Exalytics is a database and an appliance so just Exalytics so this alone represents 2 points of change = HANA
FACT 2a: Exalytics is only an OLAP accelerator so what you are actually doing is replacing BW Accelrator with Exadata - not a good idea
FACT 2b: Exalytics will probably need Exadata as the underlying database in BW so that is still another database and represents change 3
FACT 2c: Exadata will probably require Times10 for Data load optimization so that is still another change and represent change 4
CONCLUSION: This is a high FUDsy statement as the total solution from Oracle will require far more change and exchange points than HANA


FUD 3: As Exalytics is Oracle to Oracle migration customers get higher data quality after migration
FACT 3: Data quality is compromised (BI Valuenomics 2010) at each point of data exchange and data change. As exemplified above the Oracle solution exchanges data, for BI analytics, between servers, applications, databases and appliances each is a possible data quality risk. HANA on the other side is designed as an all encompassing database with transforms, calculations, accelerated loads, accelerated queries, master data mergers, field selections, etc is done in one single database.
FACT 3a> It is critical to realize that standing up an Exalytics, Exadata, TimesTen databases and applications cannot be a trivial undertaking. There are multiple technologies, moving parts, database limitations and each one of these will need to be installed, harmonized, configured and maintained
CONCLUSION: This is a very high FUDsy statement based on the fact that data quality can be compromised at each point of data exchange, transformation and change. These numbers are many folds higher in the Oracle total solution than in HANA


FUD 4: For companies with very large number of records that require a full table scan, Exalytics has a special tool called 'SmartScan' that solves this problem. In HANA this will be a real problem
FACT 4: To start with a Full table scan is a bad design on a legacy RDBMS database. Imagine if you have a Cartesian product from two tables of a billion records each  and you conduct a full table scan for each record.
FACT 4a: Full table scans are a dilemma o the RDBMS databases . All Oracle is doing here is trying to spin one of their their fundamental shortcomings and creating a FUDsy message of something magical with still another application 'SMartScan'
FACT 4b: SmartScan are simply memory indices that are created on the Exadaa Storage server by the Exadata application. They are In-Memory, min/max indexes based on data artificially pushed into column format. While SmartScan is calculating its indexing the actual database actually sits virtually hibernating waiting for SmartScan to finish its transformations.
FACT 4c: In a traditional RDBMS database much of the space is taken by a viral growth of indexes. In some databases close to half the allocated space was occupied by indexes. HANA persists data differently , so disregards all indexes. In fact o not even consider the space occupied by indexes for HANA migration sizing.
CONCLUSION: This is a very high FUDsy statement based on the fact that full data scan is a RDBMS problem that is being FUDized as a solution by adding still another tool and probably an additional license.


I will keep this one active and communicate them as and when I see another FUDtastic statement 

1 comment:

  1. That's sales. Don't worry.

    Have you ever been to an IBM presentation. That's something special. Every generation do have their tools :)

    On the full table scan. It's more intuitive. Once you are concerned with time dependent data it can be beneficial to join starting with the fact table. In traditional BW and snow-flake in rare cases.

    A BW7 on fast hardware is hard to beat already and I think HANA must be lightning fast.

    Oracle is simply a decade behind the analyst's demands and light years away from a customizing driven approach. I do have the impression Oracle as well as IBM are aiming at employing their ECO system, Oracle developer especially.

    Analytic applications in the traditional sense of the 90s are simply dead.

    They all missed the BW after 2k. IT organizations loved their Cognos, Hyperion ... Since BW7 they are all more or less 'dead'. I think with hana you can also solve some problems left years ago in the area of logistics. (Key figures based on counts on dimensions for example)- That's something Analysis Services did very well these day.


    It takes a while until SAP ships something but when they start performing that's a German solution that simply does the job.

    BTW: Did you ever give TABLEAU a try? I like it for the desktop. Pretty amazing. A different business case than Oracle or HANA.

    ReplyDelete